Re: [Nmh-workers] nmh in near, medium, and far-term

[Ken Hornstein]

>regardless of what tool chain we use to maintain it, moving 95% of MH
>into a shared library is important. while i do still want to use MH from
>shell scripts, i think the major use of MH will be in non-shell non-text
>mail user agents.

Well, shoot, I'm convinced ... I'll look at libtoolization as part of
the Automake work.  But I just want to state this for the record ... as
I understand the state of the art today, basically in terms of shared
library support we have two options: libtool and hand-written code for
each operating system.  I'm not interested in working on the latter,
but if someone else wants to work on it I won't stand in the way.  If
there are other options, then I'd like to hear about it.  Also, if people
have some convincing arguments against libtool, this is the point where
they should speak up; otherwise I retain the right to make fun of you
later :-)

>if MH supported Maildir format folders i could use it again. (i've
>switched to pure IMAP, on a Maildir folder store, after more than 20
>years of straight MH userhood. painful but necessary.) but there's no
>way to abstract out the code that understands MH format unless we're
>moving all of it into a reusable code library.

Hm.  Okay, so I've only peripherally looked at maildir in the past.  I
took a quick look at it now.  Some questions for you:

- I assume you're using Dovecot, and as a result you want the Dovecot
  extensions (specifically the ones about folders).  Correct?

- Do you just want to be able to have "scan" and "show" work?  Or do you
  want to do more complicated things?  Just trying to get an idea of the
  functionality that is useful to you.

And for everyone else:

- For those of you who care about this, do you have any thoughts about how
  a mapping from an MH message number to a particular Maildir filename
  would work?  At first glance that's the thing that leaps out at me
  as the most obvious problem without a simple solution.

--Ken