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