[Cosmo-dev] Cosmo and Scooby URLs

Bobby Rullo br at osafoundation.org
Wed Jun 14 16:35:44 PDT 2006


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.


More information about the cosmo-dev mailing list