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.