[Cosmo-dev] Cosmo and Scooby URLs

Bobby Rullo br at osafoundation.org
Fri Jun 16 18:22:46 PDT 2006

How would such a magic url work? How would it differentiate between  

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.


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

More information about the cosmo-dev mailing list