[Cosmo-dev] Cosmo and Scooby URLs

[Mikeal Rogers]

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.

I forgot an important point. Here we wouldn't return the scooby  
interface directly, we'd simply return a 302 redirect to the scooby  
URL for the same resource.

>
> 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