[Cosmo-dev] Cosmo and Scooby URLs

Mikeal Rogers mikeal at osafoundation.org
Fri Jun 16 17:16:06 PDT 2006


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.


More information about the cosmo-dev mailing list