Proposed draft for the thumbnail D-Bus specification

[Alexander Larsson]

On Thu, 2008-10-16 at 23:29 +0200, Philip Van Hoof wrote:
> 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.

That is not enough. Just because KIO uris and GVFS uris are the same for
a file doesn't mean that one can just pass it from e.g. a kio app to a
gio app. What if the file share is authenticated in kio but not mounted
in gvfs? There are all sort of issues like that affecting uris that make
them problematic.

Of course, we should try to make the uri schemes as similar as possible,
and generally they are mostly the same. We have a shared spec for
file:// uris (which i think is followed) and all desktops try as much as
possible to follow the various upstream URI RFCs. But, even then, things
are not always so easy.

I don't see any good way around this really, and thats not really my
point either. I guess what I'm saying is that its a fact of life that
URIs are not as interoperable as one might believe, and you should
design your standards based on this. For instance, your spec implies
that each "specific thumbnailer" that you plug in must handle
downloading the file, which pushes all these problems one each author of
such a thumbnailer. 

A more forgiving design would be that specific thumbnailers would be
handled a local copy of the file to work on, and the generic machinery
handles getting it for you. That would mean the thumbnailer plugins
could be reused on different desktops. Of course, there are some cases
where you really need the whole file and don't want to download it, such
as movie thumbnailing or your IMAP convert case. So you'd have support
that case too. There are several solutions here. You can mark the
thumbnailer as supporting URIs and have only such thumbnailers load the
file itself, or you could have some generic thumbnailer API to get parts
of the file as needed.