[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [syndication] shared feed lists
Use of a static file for something that could contain QUITE a few URLs is
needlessly punative. You'd be forcing sites to create a static file from what
might be very frequently changing data. Why? So it's easy to make a lazy
request for an index?
The inefficiency comes from forcing the sites offering data into using a fixed
URL. This raises the hassles of using mod_rewrite, Options features and/or
.htaccess files. Why?
Who is this designed to help? What are they doing that's not aided by using a
<link> tag?
As for your claim of a single step, that's bull. You've already got the HTML
page, look at it's contents.
This instead of making a blind stab at what will probably not be present,
raising 404 errors, confusing users and annoying website administrators.
And here's the other benefit to a link tag, you can put them on as many web
pages as you like. So if someone's reading
http://hostingprovider.example.com/users/joe/weblog then they're not force to
step all the way back to http://hostingprovider.example.com/ and get what may be
a completely unrelated file. Instead if there's a page at
http://hostingprovider.example.com/users/joe/weblog/archives/000001.html and
there's an RSS feed or list of feeds that are best suited to being used with it
then the link tag can indicate it.
Otherwise, what're they supposed to do? Start walking up the URL path blindly
stabbing around for:
http://hostingprovider.example.com/users/joe/weblog/archives/default.feedlist
http://hostingprovider.example.com/users/joe/weblog/default.feedlist
http://hostingprovider.example.com/users/joe/default.feedlist
http://hostingprovider.example.com/users/default.feedlist
http://hostingprovider.example.com/default.feedlist
That'd be not just one request but FIVE blindly stabbing around. Raising five
different 404 errors and probably not getting anything useful in the process.
How is this a well engineered solution? What if there /were/ lists at other
points 'up' in the path hierarchy? What mechanism would have to be cobbled up
to indicate whether or not they're 'related' to the other parts of the hiearchy?
Your overly simple idea gets messy in a hurry (but this is not a new symptom)
Instead each page could contain a link tag that might even point to an entirely
different place! As in, we offer users the ability to create their own personal
lists of feeds. They can download them in several different formats. Instead
of the user having to bother creating this thing on their site they could simply
point to the one they publish on ours or some other service.
As in:
http://www.syndic8.com/userinfo.php?UserID=wkearney99&Section=lists
Here I'm not using static files. That and they're my feed lists, not the site
as a whole. Cripes, that'd be obscenely large. We've got 16k feeds we know
about. Should we needlessly publish that big-ass document into a static file
just so your hack will work? Who would we be 'helping' by hemorrhaghing that
bandwidth? Instead our HTML pages (well, most of them) contain already
established standard forms of <link> tags.
Let's not have another half-baked one-off clog up what could otherwise be a
really good idea. A good idea that many folks have suggested before.
In short, putting forth a standard that says 'use a <head> section <link> tag,
appropriately typed, as a pointer to feeds' works out better all around.
-Bill Kearney
----- Original Message -----
From: "Dave Winer" <dave@userland.com>
To: <syndication@yahoogroups.com>
Sent: Tuesday, October 14, 2003 9:49 AM
Subject: Re: [syndication] shared feed lists
> First let's take out the emotionally charged words, blindly, waste, clog up,
> etc.
>
> Do the math. I answered this question in the Q&A. I don't know how to answer
> it again without just repeating the answer.
>
> But let's try anyway. ;->
>
> Assume you look for a link to the directory file in the HTML of the home
> page of the site.
>
> To find the directory, you:
>
> 1. Read the index file.
>
> 2. Look for the link element.
>
> 3. Read the directory file it points to.
>
> In the approach I'm advocating you:
>
> 1. Read the directory file.
>
> Now please explain why is the first approach more efficient.