[Cosmo-dev] Sharing Format discussions..

[Lisa Dusseault]

I can see the attraction of sharing format code between the Cosmo  
sharing functionality and the upcoming dump-and-reload feature.   
However, there are other options with different tradeoffs in terms of  
interoperability.

One tradeoff of using a dump-and-reload format is that such a format  
may not have the same interoperability characteristics.  Two cases:
	(a) Either the format changes from version to version of Chandler,  
and therefore can't be used for sharing between two people with  
different versions of Chandler
	(b) Or, the format is consistent so that it *can* be used for  
sharing between two people with different versions, but this might  
have undue costs for dump-and-reload scenarios.  For example, if the  
dump-and-reload format is consistent between versions, we might be  
expected to support dump-and-reload from any Chandler version to any  
other Chandler version.  We might then have to test that  
flexibility.  ISMT that typically dump-and-reload features don't have  
to support major version changes, and that could be a good  
simplification to make for that feature if it was considered in  
isolation.

A tradeoff in favour of sticking with iCalendar (at least for events  
and tasks) is interoperability, of course.  I think it's feasible for  
Chandler to achieve its sharing of rich data even with CalDAV servers  
that aren't Cosmo.  (Oracle's CalDAV server is shipping this year,  
and RPI's CalDAV server is already in use in a couple places, so this  
isn't only a theoretical benefit).  There are a number of ways of  
approaching this:
    * Raw XML data could be put in an inline attachment in the  
iCalendar resource -- simple, but with the slight drawback of  
behavior in other clients likely to display the XML object as an  
attachment
    * Translate OSAF attributes into iCalendar extension attributes  
e.g. "X-OSAF-TRIAGE-STATUS=Now".  This is not much more complicated  
than storing the same data in XML anyway, and has the advantage of  
ideal behavior with non-Chandler clients -- if they don't understand  
the iCalendar extension elements they ignore them , but if they do  
decide to adopt triage status or some other property we define, it's  
possible.  Even stamping attributes can be stored this way.

iCalendar and CalDAV are more extensible than they're given credit  
for, and we haven't really had a problem solving session to overcome  
any potential barriers.

Much of the rest of what you said is applicable to any of these  
approaches (e.g. the need for an information model) but still, these  
considerations might affect some of that decision making.

Lisa


On Jun 6, 2006, at 12:04 PM, Morgen Sagen wrote:

> Now that background sync is wrapping up, it is indeed time to start  
> this discussion up.  Incidentally, I recently talked with Philip  
> (pje) about whether it made sense to use the same 'machinery'  
> within Chandler to perform both general sharing and an upcoming  
> dump-and-reload feature.  We agreed there is enough overlap that  
> we'll go that route, so let's add to the requirements list that the  
> sharing format we spec out will also be used for dumping repository  
> data to a filesystem directory and reading it back in (for use in  
> migrating data between Chandler versions, for example).
>
> Philip suggested we come up with an "information model" for the  
> format -- in other words, how an application accesses/processes  
> data in this format.  Since Chandler is extensible, as the other  
> members of the ecosystem are I'm sure, the format needs to be  
> modeled in such a way that processing can be easily handed off to  
> the proper modules/parcels/extensions.  He gave an example (pje,  
> please correct any mistakes): imagine the app receives some inbound  
> data, and that data is parsed into a dictionary whose keys are  
> namespaces.  Installed extensions could register for the namespace 
> (s) they can process, and through callbacks are given the inbound  
> data to crunch.  This allows an application to process the data it  
> understands, and ignore (but retain/republish) the data it doesn't,  
> which is important because not everyone will have the same set of  
> modules/parcels/extensions installed.
>
> So the external sharing format needs some form of namespace  
> support, whether via XML, or just splitting a file up into  
> namespace-labeled sections.  Each namespace identifies a domain  
> model (aka schema) for the enclosed data.  As for the actual  
> enclosed data, it could be as simple as a table with rows  
> consisting of: (1) UUID, (2) Attribute name, (3) Value.
>
>
>
>
> On May 23, 2006, at 3:29 PM, John Townsend wrote:
>
>> On May 23, 2006, at 3:13 PM, Brian Moseley wrote:
>>>
>>> from the cosmo perspective - i'd like to look at the complete  
>>> list of
>>> requirements from chandler, foxmarks, interop with
>>> ical/evolution/sunbird/lightning, and whatever else i've forgotten,
>>> and assign priorities. i don't want to fall into the trap of  
>>> stopping
>>> on a dime and forgetting about earlier plans because of a flavorful
>>> new feature of the week :)
>>>
>>
>> Agreed. We should invite some of the non-OSAF people like Todd to  
>> join us in this discussion. In fact, anyone who is reading this:  
>> if you know someone who should be involved in this discussion,  
>> please invite them to join us on the Cosmo list for discussion.
>>
>>
>>> btw - i think the non-osaf people on this list deserve to know what
>>> the hell we are talking about!
>>>
>>
>> Ah, ok. So, for those that don't know, here's a brief summary  
>> (feel free to correct me if I get any of this wrong):
>>
>> Up to this point, Chandler has utilized Cosmo as a sharing server.  
>> Chandler has the ability to share collections to Cosmo and current  
>> does that using WebDAV and CalDAV. When Chandler writes data to  
>> Cosmo, it writes out essentially the same set of data in two  
>> different formats: Cloud XML for Chandler use and CalDAV data for  
>> interoperability with other clients like Scooby or Sunbird.
>>
>> Going forward, we would like to change that. Beside the obvious  
>> fact that sharing the same set of data is slow and inefficient, we  
>> eventually plan to deal with other media types when we do sharing.  
>> Some of those media types are known today, some are not. So, to  
>> summarize.. we want to develop a rich sharing format that can:
>>
>> - Satisfy the needs of the projects within the Chandler ecosystem.
>> - Be more efficient than how we are doing it today
>> - The format should be extensible and scalable
>> - The format should utilize standards where possible.
>>
>> Other points to consider are that even though we are sharing a  
>> newer richer format with Cosmo in this plan, we still would like  
>> to maintain interoperability as much as possible. This might mean  
>> that Cosmo has explicit knowledge of the sharing format, parses  
>> it, and creates standards-based data structures on the server (for  
>> example, Cosmo might take in the rich sharing format, store it for  
>> chandler, and then parse it to create a CalDAV collection for  
>> interop use). Again, these are just ideas and we haven't set  
>> anything in motion yet.
>>
>> If you have thoughts on this, now is the time to speak up. Any and  
>> all thoughts are welcome!
>>
>> --> John
>>
>> _______________________________________________
>> cosmo-dev mailing list
>> cosmo-dev at lists.osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev