[Cosmo-dev] Cosmo and Scooby URLs
lisa at osafoundation.org
Wed Jun 14 17:48:35 PDT 2006
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.
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.
> (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
More information about the cosmo-dev