Proposed draft for the thumbnail D-Bus specification

Wed Sep 3 10:01:57 PDT 2008

Note that some people are changing the draft as we speak. You can
subscribe to the document at the right side of the page if you are
interested in the changes.

We for example added a `handle_to_unqueue` parameter to the `Queue`
method.

<method name="Queue">
      <arg type="as" name="uris" direction="in" />
      <arg type="u" name="handle_to_unqueue" direction="in" />
      <arg type="u" name="handle" direction="out" />
</method>

This makes this possible:

Use case:
Open window -> Scroll -> Scroll -> Scroll -> Close window

Original version of the specification:

Queue (-> visible items) (<- 0) -> Queue (-> Vis itms) (<- 1) -> 
Queue (-> Vis itms) (<- 2) -> Queue (-> Vis itms) (<- 3) -> 

Close Window happens

Unqueue (0) -> Unqueue (1) -> Unqueue (2) -> Unqueue (3)

So that's 8 D-Bus requests

New version of the specification:

Queue (-> visible items, 0) (<- 1) -> Queue (-> Vis itms, 1) (<- 2) ->
Queue (-> Vis itms, 2) (<- 3) -> Queue (-> vis itms, 2) (<- 4) 

Close Window happens

Unqueue (4)

So this is just 5 D-Bus requests

Anyway, ask Rob Taylor for details, he came up with the idea ;-)

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