Proposed draft for the thumbnail D-Bus specification

[Philip Van Hoof]

Going to keep this reply around for when I do another iteration over the
specialized thumbnailer's interface specification.

Later is not never. I want to get the Generic interface right and
therefore I'm prioritizing it. For me, at this moment, it's the core of
what I need. 

I don't think etching this spec will be something of a few days or
weeks. Right now I'm already happy with the generic consensus that an
infrastructure like this is useful at the level of freedesktop.

In the prototype we are at this moment focusing most on our own internal
plugin system. That's because for our application it'll be better if as
much as possible thumbnailing work happens in-process of the generic
thumbnailer's daemon (rather than activating a specialized thumbnailer
and requesting the creation itself over DBus).

I'm thinking about renaming the interface "Thumbnailer" to "Renderer" or
"Resizer" (just like you, I don't have a solid-sounding name for it yet.
But I'm confident that we mean the same thing - I understand that you
want to thumbnail things like text and pdfs, and that you don't really
resize those. We also for example have as requirement to have cropped
thumbnails. Which is not the same as rescaling -).

So ... a "scaler" is not right, a "resizer" is a better term but perhaps
not exactly the right name. A "renderer" perhaps? A previewer .. I
personally don't like that term at all, but I'm also pragmatic about
choosing names (it's not 'that' important, for me).

Then I'll consider the three data-transfer methods that you discussed
(by pointer, by SHM +a key over DBus, Unix Domain Socket and sending the
pixmap over and by file-path and writing in /tmp).

I'll adapt the Create method to return those, etc etc ... 

Not sure about the namespace "thumbnailer", for now I plan to keep that
namespace and just have that "Renderer" as an interface in it.

And then a "GenericRenderer" as proxy or squid delegating it to the
right one.

Replace "Renderer" with "Resizer", "Scaler", "Previewer" or whatever
genius name we might come up with later.

How does that sound for you? David?


On Wed, 2008-09-10 at 13:44 +0200, David Faure wrote:
> 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").
> 
-- 
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