GNOME Bugzilla – Bug 480754
Extend f-spot dbus interface
Last modified: 2007-12-06 19:16:46 UTC
It would be useful to f-spot to expose more functionality over dbus. That way other applications (like conduit) can use that api to manipulate the f-spot photo database. The attached patch implements that behaviour by exposing two dbus objects: 1. a TagRemoteControl to manipulate the tag part of the f-spot db 2. a PhotoRemoteControl to manipulate the photo part Both have methods to query for information (about tags & photos), to insert new items into the f-spot database or to remove already existing objects. Note: the new objects are only created when running in normal f-spot mode
Created attachment 96260 [details] [review] Implement additional dbus objects
Created attachment 96261 [details] Python script to test dbus functionality This quick and dirty script can be used to test dbus api a bit
Looks good. Is it possible that a dbus signal could be emitted when a photo is added to the DB, so that Conduit could perform an always-up-to-date sync? If you have performance concerns about the DBus load when importing hundreds or thousands of photos then dont worry too much as conduit could work around it. aside: i.e. in conduit this would be dp.emit_change_detected() John
Actually I suppose that a similar signal would also be needed when a photo is modified of tagged, etc.
Just been playing with this, and perhaps this is a FSpot bug, but is the primary key on the DB Unique and auto-increment? I ask because if an id can not be guaranteed to be unique between calls then Conduit will have to use another attribute for identifying files to sync, such as the filename (which will require another call to FSpot dbus for each photo = bad) The problem is this add foo.jpg => foo.jpg has id 1 add bar.jpg => bar.jpg has id2 delete bar.jpg add baz.jpg => baz.jpg has id2 :-( baz.jpg should get id3 not id2, otherwise it takes an extra dbus call to determine that bar.jpg has been deleted and baz.jpg has been added as conduit must check the filename to test if it is the same as last time. As i mentioned, this adds and extra DBus call for each photo
(In reply to comment #5) > Just been playing with this, and perhaps this is a FSpot bug, but is the > primary key on the DB Unique and auto-increment? The id field on the photos table is created like this: id INTEGER PRIMARY KEY NOT NULL Following the sqlite documentation this means that the id "is unique among all rows in the same table" and "is one larger than the largest ROWID in the table prior to the insert". So this means that if you delete the photo with the highest id, and then import a new photo, they will end up with the same id. As long as you remove photos with a lower id, you are fine. To prevent this the id column could be created using id INTEGER PRIMARY KEY NOT NULL AUTOINCREMENT This would mean that the id is unique under all circumstances and that the same id will not be re-used ever again. I vote for introducing autoincrement, as this ensure id uniqueness. This might increase the id a bit faster, but i don't think that's a problem, as it is more likely that a user removes images "below" the highest id than the highest id itself.
More info: http://www.sqlite.org/autoinc.html
Created attachment 96310 [details] [review] Extend f-spot dbus interface Same as previous version, except that this one also migrates the photos table to use autoincrement
Created attachment 96315 [details] [review] Add a Version() call to DBus interface Adds Version() to FSpot.Core dbus interface. Should be applied after the main dbus patch
I'd love to see GUID's associated with photos and versions (and used to establish that relationship) and stored in the xmp etc. as opposed to dealing with the transitory id directly.
(In reply to comment #10) > I'd love to see GUID's associated with photos and versions (and used to > establish that relationship) and stored in the xmp etc. as opposed to dealing > with the transitory id directly. > Larry, i'm don't really understand what you're saying. Should we expose the photo versions instead of the photo objects themselves? And use the photo id - version combination? Or is your comment about the autoincrement stuff?
Created attachment 96788 [details] [review] Extend dbus interface; improved version Slightly improved version of dbus extension: * raise exceptions instead of returning failure indicating values * include version method to core interface * fire dbus specific events for photo additions or removals
Created attachment 97257 [details] [review] Extend dbus interface; now with read only mode New version of the patch; there now is a preference added (accessible via preferences dialog) to allow the dbus api to come up in readonly mode; this is the default behaviour.
Created attachment 97498 [details] [review] Extend dbus interface; now with read only mode Same as before, but IsReadOnly is a method now, dbus-python seems to like that better
The patch is committed in revision 3476; thanks Stephane for reviewing this.