Hi Norm,
Here, for example, is one stab at how messages would be stored.
Each message would be a directory. Each component would be a file or
directory, whose name was the component name, Each MIME part would be
a directory.
Plan 9's filesystem that presents an email as a directory is worth
Hi Jeff,
Just because you can use a lot of disk space doesn't mean you should.
If you use a database backend for indexing the messages you detect and
avoid duplicate copies of attachments. The actual pieces of the
message could still exist in directories with duplicate copies linked
in.
Hi Ken,
I dunno; to me, databases are fine for specialized things, but just
add a level of complexity that I don't necessarily think is useful.
Also, I'm not sure of the savings; maybe it's just me, but I rarely
get identical copies of the same message or attachment.
I think it's just you.
Hi Ken,
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.
I've stuck with MH because it's both. Either on its own may not have
kept me over the decades.
Hi Ken,
Maybe a set of primitives, like mhcat that would let you output a
part of a message on stdout
Aside, I have
$ readlink ~/bin/mhcat
/usr/bin/mh/mhstore
$
Don't recall where I learnt to create it, mhstore(1) here doesn't
mention `mhcat', but I use it quite a bit. The
Hi Paul,
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.
Yes. The original email should also be available, like upas's raw*
What you seem to be saying is that instead of an MUA where you are in
its own shell, e.g. mail(1), you have an MUA comprised of many commands,
scriptable with a bit of shell control-flow, but no commands outside the
MUA's set should touch the storage.
Well, not exactly.
I guess my feeling is
$ readlink ~/bin/mhcat
/usr/bin/mh/mhstore
$
Don't recall where I learnt to create it, mhstore(1) here doesn't
mention `mhcat', but I use it quite a bit.
Are you sure you don't have something in .mh_profile that makes that
work? I don't see anything in the code that would make that
Hi Ken,
$ readlink ~/bin/mhcat
/usr/bin/mh/mhstore
$
Don't recall where I learnt to create it, mhstore(1) here doesn't
mention `mhcat', but I use it quite a bit.
Are you sure you don't have something in .mh_profile that makes that
work? I don't see anything in the code
Hi Ken,
You say that the current store is inadequate. Okay, I can't really
argue that. But ... we've got a problem here. We have a number of
front-ends that have grown up assuming that the store isn't going to
change.
No, this isn't nmh. This is Norm's MH-2014. :-) The other projects
n...@dad.org writes:
I am suggesting this exercise only for recreational purposes.
Design MH, from scratch, without the constraints affecting the original
MH design.
Suppose, you weren't designing a system to run on a time shared PDF 1145,
but on a
single user, multi-core system.
So again, I think that the UI issues and message store issues are independent.
I'm personally much more interested in the UI issues. As I've said before,
the ability to scan/next/prev/show attachments would do it for me. This
wouldn't be too hard to add to the current UI. Oh, and the ability to
I think the whole exercise is too limited. If we're going to really blue sky
an idea, lets be revolutionary.
First of all, the whole concept of email is kind of obsolete. There should be a
universal messaging protocol that allows, for example, me to send you a message
via email, and you
to
maybe just using URIs and having the data accessed on demand would solve
this and also re duce message size.
MIME already has this. It's nice in theory, but it doesn't get used.
Among other things, it requires people to treat URIs as they're meant to
(permanent identifiers), and also to maintain a
Nothing too fancy, but possibly of interest/use for some:
http://pthbb.org/manual/software/MH/mhisto.pl
Generates text-based histograms of folder contents by
sender using perl's Text::BarGraph e.g;
FOLDER SPAM Thu, 20 Feb 2014 11:44:15 -0500
173 TOTAL
2014-02-13 ( 7) ##
Jon Steinhart j...@fourwinds.com wrote:
I use these hooks to build a separate searchable database. I have a
number
of additional command line utilities that operate on this database.
I'm interested in trying this.
Any of you could use these hooks to maintain a separate
I've added some documentation (perldoc mhisto) and filtering features:
You may specify a comma or pipe-delimited list of address (substrings)
to be used in a regular expression to limit the set of per-sender
graphs to be printed. The switch may also be given as a negated form
17 matches
Mail list logo
