Proposed draft for the thumbnail D-Bus specification

[Philip Van Hoof]

Hi there,

This is what a developer would have to do to make a specialized
thumbnailer. So also for this there's now a prototype:

https://stage.maemo.org/svn/maemo/projects/haf/branches/hildon-thumbnail/daemonize/tests/daemon.c
https://stage.maemo.org/svn/maemo/projects/haf/branches/hildon-thumbnail/daemonize/tests/daemon.xml

Note that I used glib for implementing it. That's because personally I'm
used to glib. I'm confident that you can do the same with with QT
libraries. If you want a proof of concept of both the daemon and a
specialized thumbnailer written in QT, you are hereby invited to make
one.


On Wed, 2008-09-03 at 16:15 +0200, Philip Van Hoof wrote:
> Hi there whoever is interested in thumbnailing!
> 
> This is the location to the draft:
> 
> http://live.gnome.org/ThumbnailerSpec
> 
> This is the Subversion repository to a prototype implementation:
> 
> https://stage.maemo.org/svn/maemo/projects/haf/branches/hildon-thumbnail/daemonize/daemon/
> 
> It's somewhat untested and unfinished and at the same time tested (it's
> a prototype at this moment).
> 
> I'm very interested in corrections, reviews, spelling fixes,
> concerns, ..
> 
> 
> Features of the draft:
> 
> * Dependency on the Thumbnail-spec (this is definitely a feature, yes.
>   Let's start to agree on a common thumbnail storage once and for all
>   instead of all inventing our own incompatible thumbnail caches)
> 
> * Queuing and indeed unqueuing requests. This makes it possible to let
>   the daemon forget about requests that got requested by accident (the
>   use-case being the window of a file manager closing before the
>   thumbnailing of items finished) (see lower for canceling)
> 
> * Possibility for the daemon to send early results back for items that
>   it could finish sooner than other items. This is useful for already
>   cached thumbnails.
> 
> * Possibility for third party vendors to provide a closed source, closed
>   or patented format thumbnailer by registering support for a MIME type
>   to a manager interface that is required to be implemented by the
>   thumbnailer service. Anti-patent feelings are irrelevant for this
>   this specification: I don't like patented formats too, but that averse
>   is irrelevant here - let's just make it possible and let us make
>   others decide for themselves, we are not the anti-patent police -
> 
>   Generic thumbnailer: org.freedesktop.manager.Register
>   Specialized thumbnailers: org.freedesktop.Create
> 
> * Possibility to queue a lot of items without having to send a lot of
>   DBus messages. Possibility for the daemon to reply `Ready` signals in
>   groups too (for the same reason).
> 
> * Limited error reporting (I don't think file-managers are going to do a
>   lot with errors. But if necessary we can improve error reporting to be
>   topnotch)
> 
> * Limited status reporting. You receive signals when a queued task is
>   started and when it's finished. You receive signals when individual
>   items are finished.
> 
> * Intelligent thumbnail handling on Move, Delete and Copy. This allows a
>   file manager to inform the thumbnailer about Moves, Deletes and
>   Copies. Polling to keep the thumbnail cache correct is not implied by
>   this specification (and therefore not required, but permitted).
> 
> Recommended by the specification
> 
> * Asynchronous LIFO handling of the queue (strongly recommended)
> 
> Not supported:
> 
> * Canceling of activated requests. This is too hard to implement.
>   Functions like pthread_cancel are a no-option (leaks memory) and
>   starting and killing processes is not something I want to require by
>   the specification. The only viable option would be to adapt all
>   thumbnail algorithms to have meaningful cancel points. This is not
>   something I want to require from the specification.
> 
>   I also looked at the current thumbnailing code of a few filemanagers.
> 
>   Although Nautilus's private library has a load_image_cancel method, it
>   doesn't seem to be called (which makes me wonder why it was never
>   removed from nautilus-thumbnail.c)!
> 
>   Nautilus's remove_from_queue and remove_all_from_queue are however
>   used by Nautilus itself. Therefore is this functionality available in
>   the D-Bus API.
> 
> * Topnotch status reporting. This is too difficult for implementers of a
>   daemon to require in the specification. Just like canceling would it
>   require rewriting a lot of thumbnail algorithms.
> 
> 
> Notes
> 
> Note that the not supported features don't mean that in future it wont
> ever be added to a 2.0 version of this specification or that in a custom
> DBus namespace a thumbnailer can't provide this functionality.
> 
> 
> -- 
> 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
> 
> 
> 
> 
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
> 
-- 
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