- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 29 May 2008 12:10:24 +0200
- 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