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 |
In reply to this post by Paul Vixie-2
> 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 |
>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 |
In reply to this post by Jon Steinhart
>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 |
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 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 |
In reply to this post by Laura Creighton
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 |
In reply to this post by Paul Vixie-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 |
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 |
In reply to this post by Ken Hornstein-2
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 |
In reply to this post by Ken Hornstein-2
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 |
In reply to this post by 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 |
In reply to this post by Ken Hornstein-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 |
In reply to this post by Ken Hornstein-2
> 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 |
In reply to this post by Ken Hornstein-2
> 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 |
> 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 |
In reply to this post by Ken Hornstein-2
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 |
In reply to this post by Lyndon Nerenberg (VE6BBM/VE7TFX)
>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 |
> 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 |
In reply to this post by Ken Hornstein-2
> 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 |
Free forum by Nabble | Edit this page |