>i would. first, i'd adopt the messages-as-directories model norm gave, >since it supports MIME, where our current model does not. by "support" i >mean i want to use normal UNIX file access to work with my message >store. there is no file-level access to attachments right now, which >means i have to run "mhstore" to turn an opaque black-box attachment >into a UNIX file i can access. mhstore is highly impure by MH's overall >design principles, even though i'm grateful to have it under the >circumstances.
See, this is where we run into two competing ideas as to what MH's original innovation is. Do people think it's: 1) The message store (1 file per message), instead of one file for the whole store. 2) Individual commands to perform message operations, as opposed to traditional monolithic MUAs. If you think the answer is 1), then splitting all of your attachments into separate files makes perfect sense. But I believe the answer is 2). To me the power of MH is using the individual commands, which lets you do scriptable operations from the shell, and also enables the front-ends that have cropped up. It's obvious to me that the MH message store was developed because it would be near impossible to have a single-file store if every command had to rewrite it every time (well, you could probably make it work, but the performance would suck). So, you think mhstore is highly impure by the original MH design standards. I can't really argue that, but I'd point out that the original design standards had no idea of MIME; messages were text, and that was that. That assumption is all throughout the code, and MIME was grafted on later. Alright, so you want to change that. I don't see how changing the message store helps here. If your model is you want people to have to look directly in the store to copy out PDFs that people send to you ... well, that just seems like it sucks to me from a UI perspective. I guess I'd want to know what people want to happen when they "show" a message with some images or PDFs attached to it. Let's figure out what UI people have in their minds and work from there. --Ken _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers