[Cosmo-dev] Cosmo and Scooby URLs

Wed Jun 14 18:53:07 PDT 2006

Hello,

Someone once suggested using the HTTP 'Accept'
Request Header to signal to the server the
return type the client prefers once.

Best regards,
Kervin

Bobby Rullo wrote:
> 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
>>
> 
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
> 