[Shotwell] Features for Shotwell 0.6

[Ingo Lütkebohle]

Hi Adam,

sorry for the slow reply.

Am 22.03.2010 02:09, schrieb Adam Dingle:
> By a D-Bus API, do you mean an API that allows other processes to
> control the running Shotwell instance via D-Bus, sending it commands
> which are similar to Shotwell's menu commands (e.g. import, rotate,
> publish and so on)?  And by a REST API, do you mean a similar mechanism
> in which Shotwell will listen for HTTP connections at some port and
> respond to similar commands sent in REST style?

Well, yes and no. I meant an API where Shotwell interacts over
D-BUS/REST, but not to call menu functions but to interact with the
photo database. Things such as "list photo collections" (which might
return events), "give me the image of photo <url>", "give me the
metadata", "store <blob> as the new metadata". Stuff like that. Sort of
a local web-service for photo data-base access. You can see I specified
those ops very REST-like which is because I am most familiar with that
way of working,

In a way, that would make Shotwell a service that makes available my
photos to other apps in a coherent manner so that they, for example,
share the tags or use the same organization for accessing photos. It
would do so in a way that exposes the additional meta-data that Shotwell
has over pure files.

There might be other people working on similar things, e.g. the desktop
search guys.

> Do you see compelling use cases for an external D-Bus API rather than an
> internal plugin-based one?  If so, can you explain them a bit?

I have two. Firstly, I find that with programs such as The GIMP, which
follow the traditional plug-in model, the menus get cluttered immensely.
I do not think that this model scales and for many things, you don't
really need it. I would prefer several small tools that each do a
particular job but share access to a common data collection. Of course,
some people think that multiple tools are also clutter, but I find that
you can aggregate easier than you can split up afterwards.

Secondly, I thought that maybe the REST way of doing things would make
it easier for you guys to get an API fast, because it is much simpler
conceptually. Also, your implementation is encapsulated way more so that
you can kick out an API now, without having to worry about compatibility
later on.

> For tags, captions and descriptions we've been thinking that we'd
> implement import/export via IPTC/XMP metadata.  When Shotwell imports
> photos, it can read this metadata automatically

That sounds cool. I wasn't sure whether IPTC had an XML representation
but if it has, thats the way to go IMHO.

Cheers, Ingo