Re: [syndication] shared feed lists

["Bill Kearney" <ml_yahoo@ideaspace.net>]

> 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.

Sure, and don't think I'm just arguing for the sake of arguing, either.  In
those cases do we want syndication to start pushing forth the bad practice of
"blindly look for URL named X" and have those stick-in-the-mud sites start
getting irritated with 404 requests for something that's not there?

This is the prime reason I'm cautious about ideas like this.  Let's not
introduce ways to make the content providers get unduly 'concerned' about
unexpected traffic.  I'm all for beating them up and encouraging them to start
offering RSS.  But I've gotten plenty of negative feedback on the 'sudden
appearance' of thing because of RSS consumption.  I know it's silly, you know
it's silly, but they've got the content and it's always a good idea to work
within their sensibilities /when possible/.

> 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.

I've never gotten any serious resistance to do it.  I've seen more 'concern'
from developers than anything I've ever gotten from content providers.  That's
saying, the people with the data have been willing to do it, it's the developers
doing all the hand-wringing and waffling.

> I'm not sure how those offering data dynamically are burdened than
> those offering it statically.  Can you clarify that point?

How does one take an existing dynamic script and, with no web server reconfig or
cron jobs get that kept in sync as a static URL?   As in, they can't get to
mod_rewrite and the Options on their hosting provider don't make it possible.

> > 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.

Well, let's not give them yet another "don't do it this way" fallback to make it
worse.

> > 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.

Agreed.  Sometimes when they see the backstory on this sort of stuff it gives
them a clue about why it might be worth addressing it.  As in, if they can't do
it for just this then let's try to find ways to tag along with other stuff
that'd be useful in there.  Like geographic data.  Purty pictures of maps and
the like...

> > 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.

A fixed URL tells you nothing about what format it's contents will be.  As in,
if someone wants to offer something a lot less dain-bramaged than OPML a fixed
URL would leave them screwed.

> 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?

Required?  Well, for a simple site index you'd absolutely right that it's a
simple set.  For using /one format for larger purposes/ it might be worth
entertaining the idea of something just a /wee bit/ more robust.   I've been
ruminating on a way to allow different desktop/pda/portal interfaces to share
/really robust/ sets of feed data.  As in, sync your work/home/pda/website feeds
lists with their read/unread and other stats all within the embrace of an
extensible format.  I'm saying that has to happen /before/ site indexes but how
about we pick something that'd really leave room for it?

If we're going to set and example and, as a result, have the masses follow
blindly along, then why not take a shot at making it a good one?  After all we
might only get one shot at it so let's load for bear.

-Bill Kearney