Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Lyndon Nerenberg]

On Feb 19, 2014, at 9:37 PM, Paul Vixie  wrote:

> i have a moral objection to the GPL.

I have a double-barreled shotgun for the GPL.

No, wait, against the GPL!  


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Nmh-workers] Maildir/MH advantages

[otahler]

Hi

I was wondering, what are the (supposed) advantages of maildir over MH? 
All I could find is that its filenames are unique and contain metadata, 
so that file locking is not needed. Apart from that, are there any 
substantial benefits? Personally I like simple things, so simple 
numbered filenames, like those used by MH, are more attractive to me, 
but I guess that having unique filenames may give real advantages too. 
Incidentally, they claim that maildir is the most robust email storage 
system available, as it prevents corruption. This sounds quite 
appealing. And they too stick to the one-file-per-email rule, in plaintext.


Also, does MH have any significant advantages over maildir?

Thanks

--Otto

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Paul Vixie]

Jerrad Pierce wrote:
> ... if one has no moral objections to the GPL.

i have a moral objection to the GPL.


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[otahler]

These comments are all very interesting and stimulating. Something 
useful might eventually come out of this discussion, like MH v2.0.


--Otto

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Lyndon Nerenberg]

On Feb 19, 2014, at 5:59 PM, Ken Hornstein  wrote:

> Define
> a syntax where folder_read() (or a replacement) takes something that refers
> to an IMAP mailbox, and you're most of the way there.

Try it on for size before making pronouncements :-P  The hair on the werewolf 
grows faster than you can possibly imagine.

I did an experimental IMAP back end circa 2002.  I saw enough to convince me to 
run away.

The native store, while not particularly sexy, is a mandatory component to 
allow the rest of the system to work.  If you pervert that, you destroy 
everything.

As for IMAP on the back end, forget it.  MH cannot deal with immutable message 
files.  It just won't fly.  I looked at using the various IMAP annotate 
extensions, but the bottom line is the code would have to work with a plain old 
3501-compliant IMAP server.  It can't.  And even with IMAP annotation support 
on the server, the n! conglomeration of IMAP extensions your have to deal with 
these days leads to an n! explosion in the complexity of the MH library.  That 
way lies madness.

Keep MH simple.  If you want IMAP, you know where to find it.  And if you know 
both IMAP and MH, you know when and where to apply each of them.

--lyndon



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Ken Hornstein]

>Though that could be replaced by a mhgrep that extracts
>messages from whatever form they're in and feeds them to
>grep (and caches due to likely locality of reference).

'pick' exists, although it doesn't support everything that grep does,
but it's pretty close.

>Analogous to what less(1) does with compressed files:  it just
>works.  With that, I could live with an IMAP, database,
>filesystem or other reasonable interface to whatever is used
>for actual storage.  It'd be nice if nmh supported any such
>interface if provided with a suitable adapter.
>
>Could we get there from here?  Probably but it would be
>painful, due to not being designed to support that kind of
>extension as well as having to support a storied legacy.
>I'd advocate starting over from scratch, which I think gets
>back to Norm's point.

You know, I've looked at the current API with an eye toward multiple
backends.  It's actually not terrible.  Here's a typical sequence of
things a program does (I'm using show(1) as an example) and omitting a
few steps)):

   maildir = m_maildir(folder)
   chdir(maildir)
   folder_read(folder)
   m_convert(mp, msgnumbers)
   
   seq_setunseen(mp)
   context_save()

The big things that stand out here are chdir() and directly opening each
message (you basically do an open() on the output of m_name()).  Other than
those two things, you have a reasonable start at an abstract API.  Define
a syntax where folder_read() (or a replacement) takes something that refers
to an IMAP mailbox, and you're most of the way there.  That's just the
user program API, of course ... the backends would require a lot of work.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Jerrad Pierce]

>>Might one use mailutils as a starting point? Didn't it come up in a recent
>>discussion that it was effectively a MH library with interface utilities?
>>Not necessarily the same ones we're looking for, but the core is possibly a
>>better starting point than scratch if one has no moral objections to the GPL.

>You (or anyone else) are free to do that.  Me?  I lack the energy (I have
>looked at it).

I understand, was just tossing the idea out there for someone who was
considering pitching in, to make the project seem more achievable.

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Ken Hornstein]

>Might one use mailutils as a starting point? Didn't it come up in a recent
>discussion that it was effectively a MH library with interface utilities?
>Not necessarily the same ones we're looking for, but the core is possibly a
>better starting point than scratch if one has no moral objections to the GPL.

You (or anyone else) are free to do that.  Me?  I lack the energy (I have
looked at it).

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[David Levine]

Ken's analysis is right on target.  We should pay attention
to what people need, first, and how to implement it, second.

And I agree that individual (shell) commands for message
operations give MH its real power.  The most common
resource-intensive operation that I do on my message store
is grep, so I currently need messages to be in unencoded
flat files.

