Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Jon Steinhart]

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