Re: GNOME online desktop - (some of the possible) next steps

["John Stowers" <john stowers lists gmail com>]

Hey,

Thought I would weigh in with the state of Conduit, what it can do,
and my roadmap of sorts. At the bottom is a little discussion of .Mac
and other things.

Firstly, what Conduit can do today
Photo sync with F-spot, Picasaweb, Flickr, Smugmug
File Sync with Box.net, gnomevfs volumes
Contact Sync, iPod, gnomevfs volumes via VCards

Basically ATM I am working on
Better OO DBus interface following
SyncML support (a DBus controlled syncml deamon)

> And more stuff, volunteers also welcome:
>
>   - investigate how HTTP state of browser can be used by any app
>
>   - lots of BigBoard productization/polish stuff to make it more
>     usable
>
>   - hack on AbiWord, F-Spot, other desktop apps to use the info from
>     the server in useful ways

Could you explain a little more on this point.

For example Conduit currently does photo sync for F-Spot to the above
mentioned sites. It also has various other ways to get photos into
these services, behaving nicely in situations where a photo you upload
once using F-Spot you then try and upload again from a folder (i.e. it
skips it or updates the remote copy).

In the Upload sense I don't yet see the role of
mugshot/online.gnome.org in this other than storing the notion of "my
Flickr username is foo and my password is bar". This has benefits for
Conduit because I can then skip that whole configuration step, instead
going ahead and pulling that data down from o.g.o. Unless you are
suggesting that a user uploads his photos to o.g.o which then pushes
them out to $OTHER_SITES (which i think is a terrible idea, o.g.o
servers doing 2x the data transfer to put a photo on Flickr for
example)

>   - integrate online photo sites into gnome background properties
>     and screen saver (choose a flickr photo for your background, etc.)

To continue from above. Now in the download sense I see o.g.o has
benefits. Acting as a central store of knowledge like "User has Flickr
friends called foo and bar". In this case if (for example) a user
wanted to Sync his/her friends Flickr photos with their iPod then
Conduit could ask o.g.o for their friends user ids which would avoid
the user having to explicitly tell conduit who their friends are. This
is good.

If you are thinking of data flowing differently to what I describe
then please explain.

>   - modify mugshot.org/applications (to become
>     online.gnome.org/applications) to support web apps
>
>   - store encrypted gnome-keyring on the server
>
>   - facebook application that merges your Mugshot stacker
>     into the facebook event feed

While I remember it have you seen
http://wiki.developers.facebook.com/index.php/Open_Source_Applications_Terms_Of_Service_Problem

To some extent this is why I have not yet commit ed the Facebook photo
uploader for Conduit I have been working on.

>   - right now the default online desktop config has google calendar
>     in big board and evo calendar attached to gnome-panel clock,
>     fix this
>
>   - make online.gnome.org and mugshot.org work as OpenID providers

Application Preferences,
Conduit had application preference synchronization a while ago but I
took it out to work on other things and because other than a gnomevfs
volume there was no way to get it between a user's two computers.

If you are going to run a Daemon to push non contact data to o.g.o
then consider using Conduit. The architecture these days is pretty
good.

If that suggestion is unacceptable then why not solve this problem
lower in the stack like e-d-s-sync is. What about a gconf-sync that
does the same thing on a users gconf preferemces (or an opt-in subset
of them). As for dot files in a users home directory, isnt that a
broken non GNOME way to store application prefs anyway?

>   - stuff I forgot
>
> Our thought in the office here is to somewhat focus on the server side
> since it's a little bit scary and others would take a long time to ramp
> up on it. So if there's server-side stuff you need for the client-side
> feature you want to hack on, let us know.

Discussion of .Mac and its relevance.
One of the major architectural difference between OpenSync, Conduit
and .Mac is that .Mac stores it 'truth' db on the .Mac server. The
truth DB is basically object foo is related to object bar (i.e. this
photo has been uploaded to flickr with this id).

This is good for a variety of reasons, mostly that it makes it easier
to solve situations like User A trying to sync/upload the same photo
to flickr from two computers (sorry to once again use a Flickr
example...). Currently Conduit and OpenSync get around this in various
ways, basically using some sort of 'Slow Sync' mode to pull down every
object from both sides and compare each one.

What I would love to have is the ability to do this within the mugshot
data model. Attaching the concept of two items being related to one
another. Maybe for performance reasons I would pull the truth db down
prior to a sync, then push it back to o.g.o at the end. Maybe i would
do a http query for each local piece of data I do something with (i.e.
do I know you, have you been uploaded before?, etc). I guess those
things will depend on the implemetation of the o.g.o server but Im
just trying to explain my needs from Conduits perspective.

Anyway to summarise, from myself and Conduits needs
o.g.o is good when
* Stores a users credentials on various web services
* Stores a users relationships on various web services
* Stores some concept of what data a user has on that webservice

John

> Havoc
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list