[Cosmo-dev] Cosmo and Scooby URLs
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
<link rel="alternate" type="application/atom+xml" title="Home
Calendar (Atom 0.3)" href="http://cosmo-demo.osaf.org/atom/bobby/
<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.
(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