W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2008

Re: multiget reports Re: Thoughts on relation to WebDAV

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 29 May 2008 12:10:24 +0200
Message-ID: <483E8110.8050909@gmx.de>
To: Helge Hess <helge.hess@opengroupware.org>
CC: WebDAV <w3c-dist-auth@w3.org>, vcarddav@ietf.org

Helge Hess wrote:
> ...
> On 29.05.2008, at 10:35, Julian Reschke wrote:
>> Actually, my proposal allows a server to assign a GETtable URI to any 
>> REPORT response, so a client would have an extremely simply way to 
>> find out about the URI.
> Maybe I'm reading your memo wrong, but to me it does not look like a 
> BATCH or multiget REPORT replacement. You would need to encode all 
> requested URIs in the URL or assign a stateful token.

It's not meant to be a replacement. But it can make a specific report 
GETtable, and thus cacheable (not the individual parts).

> Its not that useful to cache changeset information either (because it 
> constantly changes and is client-cache specific). Its more important to 

It can be. If a client polls for changes, it's totally useful if the 
server can say "304".

Also, it's not necessarily client specific.

> cache the contained, individual contents. In fact for the latter a BATCH 
> looks to be optimal, since the actual content caching is exactly the 
> same like for individual contents, whereas a REPORT needs custom 
> infrastructure.

The assumption seems to be: we need multi-GET because of initial sync, 
and thus, if we have it, we'll use it for everything.

Another approach would be to have a special GETtable resource that can 
be used for the initial sync, and then use regular, conditional GET 
requests for everything else....

> ...

BR, Julian
Received on Thursday, 29 May 2008 10:11:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:42 UTC