[Dev] The Chandler/Cosmo sharing format
br at osafoundation.org
Tue Mar 7 15:13:06 PST 2006
Very interesting, especially the bindings one.
Do you think the semantics of chandler objects being in more than one
collection could be expressed using bindings from what you know of both?
On Mar 6, 2006, at 7:23 PM, Lisa Dusseault wrote:
> There are proposals for both redirects and bindings (essentially
> Redirect reference I-D is in the RFC queue: http://www.ietf.org/
> internet-drafts/draft-ietf-webdav-redirectref-protocol-13.txt (The
> only difference between this and an RFC is that they haven't picked
> an RFC number yet)
> Bind is fairly stable but not yet through the WG: http://
> On Mar 5, 2006, at 11:44 AM, Bobby Rullo wrote:
>> 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
>> 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?
>>> 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
>>> 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: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:who="ticket-cafebebedeadbeef">lisa at osafoundation.org</
>>> this would not make life difficult for cosmo. when processing a
>>> or atom request, it could easily convert this to icalendar or
>>> hcalendar. when accepting an event from a caldav or atom client,
>>> could convert the icalendar or hcalendar into this format for
>>> 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
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>> Open Source Applications Foundation "Dev" mailing list
More information about the Dev