Xref: utzoo comp.emacs:5343 gnu.emacs:458
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!labrea!mcnc!rti!talos!kjones
From: kjones@talos.UUCP (Kyle Jones)
Newsgroups: comp.emacs,gnu.emacs
Subject: Re: RMAIL file ---> UNIX mail file
Message-ID: <434@talos.UUCP>
Date: 15 Feb 89 14:39:33 GMT
References: <425@talos.UUCP> <69658@ti-csl.csc.ti.com>
Reply-To: kjones@talos.UUCP (Kyle Jones)
Organization: Philip Morris Research Center, Richmond, VA
Lines: 48

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.