Re: [Ietf-carddav] Comments on draft-daboo-carddav-02

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" 
> <mrdemeanour@jackpot.uk.net> 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.

Received on Monday, 16 July 2007 15:38:26 UTC