Re: [Nmh-workers] Future directions for nmh

[Ken Hornstein]

>Rather than push the mailstore code into MH, I think a much cleaner
>model would be to use FUSE-based providers that translate between
>external store formats and the native MH layout.  This means no
>intrusive changes to MH itself, and people can roll whatever
>translators they want.

There was a guy on this mailing list who's name escapes me right now ...
who was a real bear when it came to insisting that nmh should stick to
100% POSIX compatibility.  You should talk to him.  What was his name
again ....?

In all seriousness ... I've looked at the various IMAP-FUSE
implementations.  They could be kindly described as "toys"; they
were worked on for a while and the authors gave up on them.  At a
fundamental level, I don't see how putting a FUSE layer in there solves
the fundamental problem of mapping Maildir filenames to MH message
numbers.  It has the advantage of not requiring any changes to nmh, but
the major DISADVANTAGE of moving the Hard Problem into a layer which is
super non-portable and difficult to debug.  As for 'cleaner' ... I guess
that's in the eye of the beholder; I'd say you're just moving the dirt
around.

>[1] Long ago and far away (2000?), as an experiment, I hacked MH 6.8.4
>to let it use IMAP as a backend store.  At a *very* basic level.  It
>was much easier than I thought it would be to get the basics working.
>But it quickly became apparent that mapping the finer nuances of MH to
>external stores was going to take a *lot* of thinking.  And in the IMAP
>case specifically, MH doesn't take well to external forces changing its
>world view of the message store.

So you've made allusions to this in the past, and since you're the only
one with actual experience here ... care to expand?  I'm not seeing
the actual problem; while mostly you cannot run two nmh commands at the
same time, if the MH mailstore changes between commands then everything
works fine in my experience (if you use something like rcvstore then this
is the normal behavior).  I was under the impression that your view
of an IMAP mailbox at least in terms of message numbers is fixed during
a single IMAP session.  I know messages can be added or removed from
a mailbox and you're get notified in the middle of a session, but I
can't see why we can't just ignore those messages

And, fundamentally ... if the goal here is to use nmh with other mailstores,
ones that OTHER tools may be accessing at the same time ... well, we have
to solve that problem at some point!  Even if we put a FUSE layer in there,
that problem will need to be solved.  So let's quantify the problem!

--Ken