[Cosmo-dev] Re: Atom Publishing

Ted Leung 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.

Ted

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  
> 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
> ops).
>
> 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.
>
> thoughts?
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev



More information about the cosmo-dev mailing list