Re: shared feed lists
Jeremy Zawodny <[email protected]>
| Newsgroups | gmane.network.syndication.discuss |
|---|---|
| Message-ID | <20031014175836.GB1351@thermal> |
On Tue, Oct 14, 2003 at 12:04:24PM -0400, Bill Kearney wrote: > > It is sufficient if one has the ability to add <link> tags to their > > <head>. But what if you cannot? > > Under what situations would you not be able to do this? What tools in current > use have this limitation? I'm not arguing it's not possible, more that it's an > edge case, not the norm. Based on my experience working more traditional publishing outlets (think about local newspapers, tv/radio stations, web sites like news.com, cnn.com and news.yahoo.com), their publishing technology is often difficult or expensive to tweak, inflexible, or not sufficiently transparent. I'd rather not close the door on the possibility that for some sites it may be much easier to get on the syndication bandwagon by writing a script that updates a little file every hour (or day, or week) than by figuring out how to introduce metadata into their HTML. > > > Where robots.txt works, in that it's intended as a tool that something > > > potentially causing TREMENDOUS amount of traffic can use as a guide, is > useful > > > the same can hardly be said of an index file of this nature. The > favicon.ico > > > thing is little more than just another vendor embrace and extend hack. > > > > The analogy isn't quite right here. favicon.ico generates a lot of > > traffic because most browsers request it. robots.txt is requested by > > most well-behaved robots. This file is intended to be a simple > > bootstrap--a way of finding the feeds. It should be requested > > infrequently and by relatively specific tools. > > What's troubling here is two-fold. Use of a static filename > needlessly burdens sites that offer this data dynamically. I'm not sure how those offering data dynamically are burdened than those offering it statically. Can you clarify that point? > Second it opens the door to using poorly-mannered spiders that go > digging for stuff that's never going to exist. Based on the web logs I've seen, that door has already been open, removed from the hinges, and used as firewood. Many spiders are dumb. There's no getting around that. > Not to mention the idea that if a site's go the data dynamically we > end up forcing them to jerry-rig things in their httpd.conf to > rewrite the static URL to the script. Granted, this is likely an > edge case as well but one perhaps slightly larger than the "can't > alter the head section" group. I don't know about that. There's a lot of content produced by some pretty low tech tools out there. I'm afraid I can't cite specific examples without the danger of pissing off content providers who might be on this list. But it's been my experience that format/template changes are often quite difficult. > Besides, this also raises the hassle of the format being used ending > up being far too limited. If we've got a shot at exposing valuable > information it might as well be thought out. What raises that hassle? I don't understand. My original proposal was aimed at answering the question "what feeds does this site provide?" What other valuable information are you interested in having that also does not belong in the feeds themselves? And how much of it do you believe should be required in this [new] format? > Now, all this said, I think the idea of promoting a set of best > practices that raises the level of feed awareness is a GOOD thing, > technical arguments notwithstanding. I hope we all do. Jeremy -- Jeremy D. Zawodny | Perl, Web, MySQL, Linux Magazine, Yahoo! <Jeremy-LaWf/[email protected]> | http://jeremy.zawodny.com/ Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/