RE: [syndication] RFC: myPublicFeeds.opml

["Chad Everett" <yahoogroups@jayseae.cxliv.org>]

I'm sorry to butt in here when I've only got a cursory idea of all the
details involved (like that's any different than any other time I butt in
:), but this page contains an argument that I just don't get.  Maybe I'm
missing something.

Point: Bandwidth costs money.

Point: 404 errors for a fixed file name that does not exist will take up
bandwidth, and thus cost more money.

Assumption: If you don't support a feature, then a 404 error will cost you
more in bandwidth than if the feature is implemented in a different way.
This is where I get lost.

If the file exists at the given location, and only at the given location,
then by not supporting a feature with that name, you're paying the cost of a
404 error.  Admittedly, these could add up if you get a whole bunch of 'em.

But if you instead choose not to support a feature and that feature is
implemented through a link tag, then it would seem that you'd pay even more
in bandwidth costs.  Someone looking through your site for feeds would need
to pull the entire index page in order to parse your link tags and determine
that you don't have what they need.  Comparison here is the size of a 404
error vs the size of a typical index.  I think that even if you have a fancy
custom 404 error page, chances are high that your index will be much larger,
and thus result in much higher bandwidth costs.  If you have to check both
an index and a file location, then obviously your costs would be higher
still.

If someone is already on your site and requests those feeds, then naturally
your costs would be even lower.  But I think the way many people work is to
go out hunting for things.  While there are certainly going to be cases
where someone is on your site and says "show me the feeds", I think it more
likely that you'll see a reader of some sort going to get that information
while browsing another feed, not looking up the data while actually viewing
the page that contains the link tag.  That means pulling the entire index.
Again, higher costs.

Please note that I'm not necessarily arguing for a static file name.  I just
don't seem to understand this as one of the arguments against a static file
name and I'm trying to get it.  While I implemented both a link and the
static name proposed by Dave on my site, I'm pretty undecided on which I
actually prefer.  Luckily my bandwidth is low enough that I don't have to
worry too much about getting killed with those costs.

It sounds like what is needed is a method to determine what someone is
looking for, be it a separate file containing just links to metadata of this
sort or extensions to RSD or something.  Maybe even an interface that could
be queried for the location of the data, and the interface could also tell
the searcher if it wasn't configured, so that the one performing the search
doesn't keep digging everywhere trying to find it if it doesn't get a hit in
the first location.  Adding extra functionality to block that URL if it
keeps searching anyway might be useful for some.

In any case, only that single location is ever queried for anything in that
scenario.  If it's not there, then no looking elsewhere is required.  Not
saying this is an easy solution - but it sounds like the solution everyone
is after.



-----Original Message-----
From: Joe Gregorio [mailto:joe@bitworking.org] 
Sent: Tuesday, October 14, 2003 4:38 PM
To: syndication@yahoogroups.com
Subject: Re: [syndication] RFC: myPublicFeeds.opml


Dave Winer wrote:

> You say it "isn't a good idea" and don't explain why.

http://bitworking.org/news/No_Fishing

	-joe

-- 
http://BitWorking.org
http://WellFormedWeb.org


 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/