Alt, A modest proposal: the Continuous Client
There is a missing link in our computing experience that has recently been made painfully clear thanks to the current onslaught of highly advanced mobile devices, and I believe the solution to this problem is simple. Allow me to set the stage. Just now, I was reading one of my favorite blogs on my laptop, but I wanted to relocate to my couch, and I wanted to switch to reading on my iPad. Of course, this required starting a new browser session, calling up the web page, and finding my place once again. This same situation now occurs constantly with Twitter (where I'll have to read and re-read timelines depending on whether I'm checking on my phone, laptop, or iPad), Facebook (a mess similar to that of Twitter), and even in my IM sessions (different locations, different conversations, different logs). There is no continuity in my call logs, text messages, or notes when seated with my laptop or desktop, and there is no way in which to continue working on something in an application on two platforms without tremendous effort. Frankly, it's a mess.
The solution, I believe, is something I'm referring to as the Continuous Client.
So what is a Continuous Client you ask? Well the premise is simple: when you leave one device, you pick up your session in exactly the same place on the next device you use. Meaning your IM, Twitter, web browsing, applications, even your windows (given the availability of such a thing on the corresponding platform) appear just as they did on the previous device. The situation I describe above would be obviated by this setup, allowing me to move from my laptop to iPad in a seamless manner which would in no way disrupt the activity I was currently engaged in. This solution seems particularly well suited for desktop to laptop transfers, but allowing for a platform which was rich enough for both PC and mobile devices (hello, Chrome OS), it could very well be carried out through desktops, laptops, tablets, and even mobile phones. Put simply, you are placeshifting your computing experience from one device to the next with no break in your work, timelines, or conversations.
Now a Continuous Client can potentially be three things: the first would be an operating system, the second would be an application available across multiple OSs, and the third would be Continuous Client as a service. An entire OS would obviously be more difficult whip up, while a standalone application would be easier to develop quickly -- a service, on the other hand, might be the real solution in both the short and long term. Regardless, an OS which is currently in existence could very well be ported or evolved into a Continuous Client, as could many applications we use. All of these solutions would heavily rely on the cloud.
Google has been particularly good at creating this experience within their Google Docs suite and Gmail -- allowing for sessions to be started and ended in two different places while keeping the work stationary. Unfortunately, what Google Docs can't do currently is be location aware. There is no way to tell your document that you're leaving from one system and moving to another. In a Continuous Client environment, there could essentially be an "eject button" which would allow you to queue your OS (or app) to "jump" to the next device, places held and all. You would naturally be prompted whenever a new device is opened or switched on to grab your session from the previous device you were working on.
If we were to look at the potential for a Continuous Client as an application, the experience would be largely the same, though obviously there would be limitations to how deep you could go. One of the things which needs to be stressed is that this is not simply about having your data in the cloud -- that isn't much of an issue right now. A Continuous Client would shift your active work from one place to the next: there would be no reloading of applications, web pages, or Twitter clients. In essence, it would "push" your session from device to device.
While someone like Google has a tremendous opportunity to do this with Chrome OS and Android, the ideal execution of this concept would be as a service or layer, meaning almost any application or platform could take advantage of these sessions, as long as each component had a Continuous Client element. A Twitter or IM application or even browser doesn't necessarily have to be built from the same raw materials since they're pulling down content from other sources to begin with -- they just need to be able to receive the signal transmitted from your last session, and bounce it to the next one you start. Think of it as the ultra-productive mutant child of push technology, cloud computing, and open standards.
Developers and OS-makers, when you're ready to get to work on this, you know where to find me.
The solution, I believe, is something I'm referring to as the Continuous Client.
So what is a Continuous Client you ask? Well the premise is simple: when you leave one device, you pick up your session in exactly the same place on the next device you use. Meaning your IM, Twitter, web browsing, applications, even your windows (given the availability of such a thing on the corresponding platform) appear just as they did on the previous device. The situation I describe above would be obviated by this setup, allowing me to move from my laptop to iPad in a seamless manner which would in no way disrupt the activity I was currently engaged in. This solution seems particularly well suited for desktop to laptop transfers, but allowing for a platform which was rich enough for both PC and mobile devices (hello, Chrome OS), it could very well be carried out through desktops, laptops, tablets, and even mobile phones. Put simply, you are placeshifting your computing experience from one device to the next with no break in your work, timelines, or conversations.
Now a Continuous Client can potentially be three things: the first would be an operating system, the second would be an application available across multiple OSs, and the third would be Continuous Client as a service. An entire OS would obviously be more difficult whip up, while a standalone application would be easier to develop quickly -- a service, on the other hand, might be the real solution in both the short and long term. Regardless, an OS which is currently in existence could very well be ported or evolved into a Continuous Client, as could many applications we use. All of these solutions would heavily rely on the cloud.
Google has been particularly good at creating this experience within their Google Docs suite and Gmail -- allowing for sessions to be started and ended in two different places while keeping the work stationary. Unfortunately, what Google Docs can't do currently is be location aware. There is no way to tell your document that you're leaving from one system and moving to another. In a Continuous Client environment, there could essentially be an "eject button" which would allow you to queue your OS (or app) to "jump" to the next device, places held and all. You would naturally be prompted whenever a new device is opened or switched on to grab your session from the previous device you were working on.
If we were to look at the potential for a Continuous Client as an application, the experience would be largely the same, though obviously there would be limitations to how deep you could go. One of the things which needs to be stressed is that this is not simply about having your data in the cloud -- that isn't much of an issue right now. A Continuous Client would shift your active work from one place to the next: there would be no reloading of applications, web pages, or Twitter clients. In essence, it would "push" your session from device to device.
While someone like Google has a tremendous opportunity to do this with Chrome OS and Android, the ideal execution of this concept would be as a service or layer, meaning almost any application or platform could take advantage of these sessions, as long as each component had a Continuous Client element. A Twitter or IM application or even browser doesn't necessarily have to be built from the same raw materials since they're pulling down content from other sources to begin with -- they just need to be able to receive the signal transmitted from your last session, and bounce it to the next one you start. Think of it as the ultra-productive mutant child of push technology, cloud computing, and open standards.
Developers and OS-makers, when you're ready to get to work on this, you know where to find me.






















