Re: feed list format and such

["Roy M. Silvernail" <roy@rant-central.com>]

Please permit a couple of cents' worth.

There's been a great amount of heat (and even some light) thrown back and 
forth on this issue.  FWIW, I don't like the fixed filename idea.  The one 
constant feature of *every* website is the root document.  Placing site 
metadata in the header of the root document is an ideal approach.  The <link 
rel="something" type="something" href="URI"/> syntax is plenty rich enough to 
handle the task.

Those parties that throw the "waste of bandwidth" argument are forgetting 
about the HEAD request. The whole root document does not *have* to be 
retrieved.  Also keep in mind that the single filename approach causes 
problems when a large number of sites are hosted under a common domain.  With 
all due respect to Userland, I think it's unlikely that everyone interested 
in one Userland feed will be interested in all of them, which returns to the 
bandwidth argument, but from the other side.  The <link> header approach also 
absolutely addresses the fishing problem...  every site has a root document 
and they are all named '/'.  Link headers also allow contextual referencing, 
something that does not easily flow from a single-file-per-domain approach.

Those parties wishing to use '/myPublicFeeds.opml' should be free to do so, as 
well.  Put that in your <link> header and everyone gets happy.  Or don't.  It 
doesn't actually matter until you argue that the fixed-filename approach 
should be the *only* way.

Frankly, that's what I get out of this whole flamefest. One side seems to be 
arguing that their limited solution is perfect and should be the One True 
Way, where the other side suggests that There's More Than One Way To Do It 
and offers a way to point to them all (including that single filename).

None of us are prescient.  None of us truly know what the web will be next 
year, let alone in 2995.  It behooves us all not to cast limitations in stone 
this early in the lifespan of the web.  Robots.txt was a well-intentioned 
mistake.  Favicon.ico is a 'Second E' deployed by a single vendor.  Even 
'/index.html' is so 2001.  (hint: how many CMS use PHP?)  Namespace pollution 
is more than just a vanity issue and should be stopped now, before it really 
gets out of hand.  

Above all, don't worry about the clients!  Letting clients drive standards 
just gets you IE.  Concentrate on building a flexible standard that's 
naturally adaptable to as yet undiscovered applications and technologies.
Successful clients will adapt, unsuccessful clients won't, and Darwin's Law 
will be preserved.