[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scr

From: Jon Steinhart
Subject: Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context
Date: Wed, 19 Feb 2014 12:15:39 -0800

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]