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.
Thanks
Jeff
--
Jeffrey C. Honig <jch(_at_)honig(_dot_)net>
http://www.honig.net/jch
GnuPG ID:14E29E13 <http://www.honig.net/jch/key.shtml>
On Wed, Feb 19, 2014 at 11:22 AM, <norm(_at_)dad(_dot_)org> 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
processing.
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
directory,
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
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers