Review of the thumbnailer spec

[Philip Van Hoof]

On Fri, 2009-05-15 at 12:34 +0200, Alexander Larsson wrote:
> On Fri, 2009-05-15 at 04:00 +0200, Jannis Pohlmann wrote:
> 
> > I think we should improve the description of Unqueue a little bit.
> > Unqueue doesn't really prevent service-side implementations of unqueing
> > batch tasks (more than one URI queued as one handle) in the middle of
> > the task (e.g. after having generated thumbnails for 2 out of 10 URIs).
> >
> >   This is exactly what e.g. file managers need though. Just imagine a
> > file manager enters a directory, queues all its files for thumbnailing
> > and then switches the directory before all files are processed by the
> > thumbnailer. So IMHO it should be pointed out more clearly that this is
> > not a violation of the spec. Right now it just says "You can't unqueue
> > requests that are currently running." This should be something like
> > "You cannot cancel the processing of individual URIs but thumbnailers
> > are free to support cancelling running tasks between the processing two
> > URIs when a task unqueued."
> 
> I don't think using this spec from a file manager is really a good idea,
> its quite a lot of overhead doing all this dbus i/o when loading a large
> directory. I certainly won't be using it in nautilus.

The DBus overhead is not really measurable compared to the time it takes
to make a thumbnail. Well, everything is measurable, but the question is
whether it's actually significant.

With the EPeg library, of course, thumbnails are made quite fast. But
still not as fast as a DBus latency overhead. By far not.

> I brought this up with philip when this was initially proposed, and the
> sense that I got from him was not that the file manager is meant to
> consume this interface, but rather to implement it.

Ok, yes. 

Nautilus would be a good place to implement the DBus interface. That's
because Nautilus, on the GNOME desktop, holds the code for thumbnailing
at this moment.

To enable the GNOME desktop to have this interface it would be most
easy, and from an architectural point of view totally fine, if Nautilus
would implement it. It would be equally fine if another process would.

Meanwhile if Nautilus developers are worried about the DBus overhead for
their own thumbnailing purposes, then they can just side-step the DBus
interface and do the thumbnails in-process instead.

The DBus thumbnailer spec doesn't forbid other processes from writing in
the thumbnail-spec's dirs (the storage spec), so even if Nautilus
wouldn't be the implementer, then still it can use its own current code.

Just rename (filename.png.part, filename.png), otherwise different
processes could pickup a half-ready filename.png. I'm pretty sure this
is in place like this already in Nautilus?


-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be