... 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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers