[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: Ken Hornstein
Subject: Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context
Date: Wed, 19 Feb 2014 15:10:07 -0500

>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

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.


reply via email to

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