Though that could be replaced by a mhgrep that extracts
messages from whatever form they're in and feeds them to
grep (and caches due to likely locality of reference).
Analogous to what less(1) does with compressed files:  it just
works.  With that, I could live with an IMAP, database,
filesystem or other reasonable interface to whatever is used
for actual storage.  It'd be nice if nmh supported any such
interface if provided with a suitable adapter.

Could we get there from here?  Probably but it would be
painful, due to not being designed to support that kind of
extension as well as having to support a storied legacy.
I'd advocate starting over from scratch, which I think gets
back to Norm's point.

I was just going to send this when I saw your message about mhcat,
Ken.  I use this frequently:

  alias sl='show -nocheckmime -showproc less'

David

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Jerrad Pierce]

>I feel about that like I do about Paul's rearchitecturing of the nmh
>library: I think that's a great idea, my only concern is who, exactly, is
>going to write that code?  I don't have enough time on my plate to finish
>the relatively straightforward things like RFC 2231 support; that's a huge
>rearchitecturing.  I don't want to discourage anyone from tackling a tough
>problem; please, if you've got the time, go for it!

Might one use mailutils as a starting point? Didn't it come up in a recent
discussion that it was effectively a MH library with interface utilities?
Not necessarily the same ones we're looking for, but the core is possibly a
better starting point than scratch if one has no moral objections to the GPL.
Purely speculation on my part...

Although it looks like they've got an incomplete project to rearchitect things
themselves http://mailutils.org/wiki/Mailutils-3 (The download server
actually has 2.99.98 from March 2013, vs. the 2011 date of the wiki,
and git shows recent activity by Sergey)

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Ken Hornstein]

>Maybe it's time to rethink where the
>UI functionality lives, with a view to creating a new set of commands
>that become the interactive front end, calling out to the traditional
>commands to do the back end grunt work. This would allow the non-UI bits
>to be cleaned up for scripting use.

Maybe a set of primitives, like "mhcat" that would let you output a part
of a message on stdout, and front-end programs like "show" would just
be drivers to one or more mhcat processes?  Also, mhstore could use mhcat.
Just shooting from the hip on that one.

I feel about that like I do about Paul's rearchitecturing of the nmh
library: I think that's a great idea, my only concern is who, exactly, is
going to write that code?  I don't have enough time on my plate to finish
the relatively straightforward things like RFC 2231 support; that's a huge
rearchitecturing.  I don't want to discourage anyone from tackling a tough
problem; please, if you've got the time, go for it!

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Lyndon Nerenberg]

On Feb 19, 2014, at 12:10 PM, Ken Hornstein  wrote:

> 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.

And this alludes to my comments about making the commands a bit more scripting 
friendly.  Not that they aren't, but they could be tuned a bit to make them 
better.

And your comments about the UI lit up a big light bulb, and finally made me 
realize something that has been nagging me for a long time.  And that is how 
the interactive interface is slowly starting to pick away at the "batch" 
functionality (for lack of a better word) of the commands.

The functionality needed to support friendly interactive use is sometimes at 
odds with what makes sense for scripting.  When you make a given command try to 
do both interactive and batch well, this tension can result in it doing both 
poorly.  Or at least inconsistently.  I suppose one of the things I would give 
a hard think is in re-evaluating the line between programs intended for 
scripting and those intended for interactive UI purposes.  Once upon a time, 
exec() was a very expensive system call, thus embedding the 'UI' behaviour into 
the existing commands made some sense.  But today, fork()/exec() and spawn() 
overhead in the MH environment would be invisible on all but the most grossly 
underpowered hardware.  Maybe it's time to rethink where the UI functionality 
lives, with a view to creating a new set of commands that become the 
interactive front end, calling out to the traditional commands to do the back 
end grunt work. This would allow the non-UI bits to be cleaned up for scripting 
use.

I have no specific ideas about this at the moment; this all just coalesced in 
my brain a few minutes ago while reading Ken's message.

--lyndon



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Paul Vixie]

Earl Hood wrote:
> On Wed, Feb 19, 2014 at 1:44 PM, Paul Vixie wrote:
>
>> 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.
>
> I have mixed feelings about this.  Personally, I want the original, raw
> email message left alone and always available.  Extraction of
> attachments could still be done, but leave the original.  This allows
> preexisting email to be reparsed to leverage newer capabilities of the
> MUA, or by other external systems (e.g. digital signature verification).

i can absolutely live with this. i love original messages. in fact i
hate the 'anno' command. in today's world there is no reason not to keep
both the full original message and also a directory containing that
message and its attachments, with all the quoted-printable crud gone.

and lest i be misunderstood -- i love mhstore, i just don't like mhstore
very much.

vixie
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Jon Steinhart]

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.

Jon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Ken Hornstein]

>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

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Lyndon Nerenberg]

On Feb 19, 2014, at 11:44 AM, Paul Vixie  wrote:

> third and finally, i'd fully support the IMAP "UID" psychosis, by offering 
> persistent-for-the-life-of-the-message numeric identifiers, 

For-the-life-of-the-message where?  Within a folder?  Within ~/Mail?

