Path: utzoo!attcan!uunet!cs.utexas.edu!usc!ucsd!ucbvax!THUMPER.BELLCORE.COM!nsb From: nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) Newsgroups: comp.soft-sys.andrew Subject: Re: Interfacing WP, AMDS with other mailers Message-ID: Date: 3 Aug 90 12:53:48 GMT References: <14778@csli.Stanford.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 50 Obviously I misunderstood Carl's question -- sorry abou that. I don't know of any software that does what you want, though it's "just a small matter of programming".... Excerpts from internet.info-andrew: 3-Aug-90 Re: Reading usenet News dir.. Bill Janssen@parc.xerox. (393+0) > Excerpts from ext.andrew: 2-Aug-90 Re: Interfacing WP, AMDS wi.. Carl > Witty@decwrl.dec.co (1342) >> (There is an option to allow the messageserver to access hierarchies >> that aren't in AMS format, but it's marked as "not well-tested". ) > This seems to work just fine. The headache is in maintaining the index > files in the usenet news directories, and adding index files to new > newsgroups. Yeah, I believe what Bill means by "headache" here is "resource-intensive" -- in a previous post, he said that the daemon that updates these indices is just too expensive. On thinking about it, I realized why: it's using a general AMS feature that is overkill in this instance. In particular, it uses the CUI scavenge command, which does the following: In each directory it looks at, typically the whole news tree, the scavenge command will compare the names of all the "body" files with the ID's of all the messages listed in that directory's index file (.MS_MsgDir). This is useful in the general case of scavenging directories after a file system crash, but is real overkill in the news case. In the news case, you could do things much more cheaply. Basically, you could first stat the index file and then see if there are any body files that are newer than the index files, and only process those. (In fact, if you stat the directory itself and it isn't more than a few milliseconds older than the index file, you can avoid statting any of the body files!) Then you'd just augment the .MS_MsgDir structure with the new message information, without all the other cost of the scavenge operation. The right way to implement this would be as a new CUI command, modeled on the scavenge command. Alternately, it could be made an optional argument to the scavenge command, I suppose. At any rate, it would make the daemon that updates the indices much more reasonable in its run-cost. Since this fix would involve either a new message server call or changes to the parameters of an existing one, it requires changes to the SNAP interface, too. This is not hard, but would make it a nuisance to test it at Bellcore, at least. I imagine an ITC wizard could do it in just a few hours, however... -- Nathaniel