Re: New URI scheme talk in RSS-land

On Dec 8, 2003, at 8:55, Patrick Stickler wrote:

>
>
> 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.

Absolutely.

The browser needs to hand over the URI of the resource as well as the 
content fetched.    In fact some data formats need the URI for their 
interpretation anyway, in order to resolve relative URIs.

It is *not* a good idea to confuse a reference to a resource with 
instructions as to what to do with it.  With RSS feeds or calendars, a 
goo solution is to ask "this is what it looks like now, do you wnat me 
to track it?".  Note that IE in one version did this for arbitrary sets 
of web pages in its "Bookmark, Save for reading offline, Subscribe" 
functionality which was/is all connected.

The fact that you might want to poll a living document to see how it 
changes and the type of data in the document are really orthoganal, and 
should be kept that way in the protocol and the UI.

This case is very similar to the webcal: (Apple's calendar 
subscription) which has the same problem.

In both cases, while the subscription function needs the URI, it is 
also useful (and fast) to get a current copy of the resource.

If the browsers don't give the app any way of finding the URI now, then 
a hack of course is to put it into the file somewhere.  Then we will 
later have questions as to which is authoritative if they differ, and 
security problems related with that, so it would be  much preferable 
for the extension interface to the Mime type handling app to be fixed 
ASAP.  Suffice to say that it is an ERROR for them to differ. If you 
put a URI in the file, it must be the one you expect people to use  to 
get (have got)  the file.


> [...] 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.

yes

> 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...).

Exactly.  The same applies to calendars, IMHO. And probably all kinds 
of information.

Tim Berners-Lee

Received on Monday, 8 December 2003 10:51:40 UTC