If you want a truly unique identifier for a message, use a cryptographic hash 
of the message file.  (The original message, before MH starts mucking it up 
with things like annotations.)  This even works with Norm's hypothetical 
distributed data model.

This is one of the reasons why I would stick with the 'one message per file' 
paradigm, rather than the 'message per directory' scheme you outlined.  It's 
also one of the benefits of UTF-8 everywhere.  Remove all the MIME encodings 
and convert to a common character set and you have a single common 
representation of the message that's independent of the originator's 
composition environment and the intervening message transports.

--lyndon


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Earl Hood]

On Wed, Feb 19, 2014 at 1:44 PM, Paul Vixie wrote:

> 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.

I have mixed feelings about this.  Personally, I want the original, raw
email message left alone and always available.  Extraction of
attachments could still be done, but leave the original.  This allows
preexisting email to be reparsed to leverage newer capabilities of the
MUA, or by other external systems (e.g. digital signature verification).

A problem that exists is the definition of "attachment"; it is not
clearly defined in email.  Content-Disposition is supposed to indicate
if something is an attachment, but attachment could be inferred if the
MUA is unable to rendering the entity directly (at a given moment of
time).  So, would it be required to extract each MIME entity to a
separate file, regardless of disposition since one cannot predict how
the user may want to access them at the file-level?

It would cause a lot of duplication of data.

--ewh

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Earl Hood]

On Wed, Feb 19, 2014 at 1:33 PM, Lyndon Nerenberg wrote:

> As for disk space, how much you use is a function of the types of
> email you receive and how much of a pack rat you are.

Yep.  Ages ago, if one had a ton of email, you may have issues of
running out of inodes, but I do not think that is much of a problem
anymore.

--ewh

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Paul Vixie]

Lyndon Nerenberg wrote:
> On Feb 19, 2014, at 8:22 AM, n...@dad.org wrote:
>
>> 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.
>
> MH is not resource constrained by CPU, or memory for that matter, so I would 
> change nothing.

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.

second, i'd put all of MH's folder and message and reception and
transmission logic into a library. this library would be fast and well
documented even though it might make huge use of the heap which would
have made it impractical in the PDP 11/45 era. all MH command line
utilities would be UI wrappers around this fast portable well documented
library. we would encourage languages beyond C to skin our API so that
it could be directly called by perl, python, php, e-lisp, and so on. the
definition of "MH aware" would add "uses MH's library" to the other
elements already present ("can access things using normal UNIX file
methods", and "knows how to execute MH commands and parse their output".
mh-e would become a library client that would almost never have to call
"popen".

third and finally, i'd fully support the IMAP "UID" psychosis, by
offering persistent-for-the-life-of-the-message numeric identifiers, and
i'd add code to the library and UI elements to the command set to access
things that way. an IMAP server should be able to link to the MH library
and everything should just work.

note well: this is practical today, as long as we can still access old
style folders as well, and as long as we offer some kind of FUSE
interface (for systems who have FUSE or similar) to allow new-style
folders to be accessed with old-style tools.

vixie
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Lyndon Nerenberg]

On Feb 19, 2014, at 8:22 AM, n...@dad.org wrote:

> 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.

MH is not resource constrained by CPU, or memory for that matter, so I would 
change nothing.

As for disk space, how much you use is a function of the types of email you 
receive and how much of a pack rat you are.  This is not a function of your 
MUA.  (Well, it might be, indirectly.  If you are forced to use an MUA that 
really really sucks, odds are you won't be saving many messages.)

> But also suppose you had to worry about distributed data and
> processing.

This I don't understand.  How would reading/storing/replying/searching e-mail 
require distributed processing?

And what do you mean by distributed data?  You can already store your Mail 
hierarchy on (say) NFS mounted filesystems.  Are you talking about supporting 
multiple storage back-ends (i.e. IMAP)?  I'm not convinced this would work.  
You are always going to run into back ends that don't support some part of the 
required semantics (think message annotations with IMAP), so ultimately you end 
up crippling MH's functionality.

If I was going to do it all over again, most of the changes I would make would 
be to streamline the commands and their interfaces to make them a bit more 
amenable to scripted processing of the messages.  It would also have the 
hindsight of MIME not being an add-on.  Perhaps the most intrusive change I 
would inflict would be to make the whole environment UTF-8 from end-to-end.

--lyndon



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] [patch] filtering support for inc

[Lyndon Nerenberg]

On Feb 15, 2014, at 1:45 PM, Mikhail  wrote:

> I've attached patch against git, which implements this functionality for
> POP protocol.

Why should this only apply to POP?  I don't like the inconsistent behaviour.  
If it's there, it should apply across the board.

--lyndon



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Ken Hornstein]

>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.

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.

>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.

Ow, FUSE?  Say goodbye to portability.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Jeffrey Honig]

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 
http://www.honig.net/jch
GnuPG ID:14E29E13 


On Wed, Feb 19, 2014 at 11:22 AM,  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@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/nmh-workers
>
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[norm]

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@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers