- From: Cyrus Daboo <cyrus@daboo.name>
- Date: Thu, 29 May 2008 12:29:00 -0400
- To: Julian Reschke <julian.reschke@gmx.de>, Helge Hess <helge.hess@opengroupware.org>
- cc: WebDAV <w3c-dist-auth@w3.org>, vcarddav@ietf.org
Hi Julian, --On May 29, 2008 12:10:24 PM +0200 Julian Reschke <julian.reschke@gmx.de> wrote: >> 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.... But I think that will end up looking exactly like multiget for the most part. Some things to note: clients will typically need to use several multigets for the initial sync if the collection is large. I believe iCal broke down multigets into 50 or 100 resource fetches at a time. Our server won't allow more than 1000 to be returned in a report. So your special GET will need to have a way to select which ranges to fetch (just as multiget does) and it will need a way to expose, at the very least, the getetag property of each of those (again multiget can do that but also allows more properties to be returned). So I think you just end up with pretty much the same feature set. -- Cyrus Daboo
Received on Thursday, 29 May 2008 16:29:43 UTC