Proposed draft for the thumbnail D-Bus specification

[David Faure]

On Wednesday 10 September 2008, Philip Van Hoof wrote:
> We already discussed this and you seem to have replied that only adding
> ints and a bool is the right solution.

No, I only suggested adding parameters because you didn't want to hear about the
proper two-layer solution because that was too much work. So I tried to find
a solution that was closer to your design, but it is certainly not my preferred solution.
When I presented the KDE design, I thought it was clear that I was advocating this
kind of architecture.

> Now, about splitting the service:
> 
> This doesn't change the current org.freedesktop.thumbnailer.Generic
> interface (I'm only talking about the interface, not the implementation)

Right.

> It would only require changing the interface of the specialized
> thumbnailers. Instead of just "Create" without a return value, it would
> have to return a key to a SHM.

Yes (although we might want a fallback solution for the case where SHM is not
available, like actually passing pixmap data over the wire, unless you have a better
idea)

> Therefore, can we continue with further specifying the Generic interface
> and later fine tune the specialized thumbnailer's interface?

Hmm, ok, although I fear "later" is "never" in this kind of sentence :-)
For anything to work you need both interfaces.

> If people really think there's sanity in starting two different
> specifications: one for generic resizing (and for playing the role of
> the plugin interface for the thumbnailer infrastructure), and one for
> generic thumbnailing (consuming the generic resizing spec to write to
> the cache as specified by thumbnail-spec), then I *am* all for it.

Me too (except that I still don't like the term "resizing" -- making an image
that shows the first few lines of a text file is not "resizing" that text file...).
I can only suggest "preview" as a better term, but I'm open to suggestions :)

> > Not at all, you're the one doing that!
> > I presented a design with two layers:
> >  * upper layer: thumbnail-spec handling
> >  * the layer below: data-to-image previewing
> 
> No, you presented a design with two ints and a bool. I laid out the two
> layer design ... 

I suggest to re-read the email where I presented the KDE design ;-)

> but it doesn't matter. Let's continue. 

Yes.

> > Can we please stick to the problem at hand instead of deriving into nonsense?
> Relax, rhetoric is fun sometimes. It wakes people up.

Sorry, I don't find rhetoric fun - I am under stress from tight deadlines to hold
and I'm trying to minimize the time I spend on this (longer than I would wish, but
now useful again it seems) discussion.

> Obviously I didn't intent to say that your proposal is indeed like a
> Universe class. I just wanted to point out that if we indeed want what
> you require, that we need to do it multi-layer instead of "just add two
> ints and a bool".

OK. See, explicit sentences are better understood than rethoric.

> I'm first going to further test, fine tune and continue with the
> org.freedesktop.thumbnailer.Generic interface, and I will rethink the
> org.freedesktop.thumbnailer.Thumbnailer interface for specialized
> tbumbnailers.
> 
> If the SHM proposal of yours is too difficult for average thumbnailer
> coders to implement, then we'll have to find proper solutions to reduce
> that complexity.

Right. What we do in kio_thumbnail is that the SHM stuff is handled by the
generic code, while the mimetype-specific plugins only have to create
an image (in memory) from a given file.
In terms of your design I think this would mean a generic previewer :-)
So, generic thumbnailer --> generic previewer --> specialized previewer.
(--> means "uses").

And both generic thumbnailer and generic previewer provide a standard dbus
interface, so it's possible for applications to access either one directly.

Specialized previewers don't have to be separate processes (ideally it's
rather an in-process plugin for the generic previewer), but can be.

> For example:
> 
> How do you support writing a thumbnailer that wants to fork(); execv() a
> ImageMagick binary like "convert"? You make it write in /tmp, and read
> in the entire imagine into a SHM?
> 
> Because that's a lot less efficient than how a current specialized
> thumbnailer would be: the requirement to read the file into SHM is
> implicit in this multi-layer proposal, for such implementations of
> resizers (or thumbnailers).

Right. Both layers of communication (specialized previewer --> generic previewer
and generic previewer -> generic thumbnailer) have to support multiple communication
mechanisms, to avoid this problem.
* passing the pointer (if same process, which is the ideal solution for specialized previewers...)
* SHM
* path to a file
* passing pixels (maybe we can do without this one, if we use tempfiles, with always
the problem of "who is deleting the tempfile").

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).