Proposed draft for the thumbnail D-Bus specification

[Philip Van Hoof]

On Fri, 2008-10-10 at 11:26 +0200, Alexander Larsson wrote:
> 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, ..
> 
> I just did a quick scan of this. Here are some comments:
> 
> The use of URIs as argument to the thumbnailer is problematic in many
> respects. For instance, URIs means different things to different
> desktops (gnome-vfs uris, gvfs uris, kio uris, apps manually handling
> http uris). They support a different set of uris, they authenticate
> differently, they don't share active connections, etc. 
> 
> I mean, how exactly is this mean to work if i'm writing a kio based file
> manager and send over a uri to e.g. a gio/gvfs based thumbnailer
> service? 

Whenever the URI is not understandable for the thumbnailer infrastruc-
ture, it should simply error.

That indeed means that only URI schemes that are shared between GVFS and
KIO will be usable.

I think URI-schemes for desktops is something the two teams should
discuss, but not something we should cripple other specifications for
(because there's no agreement).

For example, reverting to normal paths instead is not a good option
either. As you have softwares who want to make thumbnails for shares,
websites and/or files on http, for pluggable devices that don't appear
as a mount point in /media, etc

So I guess the answer is: GVFS and KIO people should (must) start
talking with each other in case there are still differences between
their URI schemes. I understood you are part of the GVFS team,
Alexander? 

> Also, having each specialized thumbnailer handle the uri getting means
> you push this even harder. What if some specialized thumbnailers use gio
> and others kio? An alternative would be for the common code to download
> the file and pass a local path to the thumbnailer, but then you get
> problems with file types with large files that you only need to load a
> part of to thumbnail (for instance movies).

What if the file ain't available locally? Some remote services have a
special way to get the thumbnails (without having to download the big
remote file locally). And future devices might offer this capability
too.

For example attachments in an E-mail stored on an IMAP account where the
future IMAP server supports CONVERT. CONVERT is not available in a lot
of IMAP servers yet, but with CONVERT available I could ask for a
thumbnail version of the bigger Image attachment, and let the IMAP
server do the resizing for me (and therefore make the thumbnail request
and creation a lot faster. Both on local CPU and I/O as on network I/O).

This of course requires that I can use URIs instead of paths:

imap://user@server/INBOX/100.3 (maybe the exact format is not right
according to the URI spec for IMAP, but you probably get the point).

Anyway, that's also why URIs are used, instead of paths. A little
library that converts everything to paths would of course make this more
difficult (as the plugin would have to implement a part of its code in
that little library, which is exactly what I wanted to avoid by making
it pluggable at the level of D-Bus - so that alien 3th party code
doesn't have to be linked into core infrastructure, but instead making
this code activatable and a D-Bus service -).

> I don't have any answers here, just pointing out problems. Of course,
> this is generally only problematic if you try to make this a
> cross-desktop standard. Otherwise you can just say "uris are gvfs uris"
> or whatever.

Yep. For now, that will do. And please, Alexander, try to negotiate a
shared desktop URI schema with the KIO people :-)

> For nautilus, what I do is queue all the thumbnailable files in the
> directory for thumbnailing, but then I prioritize the files that are
> currently visible. So, when you scroll all the newly showed files are
> pushed to the top of the queue. This seems much better than queueing
> just the visible files each time you scroll, as then the non-visible
> icons won't be thumbnailing in the background waiting for you to scroll.
> 
> I don't like that the service errors out if any one file in the
> requested set fails to thumbnail. You don't even know which one failed.
> This is useless.

This can of course be fixed.

> I still want to thumbnail all the other files that are thumbnailable. 
> A better solution would be to write out a failed thumbnail (as per 
> the spec) and then call either Ready with a boolean success argument
> or a separate Failed signal.

The prototype continues I think. Need to check. It doesn't write (as per
spec) into the 'failed' directory yet.

> Also, wrt failed thumbnailings. What id should be used to look for
> failed thumbnailings?

No answer yet. I guess things like this are items that can use some
improvement.

As I stated before as a reply to others, is the Error reporting of this
spec underspecified/underdeveloped/undecided. If people have ideas (like
the ones you just gave me), that would be great 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