[Cosmo-dev] Cosmo and Scooby URLs

[Mikeal Rogers]

After some discussion with Bobby and John there were some enhancement  
and issues brought up and solved that I would like to incorporate  
into my original proposal.

Proposal;

Cosmo would have multiple url's to the same resource, each of which  
representing the sharing format that it should be returned. In  
addition to those urls there is a "magic" url that will return a HTTP  
301 redirect url to the appropriate sharing format.

For reference:

<link rel="alternate" type="application/atom+xml" title="Home  
Calendar (Atom 0.3)" href="http://cosmo-demo.osaf.org/atom/bobby/ 
HomeCalendar" />
<link rel="alternate" type="application/rss+xml" title="Home Calendar  
(RSS)" href="http://cosmo-demo.osaf.org/rss/bobby/HomeCalendar" />
<link rel="alternate" type="application/caldav" title="Home Calendar  
(CalDAV)" href="http://cosmo-demo.osaf.org/dav/bobby/HomeCalendar" />
<link rel="alternate" type="application/webcal" title="Home Calendar  
(Webcal)" href="http://cosmo-demo.osaf.org/webcal/bobby/HomeCalendar" />
<link rel="alternate" type="application/magic" title="Home Calendar  
(Magic)" href="http://cosmo-demo.osaf.org/magic/bobby/HomeCalendar" />

Example Scenario;

-> Chandler client connects to http://cosmo-demo.osaf.org/magic/bobby/ 
HomeCalendar?ticket= with (User-Agent : 'chandler-0.6.1').
<- Cosmo returns 301 redirect to DAV (until sharing format is  
finalized??) http://cosmo-demo.osaf.org/dav/bobby/HomeCalendar? 
ticket= | Chandler stores http://cosmo-demo.osaf.org/dav/bobby/ 
HomeCalendar?ticket= for it's own use, but when telling others about  
this calendar sends http://cosmo-demo.osaf.org/magic/bobby/ 
HomeCalendar?ticket=

-> Mozilla Firefox connects to http://cosmo-demo.osaf.org/magic/bobby/ 
HomeCalendar?ticket=
<- Cosmo returns 301 redirect to Scooby , http://cosmo-demo.osaf.org/ 
scooby/bobby/HomeCalendar?ticket=

-> iCal connects to http://cosmo-demo.osaf.org/magic/bobby/ 
HomeCalendar?ticket=
<- Cosmo returns 301 redirect to http://cosmo-demo.osaf.org/webcal/ 
bobby/HomeCalendar?ticket=

-> Unknown client connects to http://cosmo-demo.osaf.org/magic/bobby/ 
HomeCalendar?ticket=
<- Cosmo returns 301 redirect to Scooby , http://cosmo-demo.osaf.org/ 
scooby/bobby/HomeCalendar?ticket=

By only sending 301 redirects we severely cut down on the load that  
the "magic" url handler has to do, since nearly every http client  
will follow the redirect and store the redirected url.

Since the scooby redirect is returned if the client is unknown we  
don't break any autodiscovery, because the scooby page has links to  
view/subscribe to the rss,caldav, etc.

Open questions:

Is it better to return 301 instead of 302? In the case of 302 the  
client will likely not store the redirected url, is this good or bad?

Is there a better more extensible way to do this?

Is it that hard for chandler to manage using one url for subscribing  
and another when telling others about this calendar?

-Mikeal

On Jun 16, 2006, at 6:45 PM, Mikeal Rogers wrote:

