Federated Identity in your Browser

In this post I am going to discuss the background information that will make a case for Federated Identity Management in Browsers. With the advent of new Browser capabilities, and leveraging the new technologies that will be adopted by Federated Identity specifications, I hope to show how Federated Identity Management can be achieved using Browsers.

Federation of Identity serves to enable portability of Identity information across otherwise autonomous security domains. In other words Federated Identity is about using a single Identity to sign into different web sites (over simplifying a bit here). This is not only about your "username" and "password" but also a about other information that identifies a person like, real name, address, nick name, email etc.

Examples of common Federated Identity usage are, using your Google or Yahoo Account to Log in to other sites like Blogger, Youtube etc. In this case the web site allows authentication via any "Provider" that follows a Federated Identity standard like OpenID eg. This is different from using your Facebook or Twitter Accounts to sign into third Party sites. In the latter case it is called Delegated Identity. In other words the web site you are signing into has delegated authentication to Facebook or Twitter.

The way Federated Identity Log ins work is that, when you visit a Site you are redirected to your Identity Provider, eg. Google. You Log in at your Provider, and also "allow" your provider to provide additional information (your name, email etc), and then you are redirected back to the web site. For one this method is prone to Phishing. If a user inadvertently visits a untrustworthy site, the site could redirect the user to a site that appears to look like the users provider and steal his user name and password.

Another problem is that when you visit a site that supports Federated Identity, you cannot log in to the site just by clicking a button. The site for various reasons will choose to support a selected list of providers from which you have to choose from, leading to what is called Nascarization.

Another problem is that of data portability. Let us say you have your identity, profile and social contacts at Google, and you want to change to Yahoo. There is no way to do that seamlessly as of now.

All this begs the question where is the best place to keep your identity information? With You! That's the obvious answer. And the closest that can get to "You" is your Browser. Unfortunately in the current state of affairs of Federated Identity, the browser only plays the role of via media or broker, between the Identity provider and the web site. If the Browser were to manage your identity you could solve all the three problems above in one fell swoop!

However there are two reasons why browsers do not play a greater role in Federated Identity Management.

1. There is no commonly accepted standard that will allow browser vendors to support this. This would require a specification to allow the browser, identity provider, web sites to speak a "common" language.
2. Another solution would have been to implement browser plug ins. This would still require the common standard but at least we do not have to wait for the browser vendors. But the problem here is developing plug ins for all types of browsers is not easy (at least up to now).

New browser developments like Jetpack from Mozilla Labs allows you to develop browser plug ins very easily using Javascript. Opera Unite is another effort to empower the browser. All browser vendors are moving in the direction of empowering the browser. What all this means that extending your browser to support a Federated Log in standard is going to be trivial.

So what we really need is a "Federated Identity Standard for Browsers". There must be a working group for this at one of the standards bodies like OpenID, Open Web, Kantara etc. I have not seen such a working group yet.

I intend to demonstrate how a simple Federated Identity standard can be implemented using Mozilla Jetpack, and some minor tweaks to existing Federated Identity provider and consumer software, in a future post of mine.

Opera Unite, will I really use it?

Opera has released its new web server in a browser called Opera Unite. This is not a new idea, and the idea of running your own server, is I guess only appealing to geeks. Having said that, it does give the lay user an ability to run some basic services like picture sharing, chat etc from his own PC.

I can't see a killer application from among the ones they have available now. So we have to wait and see what applications developers will come up with.

Also we have to consider why people don't usually run web servers from their PC's. One reason is of cource bandwidth. If you are connected via ADSL or something like that this is a bad idea. You can do some limited stuff with a small group of friends. But nothing for public consumption.

The second problem is discovery. User's may just have temporary IP addresses. Opera solves this by being your proxy server that allows users to connect to your PC. That means you have to sign up for the Opera Unite service. The part I dont like is accepting their terms of service "By uploading Content to Opera’s site, you grant Opera an unrestricted, blah blah blah ....".

So I don't think this is going to replace my blogger, facebook, twitter etc etc accounts. But I can see where I could use it. For one, to delegate my OpenID. So my OpenID could be something like

http://home.mynickname.operaunite.com/openid.

Now before you run and download Opera I would say hang on. I haven't figured how to do the above my self yet. Its 45 mins since I have downloaded Opera. So its not like just editing your "index.html". Looks to me somebody has to do a "OpenID" Opera Unite Service. So my Opera unite OpenID is actually pointing to a Opera Unite Service by adding a "/openid". And he has to upload the service and Opera has to approve it! Or has anybody figured how to edit index.html yet?

But you see, there is potential here. If you have an application that stores your personal profile data and provides it to applications as and when required, we have the beginnings of data portability. But now the problem is to port your data from browser to browser instead of from web site to web site!

Update.

To set up your openid on your browser do the following. You cannot set it on your default home page. After downloading Opera Unite, Install the web server application by clicking on web server tab. Select a folder to be your web server root. eg C:\openid. Click on automatically create index.html file. Set Access control to public and save. Edit the index and add the following in the HEAD part. Change the href's accordingly to point to your provider.

<link rel="openid2.provider" href="http://www.myopenid.com/server"/>

<link rel="openid2.local_id" href="http://myname.myopenid.com"/>

Your OpenID is

http://home.mynickname.operaunite.com/webserver

About Email Addresses and OpenID

Out of the hundreds of millions of OpenID's in the wild today, 99% of them are provided for by Yahoo, Google, MySpace and AOL.

Three of them are email providers and your OpenID is tied to your email address. ie Opening and account at one of them gives you an email address and an OpenID. You can also create a Google account with a non Google email address. Again the OpenID is tied to an email address. So when you are logging in with any of these OpenID's you are in effect logging in with an email account.

This is also true in the case of MySpace even though it is not an email provider. When you login with your MySpace ID you are really logging in with your email address! The MySpace OpenID is also tied to your login email address.

In other words 99% of the OpenID's in the wild are really email addresses masquerading as OpenID's!

Why the need for this masquerading? Because OpenID does not support Email addresses as OpenID's.

And why doesn't OpenID support Email addresses as OpenID's? Given the facts above I cant think of a reason. Can you?

Google Wave is Web 3.0

If you search the web to find out what web 2.0 and 3.0 is, you will find them associated with social aspects. Things like web 2.0 is the "social web" etc. But really each version of the web is a technological leap.

1. Static Web - Web 1.0 was the static web were you had to change the page or reload the page to change its contents.
2. Dynamic Web - Web 2.0 was the dynamic web where you could change the content without changing your browser page. (Google Maps, Ajax Pages).
3. Real time Web - Web 3.0 is the real time web where the content of the page will change in real time as the "author(s)" changes it. Google Wave makes this possible.

Web 2.0, the dynamic web took off in 2004 with Google maps. That is when developers realized that you could change the contents of the page in place, paving the way for Ajax technologies, leading to the social web.

Web 3.0 as described above is a technological leap to the next level. What is interesting is that the very same people who brought about Web 2.0 with Google maps, the brothers, Lars and Jens Rasmussen are also the ones who are behind Google Wave, poised to bring about web 3.0!

Much has already been written about Google Wave, some even skeptical. But most of the articles seem to have missed the fundamental point what Google Wave is all about. What Google Wave has done is to combine the static, dynamic, real time aspects of the web into one composite object called the "Wave".

The Wave Object can be turned into anything the developer wants. It can be turned into a message, blog comment, blog, real time game, tweet, a wall, literally limited only to your imagination. That is why 4000 developers gave it a standing ovation when it was revealed at the Google IO conference. (Standing ovations are an extremely rare occurrence at developer conferences).

Imagine a chat messenger without its text box (where you type), which has only its display area. Now imagine that you can type right into the display area. While you are typing the person you are chatting with can see you typing in real time. Actually if it is a chat conference all the people can type in at the same time and all of them can seen it in real time. You can add, pics video's and other types of content into the display area. You can fork off private conversations. A robot can spell check while all this is happening. The possibilities are endless. And this is what a Google Wave is.

Actually Google Wave sits on top of the same protocol that Google Talk sits on. The Jabber protocol now called XMPP. Google added to this protocol and called it the Wave protocol. It is an Open protocol, anyone can implement this protocol. Google is not keeping anything proprietary here. I can already see an army of developers piling on to this technology and you will see a lot cool stuff coming out within months.

Web 3.0 is here!

About Google Wave and OpenID

I have been looking at Google Wave all day, wow, very very interesting. I have a lot to say but I will make this short by sticking to a couple of points that relate to OpenID.

1) Wave servers are natural OpenID Providers.

The wave protocol sits on top of XMPP and provides for real time communication between users. It is decentralized using the DNS system. Yes this is like OpenID, but the clincher is that you can communicate with the user in real time, as soon as he logs in, and you can verify the user immediately.

2) Wave ID's are natural OpenID's

Wave ID's are really Jabber ID's, look like email addresses and have discovery inherant in the ID.

Eg. If you have a user with wave ID

user@domain.com/waveserver

An OpenID server on the same domain is a natural. The users Wave ID can be his OpenID or it can be

user@domain.com/openidserver

ie. either make the waveid and openid same with xrds discovery or let it be different but point to the openid endpoint.

Any way it really deosn't matter how we do it, what matters is how fast we do it. In the coming months we may see a lot of Wave servers popping up, and if we are ready with support for WaveID's in OpenID we can make a killing.

Other wise the world will move on without us, and this will be another missed opportunity for OpenID. (We already missed it with email addresses).

About Google, Yahoo, Facebook and OpenID

Facebook's support for OpenID may have some worrying prospects for Google, Yahoo, Microsoft  and other major email providers, who would like to be OpenID providers.

Even though everyone says Facebook is now an OpenID RP, I dont agree with that. What Facebook does is only grock the users browser login status, and logs the user in if he has delegated that provider to Facebook. It does not work in many cases and I am not impressed with their implementation, and have said as much in my earlier posts.

So what is it that is going to be of a concern for Google, Yahoo etc?

Whether by design or by accident, what really Facebook has done, is to become an OpenID discovery and delegation provider for all its users. ie. Facebook users can now point to their Openid provider and also indicate their prefered provider in case they have more than one. This is significant. Because the primary problem to be solved for OpenID is discovery and delegation, and Facebook does it for its users.

Now all Facebook has to do is "Switch On" OpenID for Facebook Connect and Voila! You have 250 million users ready with single sign on with Facebook Connect! Throw in 250 million verified email addresses for good measure. (I am not sure all these are verified, but I can say they did verify mine).

If major RP's are not already salivating at the prospects, then they will soon. And this is not really all that bad. If you don't mind Facebook being your centralized mechanism for OpenID discovery and if they are the closest you can get to one, then why not?

Now you know why Google, Yahoo etc need to be concerned. But there are other options. One is the OpenEmailID i have suggested in an earlier post, where the onus on discovery rests with the RP. An even better Option is the WebFinger protocol, where the onus on discovery lies with the email provider for email addresses as identities.

Whatever happens I think it is high time Google, Yahoo etc move ahead with providing discovery for their users. 

The OpenID community must come to a concrete decision on which way they must go and go after their objective as fast as possible.

Facebook support for OpenID. Where?

I am seeing tweets and blog posts about Facebook support for OpenID. I had already suggested in an earlier post that it is going to be a farce. And that is what it exactly is.

You see, I have always maintained that it is impossible for Web site's who base their user identity on email addresses to support OpenID in the current form. And let me list out the problems with the so called Facebook OpenId support.

You can't log in into Facebook with your OpenID unless you are already logged in to another OpenID provider. So if you fire up your browser and go straight to Facebook, sorry!

You cannot create a Facebook account with OpenID. You need to create your Facebook account with your email address, and then log in to your account, and then go to settings, and then link your OpenID account.

Ok, so I decided to link my Google Account. I found that I could not link to my Google Account without me handing over all my Google contacts! In other words Google log in was useless for me.

When I tried to log in with Yahoo and I got the famous Yahoo message "Warning: This website has not confirmed its identity with Yahoo! and might be fraudulent. Do not share any personal information with this website unless you are certain it is legitimate." 

And what I find most embarrassing is the so called "Openid evangelists" going "gaga" over this release. Maybe it is "Facebook" so they better say good things, no matter whatever they do.

Finally, light at the end of the tunnel, for OpenID

In the last few days two new pieces of information come as great news for OpenID. One for the long term, and the other for the short term.

Mozilla Firefox's demonstration of a single sign on with OpenID is testimony to the fact that Browsers will eventually manage the users identity. It may take five years or more to happen.

What is interesting for OpenID is that Browsers will not support proprietary "Connect's". Unless of course the Connect vendor also happens to own the Browser. I am hearing of Twitter Connect and Google Connect. The only "Connect" that will be common to all browsers will be OpenID! I think vendors coming out with their own Connect's, are venturing into something really futile.

The short term good news for OpenID is the webfinger protocol being developed. This will allow for email discovery, paving the way for emails as OpenID's. 

The onus on discovery lies with the email provider which is only natural, and that is the only way it can work. This won't work if non email providers were OP's. Atleast not as equals to the email providers. Non email providers can issue virtual email addresses if they like. But it is not the real thing and they will have to dish out the real email address via SREG or AX.

If Facebook had supported OpenID as an OP with SREG support earlier, me as an OpenID community member would have been hard pressed to support the webfinger protocol. Another way out would have been the centralized discovery mechanism which is not going to happen anytime soon, and Facebook would have been the de facto centralized mechanism until then!

To really make OpenID happen I always believed we need one of the biggies. Ebay or Amazon or someone like that, and these guys won't play without an email address. With the webfinger protocol for email addresses they will definitely come on board. So it becomes very important for the community to move the webfinger protocol fast.

We can now look forward to great times with OpenID!

A Case for OpenEmailID

What if Email addresses were your OpenID's, ie. your OpenEmailID's?

1) As a user you don't have to learn anything new. You just continue to use your email addresses to log in anywhere like you almost always did.

2) Web sites can easily integrate OpenEmailID into their existing log in systems. eg. If Facebook were to implement OpenEmailID's there is really nothing much more it needs to do. If the authenticated OpenEmailID is an existing account thats the users account. If it does not exist it is a new account and Facebook can skip the email verification process, an obvious advantage.

 

Considering the above two points OpenEmailID's are really a no brainer.

Now let us see what is needed to implement this. Turns out we don't need anything more than what we already have!

If a web site requires email address Log in, chances are, 1 out 3 of its users, would be logging in with a Yahoo or Gmail account. These figures are based on email client statistics.  I know you can argue this figure but it doesn't affect the overall argument.

When a web site detects a Yahoo or Gmail address it can not only get the user authenticated from that web site (via OpenID directed identity), it will also get a verified email address of the account. Google already supports this and Yahoo will be supporting this very soon.

In effect this is the Users OpenEmailID. So you already have it for one third of the cases. I expect AOL and Microsoft to support this in the near future. In effect this pretty much covers 80% of the email Users.

In the case of companies or individuals running their own email servers, they can very easily implement an OpenID 2.0 provider service on their domain. The software is available free as Open Source. 

And that's not all. We don't even have to wait for Microsoft, AOL and the other companies. If a User does not have a Yahoo or Gmail account he can get an OpenEmailID for free from a number of Providers even now! He can create a Google account with his own Email address. He can create an OpenID account from one of the OpenID providers like myOpenID or MyVidoop. He can actually create an OpenEmailID at any provider who supports OpenID 2.0 and supplies a verified email address.

So if the user does not have a Yahoo or Google account a web site needs to ask if he has an account with any of the above providers. This has to be done once only, and the web site should save his account preference. And the web site should encourage the user to create an account at one of these sites.

All this can be done very easily, because there is nothing new to implement or invent here. It only requires some concerted effort from the open web community, providers and web sites.

We can very easily achieve the objective of a single sign on. One email one password. One OpenEmailID!

Facebook support for OpenID. Farce or Feign?

You want a Facebook Account? No problem. Just sign up with your OpenID. Yes you will be able to do that in the near future.

So you type in your OpenID URL. (If you have a Google account you will have to type https://www.google.com/accounts/o8/id I presume.) Didn't you want to get notified in your email box every time there is some activity from your friends, or other interests? Great! Please get your email address verified as well.

Good now that we have a Facebook account with our OpenID we can sign in to our account, or Facebook connect, with it. Now wait a minute. I can sign in with either my OpenID or Email address it doesnt matter! So what are you going to choose? Your OpenID or Email address to sign in?

Now the above is for people who have an OpenID, people who are a small minority among a large majority of people who have not even heard of OpenID. The large majority are going to sign up with their email addresses anyway. They are not about to go get themselves an OpenID just to sign up to Facebook.

Is this a farce? Or is it a feigned right hook, before they land the knockout left hook to OpenID?

Once we have all the OpenID officionadoes and users signed up to facebook with their email addresses how about releasing email addresses with Facebook Connect? BAM! Every RP who requires an email address will adopt Facebook connect before adopting OpenID. Because OpenID has still a long way to go as far as OP SREG support goes. Your NASCAR buttons will become a single Facebook Connect button.

I had wanted Facebook to support OpenID as an OP with SREG Email support in an earlier post. These guys dont get it do they? They are virtually sitting on a Gold mine, If only they supported OpenID as an OP. Looks like they are going the Apple way back in the 80's.

The battle lines are drawn. It is Facebook Vs The Rest. We will see if history repeats itself!

OpenID Login Box user Interface released

I have released an OpenID Login box user interface for OpenID. It has a single button, drop down list of OpenID or non OpenID providers, and popup authentication. You can customize the login box to your requirements. You can view and download it by going to the link below. License MIT, GPL.

http://openid.myofiz.com

A lesson from history for Facebook

Back in the mid 80's Apple launched their now popular Apple Mac with the Mac OS. The Mac OS was the first GUI based OS on a personal computer. All Microsoft had was the rickety MSDOS. Microsoft was caught napping. It took Microsoft 10 years (windows 95) to come out with something equivalent to the Mac OS! Their earlier attempts, windows 3.0 and 3.1 being failures.

Working in favor of Microsoft was the fact that MSDOS was open, and could be used by any hardware vendor, while the Mac OS used the proprietary Apple hardware. 

Apple had a choice to make. Open up Mac OS to all hardware vendors or stay proprietary. They chose to stay proprietary, keeping the price of a Mac higher than a equivalent PC. Apple could have really trashed Microsoft if they had opened up Mac OS to the hardware vendors back then.

By the late 80's Apple was inching closer to bankruptcy, while William Gates was laughing all the way to the bank!

Facebook is pretty much faced with the same situation as Apple back then, as far as their Facebook Connect is concerned. They can choose to Open it up by supporting OpenID or stay proprietary. Only this time they have a bunch of contenders to deal with instead of just Microsoft. 

Of cource the circumstances for Facebook are different today. But the underlying strategic mistake made by Apple cannot be missed. I hope Facebook learns from the past, and chooses to support OpenID as an OP, before it is too late.

Need of the Hour for OpenID

Its been 2 weeks now that I have been involved with using OpenID. It all began when I decided to try out OpenID with a small application. Thats when it hit me, that OpenID is not going to "happen" without a verified email address. You can read the rest of it in my last 4 posts. I really want this to happen. 

The remarkable thing about OpenID is that it has all the major players (Google, Yahoo, Facebook etc etc) on their board. I havent seen anything like this happen to a standards body ever. (Correct me if I am wrong). Usually what happens to any web standard is that a rival standard will pop up, splitting the major players more or less equally among them.  This is a testimony to the great work done by the pioneers of OpenID, though things have not yet panned out like they would have wished. 

It is increasingly clear to me, that the solution involves a centralized distribution mechanism which I alluded to in my "Suggestions for OpenID 2.1". Something in the lines of "Personal Discovery Service". 

This can be possible only if all the major players come to an agreement on this. OpenID is in a perfect position to make this happen. This is easier said than done though. All the major players have their own vested interests. 

To begin with, the solution must only consider sharing of basic profile data. Bringing in other social data will only magnify the disagreements. And in any case as far as Openid is concerned its interests should only be in the basic profile. 

If the major players cant come together on this, then the only way out will be to leave out the Openid Providers from the equation and go straight for the Relying Party's. This is not too difficult a problem to solve. Definitely some food for thought. 

Accidentaly deleted some posts

Sorry to those who commented on five of my posts, which i accidentaly deleted while changing labels. I managed to recover four of them. I will try to rewrite the one i could not recover.

I think blogger must remove 'Delete' from the drop down which along with Labels, publish etc. Or for delete they must reconfirm, because you cannot recover a deleted post. I was fortunate to have most of them in my mailbox.

About Facebook, MySpace and OpenID

MySpace recently announced there support for OpenID. The idea here is that MySpace users will be able to log in to third party sites with their MySpace Id's. MySpace users needn't get too exited about it too soon. 

Consider this. A MySpace user would like to log in to her favorite shopping site with her MySpace Account. The shopping site is unlikely to support MySpace Logins. The simple reason being that shopping sites need the email addresses of their authenticated users for various reasons (communicating orders, delivery, new stock etc etc). It doesnt make sence to the shopping site to authenticate using MySpace (An extra step) and then run the user through another email verification process. This will also be true for many other web sites that require their users to login. 

However  MySpace could have made the users email available to the shopping site (Ofcource with the users consent only) via a provision in the OpenID specifications called SREG. So then why didnt MySpace choose to support SREG? 

This is not a problem for MySpace alone. When Facebook decides to support OpenID it will be faced with the same dilemma. It is really a frightening thought for social networking sites to hand over their users email address to a third party. For social networking sites keeping the users bound their network is of primary importance. 

However an equally frightening possibility for social networking sites is to see their users start using Google accounts and Yahoo accounts to log in into third party sites! They could start loosing users in that case too. 

The jury is out on what these guys should do. 

But I am clear on what MySpace should have done. Facebook being the no 1 social networking site can wait this one out a bit more. However MySpace should really have capitalized on this opportunity. Supported SREG and tried to rope in third party sites to support MySpace logins, and tried to build a small advantage over Facebook on this account. 

My 2 Cents to the OpenID Foundation

After my last blog post about OpenID i spent some time on the OpenID forums to see what was going on. The impression I gathered was that there were some genuine efforts to recognize emails as valid OpenID's in the upcoming OpenID 2.1 specifications. Is it a case of too little too late? Time will tell. 

The problem is that emails were never recognized as OpenID's right from the beginning. And that was the kiss of death for OpenID. It is beyond me, living in a world were practically every one uses an email address to log in almost anywhere, a group of well meaning intelligent people can completely miss its importance. Did they think the concept of a url as an identity could be showed down the whole worlds throat? 

So I rolled up my sleeves and went to work on this one, and I posted my solution on the Openid forum. The jist of what I had to say was, "The user MUST be able to authenticate himself with OpenID using his email address if he so chooses to". 

For those of you who are technically oriented you can see my solution suggested to OpenID foundation here.

As a side note myspace has come out with there own version of OpenID support, which is not compatible with the OpenID specification. Another example of vested interests tearing apart the concept of OpenID. I think myspace has really shot itself in its foot this time. They really should have supported directed identity in conformance to OpenID 2.0 and SREG 1.0. They are really on there way to "nospace". 

The death of OpenID

Or atleast the death of open id as we know it.  There is an interesting battle on between the big players of the web, Google, Yahoo, Microsoft, Facebook and what I call the OpenID wannabees (OpenID service providers like myopenid.com, myid.net, verisign etc). 

Lets say you have an email address, and you want to login into any site with it. If every site were to support logins via OpenID 2.0, you could do exactly that. You wouldnt need an OpenID in that case. All you need is your email address! 

Let me show you how it is done with a live example. Go to the link below. Hit on the login button. See the Google Login page. Dont Login. Hit your back button twice and return to this page. 
http://myfeeds.myofiz.com

On the Google page you can login with your google account. But thats not all. If you noticed, you can also create a Google Account if you dont have one, with your own email address, on that very same page. In effect anyone can login into this site with his own email address (which is verified by Google), which need not be a Google email address, it could be any other email address! 

This is all done with OpenID 2.0 without the user ever knowing what his OpenID actually is. He only needs to know his email address. In other words your email address is your OpenID! 

Now the site above was developed by me, and why dont I support login via OpenID? Because I want only people with verified email addresses to log in. With OpenID I am not guaranteed to get a verified email address, I get just an OpenID that does not mean anything for me. 

Now is this the future of Logins into web site. You bet! If Facebook and yahoo are to support this, the same same way like Google, I think all web sites will adopt OpenID login. If they dont, slowly Google Account will become the defacto logging method for every site. 

Now thats what the battle is all about. Web sites are not sure which way to go. And the big players are not sure either. That is why the hesitancy by Facebook, Yahoo and Microsoft. 

In the end given the choice between logging in, with an OpenId or email address, I bet the users are going to use their email addresses. And indeed that will the the death of OpenID as we know it! 

JX 0.3 beta released

I have released JX 0.3 beta http://jx.myofiz.com/

It has a quick start tutorial, examples, download and documentation.

A Feed Viewer application developed using JX, jQuery Object oriented extension

I have developed a example feed viewer application using JX. You have to read my previous posts if you havent. The complete application is done with just one config option to the viewport. You can see the demo here.

For the feed viewer application I had to make a few additions to the JX extension.

Added JX.Panel class which has a jxtype 'panel'. It requires two config objects title: and body:. In the demo the feed list and feed summary boxes are JX.Panels.

Also added some methods to JX.Component.
You can set config option scopeThis: true, and all the handler functions will be called in the this scope of the component.
Added function setLoadIndicator(imagepath, width, height) to component.

I overrode the jQuery trigger function for containers, so that custom events are propagated to all its children. eg. in the demo application the feed links triggers the custom event 'loadfeed' on the viewport, and the feed summary panel binds to the loadfeed event. var viewport is accessible everywhere in the config.

Look at the source code of feedreader.html to see how it is implemented.

You can download the latest jx.js here.

Viewport, Column Container and nested layouts

I have added a viewport class and a column container class to JX. Please read my earlier posts if you havent.

The viewport takes over the document body element. So you can have only one viewport instance in your application. If you have content in your body element the viewport will hide it. So it is unobtrusive also. Clients with no javascript will see your content. Viewport extends JX.Container so lays out its components vertically.

The column container works similar to the container in my previous post except that it lays out its components horizontally. You can set fitWidth: true to one of its components and the component width will expand to the remaining width of the parent minus its sibling widths.

You can nest the containers within each other and create complex layouts. I will create a a border layout using the viewport and column container. The border layout will resize accordingly when you resize your browser. You can see the demo here.

Here is the code to create the border layout.

$(document).ready(function() {
    var viewport = new JX.Viewport({
        css: {padding: '0px', margin: '0px'},
        items: [{
            height: 50,
            css: {backgroundColor: '#aaaaaa', padding: '20px'},
            text: $('#north').text(),
            fitWidth: true
        },{
            jxtype: 'columncontainer',
            fitHeight: true,
            items: [{
                text: $('#east').text(),
                width: 150,
                css: {backgroundColor: '#cccccc', padding: '20px'},
                fitHeight: true
            },{
                text: $('#center').text(),
                fitWidth: true,
                css: {backgroundColor: '#eeeeee', padding: '20px', overflow: 'hidden'},
                fitHeight: true
            },{
                text: $('#west').text(),
                width: 150,
                css: {backgroundColor: '#cccccc', padding: '20px'},
                fitHeight: true
            }]
        },{
            height: 50,
            css: {backgroundColor: '#aaaaaa', padding: '20px'},
            text: $('#south').text(),
            fitWidth: true
        }]
    });
});                               

I have added a new jxtype 'columncontainer' for column containers. Other jxtypes i have added are 'container' and 'component'. You need not specify jxtype if you are creating the component with 'new'. Also default is component ('div').

You can download the latest JX source code here.