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 <kenh@pobox.com> 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
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
norm@dad.org writes:
Ken Hornstein <kenh@pobox.com> 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
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Ken Hornstein <kenh@pobox.com> 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
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Conrad Hughes <biz_nmh_workers@xrad.org> 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
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
--
Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov>
http://www.newt.com/wohler/, GnuPG ID:610BD9AD