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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.