This is a rather long article.
=====
I wrote:
> > I, for one, dislike the naming convention of using nonunique filenames...
> > I'd like to lobby for a name convention change, so that the names at the
> > file level are unique across the entire news.answers directory at
> > rtfm.mit.edu. The "part#" could be used as a suffix.
Jonathan Kamens' reply in reproduced below, set off by ">", with
rebuttals interspersed.
> Speaking with my "*.answers chief moderator" hat on (a hat which,
> incidentally, I will be wearing for only a few more months), I can say
> that it's unlikely that this convention will change.
Thanks for your reply. You fail to convince me, however. My reactions
follow.
> The "/part1", "/part2", "/diff", etc. convention was the de facto
> standard for archive names before *.answers was created, and I see
> little reason to change it.
The prior existance of a convention is not sufficient justification to
keep that convention in place. For example, filenames at one time were
limited to fewer characters than they are currently, and to uppercase
characters at that; there was, at the time, little reason to change the
convention except that it didn't meet the desires of the users -
To quote Mr. Kamens (see below),
"One huge advantage of computers is that they can be made to
perform algorithmic, menial tasks repeatedly and correctly";
therefore one could have written an application to generate the 36^8
filenames possible from uppercase letters and digits on systems limited
to 8-character filenames, and the user would only have had to remember
that, say, IUYBH8YT contained one's CV/resume. Since users found that
to be inconvenient, it changed. The point is, as capabilities and
systems change and as experience accrues, things that depend on those
factors change as well.
> Doing what you suggest would either (a) introduce unnecessary
> redundancy into archive names and force people to type more in order to
> retrieve files (if we decided to leave the directories in place and
> just duplicate the directory names at the file level, e.g.,
> "foo-faq/part1" becoming "foo-faq/foo-faq.part1"),
If changing the convention would make the archive overall easier to use
for the users of the archive, this argument fails. The tradeoff here
is:
fewer characters to type to get a particular file (present convention)
vs.
unique filenames to ease the task of recovering many FAQs at once
(my suggestion).
I don't think I've ever typed in the name of the FAQ I wanted to
recover; rather, I have cut-and-pasted the name from a list of the
available FAQs, so the length of the fully-qualified filename doesn't
matter to me. (That said, I'm working from a sample space of n=1, and
I have no idea what the common practice is.) Perhaps a faq-maintainers-
wide discussion of access techniques is in order to shed light on the
naming convention question.
And just to point out a divergence between the current convention and your
assertion about fewer characters: many of the FAQs have the phrase
"-faq" as part of their names. Given that they are in the news.answers
hierarchy, what can they be but FAQs?
> or (b) turn the entire *.answers hierarchy into one big directory
> which would be far more difficult for humans to browse and slower for
> machines to maintain.
No argument here (imagine that - a point of agreement!); a single
directory would probably be a bad idea.
> I entirely disagree with your assertion that the current naming
> schemde makes it "cumbersome to recover FAQs in an automated way."
> One huge advantage of computers is that they can be made to perform
> algorithmic, menial tasks repeatedly and correctly. If you're
> retrieving FAQs automatically, you only have to fix your retriever
> once to make it understand directories in the hierarchy and handle
> them in any way you want (creating them locally and putting retrieved
> files in them, using directory names as prefixes of the file names,
> etc.). Therefore, your claim that automated FAQ retrieval is made
> more difficult by the current naming scheme makes no sense to me.
Yes, computers perform menial tasks well; but sometimes the appropriate
place to attack a perceived problem is at the source, not at the
delivery end (would you want every house to treat its own drinking
water from raw sources?). The FAQ archive is a dynamic thing - new
entries are made as more FAQ lists are assembled, among other things.
The programming effort to make an automatic retrieval application cope
with the nature of the news.answers directory hierarchy would be
substantial, particularly if many people undertook it. A naming
convention change, put in place and given a window of time during which
current FAQs could be brought into compliance with a new convention,
would require an extremely modest level of effort.
> If the current naming scheme really doesn't make it harded for
> automated FAQ retrieval, then all that's left is the question of
> whether or not the naming scheme makes it easier or harder for users
> overall. In my opinion, the current scheme is far easier on users
> than what you suggest, for the two reasons I listed two paragraphs
> ago. The requirement that users retrieving FAQs with same part names
> remember to specify a unique local names isn't such a big deal, since
> most often, people retrieving FAQs are only retrieving a single FAQ
> (or a single set of related FAQ postings, with unique names) at a
> time.
I remain unconvinced by your arguments that "the current naming scheme
really doesn't make it harded for automated FAQ retrieval" and that
"the current scheme is far easier on users than [the suggested
unique-name scheme]". Moreover, I find your unsupported assertion that
"most often, people retrieving FAQs are only retrieving a single FAQ
(or a single set of related FAQ postings, with unique names) at a
time." to be implicitly circular: it might be that most people don't
recover more than a single FAQ or set of related FAQs at a time because
the current convention makes it unnecessarily cumbersome to recover
multiple FAQs at once.
I hope this thread continues; perhaps after awhile the moderators would
consider polling faq-maintainers for the collective opinion.
-- Dennis O'Neill denio@s3reston.scubed.com 703-476-5197 S-Cubed Div. Maxwell Labs 11800 Sunrise Valley Dr. #1212 Reston, Va. 22091 USA
[
Usenet Hypertext FAQ Archive |
Search Mail Archive |
Authors |
Usenet
]
[
1993 |
1994 |
1995 |
1996 |
1997
]
© Copyright The Landfield Group, 1997
All rights reserved