[Cosmo-dev] Cosmo and Scooby URLs

[Ted Leung]

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.

Ted