[Cosmo-dev] Cosmo and Scooby URLs
lisa at osafoundation.org
Wed Jun 21 08:25:49 PDT 2006
On Jun 16, 2006, at 5:16 PM, Mikeal Rogers wrote:
> Ok, I thought of another way to do this that will satisfy everyone.
> Since it's so lost in the thread here is what bobby initially
> <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" />
> Instead of forwarding requests from one app to another, or merging
> them, let's just create another link in cosmo.
> <link rel="alternate" type="application/magic" title="Home Calendar
> (Magic)" href="http://cosmo-demo.osaf.org/magic/bobby/HomeCalendar" />
> In this space we can implement, to the best of our ability, interop
> with all clients via one URL. We can do a mix of Accept and User-
> Agent headers to interop with as many clients as possible and
> implement them on a client by client basis. Then the url still
> states what it's purpose is, and we get out of this multi-protocol
> interop scenario for the 'default' behavior of a root cosmo url.
Using User-Agent headers for the HTTP server to discriminate between
clients has a sad history. This was done in the 90s with Web sites
and regular browsers, which caused some browsers to try to pretend to
be other browsers by mimicking their User-Agent strings. (Some Web
browsers even let you configure exactly what text goes in the User-
Agent string!). Thus the approach taken by servers was quickly made
useless by clients.
It's just too broad a brush, anyway. It seems simple to start out:
"If the client is Netscape, use this tag; if it's IE use that tag".
But when one browser version changes and adds a feature that the
other had before, that approach is mal-adaptable. It's prone to bugs
-- even if the developer catches all the different cases (not just
Netscape and IE; what about Opera), the "else" case is typically a
mishmash of things that don't really behave the same. Keeping a
server up-to-date with User-Agent changes is hard. Handling cases
where the client upgrades it's functionality and FORGETS to change
the User-Agent is impossible.
We've been having lots of discussion on some IETF lists about what
are the feasible ways to shift users from plain web browsing to some
more advanced set of features. There are two and a half ways that
work in practice:
- A new scheme, like webcal, makes the browser look up a scheme
handler application. This approach is discouraged by the Technical
Architecture Group of the W3C (with certain caveats that don't apply
here) and I agree with that position. It suffers from all the
problems of the other approaches and additionally with scheme
collision risks and interoperability problems.
- A new MIME type, like text/icalendar, makes the browser look up
an appropriate document handler application. For a brand new MIME
type, the user often has to figure out, the first time they see that
MIME type, which application to launch. So this still requires the
user to know what application to launch. See for example <http://
- Microformats sometimes works: the HTML markup contains not only a
link, but also a machine-readable annotation on the link saying what
kind of link it is. This requires browser extensions to handle,
today. It may be possible, in the future, to have a general
microformat approach for "link type" that would allow creation of new
types by developers of new applications without requiring browser
upgrade/extension. But even so, it would still require user
intervention, at first sight of a new link type, to say what
application was capable of handling the new link type.
There are other ways that were designed to work for this purpose but
don't due to Web browser extensibility paradigm limitaitons:
- The "Allow" header was for the server to advertise in an OPTIONS
response, what methods worked on a resource. E.g. seeing PROPFIND
there means that the client can then PROPFIND the 'resourcetype'
property. The problem: Browsers don't investigate the OPTIONS of a
resource, and if they do, don't interpret the results in a way that
would shift the user to the new functionality.
- The "Accept" header was for the client to advertise what MIME
types it could handle. Presumably if a new "application/caldav" type
were invented and advertised, the client could advertise it, the
server could notice it and realize that the user could be shifted to
the higher functionality by returning the appropriate MIME type,
yay. But browsers don't offer an extension point for new
applications to say "please, go ahead and offer this in the Accept
header". You'd have to write a FireFox extension to do that (not to
mention the other browsers)
- Any other response header! The server can send any response
header it likes, in OPTIONS or any other response. E.g. every GET
response to a calendar URL could have a "PLEASE-USE-CALDAV: T"
header. The browser would ignore it. Only a plugin would allow the
browser to notice it.
- Any other request header! The client could add any number of
request headers to any method request. Again, today, this would
require the browser to be upgraded.
There is more prior art on this kind of problem than you can imagine,
and no usable and robust solution has emerged. Until OSAF gains the
ability to seriously change browser extensibility paradigms, we're
limited to the same kind of hacks other people have used. We can
offer a list of URLs somewhere (in email or on a Web page) and some
annotations on those URLs. A user-readable annotation for each URL
is required (e.g. "this URL is for CalDAV applications"). A machine-
readable annotation on each URL is a nice gesture of hope for
improvement but mostly useless today.
More information about the cosmo-dev