[Cosmo-dev] Cosmo and Scooby URLs

[John Townsend]

On Jun 16, 2006, at 1:12 PM, Brian Moseley wrote:

> On 6/16/06, John Townsend <johntownsend at mac.com> wrote:
>
>> the urls could be something like:
>>
>> http://cosmo-demo.osafoundation.org/sharing/<username>/<calendarName>
>> [?ticket=<ticketID>]
>>
>> 1. The default behavior would be to just to Scooby.
>> 2. If accept headers are present, then the request could be forwarded
>> onto to Cosmo.
>> 3. For clients that can't set the accept headers, we can add request
>> parameters:
>>      - ...&render=WebDAV|CalDAV|Atom|WebApp, etc.
>> 4. The ticket part is optional. If you don't specify the ticket, then
>> it just attempts to go to that user's calendar collection.
>
> this does not solve the problem of using the same url for browsers and
> non-browser clients. without a header, query parameter or some other
> token, there is no way for cosmo to know to redirect firefox to scooby
> but to send an icalendar response to ical.
>

Actually, I disagree. The point is that Cosmo doesn't do redirecting  
at all. We encapsulate that knowledge in a separate webapp for the  
ecosystem. This allows Cosmo and Scooby to stay "pure."

Point #3 proposes the query parameter method to solve the problem and  
it eliminates us giving out URLs that point directly to Cosmo  
collections or tickets.

> this discussion raises an interesting question: if it really is the
> ecosystem, stupid, why don't we just combine scooby, cosmo and osafsrv
> into one app?
>

Hmm, bcm lobs a grenade into the room. :-) Seriously, I think this  
idea has some merit actually. Especially in light of the two things:

1. Our emphasis on the ecosystem as the main goal for Beta and 1.0.
2. PPD's view that Scooby is the UI for Cosmo.

> pros:
>
> 1) we could improve the performance of scooby by accessing the
> repository locally rather than over caldav
> 2) there would be no "cleanliness" issue with having cosmo  
> redirecting to scooby
>

I agree with the first one, the second one could still be solved  
using the webapp approach I described above.

> cons:
>
> 1) we'd still have the potential problem of having multiple possible
> responses to a single unparameterized url, depending on the
> capabilities of the requesting client
> 2) it might feel unnatural for those who just want a protocol server
> to also get a calendar ui, and vice versa (altho we could provide
> configuration options to turn each of those features on and off)
>

Not sure this is an issue as long as we provide a way to turn Scooby  
off for those that don't want it. That would still have to be a  
requirement (this is important for clients like FoxMarks and those  
that just want to use Cosmo as a CalDAV server).

> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev