Proposed draft for the thumbnail D-Bus specification

[Philip Van Hoof]

On Wed, 2008-09-10 at 12:36 +0200, David Faure wrote:
> On Wednesday 10 September 2008, Philip Van Hoof wrote:

> > You want the big class that will solve all of the problems of this
> > earth's humanity.
> 
> Yeah, god knows two ints and a bool (or splitting up a service into two)

Splitting a service into two, I agree with. Adding ints and a bool, I
don't agree with.

We already discussed this and you seem to have replied that only adding
ints and a bool is the right solution.

I quote:

	"Yes. With s/resizer/thumbnailer/ ;)"

I can't know that you agreed with splitting the service if you write
things like that.

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)

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.

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

I understand that it's going to require time and rewriting of interfaces
and design. I don't think the entire concept is void just because the
interface of the specialized thumbnailers is not ideal yet.

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.

I never wrote nor said that it's insane. I even wrote that it fits my
view of taking over the world (not to take literary of course).

A.k.a. I would actually *prefer it* that way. Except that I fear that it
might simply not happen if we try to do too much at the same time.

> 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 ... but it doesn't matter. Let's continue.

> Can we please stick to the problem at hand instead of deriving into nonsense?

Relax, rhetoric is fun sometimes. It wakes people up.

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".

Those two ints and that bool change the entire concept completely.

> > I also disagree with the architecture that you propose. I would agree
> > with an architecture where the thumbnailer one depends on a generic
> > resize one.
> 
> Then go for it, it's the proper solution.

So we have a level of agreement here. Let's focus on that, then.

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.

This is not an easy task. The spec will make creating a specialized
resizer (what I used to call a specialized thumbnailer) a lot more
complex.

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).

> Otherwise, well, implement whatever you want, but based on this discussion,
> I formally object to this becoming an FDO standard.

More bullying bla bla, I'm again refusing to listen to this.


-- 
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