On Tuesday, March 8, 2016 9:19:57 PM PST Ken Hornstein wrote:
... 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.)
you won't believe what you said next, though!
... So to me, trying to use Unix text processing tools on RFC-5322
format files in 2016 is simply a fool's errand. Yeah, it may work fine ...
but you're guaranteed to have it not work at some point. And we can't
really fix that without breaking a long-standing guarantee.
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.
the only advantage is that the files i accumulated for 25 years in ~/Mail are
immutable, except where they aren't like anno(1). and i guess there's some
benefit to not having to convert them to a new format, except i already do,
since i want to access them in IMAP, which means i have to convert them to
Maildir.
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!)
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.
--
P. Vixie
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers