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

Re: [syndication] shared feed lists

index.html is NOT part of the web's namespace. Some web servers
happen to return that file when they receive a "GET" at the
root of the server's namespace, that's all.

Hardware, software, and data all have different lifetimes. Also,
those machines contained your personal files, not items built
for worldwide automatic processing. I'd be willing to bet
that you still have some of the data which was originally
created on those machines. If we do a good job of designing
the data then it will survive across changes in hardware
and software. That's all we are trying to do here.

We can build things to last and they might or might not last,
or we can build them quick and dirty and watch as they fall
apart under the weight of poor decisions.

Jeff;

PS - Apple ][ Forever.


Tim Bray is certainly an eloquent person, but he has no clue if we'll be
using the Web in 3000, nor will he ever find out. When I moved in March I
threw out four dumpsters worth of history, there were a bunch of disks
formatted for CP/M in the pile of stuff I threw out. People said things like
that about CP/M too. And the Apple II. Forget it, they're trash now, no one
cares what they called their special files and any time spent arguing over
what they were called was time wasted. And that's something none of us have
very much of, btw.

These things look precious and we'd like to think they live forever, but
they don't. We can argue about this ad infinitum, and then all we get is an
argument and no new software. Hey if I followed your advice, how would I
know where to look for the <link> element? Doesn't index.html clog up the
namespace? Aren't you blindly looking for something wasteful? Hehe. You end
up chasing your tail Jeff.

Dave


----- Original Message -----
From: "Jeff Barr" <jeff@vertexdev.com>
To: <syndication@yahoogroups.com>
Sent: Tuesday, October 14, 2003 10:02 AM
Subject: Re: [syndication] shared feed lists




The efficiency is just part of the issue here. The bigger
one is the fact that picking fixed names for things clogs
up the web namespace. If web developers keep creating fixed
names for things, then this is going to evolve in to a
mess.

The two existing fixed names (favicon.ico and robots.txt) are
seen as pollutants in an otherwise clean naming space.

Tim Bray put this very well when he stated that we are
building a web that should still be viable in the year
3000, and that we should all make decisions with respect
to that timeframe. So imagine the effect of 1000 years
of picking fixed names. Each individual choice seems
fine, but the accumulated weight of those choices isn't
so fine.

Jeff;



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.

Dave



----- Original Message -----
From: "Bill Kearney" <ml_yahoo@ideaspace.net>
To: <syndication@yahoogroups.com>
Sent: Tuesday, October 14, 2003 9:42 AM
Subject: Re: [syndication] shared feed lists





Why is using a <head> section <link> tag not sufficient?

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.

What's 'better' resource-wise?

Pull the HTML page, and from within that already obtained data detect a


link



tag.  Pull the contents referenced by that link tag.

or

Blindly request a link not knowing if it exists or not, waste the


bandwidth and



clog up server error log?

Couple the latter with the horrendously back practices of too-frequent
scheduling and you've got a real potential for problems.

I, and others, have long thought it's better to make informed requests


instead



of blindly stabbing around looking for data that's not ever going to be


present.



The only question becomes agreeing on what attribute value to use for


the


link



tag.

So, with as much respect as you're due, explain why the latter (blind
requesting) is 'better'.

-Bill Kearney


----- Original Message -----
From: "Dave Winer" <dave@userland.com>
To: <syndication@yahoogroups.com>
Sent: Tuesday, October 14, 2003 9:21 AM
Subject: Re: [syndication] RFC: myPublicFeeds.opml





With all due respect, you still haven't provided either a reason not to


do



it this way, or a realistic alternative.

Dave





Your use of Yahoo! Groups is subject to


http://docs.yahoo.com/info/terms/








Your use of Yahoo! Groups is subject to


http://docs.yahoo.com/info/terms/






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