[Cosmo-dev] Cosmo and Scooby URLs
Kervin L. Pierre
kervin at adevsoft.com
Wed Jun 14 18:53:07 PDT 2006
Someone once suggested using the HTTP 'Accept'
Request Header to signal to the server the
return type the client prefers once.
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?
> 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.
>> 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
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
More information about the cosmo-dev