[cosmo-dev] RFC4791 HTTP REPORT and Cosmo

Brian Moseley bcm at maz.org
Sat Aug 23 13:13:45 PDT 2008

On Sat, Aug 23, 2008 at 2:57 PM, Sam Halliday <sam.halliday at gmail.com> wrote:
> I am now able to get the list of VTODOs if I aim the request at a specific
> collection URL (using Depth 1), however the RFC does not make it clear how
> to perform VTODO requests for all collections, is that even possible?

servers can support depth infinity reports on any collection. iirc,
Cosmo lets you do depth infinity calendar query reports against the
calendar home collection.

> Also,
> is it possible to obtain the list of collections from the principal rather
> than the calendar-home-set... for a mobile device, every query results in a
> latency so 2 queries to get the list of the collections is a pain, and you
> don't even have their names at that point!

I hear that. unfortunately, no, the two step process is required for
Cosmo. the protocol does not address this issue, and Cosmo doesn't
have a non-standard workaround.

> Does anybody know of any more friendly descriptions of the protocol, perhaps
> with synchronisation examples and worldly advice?

I do not.

> - synchronising an edited offline todo list with a server that has been
> edited (worst case scenario for synchronising), the RFC hints that ETags are
> relevant but there are no implementation examples.

it's been a while, but I think the idea is that you do a calendar
query report to get the etags of all the items in the collection(s),
compare them locally to your stored etags, and then do a multiget
report to get the state of the items that have changed (different
etags) or been added.

> - updating portions of a VTODO. It seems that a PUT of the entire VTODO is
> the only way... but that seems crazy, especially if there are attachments
> (or I don't support all the types within the item).

there is no standard way to represent an update/patch operation
instead of a replace operation with PUT. sad but true. PATCH has been
proposed, but it hasn't gotten a lot of traction, mostly due to the
confusion around standardized patch formats and whether servers would
be required to accept them.

More information about the cosmo-dev mailing list