Ken Hornstein writes: > >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
I've been trying to ignore this but you got me. I'm at 1.5 on the Ken scale. #2 is a big win. But so is #1 because it allows new commands to be easily constructed using other elements of the *NIX toolkit. Just #2 means making new tools that don't work well with others. I believe that the majority of what MH needs is improvements to the UI to support better handling of MIME. The rest of it is good enough for me. Jon _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
