Re: shared feed lists
Jeff Barr <[email protected]>
| Newsgroups | gmane.network.syndication.discuss |
|---|---|
| Message-ID | <[email protected]> |
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" <[email protected]> > To: <[email protected]> > 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-rH/ioLL7x7RWk0Htik3J/[email protected]> >>To: <[email protected]> >>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/