[Cosmo-dev] Cosmo and Scooby URLs
johntownsend at mac.com
Fri Jun 16 13:59:06 PDT 2006
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:
>> 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
>> - ...&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.
> 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.
> 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
More information about the cosmo-dev