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

Hi Mr.,

--On July 16, 2007 4:41:22 PM +0100 "Mr. Demeanour" 
<mrdemeanour@jackpot.uk.net> 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".

Sorry, my email client has an option to auto-generate the "Hi xxx" line by 
trying to extract the first name from the From email address. Doesn't 
always work well...

>> 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.

iCalendar data for large recurrence sets with lots of overridden instances 
can grow large. Also, attachments can be included inline with iCalendar 
data so those can get (very) big.

In terms of vCard, PHOTO or SOUND properties are defined, so those can add 
a lot of data.

>> 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.

I agree...see below.

> 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.

Actually I have worked on several CalDAV servers to date (something like 
three) and all had slightly different approaches to storing/indexing data. 
In one case it was a pure filesystem store and all queries, partial fetches 
had to go through an iCalendar parser etc - certainly did not perform great 
but was OK for low volume personal use. Another used a pure database 
backend, that was better but still had issues. Another uses the filesystem, 
but augments that with index files for handling queries.

So I think CalDAV and CardDAV do provide the flexibility that is needed - 
but performance will be affected by choice of backend - obviously.

-- 
Cyrus Daboo

Received on Monday, 16 July 2007 16:03:17 UTC