Re: Rmail changes for Emacs 22

[Kenichi Handa <handa@m17n.org>]

In article <Pine.SUN.3.91.1021016080428.20518C-100000@is>, Eli Zaretskii <eliz@is.elta.co.il> writes:
>>      How will the mbox file encoding be treated?
>>  
>>  I don't know, and that is a good question.  I did not work on that
>>  aspect of Rmail before, and I am not sure what to do about it now.
>>  We might want to save these files normally in emacs-mule encoding,
>>  or maybe we would want to decode each message individually when
>>  displaying it.  pmr@pajato.com is the person doing it.

> If this aspect wasn't discussed before, it's probably a good idea to 
> discuss that now.

> Personally, I think emacs-mule is not a good idea in this case, since 
> mbox is not Emacs-private format, so some other software should be able 
> to read it.  A good alternative would be to encode each message as what 
> the charset= header says (and add/fix such a header if there is none, or 
> if the one that's there lies).

I agree with that approach.  I think we can proceed the
modification of rmail in these steps.

(1) Divide the current code into BABYL format handler
    (babyl-backend) and rmail user-interface provider
    (rmail-frontend).  Babyl-backend reads a BABYL file
    without any code conversion in an unibyte buffer, and
    provides various functions (e.g. extract message
    headers, extract a specific message header, extract a
    message body, get new messages, etc).

(2) Make mbox-backend that provides the same facilities as
    babyl-backend.

(3) Make rmail-frontend to use babyl-backend or mbox-backend
    depending on users mail file.  Rmail-frontend displays a
    message in a different buffer (rmail-view-buffer) than
    the original mail file buffer.  Rmail-frontend utilizes
    MIME handler to decode message headers and body.

This way, we can easiy add more backends, for instance,
IMAP, per-message files (like MH or GNUS), etc.

---
Ken'ichi HANDA
handa@m17n.org