Future directions for nmh

[Jon Steinhart]

Ken Hornstein writes:

> >As you might guess if you've been on this mailing list forever, I'd
> >really like to see a better user interface for reading attachments.
> >In short, I'd like to keep track of the "current part", and have
> >"next part" and "previous part" options to show.  There should be
> >a flag that allows switching to the next/prev message if next/prev part
> >runs out of parts.  To me, this would be so much better than having to
> >do a mhlist and then type part numbers.  I looked at doing this years
> >ago and got stopped by dealing with the parsing stuff.  There should
> >also be an option to scan that lists the parts in messages.  So if the
> >parser is redone maybe it will be done in such a way to support this.
>
> So I think those things would be possible.  The current thinking is that
> the message parser would be 'lazy', in that any time a message is opened
> you're going to get the complete headers, and then parse the body if you
> ask for it via the API.  I'm not convinced 'scan' is the right tool to
> list message parts; we'd have to think about how that would work.  I would
> also caution you that to completely parse a message's MIME structure you
> need to read the whole thing; maybe this wouldn't be so bad on IMAP since
> you could simply ask the IMAP server for the message's MIME structure
> (hopefully once it built the structure it would be cached on the server).
> My point is that you had a scan format that showed MIME structure, the
> performance would probably be significantly impacted.
>
> But I have to ask about the idea of going from one MIME part to another;
> do you really want to do that?  I can only go on how I interact with
> messages; almost always, I want to read the text part, and then interact
> in some other way with non-text parts (generally save them or open them
> with another tool).  'Stepping' through MIME parts is just not something
> that makes sense to me.  Sure, I want to make it as flexible as possible
> and just because something doesn't make sense to me doesn't mean it shouldn't
> be possible!  But I do want to understand the usage case completely.  It
> occurs to me that if we do it right we could make it easy to accomplish
> this via scripts, which strikes me as more of the 'MH way' (basically,
> provide the tools to interrogate the MIME structure of a message and then
> go to the "next" MIME part).

Well, it depends on the message.  Sometimes I get a message with 20 photos
attached.  I just want to be able to easily go from one to the next without
having to type their part number.
 

> >I am emboldened by David's posting regarding add-hook, etc.  Didn't know
> >that anybody actually used that stuff other than me.  The hook stuff was
> >an expedient hack on my part, and it's not really as robust as it could
> >be.  I would like to see it made more of an integral part of nmh as
> >opposed to the add-on hack that I did.
>
> Well ... do you have any thoughts there?  I mean, seems like it's integrated
> pretty well now.  Probably the two things that are lacking is a man page
> and tests for the test suite (more people might know about it if the
> various commands had pointers saying which hooks were invoked).

There is no real error recovery.  I thought that I had added it to the man
pages but it was a long time ago and don't remember now.

> The bottom line is that all of this is a large amount to bite off at once.
> My first thought is to do the MIME parser, but keep the rest of everything
> as close to the same as possible.  Then we can talk about different mailstores

I agree, I just would like to keep these other things in mind while doing the
parser so that they're not precluded later.

Gotta run, be back in touch on Monday.

Jon

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> On Mar 11, 2016, at 11:01 AM, Paul Vixie <[hidden email]> wrote:
>
> my situation is the opposite. i'd like multiple mail store types inside NMH, or a pluggable hooks-style interface allowing the creation of same, so that i can use NMH command line tools to attack my Maildir store as created for me by Dovecot.

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.

As a reference model we could include a FUSE fs that exports a Maildir directory tree as an MH store.  My guess is that's what 95% of people would want, anyway.  (And the next 4% would want IMAP.)

I have looked at the idea of implementing a simple(ish) vnode-style abstraction layer in MH.  On a high level, it's not that horribly complicated.[1]  The devil, as always, is in the details.  It's really hard not descending into a tar pit of horribleness as you start trying to support each OSes favourite little filesystem extension.  This will quickly destroy any notion of portability in the code.  Shared libraries are not that friendly to portability efforts, either.  Not without writing a lot of code that nobody here wants to maintain over the long term.

--lyndon

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



_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Ken Hornstein-2]

>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

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Ken Hornstein-2]

>Well, it depends on the message.  Sometimes I get a message with 20 photos
>attached.  I just want to be able to easily go from one to the next without
>having to type their part number.

But ... what's wrong with doing something like:

mhstore -type image

Then you can deal with each of those photos as a seperate file.

>There is no real error recovery.  I thought that I had added it to the man
>pages but it was a long time ago and don't remember now.

I think we'd need to sit down and figure out what kind of error recovery
you want.  It is definitely not in the man pages (one is mentioned in the
man page for mhfixmsg); the real documentation is in a file called
README-HOOKS, which I suspect most people don't know about since it's not
part of the normal documentation set.

--Ken

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Paul Vixie-2]

Ken Hornstein wrote:
>> Well, it depends on the message.  Sometimes I get a message with 20 photos
>> attached.  I just want to be able to easily go from one to the next without
>> having to type their part number.
>
> But ... what's wrong with doing something like:
>
> mhstore -type image
>
> Then you can deal with each of those photos as a seperate file.

ui wise, i don't want files. i want to act on the attachments (view
them, in this case) and then leave them stored as attachments (without
having to delete any temporary files.)

i don't know exactly how to match mime to the simplicity of show(1), and
i've been violently repulsed any time i tried to use mhshow(1), but i
think what i want would look a bit like whatnow(1) is to send(1).
(for many years i used "send -wa" because my sendmail.cf was a hack,
then i used "push" when i stopped being fascinated by SMTP traces.)

the command set i'd suggest for whatnowmime(1) would include things like:

ls | dir
        shows the full message structure (like in ftp)
cd x.y.z
        go to part x subpart y subsubpart z
next
        go to next attachment at same level (like in gdb)
step
        go to next attachment at or below the current one (like gdb)
prev
        opposite of next
back
        opposite of step
up
        go up one level
view
        launch an external viewer suitable for this mimetype
show
        do the best you can in inline ascii for this mimetype
save [-r] [x.y.z]
        save the current part (default) or part x subpart y subsubpart z, maybe
recursively (-r)
quit
        exit from mhshow(1)

--
P Vixie

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Paul Fox-3]

paul vixie wrote:
 > Ken Hornstein wrote:
 > >> Well, it depends on the message.  Sometimes I get a message with 20 photos
 > >> attached.  I just want to be able to easily go from one to the next without
 > >> having to type their part number.
 > >
 > > But ... what's wrong with doing something like:
 > >
 > > mhstore -type image
 > >
 > > Then you can deal with each of those photos as a seperate file.
 >
 > ui wise, i don't want files. i want to act on the attachments (view
 > them, in this case) and then leave them stored as attachments (without
 > having to delete any temporary files.)
 >
 > i don't know exactly how to match mime to the simplicity of show(1), and
 > i've been violently repulsed any time i tried to use mhshow(1), but i
 > think what i want would look a bit like whatnow(1) is to send(1).
 > (for many years i used "send -wa" because my sendmail.cf was a hack,
 > then i used "push" when i stopped being fascinated by SMTP traces.)
 >
 > the command set i'd suggest for whatnowmime(1) would include things like:
 >
 > ls | dir
 > shows the full message structure (like in ftp)
 > cd x.y.z
 > go to part x subpart y subsubpart z
 > next
 > go to next attachment at same level (like in gdb)
 > step
 > go to next attachment at or below the current one (like gdb)
 > prev
 > opposite of next
 > back
 > opposite of step
 > up
 > go up one level
 > view
 > launch an external viewer suitable for this mimetype
 > show
 > do the best you can in inline ascii for this mimetype
 > save [-r] [x.y.z]
 > save the current part (default) or part x subpart y subsubpart z, maybe
 > recursively (-r)
 > quit
 > exit from mhshow(1)

i wrote a script for myself (and my wife) that does much of this (but
by no means all).  the script i use to actually read a mail message
invokes mhshow for the main parts, and then invokes my "mhdisp" script.

mhdisp does the work of wandering through the parts of the message in
order (as well as letting the user select a specific part), and either
does the obvious thing (i.e., displays a text part) or asks the user
what to do (as in the case of a pdf -- i use different readers at
different times), or lets me save a part as a file, and prompts me
with a default filename.  it's made life with MH and MIME much more
pleasant in our household.

