Proposed draft for the thumbnail D-Bus specification

[Philip Van Hoof]

On Tue, 2008-09-09 at 23:22 +0200, David Faure wrote:
> On Tuesday 09 September 2008, Philip Van Hoof wrote:
> > Well, the thumbnail-spec allows to put nearby sizes in either large
> > or normal 

> This is my main issue with all this. The thumbnail-spec is about what
> gets cached onto the disk, right? Of course it wouldn't make sense to
> store 200x200 pixmaps of every file you moved the mouse over.

If it's not a cache nor a central kind thing, why make it a service
rather than a library?!

Just to flood the DBus system with pixbuf data?

Previews and thumbnails can of course be in the same library. For the
thumbnails you can ask the central service, for previews just use the
same scaling techniques your library uses to rescaling the thumbnail to
its final size.

What about:

if (size < 256)
  use thumbnail service
    on service's callback
      use rescaling code on thumbnail
else
  use rescaling code on original

The reason why not "use rescaling code on original at size" are:

 - Rescaling a large file takes longer
 - There's good a chance that you get an exact size (if your app uses
   the preferred thumbnail sizes, as specified by the thumbnail-spec)
 - Local availability of remote file's thumbnails
 - No duplicate disk-space for applications that are caching the same
   type of data
 - Delegation of thumbnailer work to specialized pieces of software that
   probably know better how to thumbnail specific MIME types than that a
   cloud of desktop applications would each individually know
 - Dependency problems (desktop applications linking with various image
   libraries, just for the sake of requesting the generation of a
   thumbnail)
 - No more need for applications to implement their own asynchronous
   LIFO queue for generating thumbnails
 - Less processes and threads (as generating a thumbnail is usually to
   be done in either a process or a thread, as most algorithms are not
   integrated with either GMainLoop nor QT's mainloop - if the QT being
   used ain't integrated with GMainLoop -)
- I can come up with a lot more reasons ...

> HOWEVER, a thumbnail _service_ should be able to provide such large
> previews without storing them on disk, i.e. completely unrelated to
> the thumbnail-on-disk-spec.

> Either I'm missing something here, or a dbus thumbnail service that
> would be limited to small thumbnails, would be of rather limited
> use...

The point of the service *is* to manage the cache as defined by the
thumbnail-spec, indeed.

No matter how limited of use that is.

> (what's the point of switching to something that would only do half of what we need...)

The point of using the thumbnail-spec is written on that spec. I also
gave a few reasons higher in this reply.

http://jens.triq.net/thumbnail-spec/introduction.html



But ... I don't want to keep defending the purpose of the thumbnail-spec

This DBus specification *is* about remotely managing the thumbnail-spec.
If that specification ain't useful for your purposes, I guess this DBus
specification ain't going to be useful either, indeed.


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