Proposed draft for the thumbnail D-Bus specification

[Philip Van Hoof]

On Fri, 2008-10-17 at 14:58 +0300, Marius Vollmer wrote:
> "ext David Zeuthen" <david at fubar.dk> writes:
> 
> > On Thu, 2008-10-16 at 23:29 +0200, Philip Van Hoof wrote:
> >> 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).
> >
> > Not to be rude, but I don't think you realize just how bad the current
> > situation is. First, we need to standardize on the encoding of URIs.
> > Second, we need the mechanisms consuming URIs and serving data (e.g.
> > gio/gvfs, kio, etc.) to use the same underlying connections (for cookies
> > etc.), same password stores etc. otherwise the user need to put in his
> > password again etc.
> 
> I'd say you need common code, not just a common spec.  It's too hard
> (and pretty pointless) to make two VFS implementations interoperate.
> 'Just' use a single one that is flexible enough for everyone.

I must say that I'm not entirely disagreeing with Marius here.

I know it's not very nice to say that although URIs are to be passed,
that either you can't really use all kinds and that the ones that will
work must be the same as the Desktop environment's default VFS layer's
URIs.

This means that we indeed don't have interopability between for example
KDE and GNOME until the URI schemes / problems are fixable / fixed.

But I do feel that this is an interop problem that the VFS layers must
fix. 

I will, however, consider adding bits and pieces to the spec that will
make it less painful.

I could for example let the caller pass a string like this:

Handle = org.freedesktop.thumbnailer.Generic.Queue (
	["smb://server/file.jpeg", "ftp://server/thing.jpeg"],
	["image/jpeg", ["image/jpeg"],
	"GIO/GVFS",
	0)

<node name="/org/freedesktop/Thumbnailer">
  <interface name="org.freedesktop.thumbnailer.Generic">

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

   ...

   </interface>
</node>

And we could have an interface for specialized thumbnailers like this:

<node name="/com/company/Thumbnailer">
  <interface name="org.freedesktop.thumbnailer.Thumbnailer">  
    <method name="Create">
      <arg type="as" name="uris" direction="in" />
    </method>

    <method name="GetSupportedVfsLayers">
      <arg type="as" name="VFS_layer_ids" direction="out" />
    </method>

  </interface>
</node> 

Or have a string-list key in the registration of the specialized thumbnailer.

And if the VFS_layer_id of Queue doesn't match any of the ones being
returned by the specialized thumbnailer, then the specialized
thumbnailer ain't elected to handle the request coming from Queue.

This would not create interopability, but it would make it possible to
have thumbnailers for KDE and thumbnailers for GNOME being installed at
the same time and being elected depending on the "VFS_layer_id" being
passed.

I think that's about the best you can do in the spec for this
problem ...

> > (That said, I do think it would be good to start work like this. But to
> > base new specs on this huge problem being solved already, is counter
> > productive and will not lead to anything usable.)
> 
> The thumbnail spec does not assume that the problem is solved already,
> it is just prepared for the glorious day when it finally is solved.

Indeed.

(and I know it sucks)

> To make this clear, we can add a sentence like "URIs are interpreted in
> a implementation specific way.  The file:// scheme is the only one you
> can rely on.", require specific thumbnailers to implement file://, and
> allow them to implement more.

*nods*


-- 
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