Proposed draft for the thumbnail D-Bus specification

[Philip Van Hoof]

On Wed, 2008-09-10 at 11:16 +0200, David Faure wrote:

> > Thumbnailing is not generic resizing of images (without even storing
> > it), if you just resize an image and don't store it .. it's called
> > resizing. period.
> 
> This is a very limited view - the input for a thumbnailer/previewer isn't only images.
> There is a need (and an implementation in kde) for thumbnailing/previewing
> images, but also plain text, HTML, OpenDocument files, SVG, and more.
> The service that provides a PNG out of those is not to be called resizer, but thumbnailer.

Ok ... org.freedesktop.genericresizer

> > If you indeed set up that specification and if you make a desktop
> > neutral prototype and it indeed becomes part of freedesktop, I'd be
> > happy to let this org.freedesktop.thumbnailer.Generic use the
> > specialized resizers in org.freedesktop.imageresizer instead of its own
> > specialized thumbnailers in org.freedesktop.thumbnailer implementing
> > org.freedesktop.thumbnailer.Thumbnailer.
> 
> Yeah sure, reply with "you do the work" to make sure you win because I don't
> have time for this. There is no need for a separate imageresizer service,
> all we need is a bit more flexibility in the thumbnailer service.

What makes you believe I have time for this? I sure hope you don't think
you are the only busy person on the planet, right? :)

> > Regretfully I didn't start with an existing org.freedesktop.imageresizer
> > being available. 
> 
> No, but you're specifying the thumbnailer service which will have the
> data-to-image code, and that's exactly what this theoretical imageresizer
> would be anyway. Don't do a "SEP", it's not true.

You want the big class that will solve all of the problems of this
earth's humanity.

Regretfully that class doesn't exist, and can't be made.

Quite a lot of philosophers, like I remember Descartes (although I
didn't like reading his stuff), have been teaching us that you need to
split up problems in sufficiently small parts until each and every one
of the parts becomes understandable.

Quite a lot of well known computer scientists, including but not only
people like Brad Adams, have been trying to explain us that a class must
be good at doing one thing ... but only one thing. A class must not try
to solve the world.

Thumbnailing is thumbnailing, resizing is resizing.

Thumbnailing for some thumbnail operations would "consume" a component
that does resizing.

I conclude that you are really trying to stuff the entire solution of
the entire world's problems into one class.

Which is wrong by design.

Feel free to counterargument that such a class is the right solution.
I'll give you the first few lines of code:

public class Universe extends Infinity implements TurtlesAllTheWayDown {

	public Universe () {
		try {
			throw new GodDoesNotExistException();
		} catch {
			throw new ThereforeTurtlesDontExistException();
		}
	}
}


> > But if nobody is hungry for specifying a o.f.imageresizer, let's stay
> > with our both feet on the ground and start modest with just a namespace
> > like o.f.thumbnailer.
> 
> In this case "modest" == useless. Sorry.
> 
> You're making this a freedesktop.org specification in order for this to be shared
> among desktop environments, no? Why then
> 1) ignore actual working implementations of this?
> 2) ignore comments from people who know those implementations?
> 
> I can see yet another gnome-only freedesktop spec coming up, if it is made
> less useful than kio_thumbnail :(

Yes, we have heard this kind of "If you don't do what I say, then it's
useless for us!!!" crap repeatedly. I don't really like that style of
bullying engineering.

It's actually funny that you state that:

I have to do something for YOU, because YOU are a busy person. And if I
don't do this for YOU, then it's useless for KDE. 

Of course totally ignoring that I might be a busy person too.

But that's basically what you are saying, right?

Regretfully for you I interpret it as childish and therefore I refuse to
listen to it.

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. But not where the thumbnailer one becomes a class that ought
to solve all of the world's problems (and soon the problems on Mars too,
of course).


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