[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [syndication] RFC: myPublicFeeds.opml
- To: syndication@yahoogroups.com
- Subject: Re: [syndication] RFC: myPublicFeeds.opml
- From: Jeremy Zawodny <jeremy@zawodny.com>
- Date: Tue, 14 Oct 2003 11:13:35 -0700
- In-reply-to: <033101c3926d$09f02710$200ca8c0@wkearney.com>
- References: <20031014153741.GB585@thermal> <033101c3926d$09f02710$200ca8c0@wkearney.com>
- Sender: Jeremy Zawodny <jzawodn@thermal>
- User-agent: Mutt/1.5.4i
On Tue, Oct 14, 2003 at 12:05:49PM -0400, Bill Kearney wrote:
> > I think it's important to use a well-known location as a fall-back
> > mechanism. If a site provides a reference to the XML file in a <link>
> > tag, then aggregators/spiders/bot should use it. Only if there's no
> > hint of a feed directory should they consider issuing a separate
> > request.
>
> What's the use case for this? Spiders or individual aggregators?
Both. Any piece of software that would like to discover the list of
feeds offered by a site/organization/entity.
> > The need for a well-known location is clear in my mind. There are a
> > lot of organizations and content management systems that do not make
> > it easy to add arbitrary content to <head> section of their documents.
>
> Which ones?
See my previous note on that. I've not made it a habit of asking
which CMS organizations use. If I had done that, I'd have a list that
I'd be happy to share.
> > And many will not want to regenerate megabytes of HTML that's already
> > sitting around. They may not even have an easy way to do so. We
> > should not raise the bar to entry too high.
>
> Is yahoo one such example?
Yes.
> I'd argue that the root page of a website, the likely place to have
> such a link, is something that's already being regenerated on a very
> frequent basis.
It is. But I'm more worried about other pages. Think of it from the
average user's point of view. They're looking at a page on
news.yahoo.com (or cnn.com or news.com or whatever). Why shouldn't
their browser or aggregator present a "Subscribe" button that Just
Works regardless of whether they happen to be viewing a page that
someone thought to embed a <link> tag in?
> Likewise, putting data into proper places is hardly any sort of
> unrealistic burden.
Again, it's not the proper places I'm worried about. It's the oddball
ones, like our news help pages. Or our feedback pages. They're still
part of Yahoo News but they're not where you'd expect RSS feeds to be
advertised.
> The process here would be a fallback of 'if the page you're
> examining doesn't have the <link> then look at the root page for the
> site and use that one'. The trouble here is you end up making a
> statement about things that might not be accurate.
It may not be accurate. You're right. I freely admit that this
doesn't solve the problem for 100% of cases. And I suspect that
nothing will.
> As in a user's own weblog page doesn't have the link element. The
> base hosting provider's page has links to completely unrelated
> material (and might not even /list/ the user's data). The semantics
> of falling back are more problematic than it might first appear.
Weblogs already have RSD. This is for entities providing multiple
feeds. Non-weblogs in many cases. I'm not saying that LiveJournal
couldn't use this, but I'm not sure why they would.
> > To summarize, the reasonable compromise seems to be:
> >
> > 1. Examine the page for a <link> tag that points to the mythical
> > "feeds.xml" file and use it if it's there
> >
> > 2. In the absence of any <link> tag, look in the well-known
> > fall-back location.
> >
> > If this sounds familiar, it's how many aggregators perform
> > auto-discovery today.
>
> No, existing readers depend the link tag for this.
There is evidence to the contrary. Jeff Barr, for example, mentioned
that Syndic8 will probe well-known URLs in some cases. And we have
similar technology at work. Why? Because the goal is to get at the
feed whether or not the tool advertises one by default or the author
knew how to enable it.
> The only trouble with your scenario is as it's likely to be
> implemented there won't be an effective range of examples following
> the suggested behavior offered in your example 1. It'll just end up
> being another horrible waste like favicon.ico.
That's certainly a danger in doing this. I won't deny it.
On the other hand, and this is not a justification, the presence of
these 404s may help show the demand for RSS/RDF/Atom/whatever content.
> > The impression I have is that the anti-namespace-pollution folks (such
> > as Tim) were willing to agree that a fall-back location was a
> > reasonable compromise. But that may be wishful remembering on my part
> > too.
>
> Well, what's setting the example here? If a site like Yahoo wants
> to do something like this isn't it worthwhile to have them make a
> good example? It's not like it'd be any sort of penalty for them to
> do this properly.
Agreed. In fact, we'd like to implement the preferred solution and
then publish information that other publishers can use to follow
suit. We want to get behind syndication and push. But we'd like to
get this problem solved first.
I suspect that Jeff could help make sure that Amazon.com does the
right thing here, too. But I don't claim to speak for him.
Jeremy
--
Jeremy D. Zawodny | Perl, Web, MySQL, Linux Magazine, Yahoo!
<Jeremy@Zawodny.com> | http://jeremy.zawodny.com/