[Cosmo-dev] Cosmo and Scooby URLs
johntownsend at mac.com
Fri Jun 16 13:00:29 PDT 2006
One of the other possibilities is that we write a separate WebApp
that is delivered along side Scooby and Cosmo that contains all of
the information that hooks cosmo and scooby together. It would
provide "abstract" URLs for all purposes that can be used for all
This would satisfy the requirement of simple URL support for users
while keeping Scooby and Cosmo independent of each other (and keeping
cosmo's DAV support architecturally clean).
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.
Flickr does this for its feed support. They have one URL for
delivering feeds and use the render request parameter as the driver
of the format to render. I know its not exactly the same, but I think
it still might work in this case.
On Jun 16, 2006, at 12:46 PM, Brian Moseley wrote:
> On 6/15/06, Kervin L. Pierre <kervin at adevsoft.com> wrote:
>> Hello Brian,
>> --- Brian Moseley <bcm at osafoundation.org> wrote:
>> > chances of (say) apple ical incorporating
>> > non-standard support for a
>> > cosmo usage of the accept header? :)
>> I was thinking that the standard accept
>> header values could be used?...
>> And the server would specify a default
>> return type.
> by non-standard, i mean there is no mention in the caldav spec of
> using accept headers to determine the format of the response to GET on
> a calendar collection - that response is completely undefined.
> cosmo, chandler and scooby could certainly use the accept header in
> this way, and perhaps other servers and clients would follow suit, but
> without spec support, cosmo can't count on any other client to be able
> to get anything other than whatever the default format is (currently
> text/calendar), or to allow the user to add/modify headers directly.
> so even if we go this route, we need to provide an alternate way for a
> user to direct his client to get alternate formats.
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
More information about the cosmo-dev