An issue that goes beyond the format ( #3 in your list) of individual
items is the very nature of the repository itself: when you "PUT"
something somewhere in DAV it exists only in that one place. But in
the Chandler repo a resource can exist in multiple collections. How
can we express this with DAV? Do we need to extend PUT to say "PUT
this resource in the following location(s)" (maybe a MULTIPUT?) What
about when you delete an item from a particular collection, but not
delete the resource itself? What about when you want to add an
already existing resource to another collection?
Would adding the concept of symlinks to DAV help (if it doesn't exist
somewhere else as an RFC)? Or should we abandon the notion that DAV
collections have a one to one relationship with Chandler collections
and instead implement this functionality through some DAV property
which contains a list of the collections that a resource is in (which
would make interop problematic) ?
On Mar 5, 2006, at 11:58 AM, Brian Moseley wrote:
what's the alternative?
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?
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?
<cosmo:item primarytype="cosmo:event" mixintypes="cosmo:contact,
cosmo:msg">
<cosmo:attr cosmo:name="summary" cosmo:created="xxx"
cosmo:modified="xxx" cosmo:who="bcm">this is an item</cosmo:attr>
<cosmo:attr cosmo:name="firstname" cosmo:created="xxx"
cosmo:modified="xxx" cosmo:who="bcm">brian</cosmo:attr>
<cosmo:attr cosmo:name="to" cosmo:created="xxx" cosmo:modified="xxx"
cosmo:who="ticket-cafebebedeadbeef">[EMAIL PROTECTED]</
cosmo:attr>
</cosmo:item>
this would not make life difficult for cosmo. when processing a caldav
or atom request, it could easily convert this to icalendar or
hcalendar. when accepting an event from a caldav or atom client, cosmo
could convert the icalendar or hcalendar into this format for indexing
and storage.
supporting a format like this would make cosmo very appealing for
clients other than chandler as well.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
