[Cosmo-dev] Cosmo and Scooby URLs

[John Townsend]

On Jun 14, 2006, at 2:22 PM, Jeffrey Harris wrote:

> Hi John,
>
>> We could change that behavior to make Cosmo redirect to a Scooby URL
>> in the GET of a entire collection case. That would help to solve the
>> goal of one URL to rule them all :-)
>
> This is what I've been thinking we'd probably do, hopefully we can  
> make
> it work.
>
>> - Cosmo has no knowledge of Scooby at this point. To redirect to a
>> Scooby URL, we would have to have knowledge of a running Scooby and a
>>  URL to it. Its possible that someone might want to run Cosmo without
>>  scooby. We'd have to make sure they would configure the server
>> easily to handle that case.
>

Since we always ship Cosmo with a Scooby instance, we would probably  
default
to having Cosmo know about Scooby (via a properties file?) and it  
would be easy
for someone who wants to run Cosmo without Scooby to configure the  
server
appropriately.

> Hopefully Cosmo can be configured to have pluggable behavior for
> something like this.  It could continue to default to returning an ics
> file if no plugins were present, but if Scooby was, it would do  
> what we
> want.
>
>> - Is anyone depending on the current Cosmo GET behavior? How can we
>> continue to provide this functionality? - What else have I forgotten?
>
> This behavior is the way we currently expose CalDAV collections for
> read-only access by Apple's iCal, so I think we'd need to expose  
> such a
> feature in some other way.
>

One thought on this was to have a well-known URL in each collection  
that would provide
the same behavior. Something like this:

GET /cosmo/home/towns/Work/Work.ics

That would return an iCalendar format file for the entire collection  
and Cosmo
would do that dynamically.

Would that work for iCal's needs?

--> towns