Proposed draft for the thumbnail D-Bus specification

[Philip Van Hoof]

On Fri, 2008-10-17 at 14:39 +0200, Philip Van Hoof wrote:

At some point this week I changed the spec to this proposal. But while
asking around most people don't seem to like the idea at all.

It's quite likely that I will remove the "VFS_layer_id" parameter and
the "SupportedVFS" from the spec again, and that I will add a statement
that says:

 " Only "file:///" URIs are guaranteed to work cross desktop "

To the spec. This doesn't mean that other URIs wont work, except that
only for "file:///" the spec requires and guarantees desktop
interopability.

The reason for this is that a) if we pass a VFS identifier then we
actually worsen the problem for "file:///" URIs that would have worked
cross desktop and that b) it's plain ugly to expose this in the
specification. No matter how broken the URI situation is.

So this means that if an app developer wants guarantees that his
thumbnail will work, that he'll need to copy the content to a local
location first. However if the app developer is sure that the target
platform supports his URI-string, then he can pass it naked.

Unless there's a better proposal for this soon, I will make the changes
to the spec this week and I will adapt the prototype to this conclusion
with it.


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