On sharing 1 item == 1 WebDAV resource:
On Mar 5, 2006, at 8:58 AM, Brian Moseley wrote:
it seems to me that morgen's trying to figure out:
1) how to avoid storing multiple webdav resources for a single
shared item
2) a sharing format that can fully express all of chandler's
information about a calendar item, even things that might not be
directly expressable by icalendar
3) a sharing format that can cope with stamped items
#1 could be as simple as: use icalendar for calendar items, vcards for
contacts, and "something else" for everything else.
#2 could be solved for icalendar and vcard with x-properties.
but what about #3? are x-properties sufficient for this purpose? what
about an item that's both an event and a contact - do we store it in
icalendar or vcard? what about an item that's an event, a contact, and
an email message with a big binary attachment - do we store it in
icalendar, vcard, or mime?
If we were sharing email and tasks as well as events to a CalDAV-only
server, then yes, all the stamped information besides the event
information could be stuffed into x-properties and/or attachments.
But actually, the problem comes when a server is capable of
understanding events as one kind of resource, tasks as another kind
of resource, and possibly in the longer run email as a third kind of
resource. If we had a general server capable of understanding those
different types, we wouldn't want to make one type "dominant" (the
event) and hide the information for the other kind in extension
properties.
It may be that stamped items are the one thing we have to share as 2
separate resources to maximize interoperability. E.g. for an Event
+Task we would have
http://share.o11n.org/users/lisa/work/staff-meeting-event -- this
resource has the VEVENT properties and a pointer to the other
http://share.o11n.org/users/lisa/work/task-prepare-staff-meeting
-- this resource has the VTODO properties and a pointer to the other
Another client could reasonably understand both the event and the
task and even possibly understand that they were tied together. They
would be displayed separately in most clients, at least for the
medium term, but they'd both display.
I understand that doing a PUT for both these parts of the stamped
resource is non-atomic. But there may be other ways of solving that
part.
1. Microsoft invented a WebDAV extension to combine multiple
requests in a transaction:
LOCK with special syntax to start transaction and get transaction ID
PUT #1 with Transaction header to do the first resource created in
the transaction
PUT #2 with same Transaction header
UNLOCK with transaction ID to commit the changes
2. The "If" header allows you to create two resources in a way that
creating the second one relies on the existence of the first one.
The second PUT would look like this
PUT /users/lisa/work/task-prepare-staff-meeting HTTP/1.1
If: <http://share.o11n.org/users/lisa/work/staff-meeting-event>
([event-etag])
Content-Type: text/calendar
...
There's two options, there may be others.
in the chandler repository, an item is basically just a list of types
and a flat list of name/value pair style attributes, right? couldn't a
very simple xml format address that in a flexible way?
...
supporting a format like this would make cosmo very appealing for
clients other than chandler as well.
Yes, but maintaining such formats across releases and as requirements
change turns out to be very painful. Internally both Cosmo and
Chandler maintain their own representations, but externalizing either
one of those is something that's even more difficult to maintain than
an interoperable standard format. We want version 0.7 of chandler to
interoperate with people running 0.8 and so on. Which version of
Chandler becomes the one whose internal format becomes externalized
and set in stone, and why that version?
Lisa
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
