[Cosmo-dev] Re: Atom Publishing
osafoundation at intelliot.com
Wed Jun 21 19:38:34 PDT 2006
what uses FeedServlet.java? is it used when the URI is /feed? can I
start by trying to put in another type of feed?
GDataConverter, which converts an event into an EventResource, is for
importing an event from a GData feed, right?
I also want to change /feed/atom/1.0/bcm/Calendar/ to
/feed/bcm/Calendar/. how do the URIs relate to the jsp scripts?
I saw that the feed links are in \src\webapp\WEB-INF\jsp\home\collection.jsp.
On 6/14/06, Ted Leung <twl at osafoundation.org> wrote:
> 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
> > 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
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
More information about the cosmo-dev