[Cosmo-dev] Cosmo and Scooby URLs

John Townsend 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  
client applications.

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.


--> John

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?...
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
>> 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
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev

More information about the cosmo-dev mailing list