Remote Service

This component provides access to remote calendar content (both, explicitely published calendars and remotely hosted private calendars). The intention is to return data in a known format (i.e. Cosmo collections and items) such that the changes in the Atom feed service are minimal.

Remote Access Objects

One RemoteAccessObject^? serves only one request on remote content at one time. Remote access objects CalDavAccessObject and GDataAccessObject implement the RemoteAccessObject interface. These objects have three important components:

• an HttpClient
• protocol specific methods, Caldav4j high level API in the case of CalDav^?
• a toCosmoTranslator which converts the data in Cosmo collection-item format (most difficult part)

One issue related to the last bullet is the generation of UUIDs for remote calendar resources. In the case of iCal and GCalendar there seem to be solutions, it is a matter of choosing the format. At a first look, in the case of iCal, its afferent UIDs could be used directly, a Cosmo marker could be added to them (this is open for discussion).

Remote Content Service

RemoteContentService is in charge of requests on a remote resource. When such a request is received, a RemoteAccessObject is created and the request is forwarded there. This set-up is similar to the coupling between StandardContentService and the DAO.

This solution has the advantage of allowing for incremental building. This service could later be improved to provide caching and synchronization for remote content (for example, before passing a result to the atom feed service it could make a call on the DAO). Also, it could be a good idea to keep a certain amount of state on the Cosmo server while accessing a remote calendar. Imagine a scenario where authentication is needed, it is prefered that it does not occur each time a remote request is made, therefore the same RemoteAccessObject^? should be used for tha session. This would imply keeping a reference to a RemoteAccessObject^? and assigning this object a time-to-live value. To some extent this could be a good trade-off between memory and availabiliy.

Given the structure of RemoteAccessObjects^? and the way they are created by the content service, this solution has an obvious disadvantage in memory usage. RemoteAccessObjects^? may need to be created very often and it would not be smart to rely on the garbage collector in order to free them from memory. The other problem is due to the embeded HttpClient^? which might end up producing TIME_WAIT connections. It isn't very clear at this point, but one way around these issues could be the presence of a RemoteAccessObject^? pool and a queue for requests. For the time being a simpler approach with only one RemoteAccessObject^? and a queue will be used.

Rants here please:

-- AlexandruDragusin - 26 Jun 2007