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 Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers