RE: New URI scheme talk in RSS-land

Your post seems to be offtopic. That there should be sophisticated mechanisms to talk to syndication servers and retrieve metadata about a feed is definitely an issue but it has nothing to do with this discussion. The problem is "How does a user go to a website such as http://news.yahoo.com or http://www.slashdot.com, who'd like to subscribe to information from these sites in a client aggregator do so in a quick and painless manner?". The current process is click on an icon that represents an RSS feed, copy the URL from the browser address bar, fire up your RSS client and click on the subscribe dialog (if it has one). End users would like to collapse this into one step (click link and the right dialog pops up). 
 
I haven't seen a better answer to this question than the feed URI proposal and besides arguments on philosophical reasons there don't seem to be any signficant demerits. 
 
 
-- 
PITHY WORDS OF WISDOM
Blessed are the meek for they shall inherit the Earth, minus 40% inheritance tax. 

________________________________

From: Michael Mealling [mailto:michael@neonym.net]
Sent: Sat 12/6/2003 11:21 AM
To: Dare Obasanjo
Cc: Dan Brickley; Tim Bray; www-tag @ w3. org
Subject: RE: New URI scheme talk in RSS-land



On Sat, 2003-12-06 at 13:09, Dare Obasanjo wrote:
> If we have a MIME type that always involves invoking a separate application
> when a user clicks on a feed how does one perform HTTP GETs on the feed to
> view the XML content in their browser then? So does this mean servers have
> to use separate MIME types for the same file or that the assumption is that no one will ever want to click on a feed and see the actual content in their web browser? Both seem like gross hacks to me.

Whether or not invoking a separate application is the appropriate action
is left to the application developer. It seems what you are after is an
explicit statement that some information bundle describes what is
necessary for a client application to successfully 'subscribe' to a feed
(irregardless of whether or not that is a push or pull operation). This
information bundle is separate from the bundle that is the actual
content of the feed.

IMHO, RSS (and all syndication methods) seem to be simple examples of
what some call web services, albeit a very RESTful one. Complete with
the probably requirement that multiple message patterns be available
(i.e. there is an app for subscribing to an RSS feed via jabber where
the jabber server converts a pull method to push via IM).

With all of the changes coming about with syndication and the forms its
taking, I would think something like WSDL for syndication with its own
MIME type and then using HTTP URIs to get that particular mime type
would be a) sufficient and b) much more powerful.

In many cases when I would see a 'feed:' URI I would not want to
immediately subscribe to it. I would rather have more information about
the feed (prefered update rate, namespace version, payment information,
etc) first. The action of subscribing to it is something that I as the
user initiate based on that packet of information that describes the
feed.

> Then again I don't have the "HTTP URIs can solve every problem" religion so
> this may just be a problem with me.

Neither do I. But I also think that having to many URI schemes is also a
bad thing, especially when a better solution exists....

-MM

Received on Saturday, 6 December 2003 14:39:42 UTC