On Dec 4, 2007, at 6:25 AM, Randy Letness wrote:
hank williams wrote:
Can anyone tell me if cosmo is *just* a caldav server as it relates
to
calendar events, or are there extensions.
Also I note a discussion on the website of a cardDav spec. does
cardDav + calDav = cosmo (not including the web UI). In other words
if
one had a caldav and carddav server, would that server be a complete
back end for chandler
Cosmo started out as mainly a caldav server with the thought being
that chandler would be using caldav as the synchronization
protocol. The problem is that caldav's synchronization process was
a little inefficient as it involved sending a bunch of data even if
there were no changes. That, and chandler's data model involved
more than just calendar events pushed us to come up with a new way
of storing the data (as items with stamps and attributes) and a new
protocol to access it (morse code).
So cosmo is not just a caldav server, rather an item store that
supports several protocols of accessing/updating the data (morse
code/caldav/atom/webcal). Chandler for the most part uses morse
code to share data to a cosmo server, but I'm pretty sure it can be
configured to publish data using caldav, meaning you could use
another caldav server as a back end for chandler. I"m not sure if
there are any limitations. Neither cosmo nor chandler supports
carddav yet.
-Randy
The bare minimum required for Chandler to share collections with other
Chandlers is a plain old WebDAV server. In this scenario, publishing
a collection to the server means Chandler MKCOL's a DAV collection and
then PUTs an XML file for each item in the collection; or optionally
Chandler can instead PUT/GET a monolithic .ics file representing a
collection. If you have a CalDAV server, Chandler should support that
too for the most part. By far the most tested path for sharing is the
Chandler <-Morsecode-> Cosmo way.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
