Xref: utzoo news.software.b:1227 news.misc:1271 Path: utzoo!mnetor!uunet!husc6!ncar!ames!nrl-cmf!ukma!david From: david@ms.uky.edu (David Herron -- Resident E-mail Hack) Newsgroups: news.software.b,news.misc Subject: Re: 3.0 news -- clearing up confusion Message-ID: <8631@g.ms.uky.edu> Date: 21 Mar 88 04:22:15 GMT References: <223494f9:190e@snark.UUCP> <4299@b-tech.UUCP> <507@fig.bbn.com> <2004@epimass.EPI.COM> <2570@tekgen.TEK.COM> Reply-To: david@ms.uky.edu (David Herron -- Resident E-mail Hack) Organization: U of Kentucky, Mathematical Sciences Lines: 43 In article <2570@tekgen.TEK.COM> rad@tektronix.tek.com (Richard Doty) writes: >In article <2004@epimass.EPI.COM> jbuck@epimass.EPI.COM (Joe Buck) writes: >>a) support the Xref: header, even though it's "wrong", or >Doing it "right" (i.e. getting Xref info out of the history file) has er.. what's *wrong* with Xref: headers anyway? With Xref: headers we can do away with the need for a dbm based history file in preference to keeping the same information directly in the file system. This was discussed one month about a year ago and everybody agreed that it was do-able but nobody did it. The idea is to have a seperate directory structure which encodes the article-id into a path name, and at the leaves of the path is YetAnotherLink to the article. (something like "edu/uky/ms/g/3256" as the path name in this seperate directory structure, that particular article-id -> path mapping won't work very well, but some other mapping WILL work). In the header of the article would be the Xref: header so that you can track down the places where the article lives easily (otherwise you'd have to make a recursive traversal of the directory tree). The only extra cost is inodes for the second directory structure. For articles which have expired or been canceled, we'd have to keep the entry in the article-id directory structure, but no entries in the article structure. To save space we could truncate the file to 0 characters. Unfortunately this'll cost quite a few inodes. Then of course this idea can be extended to have extra directory hierarchies on any of the header lines. Yeah, hypertext anyone? :-) For each additional directory hierarchy we gain a new way of finding articles, but it also costs more inodes to build the directories. (REMINDER TO NON-WIZARDS: It won't cost more inodes to store extra links to the file -- that is unless you're not on Unix). -- <---- David Herron -- The E-Mail guy <---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- <---- "Oh, I dunno -- I think Sean would be rather tasty!" -- Becky