[Cosmo-dev] Re: Atom Publishing
bcm at osafoundation.org
Wed Jun 14 14:59:20 PDT 2006
On 6/13/06, Elliot Lee <osafoundation at intelliot.com> wrote:
> == Design and Implementation ==
> I need help with figuring out how this would be designed and
> implemented. Atom and GData feeds should be a natural option for
> working with calendar data. Client programs talking to Cosmo over the
> network might POST a request for Cosmo to update from a remote
> calendar or POST the data directly via atompub.
my suggestion is that cosmo should provide read and write access to
its calendars via calatom (replacing the existing atom feed
functionality) and gdata. the main use case for this is to provide
access to the widest possible number of calendar clients, including
desktop clients, scripts, web sites and services, etc. no user
interface is required.
further, cosmo could support the copying of calendars into and out of
its repository using these protocols and the existing ones, as well as
with raw icalendar streams. the main use case for this functionality
is to copy an existing calendar from another service into cosmo, or to
copy an existing calendar from cosmo into another service. there is a
certain amount of user interface required for users to indicate where
to import from/export to and what format/protocol to use.
design wise, adding basic read/write capability over gdata and calatom
should be very straightforward. the existing atom feed code can be
massaged to output the headers and content required by calatom, and
the majority of that code can be reused for gdata output (the main
difference being that gdata uses additional xml elements for each feed
item to represent calendar properties, where calatom uses hcalendar
within the feed item content).
the existing code is basically broken into two areas: 1) the protocol
handler (FeedServlet) which negotiates http, and 2) the cosmo object
model (CalendarCollection) which actually converts stored calendar
data to an atom feed. i'm inclined to suggest that we introduce new
"format converter classes" like so:
* CalAtomConverter (turns an hcalendar event into an EventResource
and vice versa)
* GDataConverter (turns a gdata event into an EventResource and vice versa)
* ICalendarConverter (same for icalendar, probably just wrapping ical4j)
* XCalendarConverter (same for xcal)
and rig up FeedServlet to select the appropriate format converter
based on the used protocol and 1) generate a feed item or set of feed
items out of the requested event or collection (read operations) or 2)
merge a provided event or set of events (and removals) into a calendar
collection, creating the collection of it doesn't already exist (write
the current feed url for a calendar is /feed/atom/1.0/bcm/Calendar/. i
suggest we move to /feed/bcm/Calendar/ and use an Accept header to
signify which format is being used (the calatom and gdata specs
discuss the media types they use), defaulting to calatom. we can
deprecate the existing urls, serving them for now in the same way that
we serve calatom, and remove support for them in a future release.
import/export from a remote service or from a locally provided stream
should reuse the converter code but otherwise behave the same in terms
of generating an output feed or processing an input feed.
security wise, the current feed stuff uses the same configuration
that's used for the dav protocol. this allows ticket access. there
should not be any need to do anything new.
More information about the cosmo-dev