[Dev] The Chandler/Cosmo sharing format

[Lisa Dusseault]

On Tue, 07 Mar 2006 15:13:06 -0800, Bobby Rullo <br at osafoundation.org>  
wrote:

> 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?

Yes, although I worry that different servers would interpret permissions  
in different ways.  Right now it's not even clear if a server is allowed  
to do a "sum" of the permissions of the two different parent collectins of  
a bound resource, but I expect that's what we'd want the server to do.  So  
if you have a calendar shared with your girlfriend, and a calendar shared  
with your teammates, an event that appeared in both calendars would be  
visible to both sharing groups.

Lisa

>
> bobby
>
> On Mar 6, 2006, at 7:23 PM, Lisa Dusseault wrote:
>
>> 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
>>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev