mån 2011-03-28 klockan 13:27 +0200 skrev Sven Utcke: > Hello Simon, > > > The synchronization must: > > * support synchronization of all current metadata > > * be flexible enough to allow future additions of data in > > a backwards compatible way > > * Support conflict detection and resolution > > Sounds like Unison to me, with a specialised diff/merge for sqlite3 > files. Well, making sure no F-Spot is running before calling it might > be a good idea too, or you might be trying to hit a moving target :-) >
I looked at Unison... initially it seems like a nice tool. Though to use it I would need to figure out how to integrate it with F-Spot in a good way. It might be worth it to save the trouble of implementing change- and conflict detection algorithms :) > > It would also be nice if it could > > * support additional data that might be added by addins > > Not sure about that. > > > * support lightweight transfer of on-file metadata changes > > Unison again (which uses the rsync algorithm). I'm definitely going to look more at Unison :) > > > I will implement this as a remote repository of the F-Spot data that > > support pushing and pulling data to/from the repository and also > > some extra functionality to simplify synchronization. To > > communicate with the server an XML-based REST api will be used. XML > > makes it easy to integrate XMP metadata, which I believe will cover > > much of the per-image data. An addin to F-Spot keeps the local > > F-Spot database up to date with the server so that F-Spot can > > continue to use the already existing queries. > > Would it be possible for two people to work on the same dataset > concurrently? > That's the plan. Basically, those algorithms must be implemented anyway to make it possible to work offline. > Good luck with that, and please try not to reinvent too many wheels > :-) > > Sven -- Simon Lindgren _______________________________________________ f-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
