[Dev] The Chandler/Cosmo sharing format

[Lisa Dusseault]

There are proposals for both redirects and bindings (essentially "sym- 
links").

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://www.ietf.org/ 
internet-drafts/draft-ietf-webdav-bind-14.txt

Lisa

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 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">lisa at osafoundation.org</ 
>> 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