[Cosmo-dev] Sharing Format discussions..

[Morgen Sagen]

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