Review of the thumbnailer spec

[Jannis Pohlmann]

On Mon, 18 May 2009 16:01:27 +0200
Jannis Pohlmann <jannis at xfce.org> wrote:

> On Mon, 18 May 2009 13:48:08 +0200
> Philip Van Hoof <spam at pvanhoof.be> wrote:
> 
> > On Fri, 2009-05-15 at 04:00 +0200, Jannis Pohlmann wrote:
> > 
> > > In theory, this should completely hide how thumbnails are stored.
> > > For instance, it doesn't really matter whether a cache is used or
> > > not. It doesn't even matter where the thumbnails are stored.
> > 
> > That is correct, except of course that a consumer will need to know
> > about the thumbnail-spec (the storage one) to know where he can find
> > the thumbnails when they are ready. Or where he can find the
> > failures.
> > 
> > It's however the case that for our use-case (Nokia's devices) we are
> > only interested in cropped, not large nor normal, and that we want
> > to store thumbnails as JPeg files, not PNG. 
> > 
> > So we believe that the storage specification for thumbnails isn't
> > complete or rather isn't flexible enough.
> 
> Possibly. One part of the thumbnail spec I'm not exactly happy with is
> that failed thumbnails are stored per application. This means that
> e.g. for G_FILE_ATTRIBUTE_THUMBNAIL_FAILED, GIO has to use hard-coded
> fail paths (right now it only checks fail/gnome-thumbnail-factory/). 
> 
> > > Of course this raises the question how the interfaces should be
> > > named. Should it be org.freedesktop.thumbnailer.* or
> > > org.freedesktop.thumbnails.*, or even a mixture of both? Should it
> > > be org.freedesktop.thumbnailer.Cache or .CacheManager? 
> > >   Also, the name .Generic is rather undescriptive. I'm pretty sure
> > > we there's a better name for this. Let me
> > > throw .Provider, .Service or .Delegate in the pot as a few of my
> > > first ideas.
> > 
> > 
> > How about :
> > 
> > org.freedesktop.thumbnails.Thumbnailer
> > 	- Queue
> > 	- Unqueue
> > 	- Ready
> > 	- Error signal
> > 	- Finished signal
> > 	- Started signal
> 
> Having everything under org.freedesktop.thumbnails makes me wonder
> what to do about org.freedesktop.thumbnailer.Thumbnailer which is
> used for specialized thumbnailers. I guess it would be better to move
> them all into the same namespace and name them differently (not using
> Thumbnailer twice). Thoughts?
> 
> > org.freedesktop.thumbnails.Cache
> > 	- Move
> > 	- Copy
> > 	- Cleanup
> 
> As a consequence of the above I'm wondering about a new method called
> Failed(). But even that doesn't really solve the problem of where the
> failed thumbnails are stored of course.
> 
> > org.freedesktop.thumbnails.Manager
> > 	- Register
> > 	- GetSupported
> 
> I'm thinking about the situation where manager and generic thumbnailer
> are implemented as separate daemons. In that case we'd probably want
> additional methods like this one:
> 
>   - GetThumbnailers (returning the D-Bus names of all registered
>     specialized thumbnailers).
> 
> And maybe a signal 
> 
>   - Registered() (including the D-Bus name of a newly registered
>     specialized thumbnailer).

Ideas for an additional method:

  - Unregister (to explicitely unregister the D-Bus name of a
    thumbnailer).

At the moment implementations of the manager interface have to listen
to the "destroy" signal of proxies created for dynamically registered
thumbnailers. This is more of an implicit unregister which I don't
think is nice.

That would also lead to another signal:

  - Unregistered (sent when the D-Bus name of a thumbnailer is
    unregistered using Manager.Unregister()).

Based on that, clients of the generic thumbnailer/manager services
could cache the supported MIME types and listen for Registered and
Unregistered signals to update this cache.

Cheers,
Jannis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090519/0427af1d/attachment.pgp