What you seem to be saying is that instead of an MUA where you are in
its own shell, e.g. mail(1), you have an MUA comprised of many commands,
scriptable with a bit of shell control-flow, but no commands outside the
MUA's set should touch the storage.
Well, not exactly.
I guess my feeling is that the store isn't off-limits, but we don't make
any guarantees. We should PROVIDE the tools you need without having to
resort to mucking around in the store. But this exposes some tension here.
You say that the current store is inadequate. Okay, I can't really argue
that. But ... we've got a problem here. We have a number of front-ends
that have grown up assuming that the store isn't going to change. If
we went to a directory-per-message, that would bust every front-end out
there. I mean, we already broke things for MH-E when we went to comp(1)
supporting mh-format(5), because MH-E assumed that it could read "components"
directly. We can argue about whether or not that was a valid assumption,
but it hadn't changed for over 30 years so I can't really blame them on
that one.
Sure, we can develop a migration plan, some settings to decide if a folder
should be nmhv2 format, etc etc ... but that just makes it more complicated.
I guess my core thought here is that if people want to change the store,
THEY should work on that. I am personally neutral; I can see the
advantages, but I'd rather work on improving the UI side of things.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers