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
concern.
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.
--Ken
_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Locked
