W3C home > Mailing lists > Public > www-tag@w3.org > December 2003

Re: New URI scheme talk in RSS-land

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Mon, 8 Dec 2003 10:55:47 +0200
Message-Id: <50C564F9-295C-11D8-8962-000A95EAFCEA@nokia.com>
Cc: <www-tag@w3.org>, <algermissen@acm.org>, "Tim Bray" <tbray@textuality.com>
To: "ext Dare Obasanjo" <dareo@microsoft.com>

On Dec 05, 2003, at 23:51, ext Dare Obasanjo wrote:

> MIME type based dispatch doesn't work in this case

It doesn't work, it seems to me, because of what the browser
is not doing, not because of what it can't do. So, on the surface,
it may seem that MIME types are not enough -- but that is not
the case.

There was a time when browsers didn't support defining helper apps
based on MIME types, and browsers were made more capable in order to
meet a particular need. I don't see this as being any different
a scenario.

I would think that the most economical and generic
solution would be to simply extend MIME type based dispatch to
provide the additional information to helper apps, as needed.

I.e., since you're going to have to modify the client (browser)
anyway in order to support a new URI scheme and related semantics,
why not rather just extend the helper app capability such that one
can specify whether the helper app only cares about the content
body, or whether it also would need e.g. the response header;
i.e. a local redirection of the response to a new breed of more
capable local helper application.

Thus, for a given representation of a given MIME type, most
helper apps will only care (or be able to handle) the actual
content data. Other, more talented helper apps, will be able
to handle (and may actually need) the entire response, with
all headers, etc.

True, that would preclude a few particular (corner) use cases where
helper apps may not care about the content data -- but for the
use case in question here, RSS, I would think that passing off
the response to an RSS client would be the typical thing to do,
so that the client can both add the channel information in the
users "subscription" list as well as syndicate the feed into
the users browser (perhaps the user wants to examine the nature
of the feed before he/she decides to subscribe, and subscription
is done similarly to adding bookmarks in a browser, for content
that is found to be useful...).

Anyway, it seems that one could accomplish the end goals without
the architectural extensions proposed. I think this really is just
a browser capabilities issue, and the solution is to make the
browser more capable, if you want more capable integration between the
browser and other apps; rather than pushing the burden onto the
architecture itself.




Patrick Stickler
Nokia, Finland
Received on Monday, 8 December 2003 04:00:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:40 UTC