Re: Specifying thumbnailers as a service



Philip Van Hoof wrote:
Hi there,

Not only filemanagers want to request the creation of a thumbnail. For
example desktop search engines like Strigi and Tracker want to schedule
the creation of thumbnails for certain of the contents that they find,
ahead of time (not sure about Strigi, as one of Tracker's developers
myself I'm sure about Tracker).

This is why we would like to have a desktop wide DBus API for requesting
the creation of a thumbnail. Not just a specification about how to store
the thumbnails and where you can find them [1], but also a method to
request thumbnails.

We want to reuse the infrastructure that is available.

We want to request the creation of a thumbnail for rather a lot of items
so this API would have to accept a an array of paths to thumbnail-able
items. When finished it would return an array of paths to the
thumbnails.

For example (this is glib-dbus XML api)

<node name="/">
<interface name="org.freedesktop.Thumbnailer"> <method name="Create">
      <annotation name="org.freedesktop.DBus.GLib.Async" value="true"/>
      <arg type="as" name="uris" direction="in" />
      <arg type="i" name="size_x" direction="in" />
      <arg type="i" name="size_y" direction="in" />
      <arg type="as" name="thumbnails" direction="out" />
    </method>
    <method name="Move">
      <annotation name="org.freedesktop.DBus.GLib.Async" value="true"/>
      <arg type="as" name="from_uris" direction="in" />
      <arg type="as" name="to_uris" direction="in" />
    </method>
    <method name="Delete">
      <annotation name="org.freedesktop.DBus.GLib.Async" value="true"/>
      <arg type="as" name="uris" direction="in" />
    </method>
  </interface>
</node>

Nobody does something for no reason. Our own reason for wanting this is
to have a platform wide thumbnailer for the Maemo platform and we want
it aligned with upstream projects.

A thumbnail service on a mobile platform is not going to have the same
requirements as a thumbnail service on a KDE or a GNOME platform. It's
my opinion that although the requirements are going to be different, the
API for requesting the creation of a thumbnail isn't.

Therefore, and this is a strong opinion of me:

We make it more easy for our application developers if we cooperate on a
DBus standard at the level of freedesktop.org, instead of each having
our own client APIs for this.

We can help with the work on patches for Nautilus and Konqueror.

ps. Filemanagers could either become the providers of these DBus APIs,
this is probably the most easy change, or if the architecture is chosen
to offshore this functionality to a daemon they could be adapted to
consume the DBus API instead.

My proposal is *not* about having one great thumbnailer. If different
teams want to compete on a thumbnailer implementation, then they must
compete and that way drive innovation. This proposal is about the DBus
API only for it (to see if we can reach an agreement on that).



Hi Philip

I wonder if it'd make sense to allow multiple services to provide thumbnailing for different mime types. This could be done by having the thumbnailing service(s) register bus names of the form org.freedesktop.thumbnailer.<mime type>, and the application could look up the bus name for the mime type of the file it wishes to thumbnail, and dbus-activation would take care of running the appropriate service.

This would then allow proprietary providers of thumbnailing services for proprietary file types, or applications to provide thumbnailing of their own file types. However, I don't know if in general an application knows a file's mime type before it asks for the file. Of course, a plugin api for the thumbnailing daemon would also have much the same properties and may be simpler, though loosing the process protection.

Just an idea ;)

In terms of the above proposed API, I'm guessing that the 'thumbnails' out paramater on Create is returning a list of uris, which are 'freed' from use by the application by the Delete function? Also what is the Move method for?

Thanks,
Rob


Thanks


--- footnotes
[1] http://jens.triq.net/thumbnail-spec/index.html



--
Rob Taylor, Codethink Ltd. - http://codethink.co.uk


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]