Renditions/Reviews/Thumbnails in WebDAV

[Julian Reschke]

Hi,

the CMIS TC is currently discussing how to expose thumbnails in their
API. While listening to that discussion, I realized it would be trivial
in WebDAV, based on link-typed properties and the DAV:expand-property
REPORT.

So, the use case is: retrieve contents of a folder, and for each image
in the folder, retrieve URLs + metadata for thumbnail images.

Solution:

1) New property x:preview-set, containing a set of DAV:href elements
referencing HTTP resources representing the preview (thumbnail) resources.

2) The DAV:expand-property
(<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.3.8>)
already allows getting the contents of a collection, while also
expanding link-type properties.

Such as:

REPORT / HTTP/1.1
Host: www.webdav.org
Depth: 1
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

<D:expand-property xmlns:D="DAV:">
  <D:property name="preview-set" namespace="extension-URI">
  </D:property>
</D:expand-property>

Note that this REPORT will also allow retrieving properties of the link
targets, such as the thumbnail's dimensions.

BR, Julian

[Werner Donné]

Hi,

I would not limit preview-sets to images. Any type of document can  
have a
preview thumbnail (cfr. Coverflow on Mac OS X).

When retrieving preview-set in expand-property, into what the URLs in
preview-set would expand?

There should be a property to represent an embedded form of a  
thumbnail, i.e.
one that also contains an element with the base64-encoded binary  
stream of
the thumbnail. This way the contents of a folder, thumbnails included,  
could
be retrieved with a single round-trip, which is much more efficient on  
the
server-side. Such a property would be available directly in the PROPFIND
method.

Best regards,

Werner.

On 26 May 2009, at 20:48, Julian Reschke wrote:

> Hi,
>
> the CMIS TC is currently discussing how to expose thumbnails in  
> their API. While listening to that discussion, I realized it would  
> be trivial in WebDAV, based on link-typed properties and the  
> DAV:expand-property REPORT.
>
> So, the use case is: retrieve contents of a folder, and for each  
> image in the folder, retrieve URLs + metadata for thumbnail images.
>
> Solution:
>
> 1) New property x:preview-set, containing a set of DAV:href elements  
> referencing HTTP resources representing the preview (thumbnail)  
> resources.
>
> 2) The DAV:expand-property (<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.3.8 
> >) already allows getting the contents of a collection, while also  
> expanding link-type properties.
>
> Such as:
>
> REPORT / HTTP/1.1
> Host: www.webdav.org
> Depth: 1
> Content-Type: text/xml; charset="utf-8"
> Content-Length: xxxx
>
> <D:expand-property xmlns:D="DAV:">
> <D:property name="preview-set" namespace="extension-URI">
> </D:property>
> </D:expand-property>
>
> Note that this REPORT will also allow retrieving properties of the  
> link targets, such as the thumbnail's dimensions.
>
> BR, Julian

--
Werner Donné  --  Re                                     http://www.pincette.biz
Engelbeekstraat 8                                               http://www.re.be
BE-3300 Tienen
tel: [phone] e-mail: werner.donne@...

[Julian Reschke]

Werner Donné wrote:
> Hi,
>
> I would not limit preview-sets to images. Any type of document can have a
> preview thumbnail (cfr. Coverflow on Mac OS X).

Yes, that was the intention. Another use case are short, low-quality
excerpts from audio files.

> When retrieving preview-set in expand-property, into what the URLs in
> preview-set would expand?

That would be server-defined. In theory, it wouldn't need to be WebDAV
resources at all.

> There should be a property to represent an embedded form of a thumbnail,
> i.e.
> one that also contains an element with the base64-encoded binary stream of
> the thumbnail. This way the contents of a folder, thumbnails included,
> could
> be retrieved with a single round-trip, which is much more efficient on the
> server-side. Such a property would be available directly in the PROPFIND
> method.
> ...

In theory that can be done using the "data" uri scheme as well.

The tricky question here is who's role is to decide when inlining is
better; the client or the server? (the latter does have more information
about the size).

Also, inlining has the drawback of defeating caching.

BR, Julian