The Chandler/Cosmo sharing format

I want to get people's opinions on the format Chandler
should use  
when publishing items to Cosmo.  I'll begin with an
overview of the  
current state of Chandler/Cosmo sharing:

When Chandler publishes an item collection, it creates a
CalDAV  
calendar collection (which contains .ics resources for each 

CalendarEvent in the item collection) and a
".chandler" subcollection  
(which contains .xml resources for all items in the item
collection,  
even the CalendarEvents).  The .xml resources are in our own
flavor  
we refer to as "cloud xml", and it's tied
closely to our internal  
domain model (PIM schema).  Each .xml resource contains the
shared  
item's kind (actually its python class), its UUID, and each
shared  
attribute/value pair.  If there are other items in the main
item's  
"sharing cloud", then those items are included
in the XML too.  In  
the case of CalendarEvents, we simply leave out the
attributes that  
are represented in the iCalendar resource, so we don't
duplicate data.

Here's an example of the current "cloud xml"
which defines a  
CalendarEvent and its organizer (a Contact item in the
event's  
sharing cloud):

<?xml version="1.0"
encoding="UTF-8"?>

<CalendarEvent version='2'  
class='osaf.pim.calendar.Calendar.CalendarEvent'  
uuid='caaa1210-6cd9-11da-9e5b-000a95bb2738'>

<icalUID>caaa1210-6cd9-11da-9e5b-000a95bb2738</ical
UID>
    <organizer>
       <Contact class='osaf.pim.contacts.Contact'  
uuid='aa79fff0-6cd9-11da-9e5b-000a95bb2738'>
          <emailAddress></emailAddress>
          <contactName>
             <ContactName
class='osaf.pim.contacts.ContactName'  
uuid='aa798c14-6cd9-11da-9e5b-000a95bb2738'>
                <firstName>Chandler</firstName>
                <lastName>User</lastName>
                <createdOn>2005-12-14
11:41:48.467422</createdOn>
             </ContactName>
          </contactName>
          <displayName>Me</displayName>
          <createdOn>2005-12-14
11:41:48.471043</createdOn>
       </Contact>
    </organizer>
    <displayName>New Event</displayName>
    <createdOn>2005-12-14
11:42:42.480434</createdOn>
</CalendarEvent>

The benefits to what we have now are:

1) We have a general purpose method for sharing *anything*
between  
Chandlers, including binary Lobs (we can share Photos today
for  
example); serializing an item is simply determining which
attributes  
to share (based on sharing clouds), and stepping through
them one by  
one, serializing each value.  References to items in the
cloud are  
handled by recursion.
2) It's not much work to specify which attributes should be
shared  
when a new kind is defined (you just add those attributes to
the  
kind's sharing cloud)
3) The UUID of a shared item is the same on different
Chandlers  
sharing that item
4) We can still interoperate with other CalDAV clients,
since we  
import/export .ics resources
5) It's easy to support stamped items; the attributes from
the  
various mixed-in kinds can all be included in the XML

The drawbacks are:

1) Since the sharing format is tied to our schema, two
different  
releases of Chandler won't be able to share the same
collection if  
the schema changes in an incompatible way
2) We have to publish two different resources to share a
single  
CalendarEvent (or any item that is stamped as an event);
this causes  
problems when, for whatever reason, there is a .xml resource
on Cosmo  
without a matching .ics resource
3) Publishing two different resources for each item takes
twice as  
long 
4) We're not using 'standard' formats for kinds other
than CalendarEvent

So let's set out some goals for the sharing format...

1) The format should not be so tied to our domain model as
to be  
changing with every Chandler release.  The format should be
'long  
lived' like iCalendar.  This would allow different Chandler
versions  
to share a collection.

2) The format should be extensible to support new data types

3) We should strive to use existing standards.  Some obvious
ones:
    - test/vcard			vCard v3.0		http://www.ietf.o
rg/rfc/rfc2426.txt
    - text/calendar		iCalendar		http://www.ietf.o
rg/rfc/rfc2445.txt
    - text/message		MIME Message	http://www.ietf.o
rg/rfc/rfc2045.txt

4) The format should support our notion of stamping (where
an item  
can of multiple types simultaneously)

5) We shouldn't have to publish multiple resources to share
a single  
item

Issues with these goals:

1) We need to decide on some formats and stick with them
long term.   
Our domain model is still in a bit of flux, so too might the
sharing  
format(s).  Hopefully the schema will settle down in 0.7.

2) We trade off the general-purpose import/export conversion
for kind- 
specific converters that would have to be written, just like
Jeffrey  
did with ICalendarFormat+vobject; however, in some cases
this is  
trivial like for email since we already persist the raw MIME
message

3) If we want to share an attribute that doesn't fit in
with these  
standards, what do we do?  We solved this by using our own
XML  
schema, and I suppose we could continue to do this, for
attributes  
which don't fit a standard.

4) We'll need to be able to store multiple of these
'standard'  
representations within a single DAV resource, which means we
would  
need to define some metadata which 'wraps'  the
kind-specific  
representations, something like:

<Item
uuid="56202724-7e20-11da-89f7-c9a551df6980">
    <Data mimetype="text/calendar">
	BEGIN:VEVENT
	DTSTART;TZID=US/Pacific:20050913T073000
	STATUS:CONFIRMED
	SUMMARY:New Event
	UID:fe033476-249e-11da-d1a9-000a95bb2738
	DTEND;TZID=US/Pacific:20050913T190000
	END:VEVENT
    </Data>
    <Data mimetype="text/vcard">
	BEGIN:VCARD
	FN:Sagen;Morgen
	N:Morgen Sagen
	TEL;TYPE=WORK;VOICE:+1-415-555-1212
	END:VCARD
    </Data>
</Item>

Now that I've typed this, I wonder if it really is
worthwhile to use  
'standard' formats if we have to wrap them in this way. 
No client  
besides Chandler will understand this anyway.  There is
SyncML, which  
does something like this, but I don't know that it supports
multiple  
<Data> bodies per <Item> like we require.

5) If we go with CalDAV, I can't find a way around this
problem.  I  
thought maybe we could get by with sticking all
non-CalendarEvent  
attributes into DAV properties, but CalDAV doesn't let me
PUT non-ics  
resources in a calendar collection, so we'd only be able to
share  
CalendarEvents.  We could just do calendar sharing and that
would  
make things easier, but that's not very cool.  

So I'm torn on how to proceed with this.  On one hand,
using standard  
formats is good, and we have the most important one
(iCalendar)  
covered.  On the other hand, there may not be a big benefit
in trying  
to also use 'standards' for the other data types since we
would have  
to wrap them in non-standard ways (bundling them up within a
DAV  
resource).  Clearly we need to decouple the sharing format
from the  
domain model so that different Chandler versions can share
the same  
Cosmo collection, and that is one of my 0.7 goals.

Thoughts?   Solutions I've overlooked?

Thanks,
~morgen

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev"
mailing list
h
ttp://lists.osafoundation.org/mailman/listinfo/dev

The Chandler/Cosmo sharing format

Thread: The Chandler/Cosmo sharing format