Review of the thumbnailer spec

[Philip Van Hoof]

On Tue, 2009-05-19 at 11:17 +0200, Jannis Pohlmann wrote:
> On Tue, 19 May 2009 10:15:07 +0200

> > If the only use-case we can find for "Unregistered" is updating the 
> > list of supported MIME parts, then we should have a signal for 
> > "SupportChanged" or something like that instead.
> 
> One more use case for Unregistered would be that a generic thumbnailer
> running in a separate process could could remove (or add, in the case
> of Registered) the D-Bus name from the list of specialized thumbnailers
> it talks to.

One more important thing for specialized thumbnailers is that they
should have a fixed path. Right now the path is set to the service name
with all dots replaced with / and the $ char also replaced with a /

That's not good.

A specialized should have its service name specified in the file that
goes into /usr/share/thumbnailers and it should have a fixed interface
and path names.

For example:

service   : com.SomeCompany.Thumbnailer
interface : org.f.thumbnails.SpecializedThumbnailer
path      : o.f.thumbnails/ftp/image_jpeg
path      : o.f.thumbnails/file/image_jpeg
path      : o.f.thumbnails/http/image_jpeg

Notice the UriScheme again, we can never forget the importance for this:
we have two levels of categorization to indicate support: UriScheme and
MIME type. A specialized thumbnailer will not work for all UriSchemes
and will not work for all MIME types.

In fact is it even worse for video thumbnailers, as the great guys of
the many multimedia frameworks and codecs decided to have types inside
of container MIME types. Making MIME mostly irrelevant for videos.

Thanks guys. For majorly messing things up once more in the world of
file formats. Making it all more difficult for all. Instead of simply
registering new MIME types that contain the codec in their MIME type
name (I still wonder why the heck not).

> > However, do note that GetSupported itself isn't complete:
> > 
> > A supported MIME part must always fall under a UriScheme too.
> > 
> > It's for example possible that image/jpeg for file:// is supported by
> > a specific specialized thumbnailer, but not for http://, a good
> > example would be the EPeg library which can't work with VFS URIs at
> > this moment.
> > 
> > So if you want to take GetSupported more serious than what the spec
> > offers now, then you should involve the UriScheme information too.
> 
> Definitely. At the moment GetSupported only returns half the "truth"
> of what is *really* supported. 

Yep

And the same is true for the path to a specialized thumbnailer's DBus
object. One service can serve different support for different MIME types
on different UriSchemes.

Don't you just love the complexity of something simple? :-)


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