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

[Paul Vixie]

On 12/6/2011 6:07 PM, Ken Hornstein wrote:
> ... It seems to me that we should start
> assuming that you should always do MIME, and always do the stuff that was
> previously only turned on my MM_CHARSET.

+1.

>> While we have the phrase "nmh libraries" on the table, would it be 
>> interesting
>> to convert sbr/libmh.a into a .so that can be embedded into other projects?
>> I'm thinking that exmh could use that in a few places where it currently has
>> to run system() against an nmh binary.  And if uip/scansbr.c was directly
>> callable from Tcl, that would fix a number of warts (in particular, a number
>> of stale-data issues with the message listing frame - would also make 
>> 'rescan'
>> and 'pack' a lot faster).
> Weeeelll ... I'm open to that, but the only portable way I know of to do
> that is to use libtool.  I admit to being a fan of many of the GNU Autotools,
> but libtool is the one that still leaves a sour taste in my mouth.  ...

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.

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.