Re: Online Desktop integration ideas

[Havoc Pennington <hp redhat com>]

Luis Villa wrote:
> On 7/22/07, Alexander Boström <abo kth se> wrote:
> >  sön 2007-07-22 klockan 10:26 -0400 skrev Havoc Pennington:
> >
> >
> >  I think when possible, it can be nicer to store stuff online via the
> > online app that edits it - e.g. store photos on Flickr, rather than
> > store photos in a remote filesystem or something.
> >
> >
> >  I thought OD really wasn't at all about moving the home directory to a
> > server, but about making the desktop integrate nicely with the services that
> > are already out there.
>
> +1 for clarification on the motives/interest there.

Hmm, well in my slides the mission-statement thingy was:

>   The perfect window to the Internet: integrated with all your favorite 
>   online apps, secure and virus­-free, simple to set up and zero­
>   maintenance thereafter.

Integration with online apps is more part of "window to the Internet" 
while syncing a few of your homedir files is more the zero maintenance part.

If we aim for zero or low maintenance, one goal might be no manual 
backup/restore headaches.

Using existing web-based services avoids backup problems for those 
services' data, and also has a number of other user experience benefits 
(e.g. people are used to those services, their friends are on them, and 
they can get to them via web-based UIs on any platform). In this case 
'window to the internet' and 'zero maintenance' are solved in a single step.

But there are loose ends like .emacs that don't have a nice service 
associated with them, and if we can mop up these loose ends we can get a 
closer-to-ideal desktop feeling and better dogfood the ideal we're 
trying to create.

I think we'd be off the rails if we started trying to implement 
"online-ness" primarily via homedir syncing. To me, file copying is more 
of a hack to mop up some of the old apps.

One way to think about it, a product form of online desktop might be an 
internet appliance, or a desktop that's managed by a service provider 
rather than a local IT department. In these products, you don't want to 
deal with user data that lives only in a local homedir and nowhere else.

Obviously these products would not have .emacs, the idea of copying 
.emacs is to help us dogfood the user experience - make the developer 
workstation setup more like the ideal product setup.

For example, it would be a shame if the "guest account" feature were 
really slick for end users who only had online apps, but wasn't useful 
for developers or the many sysadmins that use Fedora and Ubuntu.

Don't get me wrong, I don't want to make dealing with .emacs and .ssh 
the primary focus (and it hasn't been so far). I think it's useful 
though. We'll see I guess, if someone tries to code it.

Havoc