Alt, A modest proposal: the Continuous Client
By Joshua Topolsky 
posted May 26th 2010 5:22PM
posted May 26th 2010 5:22PM
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.
I'm sure this is already being worked on by several companies. It almost seems like a stepping stone to the single, all-purpose device of the future
@stubby boardman
Very true. And y'all over here JUST thought of it?! That's scary. I thought it would've been picked up during Ballmer's 3 Screens propaganda.
@stubby boardman
But Thanks, JT, for spelling it out! Hopefully they'll get moving on it ASAP!
@stubby boardman
The idea isn't that new. But I think the answer that's being worked on right now (mostly by Google) isn't mentioned in this article. Google is moving more and more applications to the web. If you envision a world where all applications are on the web, then the Continuous Client could just consist of syncing opened tabs. The Chrome browser already lets you sync bookmarks, settings and themes, active tabs would just be a slight step from there. Chrome OS would obviously do this as well and I'm sure it wouldn't be too hard to include Android in this as well.
Wouldn't that be an acceptable and realistic solution, Josh?
@stubby boardman
Sounds like the path that Google may be on. The whole "push to phone" button in Chrome, for example. Obviously there is a lot more to it than that, but it's a step in the right direction.
@stubby boardman
Interesting idea but it poses some huge challenges for sites like this. If I'm browsing page 3 and I want to continue where I left off later page 3's content may now be on page 4 or 5. However this should be simple enough within an article since the URLs are distinct.
@BrightSilence Anything but Chrome (in its current form)! Android would be nice.
I think the answer is Continuous Client as a service, but the service must be standardized across platforms and implementations, not 'bastardized' by each company..
@BrightSilence
Good luck trying to get Apple to allow session syncing between an iPad and your Chrome browser. :-P
I kid, but not really...otherwise I agree with you, Google has made some steps towards this.
@stubby boardman
@Joshua Topolsky
One day, we will look back on this post and mock our past-selves.
We will have systems that do this and so much unbelievably more in ways I can't even describe because it hasn't become a problem yet, let alone necessitated a solution.
It will be just like "Thread 500" - one of my fave reads..
@stubby boardman
"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."
How about a device the size of a smartphone that docks inside a tablet and or a laptop. Moving the session from smaller screen to larger screen and back without a hiccup. No need for any service, or OS.
@BrightSilence It almost already is, with Froyo allowing you to push apps and such directly to your phone OTA.
@stubby boardman Better yet, just get a large server that wirelessly computes for all of our devices. If we do that, we could have an ipad that is just a screen with a wireless card and massive battery, and our desktop could just be a screen with a keyboard. Probably wouldn't work outside of our home over 3g or anything, but in a large office I could see it being extremely practical. This way, it could just save our user name and have it always on the server, and just let us log into the same account no matter the device, not to mention it wouldn't limit the computing power of mobile devices. Not very practical for gamers though...
@stubby boardman Microsoft calls it a cloud, but they want to push it on step further and have everything on a remote server... from apps, to data, and customizations (personally i dont like that because it moves licensing to a much more draconian place). But they also have live accounts that could evolve into making you desktop into the server.
@stubby boardman
I'm pretty sure this is called X-Windows.
@stubby boardman
Yup, check out this live demo of iPhone to PC session handoff implemented by Cisco WebEx: http://bit.ly/c67BMQ
@M I agree, but without docks. Everything should be wireless.
Wow, Thats a great idea.
I'll try some ideas I have for this. Thanks for a great project idea
@Girish
I'm diggin the green engadget too.
@Girish
how about we just cut the bullshit and stick overclocked i7's in everything from phones to microwaves. "now i can encode hd video on the go".
i would love this. The ability to switch on the go without missing a beat.
Sounds like what you want is GNU Screen for the rest of the world. I agree and that would be awesome
http://www.gnu.org/software/screen/
@taylorh This is what I came here to say as well. GNU Screen on a colocated server and SSH clients on every device/computer I own performs exactly this task for me.
@taylorh
There's also something similar for graphical applications called "xmove"
http://en.wikipedia.org/wiki/Xmove
It's worth noting, (mostly because you didn't), that iTunes does precisely what you are talking about. Watching media on any apple device is synced up in exactly this way.
@Gazoobee No, it really isn't. With iTunes, you have to sync up all your devices with your desktop/laptop. There is no continuity across devices. Stop trolling.
@chaddledee
A closer parallel could be drawn with Kindle I think, right? Doesn't it sync what page you're on, etc across all Kindle apps (the actual device, iPhone, etc)? I don't know for sure because I don't use it, but that's how I thought it worked.
@mr88 Yes, that's exactly what the Kindle does. I have a Kindle DX at home, the app on my iPhone and both my office computer and personal laptop. I open the app on my phone and it takes a few seconds to sync the last place I was on the book. I can even turn off all 3 devices at once and still be able to fire one up and read from where I left off.
Another similar function of this is what Joshua referred to as the 'eject button' that gets your work area ready to load on another device. When I'm done reading on my iPhone, I go back to the home screen of the Kindle app and it immediately starts to sync my updated page with the Kindle cloud at Amazon. It's simply genius.
Ah, aren't you basically describing VNC? VNC was developed in the 90's by Olivetti Research Laboratory. I believe it's original use was geared towards medical personnel, allowing them to roam around a hospital and bring up their "desktop" instantly on any PC/terminal.
Sure, it was not built around the limited real-estate of a modern mobile device, although there are VNC clients for many mobile platforms. However, a bit of tweaking may be all that's necessary to satisfy your desire to have a continuous client.
@Spiny Norman I use VNC all the time, but it's not really what I'm looking for, and I don't think that's what Josh is after. I just want a service that saves state across multiple platforms -- I'm here in my Twitter timeline, I have these tabs open, I'm drafting this email -- so that when I switch devices it all comes with me, but in a device and application specific way. Using VNC on my phone to click a button on my 27-inch iMac screen is one thing, but I can't get work done that way.
@Spiny Norman VNC is basically just using other devices acting as dumb terminals to access your own desktop or whatever. it's definitely not what josh is talking about..
@cassio
I understand that VNC has its limitations. I don't believe there was much development done beyond the 90's. However, with a bit of work I believe it might work.
At a minimum, you'd need a profile for each type of device, and a mapping for basic controls.
@Nilay Patel: The advantage of something like VNC or RDP is the application independence. When I used to be a mobile IT worker, my "desktop" was a session on our Windows Terminal Server. I could connect to it from any device with an IP stack, a VPN client, and an RDP client. I was never chained to a particular desktop or laptop.
That was more than 10 years ago. Thin client computing did not catch on for mobile users back then because wireless connectivity was not fast enough nor ubiquitous enough.
I believe we are almost there now. Handheld devices have the necessary CPU and display prowess now. Always-on network access is fast enough and reliable enough. True mobile computing as described in the article is on the verge of becoming reality. Someone just needs to pull the existing pieces together.
@Spiny Norman
There's also the issue that VNC can be difficult to set up (especially in a secure manner) without a pretty solid knowledge of computer networking. You have to either know your machine's IP at all times, or understand how to set up dynamic DNS. For most setups, port forwarding would also be necessary. While Josh didn't specify, I get the feeling that the ideal implementation of this idea would not require the user to actually understand what's going on behind the scenes.
And as Nilay pointed out, VNC-ing to your computer with anything with a significantly smaller screen requires you to use a full PC-type interface on a device that is less than optimal (to put it mildly). That's why Josh's suggestion is more concerned with the data/content, instead of the exact pixels on the screen.
@Nilay Patel
What you want is already available. For email. It's called IMAP.
It has puzzled me for sometime why I have to endure each device not knowing my rss feed.
For me what you describe is service based, only a little bit above IMAP or facebook knowing what I've done. Now they would know where I was. Almost just a cookie but a "known user" one. Can see a basic API written that websites use. privacy complaints anyone?
The other idea though, sort of like vnc, though I understand it isn't. That would require at the easiest a "lowest common os" approach, meaning we all end up with the mobile phone os spreading up. Most engadget readers seem appaled at the idea, unless it's android.
Reality is though computing as an appliance, the consume and use device is upon us in full force. Dev and server devices won't be doing this continum thing though, for many reasons, for that vnc and it's decendants will be the ongoing solution.
I think Tweetie was working on a sync for the desktop and mobile versions, but who knows if it'll see the light of day after the buyout.
@shaundon I don't remember where I read it, but I think Twitter is working on this functionality as an API, so you are always in the same place no matter which client you use.
Interesting idea, but I think this was kind of the ideas that Google had in mind when they added push into Android. Except you are magically doing it without reloading anything... somehow.
A number of models are possible for this:
1) Foremost is a cloud based strategy since the cloud acts like a centralized store for data and state.
2) Second is proximity based where hand-off occurs in an ad-hoc manner between devices in proximity of each other.
I think #2 should be used when #1 is not available or if both #2 and #1 are available based on the requirements for transferring the state the underlying system (not the app) should figure out which one to use.
@naashak Good idea, but I think we are so close to having cloud everywhere that direct handoff is less likely to succeed. There is also the constant war against hardware layer incompatibility.
iTunes does this with podcasts and videos. If you pause on your desktop, sync and eject your iPod and play the video it will start from where you left off.
Kindle does this too between it's various client via Whispernet.
The route for this is definitely Cloud services syncing. Though I'm not sure I'd always want a sync. I might have my work machine and my iPad and i don't want the same thing on both.
In my opinion, I'm shocked how badly Nokia is lampooned on this site. It is they that are making such a dream a reality with Qt, Maemo/MeeGo, and Symbian. They just recently showed some of that exact thing at the Intel Moblin demo.
Google's ChromeToPhone lets you send a link from your browser to the phone, opening the Android browser as soon as the phone receives it. Not quite the same thing, but Google's moving in the right direction.
@dingus exactly. The send a map from desktop to phone and send a webpage demo from IO was impressive, and right around the corner in Froyo.
Just vietualize the whole client via an intermediate machine. It'll be slow today but fast in x years.
For this you would need to be logged in your own account on shared machines. It would be seamless if everyone had their own PCs, laptops and iPads but sometimes its not the case, and user accounts make a mess. If you could have your own OS version running in parallel with other accounts all synced with everyone else's devices all the time it would be awesome. Great concept.
Well you are getting there. Some examples I can think of are.
1) the Lenovo Skylight pad which syncs essentially all your documents across the Linux and Windows OS.
2) The ability of Steam to carry save games from one computer to another (Although atm its restricted to only a particular OS i.e. Windows to Windows and Mac to Mac)
3) The future(& demonstrated) ability of Xbox 360 games to be played from the TV to your Windows 7 phone.
Unfortunately, it cannot be done without agreeing to standards which in turn are impossible to implement because what is a Saved state for one program cannot be applicable to a saved state for another program so the question is how do you carry states across.
The only obvious solution is to move to the Cloud which IMO is not practical for a bunch of programs and situations. The need is obvious but IMHO the solution is not so clear as you make it out to be.
@arnavdesai I disagree that the saved state is an issue. If the service is built right each vendor can control thir own state definition. Heck, this could be implemented right now on a client-to-client basis using AWS or other cloud provider.
Is that what fennec FireFox and weavesync are trying to achieve? Well the browser page sharing anyway.
@slaming +1
http://blog.mozilla.com/blog/2010/05/26/firefox-home-coming-soon-to-the-iphone/
http://mozillalabs.com/sync/2010/02/05/weave-sync-new-apis-and-resources-for-developers/
The solution that the Echofon twitter client implements is basically a small and simple first step implementation of what you are looking for. It allows for unread tweet sync between my Macs and my iPhone.
@Spiny Norman - you are describing a remote desktop which in turn would require a central "server", doesn't sound like a great solution.