Proposed draft for the thumbnail D-Bus specification

[Mikkel Kamstrup Erlandsen]

2008/9/7 Philip Van Hoof <spam at pvanhoof.be>:
> On Sun, 2008-09-07 at 13:47 +0200, Mikkel Kamstrup Erlandsen wrote:
>>  * Why do each specialized thumbnailer has its own interface name? Ie
>> com.mikkel.Thumbnailer? Since the interface is defined by the
>> thumbnailer spec anyway, why is the name not? Calling it
>> org.freedesktop.ThumbnailFactory or something would be more consistent
>> imho.
>
> Somewhat agree.
>
> What about
>
> org.freedesktop.Thumbnailer.Specialized ?

I used the flatter namespace because of Havoc's comment on nested
interfaces. If you don't want to pollute the org.freedesktop NS then
you could put the interfaces in org.freedesktop.thumbnail instead. Fx.
org.freedesktop.thumbnail.Core and org.freedesktop.thumbnail.Factory

>>  * Under which circumstances does the methods throw errors and when do
>> they silently fail?
>>   - What happens if I Queue the file "$£@2345234.$£"?
>>   - Unqueuing a non-exisitng handle is probably not worth throwing
>> errors for, but should be noted
>
> So you do want more specification for error handling? I kept is loosely
> defined because error reporting is a specification by itself.
>
> Would you be interested in investigating the possible error situations,
> and specifying them individually?
>
> I imagine it's by itself quite a task.

While I would not drill down into every detail I would like common
error cases to be cleared. Like passing a non-uri, or non-exisiting
file, to Queue.

I am desperately lacking time these days, but let me see if I can come
up with a proposal, but don't hold your breath :-)

>>  * Which URI schemes are supported? Can I thumbnail web pages? Perhaps
>> there should be some introspection for this (both in the generic
>> thumbnailer and the specialized ones).
>
>
> This is an extremely good question and I am so happy that you raised it!
> This way and now I know I don't have to explain what I was about to
> change myself!
>
> For example  (if I get your question right) ...
>
> What if you want to register a specialized thumbnailer for all your
> Email attachments, for example? -- people who know me know that I
> sometimes happen to care about E-mail ;) --
>
> That's an URI like this:
>
> imap://user@server/INBOX/993/2.2
>
> That's (usually) for the second attachment if you have a multipart
> text/plain plus text/html with two attachments.
>
> This URI doesn't give-away the MIME type and more, the MIME type is not
> what you want to correlate your specialized thumbnailer with in this
> case. That specialized thumbnailer might want to extract the base64
> encoded information and pass that information to yet another specialized
> thumbnailer.
>
> I conclude that you want either the URI-scheme OR the MIME type to
> correlate the specialized thumbnailer with.
>
> And that's what your question at its core is about, right?
>
> So I will have to rethink the correlation between specialized
> thumbnailer and generic thumbnailer:
>
> - based on a variety of things which means a hard specification and an
>  even harder implementation
>
> - based on MIME type only which doesn't solve this problem
>
> - or based on URI scheme and MIME type.. which I currently think is
>  ideal.

When playing around with this in my head I quickly realized that there
are endless possibilities for combining these things, so I would
advise that you strive to keep this area simple.

The simplest approach is probably to extend your. Thumbnailer.service
files with 'uriSchemes' key. My custom webkit-based thumbnailer could
then be defined as:

[D-BUS Thumbnailer]
Name=org.grillbar.Thumbnailer
comment="thumbnailer for web pages"
uriSchemes=html;ftp;file

The missing 'mimeTypes' key should then indicate "hit me, i can take
it". Ie the default mimeTypes value is '*'. The default value for
uriSchemes would probably be 'file'.

Exactly how the thumbnailers should be selected in this two
dimensional uri/mimetype system I don't know. The core thumbnailer
will have a hard time guesssing the appropriate thumbnailer for stuff
like:

http://google.com
http://example.com/myDoc.pdf
http://mail.example.com/?attachment=1235&user=mikkel
<insert your own variation>

Maybe it is enough to specify that these keys are merely hints to the
main thumbnailer... Or maybe these examples goes to show that
uriSchemes are better left out of the spec.

Cheers,
Mikkel