[wp-hackers] feed:http://address problem

Owen Winkler ringmaster at midnightcircus.com
Thu May 19 14:17:48 GMT 2005

Mike Little wrote:

> I meant to say *isn't* but you guessed that!

I just thought it was bitter sarcasm.  Good thing I didn't take it 
personally.  ;)

> Yes, you are right, it *would* help wp admins. My response was more to
> say that that message would not be sufficient to "be done with this
> issue"

There are still going to be people that ask "Which button do I push to 
Publish a post?" no matter how well we document it or obvious it seems. 
  I was just hoping to get this particular discussion over with.

> I still think it *should* be changed or rather, as per my suggestion
> earlier, the wording changed to more explicitly state these are not
> ordinary links.

I'll state my case, since nobody is defending feed: as ardently as they 
are poo-pooing it, and then you can all say "Bah!" and continue to rant.  :)

Personally, I prefer the http:// link to feeds because it does not cause 
failure, and the output could potentially be styled to explain to the 
user what to do with it.  However, I realize that feed readers are 
becoming more important for my daily use of the web, and a link in a 
browser that tells my feed reader what to do is more useful to me than a 
link that I have to copy.

Moreover, without the feed: "protocol", the xml that appears is useless 
to a user.  I know the mailto: analogy has been made before, but I'll 
present a different way of looking at it.  Imagine that when you clicked 
a mailto: link, instead of opening your email program, your browser 
displayed routing information to the email address in question. 
Essentially, that's what happens when you click on a feed link, 
especially without XSL to style it.

On the topic of XSL, it's worth mentioning that using strictly http: and 
XSL doesn't allow installed feed readers to capture those links.  Feeds 
would seem like normal html files for display and nothing would trigger 
the feed reader to respond.  Even if you use a custom mime-type, that's 
no good because the browser doesn't pass the feed URL to the feed reader 
application; it passes the feed content.  Feeds are not required to 
contain the URL that generates them.

Now I'm going to explain why I don't think we should change it back.

I really do think that WordPress should take more initiative in pushing 
the technology.  We can't let other software drive the market, even if 
we're not a "business".  Using feed: seems pretty cutting edge, but as 
has been pointed out, it's already supported by many feed readers.  In 
this case we would not be pushing the technology, just catching up to 
where many feed readers already are.

In addition, if we change it back now, we'll just end up putting it back 
when everyone else starts to standardize on it and it becomes common in 
the public mind.  And at what point would we decide that it's a common 
thing?  Please not by having another discussion such as this every few 
months.  Let's just do it now and get the public behind the idea of 
easier to use feeds.

Finally, I don't think anyone has bothered to reference these or 
annotate them, so here they are:

URI of "feed:" RFC -

URI of "URI" RFC -

Note that "feed:" is not a protocol like HTTP, it is a URI scheme that 
tells a program that the protocol is either HTTP (if specified as 
"feed:example.com/feed/"), or HTTP or HTTPS (if specified directly as 
"feed:http://example.com/feed/" or "feed:https://example.com/feed/"). 
The protocol can be specified in the URI to avoid having to register an 
additional scheme handler, as has been jokingly remarked upon elsewhere 
in this thread.

Yes, it looks funny, but there is an actual reason for it.  If you don't 
like the way the protocol specifier looks and you're not using SSL to 
provide your feeds, you can change it to the pretty 
"feed:example.com/feed/" and still comply with the spec.  Read the spec, 
it's short.

Check out this URI as a jumping-off point for other online discussion on 
the use of feed: and whether it's a good idea:

I stand by the assertion that it's in WordPress' best interest to at 
least inform WP admins (via the Dashboard) what the ultimate feed: 
decision is, how we arrived there, and what they can do if they don't 
like it.  Besides that, it would be nice to have volume in the Dashboard 
besides WordPress release announcements.  People might realize that 
there are intelligent folks (everyone contributing to this thread) 
thinking about even the smallest details of WordPress and blogging (like 
this issue, IMHO) between releases.  When considering the issue of "How 
do we reduce support questions?" it occurs to me that the dev blog could 
be used less sparingly.  A "support issue of the week" thing might be 
cool.  Tangental.

Bah.  Should've written this as a post.  Maybe I'll write up a "What's 
this 'feed:' thing?" post instead.  Is there a Codex page already?


More information about the wp-hackers mailing list