[Cosmo-dev] Cosmo and Scooby URLs

[Mikeal Rogers]

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