[Cosmo-dev] Cosmo and Scooby URLs
twl at osafoundation.org
Thu Jun 15 17:15:15 PDT 2006
On Jun 15, 2006, at 3:46 PM, Mikeal Rogers wrote:
> Right now we have one way tight coupling between the cosmo and
> scooby projects. Scooby _requires_ cosmo, but Cosmo doesn't require
> scooby. Scooby has not plans of interop with other clients, and
> Cosmo does.
> That said, it is important that we prioritize the interaction
> between Scooby and Cosmo over our interop with other clients, but
> if we tightly couple Cosmo to Scooby we sacrifice much of our
> ability, even down the line, to meet our long term goal of interop
> with other clients.
I think that we need to be clear on what the overall priorities are,
especially for beta.
The majority of the discussion around this topic seems to assume that
interoperabiilty, especially based around standard protocols and
formats, is the foremost requirement for Cosmo, Cosmo is the
sharing server for the Chandler desktop and the Chandler web client
(Scooby). It needs to support the sharing/collaboration needs of
those clients. A lot of that sharing is going to be around data
formats that are not standardized. For those data formats, there is
no meaningful definition of interoperability other than, "here's a
network port, we'll give you the data, and here's the format". For
those data formats which have some semblance of standardization, and
here I am thinking of events, tasks, and contacts, Cosmo is the point
of integration/interoperation with other clients (and servers), and
it is here that interoperation is very important.
Personally speaking, I see the beta priorities for Cosmo this way:
1. Features (to support rich sharing, free/busy scheduling, etc)
2. Performance - there is have a lot of work to do here
3. Interoperability - And here I will be controversial. I like
CalDAV and I think it is very important for the long term future of
calendaring. However, for beta, most of the client interoperation
that we need to do is not necessarily with CalDAV, it's with
iCalendar, vCard, and GData. CalDAV is not supported by any widely
distributed calendar client, but I think we should maintain what we
have in service of our longer term goals. CalAtom is blogpostware, so
I don't see it as a serious contender.. So in the beta timeframe,
those would be my interoperability goals.
More information about the cosmo-dev