[Cosmo-dev] Cosmo and Scooby URLs

[Jeffrey Harris]

Hi Folks,

> 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.

I don't think it's actually a requirement that the "one url to rule them
all and in the darkness bind them" point to Cosmo.

I think, from all that I've heard said so far from the PPD team, it
would be perfectly acceptable to have Chandler construct a URL that
pointed to Scooby and distribute just that URL.  Bobby's proposal that
we provide various links (with appropriate metadata) to the relevant
Cosmo share would work just fine, if we put that information on every
Scooby page.

Doing this on the URL construction end would require that Chandler know
how to construct an appropriate Scooby URL from the URL of a Cosmo
collection, but that's easily achieved either via some kind of
well-known-path munging or setting a custom property on Cosmo
collections that are linked to a Scooby instance.

On the receiving end, Chandler would have to send a bit more HTTP
traffic and scan the HTML (hopefully XHTML) it receives, but that's not
a heavy burden.

I don't think it's a requirement that iCal users be able to immediately
plug a Chandler sharing URL into iCal's subscribe dialog.  As long as
that URL returns non-techie-friendly HTML, it should be adequate to
include a "subscribe to this calendar in iCal" link.

This would leave us wiggle room if we wanted to repurpose GET on the
collection to do something else, then all we'd need to do would be to
create some other mechanism and have Scooby construct different URLs for
CalDAV clients and iCal.

In summary, I think achieving the illusion that Scooby is the interface
to Cosmo (for Chandler ecosystem users) should be quite doable without
losing request handling purity.  In fact, Cosmo needn't know that any of
this is happening.

Sincerely,
Jeffrey