[Cosmo-dev] Cosmo and Scooby URLs

Brian Moseley bcm at osafoundation.org
Fri Jun 16 13:27:03 PDT 2006

On 6/16/06, Mikeal Rogers <mikeal at osafoundation.org> 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.

to follow on my thought experiment of merging cosmo and scooby: i
don't think there's any fundamental reason that scooby, as a native ui
of cosmo, couldn't also very easily publish calendars to and subscribe
to calendars on remote caldav servers. i also don't see any reason
that pure (non chandler or "integrated scooby") caldav clients
couldn't continue to fully interoperate with cosmo in such a world.

> 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 don't think that's true.

> I think there is a technical solution to the "one url to rule them
> all" scenario that only requires the coupling of cosmo and scooby
> that we already have.
> If the objective is to give one URL to Chandler and non-Chandler
> (Scooby) users we should just give them the url to read or read/write
> the calendar in Scooby. Then Scooby can include logic to hand that
> request off directly to cosmo if it determines that the request came
> from chandler ( we could do this based on 'User-Agent' header, or the
> 'Accept' header, etc ).

the only way this could happen is if cosmo communicates a scooby url
to chandler in some fashion. it strikes me wrong, though, to make
scooby behave as a sort of caldav proxy.

More information about the cosmo-dev mailing list