Path: utzoo!attcan!uunet!snorkelwacker!bloom-beacon!Morgan.COM!dpk From: dpk@Morgan.COM (Doug Kingston) Newsgroups: comp.mail.mush Subject: Re: mush and mmdf help wanted Message-ID: <9007211604.AA17220@Morgan.COM> Date: 21 Jul 90 16:04:45 GMT Sender: daemon@athena.mit.edu (Mr Background) Organization: The Internet Lines: 32 Some quick history on ._ files and the msg mail reader. msg came to BRL and other MMDF sites as a sample and full featured mail reader along with the core of the MMDF distribution. It is not considered a real part of MMDF which is really only an MTA (mail transfer agent). These days we also provide a copy of UCBmail and the /bin/mail replacement we have always had. At BRL, MMDF met large mailboxes, principally those of myself and Mike Muuss. We got tired of it taking minutes to start up msg on our mailboxes (which often contained 100 new messages a day back in 1983), so we added the "binary box" that was maintained in parallel with mailbox (we had our mail delivered to $HOME/mailbox). The binary box began with "._". It has all the information that a mail reader needs to sort and display messages. In fact, it only reads the message text once when a new message is added to the mailbox. This makes the startup for msg faster than any other mail reader. If there are no new messages, it takes four system calls (open, stat, malloc, read) and msg is ready to go. I would love to see this facility in MUSH. In retrospect, we should have switched to network by ordering in the file, and perhaps fixed lenght ascii readers a long time ago, but now is as good a time as any. Startup would be an order of magnitude faster on large mailboxes. Basicly you want all the incore information written out in a fixed format for retrival. In more recent msg changes, the binary box reading code has gotten rather careful about checksuming the binary box and making sure the last message is where we expect it as a safety check. I would be willing to work with folks on this if there is interest from Bart & Co. -Doug-