Xref: utzoo comp.emacs:5347 gnu.emacs:465
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!think!rlk
From: rlk@think.com (Robert Krawitz)
Newsgroups: comp.emacs,gnu.emacs
Subject: Re: RMAIL file ---> UNIX mail file
Message-ID: <36447@think.UUCP>
Date: 15 Feb 89 23:42:25 GMT
References: <425@talos.UUCP> <69658@ti-csl.csc.ti.com> <434@talos.UUCP>
Sender: news@think.UUCP
Reply-To: rlk@think.com (Robert Krawitz)
Followup-To: comp.emacs
Organization: Thinking Machines Corp., Cambridge MA
Lines: 80
In-reply-to: kjones@talos.UUCP (Kyle Jones)

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-1111