Re: [Nmh-workers] Maybe time for a new release?

[Ken Hornstein]

>> ... I hate
>> to be the the one who has to explain this ... that hasn't been a realistic
>> goal since the advent of MIME.  The model that "email is text" just
>> isn't valid anymore.
>
>i know. which is why i don't see much value in the mhdir layout. if
>we're not going to go after it with "grep -r" any more, then we should
>consider using Maildir format instead, for all of its advantages.
>(also i'd love to have good command line tools for managing maildirs,
>my wife's inbox has to be archived annually, which today i do via
>Thunderbird, which bites.)

>From what I've seen of Maildir, the big disadvantage is that there isn't
a good way to map MH message numbers (I'm assuming we still have them)
to Maildir filenames.  That seems solvable somehow.  But the main gain
of Maildir seems to be lack of locking requirements ... am I missing
something?  Is it more about interoperability with other software?

>that guarantee is helping precisely nobody now. whether mail is or
>isn't text, or whether mail is or isn't a file, makes no difference
>to anyone if the only way to access it is via the MH commands and/or
>library.
>
>it might as well me in berkeley db at this stage. or maildir. or IMAP.

Well ... I see your point. Let's put a pin in it for now.

>so, while i appreciate the design level purity of just wanting a better
>API and let's not also fiddle with the on-disk format, i argue that
>you're preserving a benefit that no longer exists, because nothing
>other than your API is going to be able to access this data.
>
>you seem uncertain of this, however:
>
>> ... If we want to have the MH store consist of "email", then it can't
>> be text.  If we want to change the concept of what an MH store is,
>> then that would break a lot of third-party tools.
>
>the only third party tools that are still working are those which
>understand on-disk MIME (as received over SMTP). of those, the only
>ones that will break will be those which do not adopt your new API.
>
>how many tools is that? as far as i know: just the various MH-only
>graphical shells. i don't see those as a growth area in information
>technology. new graphical e-mail shells use IMAP, and the on-disk
>format used by MH is somewhat incompatible with IMAP, as those of us
>who spent 25 years keeping uw-imapd working for MH can explain in some
>detail. (sequences? sortm? folder --pack? PFA!)

I see where you going, there are a few (I am using one right now).

>> So, getting around to my larger point ... my goal here is to make it
>> so all of the MIME tools natively deal with MIME.  That means the
>> standard internal API is MIME-aware, things like %{body} in scan(1)
>> are MIME-aware (it could be the decoded version of the first text
>> part), and "pick" would know how to search inside a MIME-encoded text
>> part after converting everything to the native character set.  You
>> get the idea.  This requires a new API, parsing routines, etc etc ...
>> that's the part I'd like to work on.
>
>please don't let me dissuade you. nmh would be much cleaner with what
>you're proposing.
>
>> ... I don't recall a suggestion about helper tools a la find(1)
>> and/or xargs, but that could just be my memory going; I'm not sure
>> how that would work. ...
>
>imagining for a moment that something somebody wants to do can't be
>done with pick or rmm or refile even with a new, better, and universal
>MIME API, i think we need some outreach to UNIX command line tools,
>like an option to mhpath or mhstore that uses FUSE or even temporary
>files to offer a read only set of paths that "xargs egrep" would work
>for.
>
>> So, I guess the TL;DR answer is:
>>
>> - There were lots of ideas, but nothing concrete in terms of people
>> volunteering to write code. - I wasn't planning on doing anything
>> like that as part of my work.  My work wouldn't stop that and might
>> make it easier.
>
>thank you for explaining. if you hear about an MH-similar set of
>commands that works on Maildir stores, please point it my way. less and
>less of my archives are still in MH format.

Is the real goal to search a Maildir store, or an IMAP store?  The latter
is something I've been thinking about on and off for a while noe.  That should
be relatively straigtforward to implement.

--Ken