EDIT: Actually, how hard _would_ it be to make screen work with x-forwarding? This is unfortunately outside the area of my EEly expertise.
This enables another notable feature of the Sun Ray, portable sessions: a user can go from one Sun Ray to another and continue their work without closing any programs. With a smartcard, all the user has to do is slip in the card, enter their password when prompted, and they will be presented with their session.
Of course, obvious flaw in the model: If you need mobility, you have a laptop. If you don't, well, the feature isn't really that useful. Also, the Solaris 9 user experience leaves something to be desired, but that's not the Sun Rays fault. (I compiled almost everything from source in my homedir.)
Really cool thing: It is (was?) possible to configure a multi-monitor setup with several Rays, purely over the network.
The easiest way to implement this "vision" would be to host your session on a cloud-based server, and then use VNC from whatever machine you're at to connect to it.
It would require some tweaking of typical accessing machine's operating systems and so on, to drop you straight into a login dialog for a VNC client, and would of course assume that bandwidth isn't expensive, but it would be very simple.
Since your (default, at least) VNC server address would be constant for you, it could of course be trivially remembered by the various client machines, so all you do is log in and there you are.
I think you'll see it come together from two separate places.
1. Standardization of browser event subscription by a remote host. This might happen via an HTML5+ ecmascript API in which scripts register user event callbacks. Think ACPI through JS. This requires aware applications but Google could make it a de facto standard.
2. In-browser identity management and single sign-on. This is necessary to achieve the seamless re-authentication to services. This may be in the form of a browser plugin that, like regularfry says, saves to cloud storage. I think we'll see browsers grow web-aware state APIs in the next 5 years as local and remote get blurrier and blurrier.
What do you think?
Browsers should be managing this kind of continuous (or as I like to say, persistent) state for us. They should also be capable of a lot of the social interaction some companies have chased after - sharing certain information with friends, syncing things up (simple app idea: sync up youtube across multiple browsers so you can fill your house with music simply by having a net connection), and likely other things as well.
I would suggest that people work toward building these browsers of the future, but such an undertaking would be monumental, and as you noted, Google has a pretty strong lock on this corner of the tech world.
Basically, it synchronises your saved passwords, browsing history, and open tabs between different machines with Sync installed. If you use Firefox Mobile (née Fennec), you can open a tab from your desktop machine on your mobile device, and vice-versa. Mozilla have even announced an iPhone client that (presumably) launches Safari instead of Firefox, but still gives you access to your open tabs and history:
http://blog.mozilla.com/blog/2010/05/26/firefox-home-coming-...
Can you imagine the support tickets? "Outlook doesn't look right on my cell phone." "I can't swipe in iBooks on my Eee." It's the ultimate epitome of the problem with Android's fracturing across devices (which is, thankfully, not too bad).
The obvious ones are VNC and GNU Screen, but the fundamental problem with these is that the client is too dumb and can't adapt to different form factors. The client needs to talk to the server in much higher level, more abstract terms.
This is where REST comes in. If you can sync URIs between devices, then REpresentations of application States can be Transferred to and from each device, and you should be able to seamlessly move sessions around, in theory.
In practice, not all web apps are properly RESTful and so won't work this way, though the landscape is certainly improving in this regard.
Also, not all apps are web apps, nor should they be. But a URI doesn't have to be a web page. I believe, and correct me if I'm wrong, that Android provides some sort of facility for native applications to intercept and handle arbitrary URIs. This could be used, for example, by a native Twitter client to show the equivalent native interface for a URI on the Twitter site.
This way I can use my netbook on the road and still have the quadcore gpu, multiple vm's and the open tabs in firefox.
