[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: Jeffrey Honig
Subject: Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context
Date: Wed, 19 Feb 2014 11:42:24 -0500

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.  Attachments, and copies of attachments, are the main source of disk usage in my mail folders.

You could go even further and use FUSE to present a legacy interface.  While maintaining a backend in another format, even on an IMAP server.



Jeffrey C. Honig <address@hidden>
GnuPG ID:14E29E13 <http://www.honig.net/jch/key.shtml>

On Wed, Feb 19, 2014 at 11:22 AM, <address@hidden> wrote:
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. Suppose that you  had multi gigabyte disks
available. But also suppose you had to worry about distributed data and
But, mostly importantly, suppose that you didn't have to worry about
being too radical for acceptance.

What, then. would MH look like?

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
whose name was the component name, Each MIME part would be a directory.

There would be program, call it mhpath, that would give the URLs of
selected parts of selected messages.

    Norman Shapiro

Nmh-workers mailing list

reply via email to

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