>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@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers