[Shotwell] Features for Shotwell 0.6

[Ingo Lütkebohle]

Hi Adam,

Am 05.04.2010 16:44, schrieb Adam Dingle:
> - a plugin-based API where Shotwell dynamically loads plugins at startup (like 
> gedit or GIMP).
> 
> - a shared libary (libshotwell) which any application can use to interact with 
> the photo database.
> 
> - a D-BUS or REST-based API which allows external programs to interact with the 
> running Shotwell instance.

I would also add that, irrespective of the means of communication, there
are two different extension choices:

 * A "plug-in" system suggests that Shotwell is enhanced, i.e. through
new menu items or dialogs. It is not important for that whether the
plug-ins run in process or not.
 * In contrast, a "service" model looks basically at "other programs
accessing the same database in a coherent manner".

Historically, your first option has mostly been used to achieve choice 1
and this is likely the easiest way, due to the ease of adding API for
providing a GUI within another program.

> It's true that a disadvantage of plugins is that menus can become cluttered if 
> the user loads lots of plugins. Of the other approaches, I see some advantages 
> of a shared library over D-BUS/REST as a means of providing database access. In 
> particular, with a shared libary, external programs can interact with the 
> database even if Shotwell isn't running.

That is true, but could also be achieved through a daemon model.

> With a shared library, we also wouldn't 
> need to concern ourselves with serialization via D-BUS or REST: external 
> programs could interact with the database using the same calls which Shotwell 
> itself for database access.

Also true. Hpwever, at least with REST, if you're clever, you can
minimize that quite a bit. Think of HTTP's four basic operations (GET,
POST, PUT, DELETE) and one or two content types (images/metadata). After
that, adding URIs for different functions is much less work.

> I think it's safe to say that none of the above will happen for Shotwell 0.6 
> (tentatively planned for June) but we can consider all of the above for future 
> releases.

great to know, thanks :-)

cheers, Ingo