cwitty@csli.Stanford.EDU (Carl Witty) (08/02/90)
Recently there's been some discussion on how to use the Andrew mailers with systems that don't use AMDS. We've got the opposite problem here. We like the fuzzy name matching provided by WP, and the reliability and convenience of AMDS, but convincing everybody to use the Andrew user interfaces just isn't practical--people are too attached to their own favorites. Has anybody dealt with this problem? We're thinking of writing a program which collects mail from ~/Mailbox and puts it in a mbox-format file for the mailer to read; it should then be a (relatively) easy task to modify the existing mailers to process this file as they would have processed /usr/spool/mail. (This is the opposite of eatmail; should it be called regurgitatemail?) Also, it would be nice to keep our news tree in AMS format, for people who do use the Andrew mailers. Most newsreaders nowadays use NNTP, so we could support those newsreaders by writing an NNTP daemon. Has anybody written either of these programs? Any suggestions or comments? Thank you. Carl Witty cwitty@cs.stanford.edu (P.S. I discovered why the Andrew dynamic loading wasn't working for me--I needed to compile with -Bstatic. Shouldn't there be a warning about this in README, in *REAL BIG PRINT*?)
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (08/02/90)
Excerpts from internet.info-andrew: 2-Aug-90 Interfacing WP, AMDS with o.. Carl Witty@eos.arc.nasa. (1262) > Also, it would be nice to keep our news tree in AMS format, for people > who do use the Andrew mailers. Most newsreaders nowadays use NNTP, so > we could support those newsreaders by writing an NNTP daemon. > Has anybody written either of these programs? Any suggestions or comments? This program is called "nntppoll" and is included in the Andrew distribution. Also of possible interest to heterogeneous sites with Andrew users: I will also soon be making public a set of patches that will make it possible to read Andrew-format multimedia mail with any common UNIX mail reader running under X11 . If you're running one of these mail readers (which include Berkeley mail, MH, XMH, Elm, 2 Gnumacs mailers, and others) and you read a "Content-type: X-BE2" (Andrew format) message, they will open up an ez window to show you the message in full multimedia glory. These patches (typically 20 to 30 lines of code for each mail reader, always localized to a single source file) are currently being tested at Bellcore. After they've been tested & the patch document clears Bellcore's legal department, I'll publish it for anyone who might find it useful.
Craig_Everhart@TRANSARC.COM (08/02/90)
I daresay that's an interesting problem. Interfacing AMDS with MH shouldn't be difficult, should it? Where does MH expect to get its mail--is it still /usr/spool/mail/userid, or does it expect that mail can arrive as separate messages in $HOME/some-directory? Maybe you could set your site so that its default location for AMDS-delivered mail is $HOME/Mail/inbox (or whatever). You should be able to do this by changing the AndrewSetup (or mailconf.c) variable ``MailboxName''. Is that sufficient? Nathaniel already mentioned nntppoll/nns as a mechanism for maintaining NetNews in a tree of AMDS folders. What else? Craig
cwitty@csli.Stanford.EDU (Carl Witty) (08/03/90)
In article <Mai1Eim0M2YtA49Wwd@thumper.bellcore.com> nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) writes: Excerpts from internet.info-andrew: 2-Aug-90 Interfacing WP, AMDS with o.. Carl Witty@eos.arc.nasa. (1262) > Also, it would be nice to keep our news tree in AMS format, for > people who do use the Andrew mailers. Most newsreaders nowadays > use NNTP, so we could support those newsreaders by writing an > NNTP daemon. > Has anybody written either of these programs? Any suggestions or > comments? This program is called "nntppoll" and is included in the Andrew distribution. As far as I can tell, nntppoll is an NNTP client that talks to an NNTP server and pulls across all the news that's newer than a given date, and is used to keep a news tree in AMS format. That's not the question I asked. I want an NNTP *server*, that runs on an AFS machine with the news tree under AFS, which would accept connections from arbitrary NNTP clients (rrn, Gnews, GNUS, nn, etc.) Thanks for your help, Carl Witty
cwitty@csli.Stanford.EDU (Carl Witty) (08/03/90)
In article <oai2m4=0BwwO9BgFAs@transarc.com> Craig_Everhart@TRANSARC.COM writes:
Interfacing AMDS with MH shouldn't be difficult, should it? Where does
MH expect to get its mail--is it still /usr/spool/mail/userid, or does
it expect that mail can arrive as separate messages in
$HOME/some-directory? Maybe you could set your site so that its default
location for AMDS-delivered mail is $HOME/Mail/inbox (or whatever). You
should be able to do this by changing the AndrewSetup (or mailconf.c)
variable ``MailboxName''. Is that sufficient?
No, MH wants all its mail to be in one file (although the maildrop can
be one file in the user's home directory.) Even if MH could be made
to work relatively easily, that still leaves all the other mailers
that people here use and don't want to change from.
Nathaniel already mentioned nntppoll/nns as a mechanism for maintaining
NetNews in a tree of AMDS folders.
Yes; but I want NNTP clients and messageserver clients to be able to
access the same news tree, which (I believe) isn't currently
supported. (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". Besides, the AMS format is richer, it seems, than the
/usr/spool/news format, so I'd like to use it.)
Thank you,
Carl Wittynsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (08/03/90)
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
Craig_Everhart@TRANSARC.COM (08/03/90)
I'm sorry for the misunderstanding about what news services you wanted. Indeed, AMS doesn't come with an NNTP server; sorry. Or, it doesn't yet come with one; it's a small matter of programming, and maybe one will be written. Two of the problems that AMDS solves in the big-distributed-filesystem environment (read AFS with 10^4 users) are: - not relying on the centrality of /usr/spool/mail/<userid>, but instead delivering mail to a place relative to a user's home dir; and - not relying on distributed file systems to rewrite a potentially long file at every delivery time, but instead keeping every message separate (and relying on the DFS to maintain the directory of such messages). All I'm saying here is that the architecture for delivery (separate files under ~/Mailbox directory) was deliberate. I suppose that all you're asking for is a program to take all the files out of ~/Mailbox and append them in some quasi-safe fashion to /usr/spool/mail/<userid>, regardless of what /usr/spool/mail/... is on that system. Presumably you'd then use your mail system of choice to absorb all the messages out of /usr/spool/mail/<userid>. But now you have at least a small problem: if your favorite mail system doesn't empty out /usr/spool/mail/<userid>, then you still have mail sitting there. If that machine is a workstation, and /usr/spool/mail/<userid> is just a local file on that workstation, what happens when the user walks to a different workstation to read mail next time? I guess this is no different than the problems that you're already living with. Whatever interfaces you're using are probably not prepared to handle transient failures, though, so you can't necessarily move them to run with all their files on AFS, without their users managing what happens when a file server becomes unavailable. Hey, here's another solution. Run AMDS, but initially provide everybody with a mail forwarding address that delivers mail to their favorite, current home. That is, when you add an account on your system (on which you run AMDS), also add a forwarding address (to the file wp-build-directory/hist/passwd.chg, or use the ``forward'' or ``wpi'' programs to add it). People read their mail exactly as before, delivered to their timesharing machine or workstation. When somebody wants to read mail with an AMS interface instead, they can stop their own mail forwarding; mail will be delivered to their own AFS home directory, and they can run Messages or the like to read it. How does this fit with your projected environment? Craig
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (08/04/90)
Yeah, I'll buy that. The new program would check the active file and do the equivalent of my "cheaper scavenge" on the directories that have changed. A small matter of programming...