Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
"Mr. Demeanour" <[email protected]>
| Newsgroups | gmane.ietf.webdav |
|---|---|
| Message-ID | <[email protected]> |
Cyrus Daboo wrote: > Hi Mr., Perhaps I should have signed up using a less silly email address! My name is Jack Cleaver. I shall alter my list registration details "soon". > > --On July 16, 2007 4:06:30 PM +0100 "Mr. Demeanour" > <[email protected]> wrote: >> >> Not really; the CalDAV multiget requires the server to parse the >> resource body, because the client can ask for selected iCalendar >> properties. ASs it happens, I think that was a rotten idea, and >> multiget would be better-off without that feature. > > Returning partial data is important for "low capacity" devices such > as mobile devices, who arguably benefit the most from multiget as > well. OK, I appreciate that. IME the amount of data in a single CalDAV resource is generally under about 3K, unless there is an essay in the <description> field. But I take the point. > Note that parsing the data is an implementation issue, e.g. servers > that store the data in a database can simply implement the the > "partial data" aspect by doing a query for only the requested > parameters etc. OK; I'm aware that the majority of CalDAV servers (perhaps the majority of DAV servers) rely on a database, and that as a consequence, data and properties are all implemented as columns in a RDB, and are therefore logically more-or-less equivalent. But that shouldn't colour the approach taken by spec-writers; otherwise we will end up with specs that place pressure on implementors to use a RDBMS. In the extreme, we'll end up with specs that implicitly mandate a RDBMS. Declaration of interest: my own project is to implement a CalDAV server that has no DBMS dependency - it's a servlet that uses exclusively the filesystem for storing data. I have repeatedly run into details in the specs that would have been *much* easier to implement had a database been my underlying store; typically these details relate to the blurred distinction between data and properties. -- Jack.