Re: Future directions for nmh

[Bill Wohler]

Wow, have I been away since 2016?

Assuming it's no longer moot, I have a couple of thoughts regarding
grepable mail:

1. I use grep via MH-E probably on a weekly basis to find messages in
   non-indexed folders.

2. I also use grep to discover deleted messages more often than I'd like
   to admit.

3. I use mairix to index my email. It appears mairix supports Maildir.

In another thread, pack and sortm were mentioned. I use those on a
regular, if annual, basis and would like to see these preserved with any
new mail store.

Being able to access my mail folders remotely (via the Gmail app on
Android, for example) is very attractive. If Maildir or IMAP gets us
there, then I'm all for it.

3,000 more messages to go... I'll surely find discussions on these
topics along the way.

Ken Hornstein <address@hidden> writes:

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

address@hidden writes:

> Ken Hornstein <address@hidden> writes:
>
>>
>>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.
>
> I can't quite tell if by "alternate", you meant optional. I certainly hope
> so.
>
> _______________________________________________
> Nmh-workers mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/nmh-workers
>

Ken Hornstein <address@hidden> writes:

>>>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.
>>
>>I can't quite tell if by "alternate", you meant optional. I certainly hope
>>so.
>
> I am not proposing that we replace the current MH mailstore with Maildir,
> if that's what you mean.  You should still be able to use the traditional
> MH mailstore (and we'll keep that the default) for the forseeable future.
>
> I am saying that we have people who want to use the nmh tools with both
> IMAP and Maildir mailstores.  So making the nmh tools work with those
> mailstores would be useful.
>
> --Ken
>
> _______________________________________________
> Nmh-workers mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/nmh-workers
>

Conrad Hughes <address@hidden> writes:

> Ken> I am saying that we have people who want to use the nmh tools with both
> Ken> IMAP and Maildir mailstores.  So making the nmh tools work with those
> Ken> mailstores would be useful.
>
> .. with migration via refile between different store types .. that
> sounds cool..
>
> C.
>
> _______________________________________________
> Nmh-workers mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/nmh-workers
>

-- 
Bill Wohler <address@hidden> aka <address@hidden>
http://www.newt.com/wohler/, GnuPG ID:610BD9AD