there's a bit of a chewing-gum-and-string aspect to it all -- for
instance, to force some actions from mhshow i create custom profiles
on the fly for it to use for that invocation.  it was easier to do
that than create a single profile that always did the right thing in
all cases.

other than being customized mainly for the mail i get (i never receive
audio files, so there's no custom handler for those, for instance),
the biggest missing piece currently is a fully recursive handler for
message/rfc822 parts.  i end up having to save those to a file, and
then run mhdisp on them separately.

i don't see anything terribly difficult about converting what i've
done as a looping "what do you want to do next?" shell into separate
commandline commands, except for the preservation of state between
each such command, and the necessary reparsing of the original message
for each one.  all of the currently hard-coded actions would need to
be sensibly configurable, too, probably with something different than
the current mhn.defaults.  so in principle what paul is asking for is
SMOP (simple matter of programming), but it's definitely a project.

(i just reread paul's message, above, and realize he wasn't describing
separate commandline commands, but the sub-commands in a whatnowmime
shell.  that's more similar to what i've done than i realized.)

i've attached mhdisp in case someone wants to see it.  it's never been
out in the wild before, so it might depend horribly on my environment --
no promises.

paul



 >
 > --
 > P Vixie
 >
 > _______________________________________________
 > Nmh-workers mailing list
 > [hidden email]
 > https://lists.nongnu.org/mailman/listinfo/nmh-workers


=----------------------
 paul fox, [hidden email] (arlington, ma, where it's 38.8 degrees)

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[David Levine-3]

Laura wrote:

> but I would be seriously inconvenienced if mh directory mail store
> went away.

Enough of us would also, I expect, that this won't happen.  At least at some layer that the user can see.

David

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Ken Hornstein-2]

>i don't know exactly how to match mime to the simplicity of show(1), and
>i've been violently repulsed any time i tried to use mhshow(1), but i

I can't really blame you on that one.  But really, mhshow(1) is really just
the old mhn, slightly rewritten.  And mhn was a horrible hack, we all agree.
We've made it suck less.  But my thinking has always been that mhshow goes
away, and mhl be the "display message" command ... you know, like it used
to be.

>the command set i'd suggest for whatnowmime(1) would include things like:

Alright, I see where you're going with this.  Fair enough; that's not
how I personally work with MIME messages, but enough people have said
that they want this (and Paul even wrote something that does it!) that
clearly this UI fills a need.

But ... let's take a step back.  I've heard that "whatnow" is a Horrible
Corruption of the MH way, in that everything should be a distinct
command rather than create a shell that does a bunch of commands.  I
find that argument compelling; any shell we create will lack the full
power of a command shell, and I'm assuming we don't want to cram all of
/bin/sh into nmh.  So do you (and others) really want a "MIME shell",
or do you just want a bunch of commands to operate on MIME parts?  I
do recognize that there is the issue of command collision, so that's
one concern.  Technically, I see no obvious challenge in doing it as
individual commands; there would be some file in $(mhdir) that would
hold current part you're working on, like context today.

If the message parser is done right, mhl would just be a special case of
your "view" command.  Or view would be mhl; details are still a bit
hazy.

--Ken

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Paul Fox-3]

ken wrote:
 > Alright, I see where you're going with this.  Fair enough; that's not
 > how I personally work with MIME messages, but enough people have said
 > that they want this (and Paul even wrote something that does it!) that
 > clearly this UI fills a need.
 >
 > But ... let's take a step back.  I've heard that "whatnow" is a Horrible
 > Corruption of the MH way, in that everything should be a distinct
 > command rather than create a shell that does a bunch of commands.  I
 > find that argument compelling; any shell we create will lack the full
 > power of a command shell, and I'm assuming we don't want to cram all of
 > /bin/sh into nmh.  So do you (and others) really want a "MIME shell",
 > or do you just want a bunch of commands to operate on MIME parts?  I

in practice, for me, the shell approach hasn't been an issue.  for the
parts of a message that are plain text, or close enough, i can see
them just fine with mhshow, and commandline tools mostly work.  for
the non-text parts, the commandline tools don't really work well
anyway -- i'd argue that xv, xpdf or libreoffice, although they all
take a filename as argument, aren't really commandline tools.  so
whatever new command we came up with would just invoke one of those
anyway.  i just need something, while looking at a message, that will
invoke the right viewer/saver/whatever on a part, without corrupting
it.

i suppose if i wanted to someday go through all of the mail in a
folder and, say, extract all of the pdf attachments from a specific
sender, i'd appreciate a scriptable interface to mime parts, but my
needs so far are met by a per-message interactive process.

paul

 > do recognize that there is the issue of command collision, so that's
 > one concern.  Technically, I see no obvious challenge in doing it as
 > individual commands; there would be some file in $(mhdir) that would
 > hold current part you're working on, like context today.
 >
 > If the message parser is done right, mhl would just be a special case of
 > your "view" command.  Or view would be mhl; details are still a bit
 > hazy.
 >
 > --Ken
 >
 > _______________________________________________
 > Nmh-workers mailing list
 > [hidden email]
 > https://lists.nongnu.org/mailman/listinfo/nmh-workers


=----------------------
 paul fox, [hidden email] (arlington, ma, where it's 47.5 degrees)

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Norman Shapiro-3]

Ken Hornstein <[hidden email]> writes:

>But I have to ask about the idea of going from one MIME part to another;
>do you really want to do that?  I can only go on how I interact with
>messages; almost always, I want to read the text part, and then interact
>in some other way with non-text parts (generally save them or open them
>with another tool).  'Stepping' through MIME parts is just not something
>that makes sense to me.  Sure, I want to make it as flexible as possible
>and just because something doesn't make sense to me doesn't mean it shouldn't
>be possible!  But I do want to understand the usage case completely.  It
>occurs to me that if we do it right we could make it easy to accomplish
>this via scripts, which strikes me as more of the 'MH way' (basically,
>provide the tools to interrogate the MIME structure of a message and then
>go to the "next" MIME part).

Hear, Hear. But I assume and hope that you are talking about new commands
rather than more arguments to additional commands.

    Norman Shapiro

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Norman Shapiro-3]

Ken Hornstein <[hidden email]> writes:

>>i don't know exactly how to match mime to the simplicity of show(1), and
>>i've been violently repulsed any time i tried to use mhshow(1), but i
>
>I can't really blame you on that one.  But really, mhshow(1) is really just
>the old mhn, slightly rewritten.  And mhn was a horrible hack, we all agree.
>We've made it suck less.  But my thinking has always been that mhshow goes
>away, and mhl be the "display message" command ... you know, like it used
>to be.
>
>>the command set i'd suggest for whatnowmime(1) would include things like:
>
>Alright, I see where you're going with this.  Fair enough; that's not
>how I personally work with MIME messages, but enough people have said
>that they want this (and Paul even wrote something that does it!) that
>clearly this UI fills a need.
>
>But ... let's take a step back.  I've heard that "whatnow" is a Horrible
>Corruption of the MH way, in that everything should be a distinct
>command rather than create a shell that does a bunch of commands.  I
>find that argument compelling; any shell we create will lack the full
>power of a command shell,

And it would not participate in the improvement, over the years, of the shell
and in the advent of new shells.


> and I'm assuming we don't want to cram all of
>/bin/sh into nmh.  So do you (and others) really want a "MIME shell",
>or do you just want a bunch of commands to operate on MIME parts?  I
>do recognize that there is the issue of command collision, so that's
>one concern.

If that were really a problem you could just make the new command names begin
with "mh" and let the user make his own aliases.

>Technically, I see no obvious challenge in doing it as
>individual commands; there would be some file in $(mhdir) that would
>hold current part you're working on, like context today.
>
>If the message parser is done right, mhl would just be a special case of
>your "view" command.  Or view would be mhl; details are still a bit
>hazy.
>
>--Ken
>
>_______________________________________________
>Nmh-workers mailing list
>[hidden email]
>https://lists.nongnu.org/mailman/listinfo/nmh-workers

    Norman Shapiro

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Norman Shapiro-3]

[hidden email] writes:

Correction:

>Hear, Hear. But I assume and hope that you are talking about new commands
>rather than more arguments to additional commands.

I meant:

Hear, Hear. But I assume and hope that you are talking about new commands
rather than more arguments to existing commands.

    Norman Shapiro

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Paul Vixie-2]

Ken Hornstein wrote:
>> i don't know exactly how to match mime to the simplicity of show(1), and
>> i've been violently repulsed any time i tried to use mhshow(1), but i
>
> I can't really blame you on that one.  But really, mhshow(1) is really just
> the old mhn, slightly rewritten.  And mhn was a horrible hack, we all agree.

well, yes, but i don't think you realize how deep the reaction went. i
despised mhshow, that's true. but i was horrified by mhn and absolutely
disgusted by mhl. these apps had byzantine syntaxes and filled my screen
with what looked like line printer noise. so when you talk about The MH
Way and speak of whatnow having departed from that Way, please realize
that whatnow was a choir boy compared to mhn, mhl, and mhshow.

i use show, next, and prev. sometimes scan and pick. and of course rmm.
the template .cshrc file i built for my colleagues and myself back at
DECWRL, which many of us still use, contains these elements:

alias   mhf     'pick -seq foo -zero'
alias   n       'next +inbox'
alias   p       'prev +inbox'
alias   s       'show +inbox'
alias   rmn     'rmm +inbox;next +inbox'
alias   rmp     'rmm +inbox;prev +inbox'
alias   rpl     'repl -nocc me  -anno -inplace -filter rplfilter +inbox'
alias   mhc     'find ~/Mail/. \( -name "[@#,]*" -o -name "*~" -o -name
".#*" \) -print | xargs -t /bin/rm'

i think i had some "-nochangecur" options in there at some point. but if
any of you guys wondered why i worked so hard to fix the flock bug, it's
because i got tired of corrupt "sequences" files whenever i used MH from
the shell, from EMH, from uw-imapd, and in my .forward file, all at the
same time.

> But ... let's take a step back.  I've heard that "whatnow" is a Horrible
> Corruption of the MH way, in that everything should be a distinct
> command rather than create a shell that does a bunch of commands.  I
> find that argument compelling; any shell we create will lack the full
> power of a command shell, and I'm assuming we don't want to cram all of
> /bin/sh into nmh.  So do you (and others) really want a "MIME shell",
> or do you just want a bunch of commands to operate on MIME parts? ...

that's EDONTCARE for me, for the most part. work flow wise, i'd love to
be dropped into a subshell at about the complexity level of sftp or ftp
when the message i'm trying to read is full of MIME gravel. that way my
primary shell level command would just be "rmn". but if you want to
parse the message into some temporary area and then update something
like a "context" file in that area as i step through the message using
separate shell-level commands, i can adapt.

remember, if i'm being too much of a pain in the ass, ignoring me is OK.

--
P Vixie

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> On Mar 11, 2016, at 9:09 PM, Ken Hornstein <[hidden email]> wrote:
>
> 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 ....?

Oh bite me! :-)

You know this sort of thing falls well outside POSIX. It would be inside a non-portability #ifdef.

But if you want me to get all pedantic, I could write a protocol interface, spoken through a named socket - which is POSIX portable - through which anyone could write their own message store interface adapters as external interfaces.

Actually, that's my preferred scheme.  But it's not trivial to do – on either side – so FUSE seemed like a more practical solution.

--lyndon


_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> On Mar 11, 2016, at 9:09 PM, Ken Hornstein <[hidden email]> wrote:
>
> 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

IMAP has a somewhat bizarre idea of the transactional state of a mailbox, primarily in reference to deleted messages and preserving message reference views across multiple client connections to the same mailbox (aka tombstones).  Think of 'SELECT' as 'BEGIN TRANSACTION' and 'EXPUNGE' as 'COMMIT + BEGIN TRANSACTION'.  Sort of.  This is the stuff that drives IMAP server writers to absinthe.



_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> IMAP has a somewhat bizarre idea of the transactional state of a mailbox, primarily in reference to deleted messages and preserving message reference views across multiple client connections

Sorry, I meant to say 'preserving message sequence views'.


_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Thomas Levine]

On 09 Mar 10:18, Ken Hornstein wrote:
> 4) In terms of alternate mail stores, be they Maildir or IMAP (I think
>    those are the two major candidates now, right?), I think those ideas
>    are interesting.  The #1 problem with those ideas is how to map MH
>    message numbers (which can range 1-MAXINT, with holes) to the internal
>    key used by those mail stores; everything else is relatively easy
>    to deal with.

A few months ago I started working on something like nmh that would
support Maildir.
http://dada.pink/mhdir/

It seems that I addressed this particular issue by building my own
index during inc.
http://dada.pink/mhdir/mhdir/index.py

After doing that, I considered that it might make sense to pass more of
the Maildir structure to the user interface, perhaps by listing
something closer to plain filenames. I think you are right in that this
is the only hard thing; the rest of the MUA was tedious but
straightforward. (In case I got any excited: It was tedious enough that
I never finished it.)

Perhaps it is worth noting that I have never really used nmh; I have
wanted to use it for years but the lack of IMAP or Maildir support to be
too annoying, so I started writing my own to remedy that.

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Ken Hornstein-2]

>You know this sort of thing falls well outside POSIX. It would be inside
>a non-portability #ifdef.

Heh, well, I just wanted to remind you of your previous opinions, that's
all :-)

>Actually, that's my preferred scheme.  But it's not trivial to do – on
>either side – so FUSE seemed like a more practical solution.

Personally I think just writing the code and linking into all of the programs
is the easiest.  But putting that aside now...

You bring up a fair point about mailbox changes during an existing
session.  It seems that's a concern when using message numbers; if
messages are referenced via UID, then that seems like we don't have to
worry about it; if messages are added we just ignore them during the
command (like we do now), if they are removed we deal with them like we
do now (basically, throw an error); as long as we fetch messages via UID
we don't have to worry about a message sequence number changing out from
under us.  I am aware that you're not required to support persistent
UIDs, but I think most IMAP servers do?  We could simply refuse to work
if the IMAP server does not support persistent UIDs.  It occurs to me
that since nmh commands are short-lived, it might not be a problem in
practice.

But here's the thing I really want to get at.  People bring up FUSE
as a viable interface for nmh to use for IMAP.  The point I'm trying
to make is: as far as I can tell, a FUSE interface to IMAP does _not_
solve the above problem; you still have to deal with it.  And I believe
it makes it WORSE; each nmh command starts with a brand-new scan of a
folder, so messages added or removed between commands work out fine.
But a FUSE interface would have no idea when an nmh command is starting
or stopping, so you'd have to do a lot of caching or a new IMAP session
for each file access.  The ONLY value of an FUSE IMAP interface I see is
that you wouldn't have to change base nmh code; I think any FUSE IMAP
interface would be more complicated than directly integrated code, and
hence it would be more buggy.

--Ken

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> On Mar 16, 2016, at 4:56 PM, Ken Hornstein <[hidden email]> wrote:
>
> But here's the thing I really want to get at.  People bring up FUSE
> as a viable interface for nmh to use for IMAP.  The point I'm trying
> to make is: as far as I can tell, a FUSE interface to IMAP does _not_
> solve the above problem; you still have to deal with it.  And I believe
> it makes it WORSE; each nmh command starts with a brand-new scan of a
> folder, so messages added or removed between commands work out fine.

But this makes it *your* turn to come up with an insane idea.

Waiting ...

_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> On Mar 16, 2016, at 4:56 PM, Ken Hornstein <[hidden email]> wrote:
>
> And I believe
> it makes it WORSE; each nmh command starts with a brand-new scan of a
> folder, so messages added or removed between commands work out fine.
> But a FUSE interface would have no idea when an nmh command is starting
> or stopping, so you'd have to do a lot of caching or a new IMAP session
> for each file access.

That pretty much nuts down the issue.  If you want to play IMAP in MH, you must become a full-on IMAP client, playing all those locking games.
_______________________________________________
Nmh-workers mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/nmh-workers