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 :-) > 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 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? Good luck with that, and please try not to reinvent too many wheels :-) Sven -- __ _ _ __ __ __ / _` || ' \ \ \ / http://www.svenutcke.de/ \__, ||_|_|_|/_\_\ http://www.dr-utcke.de/ |___/ Key fingerprint = 6F F8 55 1C F9 E3 A8 F7 09 DF F7 2C 25 0C 54 53 _______________________________________________ f-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
