kjones@talos.UUCP (Kyle Jones) (02/15/89)
In article <69658@ti-csl.csc.ti.com> Paul Fuqua gives reasons for RMAIL's use of BABYL files: > 1. Compatibility with Babyl, the ITS/Twenex Emacs mail-reader, which > brings with it compatibility with lispm mail-readers. (Wasn't Babyl's > ancestor named Rmail?) But isn't GNU Emacs primarily targeted at UNIX systems? Specifically the BSD-like system that GNU will eventually be? No UNIX system that I know of uses BABYL format mail files. One reason I find BABYL files irritating is because I have to treat them almost like binaries. If I want to concatenate them, I can't use the cat(1) command. The format contains control characters, so I can't mail a BABYL file either. If I move to another system, it better have GNU Emacs otherwise I and my mail files are out of luck. (Any other BABYL mail readers running on UNIX systems out there?) > 2. Where do you put the labels (keywords, whatever) and attributes > (like Unseen, Answered, etc)? Use the `X-' header extensions provided by RFC822. E.g. X-RMAIL-Labels. Berkeley mail(1) does this now, except it uses a Status header instead of the technically correct X-Status. > 3. Where do you cache the reformatted header? What reformatted header? Do you mean the BABYL header generated by RMAIL? If I were writing RMAIL again I wouldn't have it use the BABYL format at all, even internally. > 4. Where do you put file-specific attributes like the inbox list and > others that rmail doesn't use yet? I'm not sure what the inbox list is supposed to do. But the fact that it is file specific rather than message specific is a problem. How about this: A dummy message could be prepended to the mail file that contains this (and any other file specific) information. This message would contain a special header (e.g. X-RMAIL-Data) so that RMAIL would know not to show this message to the user. Other UNIX mailers wouldn't understand this convention but they could still parse the mail file. * * At one point I attempted to rewrite the existing RMAIL to use the RFC822 message format but was confounded by the fact that the BABYL file dependencies are scattered throughout. I now believe rewriting it from scratch would be the most expedient solution.
pf@csc.ti.com (Paul Fuqua) (02/16/89)
Date: Wednesday, February 15, 1989 8:39am (CST)
From: kjones at talos.UUCP (Kyle Jones)
Subject: Re: RMAIL file ---> UNIX mail file
Newsgroups: comp.emacs,gnu.emacs
I had a long reply mostly composed, when I realised that I was missing
the point: Rmail uses a special mail-file format because it is a closer
textual representation of the abstract notion of a mail-file.
A mail file is just a sequence of messages. The file has some
attributes (inbox, global label list), and each message has some text
and some attributes (labels, unseen/deleted/answered, summary line, old
header). The Babyl/Rmail choice is to parse incoming messages into that
abstract form, and save them back out in a textual form that is closer
to the abstract than to the original.
I think that many problems would be solved if Rmail's O and ^O listened
to numeric arguments. Then, to convert a file, you could go to the
first message and type 9999 ^O (Help M in Rmail should mention this one
prominently for the accidental users). To move all the messages to
another Rmail file, do 9999 O.
Yes, you can stick the labels into a special header line, and keep the
file attributes in a special message, and trim the headers from the
originals at load time. If your priorities are compatibility with Unix
mailers and manipulation with Unix file tools, you'd probably want to do
so. You'll pay a price in runtime, though, because of the extra
recalculation and searching.
My priorities are different, but I'm a lispm/Teco hacker, not a Unix
hacker. If you want to discuss them, or if you want specific answers
to your questions, let's do it by mail.
Paul Fuqua pf@csc.ti.com
{smu,texsun,cs.utexas.edu,rice}!ti-csl!pf
Texas Instruments Computer Science Center
PO Box 655474 MS 238, Dallas, Texas 75265jr@bbn.com (John Robinson) (02/16/89)
In article <434@talos.UUCP>, kjones@talos (Kyle Jones) writes: >In article <69658@ti-csl.csc.ti.com> > Paul Fuqua gives reasons for RMAIL's use of BABYL files: > >> 1. Compatibility with Babyl, the ITS/Twenex Emacs mail-reader, which >> brings with it compatibility with lispm mail-readers. (Wasn't Babyl's >> ancestor named Rmail?) > >But isn't GNU Emacs primarily targeted at UNIX systems? Specifically >the BSD-like system that GNU will eventually be? No UNIX system that >I know of uses BABYL format mail files. Emacs started with no rmail code, but it was easy to steal it from elsewhere, namely the existing implementation on some random lisp machine, which happened to be using Babyl format. This is not an endorsement of that, or an anti-endorsement of Berkeley mail; it just happened. Yes, Babyl's predecessor on ITS/Twenex was named rmail. The grandaddy of them all was called readmail, and its buddy was sndmsg. At a more general level, GNU emacs' target is GNU, alias "GNU's not Unix". I suspect the mail "standard" for GNU is not settled yet. If a package were available under the FSF terms and conditions, and it happened to have good functionality, and it happened to use Babyl format and not Berkeley mail, I have no doubt what GNU Unix would offer. Given the tahoe effort, though, Berkeley may already be available under the right terms, so perhaps FSF would like to change over. > If I were writing RMAIL again I wouldn't have it use the >BABYL format at all, even internally. I doubt anyone else would either, but I suspect Babyl/rmail predates GNU emacs. >At one point I attempted to rewrite the existing RMAIL to use the >RFC822 message format but was confounded by the fact that the BABYL >file dependencies are scattered throughout. I now believe rewriting >it from scratch would be the most expedient solution. If you step back (again), you would look around for more modern models of how mail ought to be done (independent of whether it is accessed from inside emacs, or what machine is hosting the service). This would lead you to X.400, an international standard set that provides for electronic mail. The implementation model is like what we are running on machines here at BBN - MMDF is the mail delivery agent, and MH is the mail user agent. Separating these groups of functions is crucial. In emacs, mh-e is an interface (front-end, really) to the MH user agent software. In principle, you could write all the support directly in elisp, but mh-e doesn't use that approach. The internet is working out a transition plan for X.400. At some point it will supplant RFC822. There will be gateways between the two for quite a long time. I have redirected followups to gnu.emacs. -- /jr jr@bbn.com or bbn!jr
rlk@think.com (Robert Krawitz) (02/16/89)
In article <434@talos.UUCP>, kjones@talos (Kyle Jones) writes:
]In article <69658@ti-csl.csc.ti.com>
] Paul Fuqua gives reasons for RMAIL's use of BABYL files:
]
]> 1. Compatibility with Babyl, the ITS/Twenex Emacs mail-reader, which
]> brings with it compatibility with lispm mail-readers. (Wasn't Babyl's
]> ancestor named Rmail?)
]
]But isn't GNU Emacs primarily targeted at UNIX systems? Specifically
]the BSD-like system that GNU will eventually be? No UNIX system that
]I know of uses BABYL format mail files.
Unix mail file format is pretty lame, actually. No provisions for
labels or anything (status is no substitute for full keywords &
attributes), non-transparent delimiters between messages, no per-file
attributes, etc. Babyl file format has more implementations than most
other formats.
]One reason I find BABYL files irritating is because I have to treat
]them almost like binaries. If I want to concatenate them, I can't use
]the cat(1) command. The format contains control characters, so I
]can't mail a BABYL file either. If I move to another system, it
]better have GNU Emacs otherwise I and my mail files are out of luck.
](Any other BABYL mail readers running on UNIX systems out there?)
It isn't the non-graphic characters that prevent you from cat'ing them
together, it's the file header. You can use rmail to concatenate
them; merely use 1g to append the second file to the first. The fact
that the delimiters are control characters makes it that much harder
to confuse a delimiter with a message body. Besides, the high bit
isn't set; the control-underscore and control-l characters are
certainly mailable. Unix mail format isn't all that portable either;
the silly From line (not the From: line!) is a pure unixism.
]> 2. Where do you put the labels (keywords, whatever) and attributes
]> (like Unseen, Answered, etc)?
]
]Use the `X-' header extensions provided by RFC822. E.g. X-RMAIL-Labels.
]Berkeley mail(1) does this now, except it uses a Status header
]instead of the technically correct X-Status.
I'm unhappy enough with the way the summary line is stored, although I
must admit that it speeds things up (it's stored in the header).
]> 3. Where do you cache the reformatted header?
]
]What reformatted header? Do you mean the BABYL header generated by
]RMAIL? If I were writing RMAIL again I wouldn't have it use the
]BABYL format at all, even internally.
Well, you want somewhere to hide the headers that you aren't showing
to the reader.
]> 4. Where do you put file-specific attributes like the inbox list and
]> others that rmail doesn't use yet?
]
]I'm not sure what the inbox list is supposed to do. But the fact that
]it is file specific rather than message specific is a problem. How
]about this: A dummy message could be prepended to the mail file that
]contains this (and any other file specific) information. This message
]would contain a special header (e.g. X-RMAIL-Data) so that RMAIL would
]know not to show this message to the user. Other UNIX mailers wouldn't
]understand this convention but they could still parse the mail file.
The inbox list is supposed to specify the set of mailboxes that you
wish the file to read mail from. Since I use pmd, I have multiple
mailboxes, and some of my mail files read mail from multiple inboxes.
This hack would work, but would be a mess.
]At one point I attempted to rewrite the existing RMAIL to use the
]RFC822 message format but was confounded by the fact that the BABYL
]file dependencies are scattered throughout. I now believe rewriting
]it from scratch would be the most expedient solution.
But Unix mail format isn't RFC822, either! It's closer, but close
doesn't count in computers!
--
harvard >>>>>> | Robert Krawitz <rlk@think.com> 245 First St.
bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142
topaz >>>>>>>> . Thinking Machines Corp. (617)876-1111jr@bbn.com (John Robinson) (02/16/89)
In article <36061@bbn.COM>, I write: >Emacs started with no rmail code, but it was easy to steal it from >elsewhere, namely the existing implementation on some random lisp >machine, which happened to be using Babyl format. Now that was a pretty lousy way to say that. I meant that the Babyl structure for a file of messages had been kicking around for quite a while, including on lisp machines and others, and it was certainly a method that the GNU emacs builders were familiar with, so it was a natural choice to implement for GNU emacs. I did not mean to imply anything sinister about the origins of the actual code in rmail.el. Given the FSF's public stance on how software ought to be distributed, I am sure that they are in fact extra scrupulous about what they choose to call their own. -- /jr jr@bbn.com or bbn!jr