Cosmo Feed Design
GData support
Exporting GData means creating a feed in the GData format, based on Atom. Would we use Google's Java Client Library?
http://code.google.com/apis/gdata/client-java.html
Updating with GData means a client writing to an edit URI provided by cosmo. See method update of Class
GoogleService? in the Java Client Library:
http://code.google.com/apis/gdata/javadoc/com/google/gdata/client/GoogleService.html .
APIs: existing code to change
I think this might be implemented in the
FeedServlet? class, so a new class isn't needed. These methods correspond with ones currently used for Atom. Since GData is based on Atom I think
\src\main\java\org\osaf\cosmo\feed\FeedServlet.java
private void spoolGDataFeed(CollectionResource? collection, HttpServletRequest? req, HttpServletResponse? resp ) - similar to spoolAtom10Feed but for GData
\src\main\java\org\osaf\cosmo\model\CollectionResource.java (
CalendarCollectionResource?.java ?)
public Feed getGDataFeed() - similar to getAtomFeed
protected void addGDataFeedEntries(Feed feed) - similar to addAtomFeedEntries
protected Entry getGDataEntry(FileResource? file) - similar to getAtomEntry
constants
public static final String FEED_GDATA = "gdata"';
public static final String FEED_GDATA_URI = "/gdata";
feed publisher interaction
In collection_jsp.java where we have the [subscribe to feed] link: for now, I would change it to:
Subscribe: [Atom] [GData]
Since GData is based on Atom, eventually when we're sure it works it would be replaced by a single XML button, as in Google Calendar (see attached screenshot).
feed subscriber interaction
Subscriber would take the linked URI from above and use it in their PHP, Perl, CGI, JSP, ASP scripts, or feed reader, Google Calendar, etc. I'm not really sure of the practical differences between Atom and GData since they're both compatible with any feed reader..
security -- no change; same as current Atom support
storage -- no change; dynamically generated feed
GData protocol:
http://code.google.com/apis/gdata/protocol.html