Subject:
|
Re: Namespace of FAQ-entry filenames
|
Newsgroups:
|
lugnet.faq
|
Date:
|
Sat, 15 May 1999 00:08:10 GMT
|
Reply-To:
|
jsproat@geocitiesSAYNOTOSPAM.com
|
Viewed:
|
1807 times
|
| |
|
|
Todd Lehman wrote:
> In lugnet.faq, jsproat@geocities.com (Sproaticus) writes:
> > Todd Lehman wrote:
> > > If you make the filenames themselves unique, you'll end up in the long run
> > > encoding bastardized forms of the directory names into the filenames in
> > > order to keep the namespaces clean. No way to avoid that. :-(
> > An alternative is to refer to the directory and the file specifically,
> > leaving the slurper script to figure out if it should resolve the address or
> > not (1).
> > 1. That is, if it's a single large document or snippets of the FAQ.
> By "resolve the address" do you mean munging the HREF? Can you give an
> example?
Sure.
Example 1:
File "twitch.faq" contains the HREF ".../twitch#kneecap". The HREF is pointing
to a name within the same file. The script would convert the HREF to
"#kneecap".
Example 2:
File "scarface.faq" contains the HREF ".../boondoggle". The file
"boondoggle.faq" is located within the LUGNET directory structure, e.g.
"../../sideswipe/jeeves/boondoggle.faq". The script would convert the HREF to
"../../sideswipe/jeeves/boondoggle.html".
Example 3:
File "qwerty.faq" contains the HREF ".../dvorak#carpal-tunnel". The file
"dvorak.faq" is located within the LUGNET directory structure, e.g.
"../quality_keyboards/dilbert_reference/dvorak.faq". The script would convert
the HREF to "../quality_keyboards/dilbert_reference/dvorak.html#carpal-tunnel".
Example 4:
File "baby_dinosaur.faq" contains the HREF "http://www.notthemama.com/". This
syntax is a valid Internet URL, and doesn't contain the magic token (".../"),
so it goes through unchanged.
etc...
I suppose unmungable URLs should go through unchanged, with a big red flag
going up for the FAQ maintainer to notice.
> > b) to keep track of linked-to FAQ items which may be moved into another
> > directory
> In a very large system of ID strings (1000 or more), how many moves are
> likely to occur without slight name changes in the ID strings?
That's really a design issue. We could come up with an addressing method right
now that would make this not likely...
> Why can't the computer easily point out obsolete/broken "see also"
> references if one is accidentally bungled?
Good idea. Assuming the script doing the work generated a log file, could that
log file be automatically e-mailed to the FAQ maintainer?
> Requiring unique filenames, to me, seems just like asking for trouble in the
> long run. When a flat namespace gets above 100 or so items -- especially if
> there are multiple people making contributions -- it's a situation prone to
> arguments, accidental collisions, unnecessarily long names, and
> uncomfortable workarounds and compromises.
I see your point. What needs to be done, then, is to determine very early on
where each FAQ item resides and don't change it later.
Which brings up a request: Can someone, anyone review the FAQ items I've
arranged, and make criticisms and / or recommendations on the structure? You
can see what I've got in the ZIP file at:
http://www.geocities.com/SiliconValley/Horizon/5249/lugnet/lugnet_faq.zip
and in a quick-n-dirty one-file sort of thing, at:
http://www.geocities.com/SiliconValley/Horizon/5249/lugnet/whole_thing.html
I'll also make this request in another message, to make it stand out more.
> Say, I must've missed the discussion about how filename representations came
> up...
Actually, the discussion didn't come up.
I've been assuming (1) that a loose alphanumeric character set (2) would be
beneficial, for the various reasons you've mentioned, and also to make my job
easier browsing the directory tree. Ordering can be enforced by making the
first few chars the question number (e.g. "02_who_pays_for_shipping.en.faq")
which I have done for items from previous FAQs where order was noticably
important.
I'm inclined to stick with the file naming method I've been using (with or
without unique filenames), because it carries benefits from both numerical and
alphanumerical camps, and carries few drawbacks.
Cheers,
- jsproat
1. Arg. That assumption thingy again. :-P
2. $filename =~ m/^[a-z0-9_-]+$/i (3)
3. Plus a rule for items in a working and unanswered state, which are
indicated by the chars "~u." at the beginning of the filename, e.g.
"~u.is_tlg_reading_this.en.faq". (This pushes the filenames to the end of a
sorted list.) I hope to have these items taken care of before the FAQ goes
live. (4)
4. Plus a rule for the ng charters, which are indicated by the filename
"0000.charter.en.faq", which breaks my unique filename rule, I know, but
they're mainly there for my benefit and won't be in what I deliver when the FAQ
goes live.
--
Jeremy H. Sproat <jsproat@geocities.com>
http://www.geocities.com/SiliconValley/Horizon/5249/
May the Force be with y'all.
|
|
Message is in Reply To:
 | | Namespace of FAQ-entry filenames
|
| (...) By "resolve the address" do you mean munging the HREF? Can you give an example? (...) Doing that is surely gonna be easier than firstly doing that and secondly looking up the associated global ID string. (...) In a very large system of ID (...) (25 years ago, 15-May-99, to lugnet.faq)
|
24 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
