It sounds like an ambitious idea, but Mozilla has had their "Firefox Sync" product (née Weave) available as a developer release for some time now:

https://mozillalabs.com/sync/

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-...

Sun kind of did this in 1999 with the Sun Ray (http://en.wikipedia.org/wiki/Sun_Ray)

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.

Not just "kind of". They had a bunch of Sun Rays at my University, and this worked great. Just pull out your card, and plug it in somewhere else, and it'd be like your session had just gone on screensaver.

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.

A Firefox plugin to save-state-to-Dropbox (or something) would address a lot of this. Would that I had the addon-fu to attempt it...

Indeed. As would 'sync tabs', in the same vein as Chrome's 'sync bookmarks'.

The Xmarks plugin has the option to sync tabs, although I haven't used it myself.

I see this as problematic. Throw in different screen sizes, different input methods, and different operating systems, and what do you get? Maddening chaos for application developers, meaning it wouldn't be supported.

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).

Given the title, I expected satire. I can't see it. Am I missing something?

Possibly the author (who I haven't researched and didn't recognize) failed to realize the connotations of the "A modest proposal" meme.

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.

This exists already, in a few different forms.

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.

Is he being satirical? I think it sounds like a good idea.

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?

It could be argued that the browser itself is ripe to undergo a rather radical change over the next few years. Google's strategy here is to fatten the browser so that it becomes the Operating System, and then offer web-aware apps through that environment. Another strategy would be to thin the browser down and integrate it more strongly into the OS.

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.

My friends and I began working on building a service which provides this functionality not long ago -- we planned to offer an application service available through the web browser, but after Google announced the Chrome Web Store, we may pivot to build applications suited toward that arena. There's a lot of ways to use this, and we can't wait to show them to the world.

screen -R

The fact that this is still sometimes the most practical solution is amazing to me. I was trying to get an IRC client for my Droid so I could talk to my friends during a road trip I was on, but the connectivity was poor enough that any local client would leave gaps in the channel logs whenever I was out of service. After searching a bit for something that would hold my message buffer server-side, I ended up just SSHing into my VPS and running irssi through screen.

Most of the productive stuff we do with computers is still all about text. Our computers are replacing our TVs though.

That's what I've been using for all my IMing for the last Month or so and I'm loving it. If only it worked as well for web browing...

EDIT: Actually, how hard _would_ it be to make screen work with x-forwarding? This is unfortunately outside the area of my EEly expertise.

GNU screen, the most convenient approach to persistent, "distributed" personal computing :-)

Well, I connect to my workstation on my laptop with remote desktop.

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.

Literary unsavviness aside, this is definitely the future of computing, maybe not in 2 years but not far after... All that's needed is good execution.