[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Nmh-workers] Future directions for nmh

From: Ken Hornstein
Subject: [Nmh-workers] Future directions for nmh
Date: Wed, 09 Mar 2016 10:18:04 -0500

So, since my simple question about a new release spawned a whole thread
about the future direction of nmh I wanted to create a distinct thread
to discuess those ideas.  If you're interested in commenting on future
ideas for nmh, this is the place to do it.

I am first going on the assumption that completely redoing the email parser
and making all of the nmh tools MIME-aware is a noncontroversial subject.
If you disagree, please speak up.  Also, if you are unclear what exactly
I mean by that, also speak up.

To address other things brought up recently:

1) I do not think converting and storing incoming messages as UTF-8 is wise.
   In terms of just simplicity alone I think messages should be stored
   (somewhere) in their on-the-wire format; this is more robust and
   would prevent loss of mail if there is an issue with character
   conversion at mail incorporation time.  I'm talking about the default
   here; if you want to convert them to some other form using mhfixmsg
   or some yet-written tool, that's your business.

2) Assuming you agree with 1) (I know Lyndon does not :-) ), then I think
   converting stuff internally to UTF-8 before output would not be a net
   gain; it might make some things easier, but I think in general it would
   make things more complex.  The system we have where character conversion
   happens somewhere after parsing and before display, while a bit
   haphazard, seems to be fine in practice, and it's close to what other
   open source MUAs do when I looked at them.  If we were on Plan 9
   then this would be a different decision, but we've heard from enough
   users that do not use UTF-8 locales that makes me think this is a serious

3) Like I said, I am officially neutral on creating a grep(1)able mail
   store; I think it's an exercise in futility, but enough people want
   it that it's clearly not something that is worth dismissing.  As
   Jerrad pointed out, you can probably accomplish most of this today
   with his MIME-Hooks.  Do we include that?  If we do not, we should
   put it in contrib if there isn't a good home for it.  Would that
   be sufficient for people that wanted it?  I just don't feel great
   about having the "exploded" message being the canonical format.
   Maybe Paul Vixie is right about me holding onto this idea that nmh
   should keep the original mail store; maybe that's driven by me still
   using exmh.  I'd make the point that at some point we have to process
   a RFC5322-format message for every piece of email, so that code still
   needs to be written regardless of doing anything else.

4) In terms of alternate mail stores, be they Maildir or IMAP (I think
   those are the two major candidates now, right?), I think those ideas
   are interesting.  The #1 problem with those ideas is how to map MH
   message numbers (which can range 1-MAXINT, with holes) to the internal
   key used by those mail stores; everything else is relatively easy
   to deal with.

   For IMAP ... well, it occurs to me that locally you have a database that
   would map message numbers to IMAP UIDs.  This local database could also
   store annotations, sequences, and maybe something else I'm forgetting.
   If you found a message that wasn't in your database, you'd have a new
   message and add it to your local database; if a message was missing,
   you'd have a hole in the message number sequence.  sort(1)/pack(1) would
   really be about shuffling around this list of message numbers.  This
   would have the disadvantage that if you accessed your IMAP store from
   another system you'd have new message numbers, sequences, and annotations,
   but it would be tons better than what we have now (which is that it
   doesn't work at all).  I have some thoughts on how to create a shareable
   database for that stuff in IMAP, but I'd need to include a trigger
   warning for Lyndon so he could start drinking heavily before he
   read it :-)

   For Maildir, a similar idea, except that you could do annontations
   directly in the message.  Really, none of that seems hard to me.
   Maybe some details to work out, but I don't see any major challenges.
   I'd be interested to hear people tell me if I'm wrong, or if they
   have suggestions or better ideas.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]