xmarks works well for web browsing. for those who are unaware it's a browser plugin that syncs your bookmarks to a cloud. it's available for all the major browsers so just bookmark whatever you're looking at and resume from whatever.
videos and music have this neat "time elapsed display" that you can refer to so you know where to resume watching or listening.
To Josh/Nilay:
Ever heard of Google Reader? Twitter feeds in there work really well.
Tabs open etc --> mobile Firefox with Weave.
"There is no way to tell your document that you're leaving from one system and moving to another" -- This makes no sense. Click save. Open Gdocs elsewhere, open file. I don't see the problem.
Wow. I can think of hundreds of times where I've been in this situation.
This can be accomplished nicely with virtualization. Check out the Internet Suspend/Resume project:
http://isr.cs.cmu.edu/
I dig the concept, but it sounds like using remote/cloud desktop already serves this purpose for the always-on world/crowd, though?
I remember being exited back in the days hearing about how QNX Neutrino would (besides saving the Amiga platform) enable you to shift applications and their state to another computer in near realtime. It wasn't a saviour for the Amiga, but I don't know if it delivered on the promise of switching apps from one computer to the other, keeping state. Perhaps someone here knows?
@Josh if Chandra Rathakrishnan is offering you to work on this, you better start running fast ;)
Wasn't that one of the new Froyo features demonstrated last week ? (2nd day keynote)
Nice idea ... but next time, I would be better impressed if you describe an idea before any implementation show of it ...
I think he's just described Chrome OS
Also, I have this feature on my Nexus One, where if I flash a new ROM or buy a new phone, when I sign in all of my data is restored: old apps (Froyo includes data), contacts, calendar, and all of the other cloud-based google services.
And Meego is developed my Intel so you know it's going to be good..
I think I'll "Chrome to Phone" this and finish reading it later...
I'm a bit late to the party… but I've been playing around with this idea for years... IBM has been working on some aspects of this since the late 90's with their pervasive computing. They were doing some cool stuff at the application level I don't know the current state of the project.
You can almost do this now with the OS. The OS becomes a container which preserves state and connections. This could be a VM if you would extend migrations across filesystems. I've seen demos of mp3 streaming off of a VM which was moved while it was up from one piece of hardware to another and the stream never dropped. Currently it requires a common filesystem, but that might be able to be worked around. If the VM would be running something like Lotus Mobile Connect to abstract the network layer you could keep your tcp/ip connections alive while you move across networks. (incidentally the ability to keep ssh sessions open from one wifi hotspot to the next made Lotus Mobile Connect the coolest VPN software I've ever used) The end result would be an OS which is independent of hardware. This is very expensive in terms of processing and storage resources. Every device has to have greater storage than the OS image and enough processing to handle the virtualization.
Plan 9 is potentially a blend of the OS and application level. At the application level every application would need to know how to pass state. This is really complicated because every application needs to know about every possible destination. Apple could probably do something like move your now playing music from one place to another. Google could do the same with their ecosystem, but as soon as you add in additional vendor the only way would be to standardize an API to handle this at the application level. Given the HTML5 Flash battles...
The other extreme is depend on a speedy network connection and access a common system through the proverbial "dumb terminal" ssh, vnc, rdp etc. etc. I think RDP has the ability to now run applications remotely similar to X11 which are two ways of getting more granularity The upshot of this is that your access devices can be really lightweight, except for a kicking network connection.
As I see it the landscape on one axis is ideological battles, open vs. proprietary, one vs the many and is defined by personal choices, you can choose or roll your own tools and adapt the way you work or push for an industry standard/protocol. On the other axis is technical and physical constraints. Even if within a microcosm such as the the Google or Apple ecosystems you're still going to have to solve the technical problems. If we had unlimited storage on every device, we could replicate our data on everything we use and always the same information on every device. The flip side would be to have a great network connection with high bandwidth and low latency so we could depend on accessing our data remotely. The reality is that as long that we have technical constraints from storage and networks, tradeoffs will have to be made.
I wrote a missive a few days ago about a better social media client app:
http://kylecordes.com/2010/better-social-media-client
and one of my gripes was the same thing as in this Engadget post.
Chrome and Froyo were demo'd doing exactly this at IO weren't they?
Sounds like what you want is a sessions manager. I think sun/oracle already has something like this for keeping desktop session states which are restored/accessed via a smart card from any terminal that is connected to the sun servers. Maybe a unified session manager that maintains the session state for every app that wishes to subscribe to the facility will allow this to happen. But this means existing apps would have to be modified to access the session manager.
There is also the consideration for security as well, so a lot of ground work to be covered in terms of a spec before you can launch off into a build.
Why does this post have nothing to do with eating Irish babies as a delicacy?
FAIL.
THIS IS VNC! I know I am not fir first to say that. But I will add on.
I have been working on a "family computing initiative" (FCI) that has a lot in common with this "Continuous Client". Let me explain the FCI. I am tech support for my entire family. Some households in the family are geographically disperse, yet drivable, so there is an expectation that I fix their computer. Most of the time, the fix is far less than than the travel time. (Most of these problems are viruses or malware installs.) My FCI would use a bare-metal virtualization server and their desktop would actually only be the client. I'd set t he Documents folder to be on a network share (possibly another VM, or NAS) and when something went wrong, they could just switch to an alterate VM until I was able to fix it. The only problem is application installs, which have to be repeated, but they can be deferred until there is a problem.
What this shares with the CC is that your immediate device is not the computer doing the computing. You are actually remote. This abstraction allows platform independence at the device level. You can get the VM client for OSX, Linux, Windows. So no matter where you are, what platform you are on, you can do computing. If you're not using VMs, you can use a Citrix or VNC client. But they all accomplish the same abstraction.
The advantage here is there are NO application changes that need to be implemented.
The ONLY disadvantage is streaming video, which kills a network, and particularly a wireless one. For that, you want to do the decoding on the local CPU. Still, for most people, this is ok, as they can always use the local system for videos. You'd keep your important stuff on the VM (Quicken , Quickbooks, Office). What's more is you can use a hack to run video on the local computer by un-associating the media types from the usual player, you can set up an alternate handler that with some configuring, will launch the video locally.
For most people though VNC will work just fine.
Wouldn't this pose some potent security risks? Already logged-in to one or more websites?
Very good idea indeed, since I can't think of a better comment that sounds more intelligent ;-) . So it might be "a modest proposal", but the end result could be "a giant leap forward" when succeeded.
We have something already that is part of what this is proposed, but not exactly, only pieces and fabrics of. Right now in practice, one could use a remote control app to remote (VNC, RDP, or you name it) a particular target, however, it is not universally friendly especially small screen would be scaled down to "hard to see", "hard to maneuver", etc, as these things don't scale well as they are mainly desktop targets that we are used to.
I think if it were some kind of apps or services, it would be really complicated, and not sure when it can become practical. However, what I can see may be more of a adaptable environment that can be "sneakered" about (as in Sneaker Net).
So crudely, think of a Live Boot OS on a stick, and then think of a hibernation like freezing function, and then think of an adaptable OS that can get out of the hibernation but won't crash but instead adapt to the new device that it is plugged in, adapting the device drivers, screen, control etc (even pre-arranged as in "dock / no dock" selector is ok enough), and then work can continue from the frozen moment.
So may be one would need a piece of hardware (a stick) to plug into heterogeneous devices, or one would grab this from the cloud (depending on how much OS and if it really needs to boot a host OS etc), then it is there. With portable apps, Live boot, hibernation, and dynamic device management in recent advances, a total solution of this proposal doesn't seem far fetch.
But if the idea requires a brand new systemic approach, rather than taking already pieces available, then we will be talking about a further future, and it would be harder to imagine.
It's an interesting idea Josh.
You recognized Google Docs and Gmail. But you missed Google Reader. I track 90 blogs with Google reader. It marks read/unread on each one of them. When a blog entry is read, it disappears in Chrome desktop, on my Android phone using the NewsRob RSS reader, and it's gone.
But we could use more, I think.