[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [syndication] shared feed lists

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@Zawodny.com>  |  http://jeremy.zawodny.com/