[wp-hackers] feed:http://address problem
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
> 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
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,
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
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