On Mar 2, 2006, at 8:23 AM, Brian Moseley wrote:
On 3/1/06, Morgen Sagen <[EMAIL PROTECTED]> wrote:
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.
this is the heart of the matter, i think. icalendar and vcard are
interop formats. they exist so that software from different vendors
can talk to each other. we don't need to store our data in these
formats - we just need to be able to deliver our data in these formats
to software other than chandler and cosmo, and accept data in these
formats from that other software.
once we accept this premise, we are free to design a data format that
is extensible enough to accomodate changes in chandler's repository
schema, new content types, etc. as long as this format is well
documented, cosmo can implement converters that export this format to
icalendar for delivery to caldav and webcal clients and imports the
format from icalendar from caldav clients. in the future, cosmo can
implement similar converters for vcard+carddav and so forth.
cosmo's only real requirement is that this data format expresses the
same semantic information as icalendar (eg an event's uid, start date,
end date, etc) so that these attributes can be indexed to service
caldav reports.
Ok. Although I've always been hoping for ACID transactions and the
ability to send/receive 'sync diffs', if we decide we're going to
stick with DAV, and the server can convert between a Chandler data
format and the various standards, then that is a huge improvement
over the 'dual-resource' sharing we do today. I also have to
apologize to Brian since he made this suggestion to me a day or two
ago in an email which I completely missed until this morning. So
assuming we go this route, where on the Cosmo roadmap would this
translation feature sit in terms of priority? I hate to put Brian on
the spot about this, but this would be seriously cool and helpful. :-)
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. :-)
i think this is one place where caldav has gotten it wrong. servers
ought to be able to allow non-calendar resources in calendar
collections if they so choose.
caldav takes the prejudiced view (for reasons of compatibility with
certain types of limited datastores) that the only content anybody
will ever want to put in a calendar collection is calendar content,
but clearly this breaks down when adding caldav support to a generic
content repository.
i have implemented "calendar collection" in cosmo as a mixin type. the
primary type of a collection in cosmo is "dav collection" which can
contain any arbitrary resource and on which we can set any arbitrary
property. we can selectively add mixin types like "calendar
collection" and "contact collection" to the collection as desired. the
presence of these mixin types will cause cosmo to behave appropriately
when caldav or carddav is used to access the collection.
if we ignore the caldav restriction that we can't put non-calendar
resources into a calendar collection, hoping that lisa etc will remove
it from the draft ;), then chandler can create these "anything-goes"
collections and stuff whatever data it wants into them, and when a
caldav or carddav client comes along and interacts with one of them,
the collection will behave exactly as that client expects.
+1, (+2 even)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
