[Cosmo-dev] Cosmo and Scooby URLs

[Bobby Rullo]

Fair enough, you're not really clobbering DAV. But we are already  
using GET on calendar collections to do something else that is pretty  
useful - webcal access to Cosmo.

Also, having the "sharing" page outside of the DAV namespace makes  
more sense to me - why should the page that points you to all the  
other conduits be located in the namespace of one particular conduit?

Bobby

On Jun 14, 2006, at 5:48 PM, Lisa Dusseault wrote:

> The RSS-style idea is much like stuff I've been thinking of for  
> microformats and discovering CalDAV and WebDAV resources, good stuff.
>
> But you're really not clobbering on WebDAV and CalDAV space by  
> using a GET on a collection to retrieve some kind of browser- 
> displayable page which can lead, somehow, to a number of features/ 
> URLs.  The reason GET isn't defined on WebDAV collections is  
> exactly because people do this to help WebDAV and CalDAV URLs that  
> get sent around in email, to be clickable and viewable in the  
> browser too.  We could "define" this but it would amount to "do  
> something that you're probably doing anyway, that we can't really  
> explain in the first place".
>
> Check out www.sharemation.com.   E.g. www.sharemation.com/~milele/ 
> public/images (and most other URLs without parameters) are in the  
> WebDAV part of the namespace, whereas if you go to  
> www.sharemation.com/xythoswfs/webui you're in the WebUI.   But if  
> you do a GET on either of those URLs, you get browser-displayable  
> stuff.  In the WebDAV part of the namespace, it happens that a user  
> can override the default representation by putting an index.html  
> file in their WebDAV collection -- thus at "www.sharemation.com/ 
> ~milele/public/images/crafts" I overrode the default dynamically  
> generated GET response with a crafted image gallery HTML page.
>
> Lisa
>
> On Jun 14, 2006, at 4:35 PM, Bobby Rullo wrote:
>
>> I think the problem that you are trying to solve, John, is  
>> legitimate - namely that of not having the user be confused by a  
>> deluge of sharing URLs that are used for different purposes - i.e.  
>> "Use this url to access my calendar in Scooby, this URL to use in  
>> iCal and this one in Chandler, and this one in Evolution"
>>
>> But I don't think overriding DAV behavior (even if the spec does  
>> leave it undefined) is the right solution, for the reasons  
>> mentioned by Brian as well as some vague queasiness about it just  
>> not feeling right architecturally. It's sort of like doing a SQL  
>> select statement on your RDBMS and getting back a PDF report or  
>> something. Not quite that wrong, but along those lines.
>>
>> The source of confusion here is that URL's are sort of unique in  
>> that they locate resources that humans consume directly sometimes  
>> (html pages), and sometimes locate resource that are only machine  
>> readable (XML, icalendar resources, etc.) We see a URL and we want  
>> to click it or paste it in our browser.
>>
>> Todd and I were hashing this out over IRC and noticed that the RSS  
>> world solves this problem by having "autodiscoverable" links  
>> within a normal (that is, human readable) web page. Why not do  
>> something similar with cosmo? Have one uri space called  
>> "sharing" (eg. the sharing url might be "http://cosmo- 
>> demo.osaf.org/sharing/bobby/HomeCalendar") for instance that  
>> returns an human-readable html page with verbiage like "To view  
>> your calendar in scooby, click here. Copy this link for RSS  
>> readers. Copy this link for ATOM readers. Copy this link for  
>> CalDAV clients like Evolution and Chandler" for humans and for  
>> savvy clients who do autodiscovery have links embedded in the page  
>> like:
>>
>> <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" />
>>
>> Note that I don't believe anyone's defined a way to do  
>> autodiscovery for CalDAV yet, so we'd have to take the lead here.
>>
>> The nice things here are that
>> 	a) You can make Chandler (and Scooby) smart enough to  
>> autodiscover the CalDAV link (or whatever protocol we go with for  
>> Chandler in the end) or consume a CalDAV (or atom or XXX) url  
>> directly, and other clients already know how to autodiscover rss,  
>> atom etc.
>> 	b) You have one place to show off all of Cosmo's conduits!
>> 	c) You're not clobbering CalDAV or anything.
>>
>> Thoughts?
>> (props to Todd for working through this with me)
>>
>>
>> On Jun 14, 2006, at 2:31 PM, Brian Moseley wrote:
>>
>>> On 6/14/06, John Townsend <johntownsend at mac.com> wrote:
>>>
>>>> One thought on this was to have a well-known URL in each collection
>>>> that would provide
>>>> the same behavior. Something like this:
>>>>
>>>> GET /cosmo/home/towns/Work/Work.ics
>>>>
>>>> That would return an iCalendar format file for the entire  
>>>> collection
>>>> and Cosmo
>>>> would do that dynamically.
>>>>
>>>> Would that work for iCal's needs?
>>>
>>> yes, but i have two problems with it:
>>>
>>> 1) it introduces a bogus url that doesn't actually represent a
>>> resource. i'd rather use a query parameter (or even better a custom
>>> header, but this wouldn't work with existing clients)
>>>
>>> 2) it defeats the purpose of having a single url that works for all
>>> dav and caldav clients. chandler and scooby would have to make sure
>>> the user knew to tell their chandler, scooby, sunbird/caldav, et al
>>> using friends about url A and their ical and sunbird/webcal using
>>> friends about url B. to me that is *way* more confusing than having
>>> separate "data" and "web calendar" urls.
>> _______________________________________________
>> cosmo-dev mailing list
>> cosmo-dev at lists.osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>