RE: New URI scheme talk in RSS-land

You want cross-platform?  Well that isn't in the original 
requirements so it will cost more.  :-)

I think I don't understand the problem being posed.

If I click on http://www.tbray.org/ongoing/ongoing.rss 
in Outlook, I get the File download box with the usual 
warnings about content and options.  I can't click on 
feed://www.tbray.org/ongoing/ongoing.rss because Outlook 
doesn't see http:/ and create a control on the fly for 
that as an inline hyperlink.  It seems what Tim is 
asking is for Outlook to recognize feed:/ , turn it 
blue and make it clickable such that it opens the 
RSS client without knowing that .rss is at the end 
of the string.  Is that it?  Is Tim asking not only 
for a new URI type, but for a new URI handler to be 
added to all text display clients so it recognizes 
feed:/ ?

If one is pushing the value to the client as 
in email and wants it to do what I describe above, 
you are right.  If one has the value otherwise, 
one pastes it into a field with a button with script 
logic to microparse the string, then open the RSS client 
and pass it that value, using the usual hyperlink object 
voodoo VBA provides.

len

From: Dare Obasanjo [mailto:dareo@microsoft.com]

I don't follow. What is the cross platform way for a website owner to create
a "control" that knows how to launch arbitrary aggregators on the client
machine and subscribe to a feed. The analogy to this scenario is the mailto:
URI scheme. How would you use a GUI control with event logic to replace it's
traditional behavior when clicked by users on the WWW? 
 
From: www-tag-request@w3.org on behalf of Bullard, Claude L (Len)


Doesn't that conflate the role of the URI as an
identifier and its role as a data value to a
control?  Couldn't they do this by implementing
a GUI control with event logic?  Why should
browser vendors implement yetAnotherURIasClickEvent?

len


From: Tim Bray [mailto:tbray@textuality.com]

RSS feeds are ordinary web resources and have ordinary URIs.  For
example: http://www.tbray.org/ongoing/ongoing.rss is one, and as the
scheme suggests, is typically fetched via HTTP and there's lots of
scope for caching and all the usual helpful HTTP machinery.  However,
there's a lot of talk in the RSS community recently about wanting a new
URI scheme, e.g. feed://www.tbray.org/ongoing/ongoing.rss.  The reason
is that they want to be able to click on one of these things and wake
up the RSS client to read it and potentially subscribe.  You really
can't do this with MIME types because the RSS client doesn't need the
representation, it needs the URI.

Once you've got a new scheme, in popular operating systems it's
straightforward to cause them to be handed to an app of your choice
when clicked on.

In general it seems nuts to create a new scheme for URIs that describe
ordinary HTTP-accessible web resources, but I don't see any other
obviously-good solutions.

Received on Friday, 5 December 2003 16:53:38 UTC