> I think RSS, in this case, is far less of an issue. PPD hasn't  
> stated a need for RSS client interop w/ this "one url". We're  
> really looking for one url to do:
>
> Firefox/Safari/IE -> Scooby
> Chandler -> CalDAV, but eventually the sharing format
> Evolution -> CalDAV
> iCal/Google -> webcal
>
> We won't go in manually and support EVERY RSS client, just like we  
> don't support every language in chandler, just the ability for  
> someone in the community to do so. And if someone contributed it we  
> wouldn't turn it down.
>
>> Playing the Accept/User-Agent header game is dicey
>
> Yup, it's a hack at best. But so are most of the other solutions to  
> this problem. This would at least isolate the solution so that the  
> supporting architecture doesn't change anything else about our  
> products. If there are conflicts or issues with how we figure out  
> what format our responses should be in at least it's isolated.
>
> Let's just admit it, getting one URL that means different things  
> based on the request clients is going to _have_ to be something a  
> bit dicey :)
>
>> How would such a magic url work? How would it differentiate  
>> between clients?
>
> This is a question for all the implementations of the "one url"  
> scenario if we want to support more than just our clients with it  
> (iCal has been suggested). But we know what User-Agent's belong to  
> the clients we care about supporting, and we know what format they  
> would like the response in. If we don't find one we can either,  
> default to some logic on the Accept header or just redirect them to  
> scooby.
>
> Also, I'd like to reiterate that this is in _addition_ to having a  
> separate space for each supported sharing format. http://cosmo- 
> demo.osaf.org/rss/bobby/HomeCalendar will _always_ return RSS, so  
> it's not like we're breaking cosmo interop with other clients.
>
> -Mikeal
>
> On Jun 16, 2006, at 6:22 PM, Bobby Rullo wrote:
>
>> How would such a magic url work? How would it differentiate  
>> between clients?
>>
>> The idea in my original proposal was that you get a single human  
>> readable web page with all your sharing options contained within it.
>>
>> For clients that can do autodiscovery (like many if not most  
>> current rss readers/aggregators) this url already IS the "magic"  
>> url in that both humans and machines can consume it directly.
>>
>> Playing the Accept/User-Agent header game is dicey - most clients  
>> AFAIK don't specify that they'll only accept say RSS or webcal and  
>> we don't want to be maintaining a list of user-agents that we have  
>> to update everytime a new RSS reader comes out or something.
>>
>> Bobby
>>
>> On Jun 16, 2006, at 5:16 PM, Mikeal Rogers wrote:
>>
>>> Ok, I thought of another way to do this that will satisfy everyone.
>>>
>>> Since it's so lost in the thread here is what bobby initially  
>>> suggested:
>>>
>>> <link rel="alternate" type="application/atom+xml" title="Home  
>>> Calendar (Atom 0.3)" href="http://cosmo-demo.osaf.org/atom/bobby/ 
>>> HomeCalendar" />
>>> <link rel="alternate" type="application/rss+xml" title="Home  
>>> Calendar (RSS)" href="http://cosmo-demo.osaf.org/rss/bobby/ 
>>> HomeCalendar" />
>>> <link rel="alternate" type="application/caldav" title="Home  
>>> Calendar (CalDAV)" href="http://cosmo-demo.osaf.org/dav/bobby/ 
>>> HomeCalendar" />
>>> <link rel="alternate" type="application/webcal" title="Home  
>>> Calendar (Webcal)" href="http://cosmo-demo.osaf.org/webcal/bobby/ 
>>> HomeCalendar" />
>>>
>>> Instead of forwarding requests from one app to another, or  
>>> merging them, let's just create another link in cosmo.
>>>
>>> <link rel="alternate" type="application/magic" title="Home  
>>> Calendar (Magic)" href="http://cosmo-demo.osaf.org/magic/bobby/ 
>>> HomeCalendar" />
>>>
>>> In this space we can implement, to the best of our ability,  
>>> interop with all clients via one URL. We can do a mix of Accept  
>>> and User-Agent headers to interop with as many clients as  
>>> possible and implement them on a client by client basis. Then the  
>>> url still states what it's purpose is, and we get out of this  
>>> multi-protocol interop scenario for the 'default' behavior of a  
>>> root cosmo url.
>>>
>>
>>
>>
>>> When chandler publishes it sends down a bunch of urls to  
>>> chandler, but the one displayed to the user is always the magic URL.
>>>
>>> -----------------------------------------------------------
>>>
>>> On merging cosmo and scooby.
>>>
>>> I agree that there are some benefits to merging scooby and cosmo,  
>>> such as directly connecting to the repository. But I can't think  
>>> about how difficult my life would be if we _removed_ the current  
>>> cosmo web ui, it's a very important administration tool and will  
>>> probably become even more important the more cosmo supports new  
>>> sharing formats. If we do go in the "merge" direction I would  
>>> just ask that, as has been suggested as a feature, turning off  
>>> scooby is an option and we retain the current cosmo web ui.
>>>
>>> Also let's talk about the product planning and development  
>>> implications of merging the development cycles for cosmo and  
>>> scooby. The last time we tried to just line up the two releases  
>>> we held onto release bits of scooby for like 6 weeks. And from my  
>>> end, whenever releases land within a week of each other I cringe  
>>> knowing that QA resources will be stretched so much between the  
>>> releases in a short timeframe.
>>> _______________________________________________
>>> cosmo-dev mailing list
>>> cosmo-dev at lists.osafoundation.org
>>> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>>
>> _______________________________________________
>> cosmo-dev mailing list
>> cosmo-dev at lists.osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev