[Cosmo-dev] Re: Atom Publishing
twl at osafoundation.org
Wed Jun 14 15:48:55 PDT 2006
I agree with what Brian is proposing here.
I'd prioritize GData ahead of Calatom, since GData, while not a
"standard" is actually implemented by a service that people are
using. That's not to say we shouldn't also do calatom, it's just a
preference about which one gets done first.
I also agree with an architecture arranged around converter classes,
this aligns with our evolving notion of Cosmo as a data storage
services that provide adapter/converters to allow for communication
with other clients.
On Jun 14, 2006, at 2:59 PM, Brian Moseley wrote:
> 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
> * 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.
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
More information about the cosmo-dev