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 > _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list