Re: [Nmh-workers] cleaning out the cobwebs
If you see any code which has an #ifdef KPOP, rip it out! There are few left in the 1.3 source: sbr/client.c:28: #ifdef KPOP [...] Yeah, I didn't go through and purge all of the KPOP code. Were you talking about the CVS head? Yeah. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
Thus spake Lyndon Nerenberg (VE6BBM/VE7TFX): Below I've listed all the unique #if* tags I found in the 1.3 source. While I haven't combed the list in detail yet, it looks like the majority go away with a POSIX conversion. The YY_* stuff has be a bit concerned, but again, I haven't dug into the details yet. The YY_* defines are used by flex. They're not something you should be planning to get rid of, unless you're going to write your own tokenizer. -- J. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
Lyndon Nerenberg (VE6BBM/VE7TFX) wrote: And since I have to do this anyway for the Plan9 port, I'm just going to go ahead and do it. I was planning to base the port on the 1.3 release source; would it be better to start from the CVS head? Yes, please start with the CVS head. -- PMM ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
Date:Wed, 03 Nov 2010 13:40:43 -0400 From:Ken Hornstein k...@pobox.com Message-ID: 201011031740.oa3hehig026...@hedwig.cmf.nrl.navy.mil | If someone wants to use something instead ... well, okay, let's see a | concrete proposal. Unless you are suggesting going back to simply | editing a Makefile by hand to set things like features, install location, | etc etc. I know that was written as kind of a rhetorical question, no-one would ever want to go back to editing Makefiles and config.h type files, would they, these days? But yes, that is exactly the right solution these days - the time for autoconf has passed (when Larry Wall wrote the config script for perl upon which all of this is based, it was a great idea - no longer.) That's partly because now it is possible to write much more portable code in the first place, with some actual expectation that it will work, and work effectively. However, I am not nearly as confident as some here that everything is possible simply by writing posix compatible code. I don't mean by that that posix code can't do what MH needs, but that I suspect that there are still real users on real systems that don't do everything the posix way, and I don't think that simply ignoring them is a rational approach. More on the kind of config that's needed for this below. But aside from that, as has been pointed out, there are compilation choices (does my installation of MH really need support for ...), and installation choices (where should the binaries, man page, etc, all get put). For those, autoconf is no real help anyway, autoconf cannot know whether I want to use kerberos with MH or not. It often guesses - if it sees I have kerberos (or whatever) installed, it just assumes I must want to use it, but that's completely bogus. Really, all autoconf provides for this kind of option is a semi-standardised way by which I can tell the Makefiles which options I want to turn on or off, and what path names should be uses for installation directories, etc. Personally, I prefer to simply edit that kind of thing into the Makefile (or whatever) because then I have to do it just once (I even get to use diff/patch type upgrade methods to move from one version to the next). As long as there aren't too many files that need human attention, it is simply easier that way than supplying a whole bunch of --prefix=/a/b/c --with-xxx --without-yyy type options to configure every time I need to run it. What's more, for anyone who does prefer a command line edit the options tool, we have sed already - a simple script wrapper around that, and the file editing can all be based upon command line options for those who prefer it that way. But the real reason autoconf isn't needed any more, isn't either of those, that is, it isn't because POSIX rules everywhere, and that editing Makefiles is easier than giving command line options (even though both of those are mostly correct), it is that these days we're no longer in the situation where we have every random half-knowing idiot in the world attempting to figure out the answers to all of these questions by themselves. Almost no-one downloads nmh.tar.gz and starts from that to install MH any more, and those who do, almost certainly know what they're doing and whether of not their system has statfs() or statvfs() or whatever today's remaining questionable portability issues are. Almost everyone these days uses either pre-built binaries that someone else has compiled for them, or one of the packaging systems that automate the entire build process. The only people who need to know what the settings for all these options are are the people to provide the package system template files - and they're almost always people who understand enough about the system they're building for to not need assistance from something like autoconf - and more particularly, to not need to find ways to defeat it (I observe NetBSD's pkgsrc developers go to sometimes absurd lengths to defeat what configure scripts are trying to do when simply supplying patch files to modify a Makefile or a configuration header file is trivial). So, yes, please, remove all vestiges of autoconf from nmh - by making the code portable where that is possible, and where it isn't, then yes, just put the remaining config in whichever is appropriate of the main Makefile, or a single options.h or config.h type header file (and from which everything else gets info it needs). kre ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
out the answers to all of these questions by themselves. Almost no-one downloads nmh.tar.gz and starts from that to install MH any more, and those who do, almost certainly know what they're doing and whether of not their system has statfs() or statvfs() or whatever today's remaining questionable portability issues are. False. I wouldn't know anything about stat*, but I have in the not-too distant past had to build my own nmh from scratch. For instance, MIT has historically been slow to update the default version on workstations, so I had a local copy installed in my home directory. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
i strongly suggest that KPOP not be deprecated unless you can prove there are no sites using Kerberized POP. (Hint - i know the answer) -mo On 11/3/10 2:05 PM, Lyndon Nerenberg wrote: 590610/29 X XXX Re: Coming down your way soonThanks. I am doin 5907+ 10/29 XXX X Election editorial cartoons--Apple-Mail-19-856 .1 text/html I decided to stick to just one topic, since the .1.2 image/gif JGPfwdtoon.gif [...] show 5907.1.2 or maybe if 5907 is the current message just the ability to do something like show .1.2 I like this, provided it requires a switch to enable it so that we don't break existing scripts that parse the current default scan format. next -part prev -part What if the next part is a message/rfc822? Do you descend into it recursively? Interesting idea, but the semantics will need some careful thought methinks. Again, the stumbling block here is m_getfld.c and my not wanting Van Jacobson, his children, and my children cursing me as per the comments. The day of the VAX is long gone, and with it, the need for this sort of bowing down to the necromancer. When a piece of code gets this disgusting the best path forward is to throw it out and rewrite it. In my mind, the best way to start a clean-up project is for people to go into the existing code and add good comments. As with m_getfld.c, the big stumbling block is not understanding what the stuff that's already there does. Once it's understood it's probably pretty easy to change. Here we disagree. It's a waste of time commenting code that's just going to be ripped out. From what I see there are two immediate tasks that can be taken on without too much pain: * replace HAVE_* defines with POSIX calls, eliminating autoconf. * remove old compatibility cruft (KPOP, ZMAILER SMTP workarounds, site specific hacks) These alone will substantially improve the readability of the code in many places. Once that's done it will be easier to move forward with general feature cleanup. BTW, it seems to me that part of what's going on in m_getfld.c is poking around in stdio buffers to avoid fetching the data twice. Most message are pretty small so I've wondered whether it would be better to just memory map the files. Or, maybe systems are fast enough today that we can just bail on the tricky stuff and use stdio. Stay away from mmap. It's not portable, and it's doubtful it would give any visible performance gain in a non-contrived scenario. stdio is more than fast enough for the job, and portable. --lyndon ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
easy support for BSD systems is non-negotiable. if that doesn't cover MacOS X - that needs to be added as well. On 11/3/10 2:45 PM, Jon Steinhart wrote: Wow. Glad to see that there are still people interested in nmh out there. I'm going to try to respond to a whole pile of messages at once rather than flooding you with messages. Autoconf: As long as we stick to simple usage it's fine. In general, I find that the way that autoconf works, requiring heavily ifdef'd code, makes code pretty unreadable. But usage is generally understood for just getting things to build. Comatibility: I am fine with removing code that makes nmh run on VAXs, PDP-11s, Apollo workstations, and other obsolete systems. I'm fine if it doesn't run on RSX-11 or GECOS and so on. Anybody who is still using such systems can get by (in my opinion) with using the current version of nmh. So let's figure out what's really important. To me, that's Linux. I don't know is nmh gets enough usage on Apple or Microsoft systems to be worth any special effort. Don't think that it needs to work on Android or Chrome or iOS either. But, that's my opinion. Can we come to a concensus on the important target systems? MIME Support: Glad to see that someone is awake out there. I understand the desired to have scan stay out of message bodies. But, wen you look at it, MIME essentially put headers in message bodies. So I think that scan should be able to look at 'em. As I said in my earlier post, that would be an option; old scan behavior would still be available. I don't have any trouble with an additional piece of state to handle this. I do agree with the sentiment to better integrate MIME so that it's not the add-on that it was. So let's try to reach a concensus on what to do before anybody gets to work. Code Base: Please, if your're working on becoming familiar with the code base put in comments as you go. If everyone helps to figure out what it does it'll be easier to make changes later. I'm heading out of town for a week so won't be answering much email. Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
i strongly suggest that KPOP not be deprecated unless you can prove there are no sites using Kerberized POP. (Hint - i know the answer) Let me speak up a bit regarding that. If you want to do Kerberos authentication via POP, there are two ways: a protocol which has generally been known as KPOP, and RFC 5034. Technically RFC 5034 spells out how to do SASL over POP, but that means you get GSSAPI authentication, and for the purposes of this discussion that means Kerberos. So when you say Kerberized POP, you could be talking about two very different protocols. Without going into the gory details ... KPOP is an ugly, ugly protocol. The only reason it has stuck around as long as it has is because for a long time it was the only way to get Kerberos authentication for Eudora. Fast forward a few years or ten ... and now we've got a more sane protocol, and we have many programs that implement it (Thunderbird, Apple Mail, and even Eudora). nmh also implements it via the Cyrus-SASL library; I wrote that code a while ago, and it also uses Cyrus-SASL to implement SMTP AUTH support as well. At this point ... I can see no reason to continue to support KPOP. I'm not even sure what servers still implement it, except maybe old versions of Qpopper (maybe the newer versions still have that code in there, but I suspect it doesn't get much love). Now, I suspect that there MAY still be a few crazy people that still run the KPOP protocol, but there is no reason for them to do so, unless they are still supporting things like MacOS 9 and ancient versions of Eudora. Nowadays everything implements some variant of the SASL protocol (at least things that support Kerberos in some form). So my vote is to kill it in the spirit of garbage-collecting unused code. Unless we can get some people to speak up and say that hey, we DO use KPOP, and we can't really use the SASL protocol (for some weird reason). If you're one of those people, then this is when you should chime in! --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
On 10-11-04 11:44 AM, Mike O'Dell wrote: i strongly suggest that KPOP not be deprecated unless you can prove there are no sites using Kerberized POP. You are still running Kerberos IV? Really? ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
there's no Kerberos V that I know of. MS and Apple both use K-IV (MS's being slightly perverted) as the basis of their distributed authentication (single sign-on) system. for small apps, running an ssh vpn accomplishes some of what a full Kerberos deployment can do, but certainly not all of it. if you need to manage the authentication environment on thousands of machines located around the world using only a few people, i don't know of anything, off the top of my head, that can do the job as well or as simply. so why not run Kerberos IV? it beats the heck out of trying to manage a large PKI deployment. -mo On 11/4/10 4:14 PM, Lyndon Nerenberg wrote: On 10-11-04 11:44 AM, Mike O'Dell wrote: i strongly suggest that KPOP not be deprecated unless you can prove there are no sites using Kerberized POP. You are still running Kerberos IV? Really? ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
On Thu, 04 Nov 2010 17:12:06 EDT, Mike O'Dell said: there's no Kerberos V that I know of. V4 was officially End-of-Life'd several years ago: http://web.mit.edu/kerberos/krb4-end-of-life.html V5 has been around for a while. See RFC1510, from 1993. 1510 The Kerberos Network Authentication Service (V5). J. Kohl, C. Neuman. September 1993. (Format: TXT=275395 bytes) (Obsoleted by RFC4120) (Status: PROPOSED STANDARD) http://en.wikipedia.org/wiki/Kerberos_%28protocol%29 pgpCQJ216tfRW.pgp Description: PGP signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
MacOSX uses Kerberos V, which typically includes a pretty useable krb4 legacy support mode. I ducked out of the corporate world before I had to care about widespread kerberos support from Microsoft, but a few seconds with google shows their documentation using several terms that only make sense with krb5. I wouldn't be surprised if there are old MS installations still using krb4, but I doubt that there are many that care about nmh. Hope that helps, *Chad ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
On 10-11-04 2:56 PM, Chad Brown wrote: I wouldn't be surprised if there are old MS installations still using krb4, but I doubt that there are many that care about nmh. Active Directory has been Kerb 5 all the way (although it was a typically bastardized variant in its younger years.) ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
Below I've listed all the unique #if* tags I found in the 1.3 source. The complete list indexed by file and line number is at: ftp://orthanc.ca/mh/DEFINES ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
Separate from the above, I would like to see as much as the pre-Posix gratuitous stuff removed from sbr. It's fine with me if going forward, new versions of nmh only run on Posix-compatible systems. I too am a hater of autoconf/automake; I like elegance, not the ugliest sledgehammer in existence. That said, I'd rather use these than create new ones. While I'm not particularly in love with autoconf or automake, my response to people who say that they hate autoconf is: what do you propose we use instead? Unfortunately, dealing with portability is ugly, and there is AFAIK no elegant way to deal with this ugliness. And unlike 90% of the open source projects out there, autoconf and automake actually have nearly-complete manuals that allow someone who has no experience with these tools to get up to speed on them fairly quickly. They are fairly standard in the open source/Unix world, and all of the attempts I've seen to use something else instead of them end up being vastly inferior. (I know you were saying basically the same thing, Jon, but I guess this is more toward the other comments. And we don't use automake, so that's really moot I think). If someone wants to use something instead ... well, okay, let's see a concrete proposal. Unless you are suggesting going back to simply editing a Makefile by hand to set things like features, install location, etc etc. BTW, it seems to me that part of what's going on in m_getfld.c is poking around in stdio buffers to avoid fetching the data twice. Most message are pretty small so I've wondered whether it would be better to just memory map the files. Or, maybe systems are fast enough today that we can just bail on the tricky stuff and use stdio. Any opinions? My feeling: that might have been a win 15 years ago. Now? Meh. When the code gets so complicated that potential developers can't understand it, then I don't think it's worth it. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
While I'm not particularly in love with autoconf or automake, my response to people who say that they hate autoconf is: what do you propose we use instead? The POSIX standard. Everything MH needs in the way of APIs is provided by POSIX. By coding to POSIX we eliminate the need for autoconf in the first place. --lyndon ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
590610/29 X XXX Re: Coming down your way soonThanks. I am doin 5907+ 10/29 XXX X Election editorial cartoons--Apple-Mail-19-856 .1 text/html I decided to stick to just one topic, since the .1.2 image/gif JGPfwdtoon.gif [...] show 5907.1.2 or maybe if 5907 is the current message just the ability to do something like show .1.2 I like this, provided it requires a switch to enable it so that we don't break existing scripts that parse the current default scan format. next -part prev -part What if the next part is a message/rfc822? Do you descend into it recursively? Interesting idea, but the semantics will need some careful thought methinks. Again, the stumbling block here is m_getfld.c and my not wanting Van Jacobson, his children, and my children cursing me as per the comments. The day of the VAX is long gone, and with it, the need for this sort of bowing down to the necromancer. When a piece of code gets this disgusting the best path forward is to throw it out and rewrite it. In my mind, the best way to start a clean-up project is for people to go into the existing code and add good comments. As with m_getfld.c, the big stumbling block is not understanding what the stuff that's already there does. Once it's understood it's probably pretty easy to change. Here we disagree. It's a waste of time commenting code that's just going to be ripped out. From what I see there are two immediate tasks that can be taken on without too much pain: * replace HAVE_* defines with POSIX calls, eliminating autoconf. * remove old compatibility cruft (KPOP, ZMAILER SMTP workarounds, site specific hacks) These alone will substantially improve the readability of the code in many places. Once that's done it will be easier to move forward with general feature cleanup. BTW, it seems to me that part of what's going on in m_getfld.c is poking around in stdio buffers to avoid fetching the data twice. Most message are pretty small so I've wondered whether it would be better to just memory map the files. Or, maybe systems are fast enough today that we can just bail on the tricky stuff and use stdio. Stay away from mmap. It's not portable, and it's doubtful it would give any visible performance gain in a non-contrived scenario. stdio is more than fast enough for the job, and portable. --lyndon ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
It's also long overdue to clean up the SMTP client code to bring it into line with the current port 587 submission regime. That code has pretty much been done (18 months ago). At least the part that lets you set a different port to use, which was the bulk of the code. We might have some protocol stuff to clean up, but I've been using this code for a while now. A brief looking at RFC 4409 ... nothing leaps out at me in terms of protocol issues that we have. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
[2010-11-03 10:07] Jon Steinhart j...@fourwinds.com While reading much nmh code these days, I also feel that parts of the code are ancient. I'd like to support any effort in renewing it. Autoconf is something I dislike. I suppose that I'm willing to do some work here too if I'm not alone. Great! I'm at your side. :-) About my time: I have free time until Christmas, which I put into the quoted reply thing, as already announced. Then I'll travel again and will be offline until April. From April until summer I like to work on nmh again, besides my studies. My main interest, which I expressed years ago, is to figure out what sbr/m_getfld.c is really doing and rewrite it so that I can add additional functionality without breaking anything. How performance optimizations haunt you after so many years ... The functionality that I want to add is better handling of attachments. Even though there have been some complaints long after the fact, I think that my code that simplified sending attachments was a success. But, it's my opinion that receiving attachments still needs work. The current attachment approach collides with running `mime' on the whatnow prompt. But this is only one other problem originating in the approach that was taken to implement MIME support. And I really don't like what happens when I show a message with a lot of attachments and they keep on popping up even though I want to move on to the next message. I'd like to have show(1)/mhshow(1) redesigned. The programs should be merged when MIME support is not something sitting on top anymore. IMO show(1) should per default display: - for non-MIME: the whole message - for MIME: the first text/plain part and the output of mhlist(1) I'd like an option to scan that would give me something like this: 590110/28 X XXX Re: Coming down your way soonBoob cancer. Prog 590410/28 XXX XX FW: Hallowe'en2010--_000_1D0D56EB54ECF6428182E 590610/29 X XXX Re: Coming down your way soonThanks. I am doin 5907+ 10/29 XXX X Election editorial cartoons--Apple-Mail-19-856 .1 text/html I decided to stick to just one topic, since the .1.2 image/gif JGPfwdtoon.gif .1.3 image/jpg Lukovich - election 2010.jpg .1.4 image/jpg Kirk GOP no solutions-1.jpg .1.5 image/jpg Luckovich - Money - Republicans - Obama.jpg .1.6 image/gif toles - Public voted out.gif .2 text/plain I decided to stick to just one topic, since the 590810/30 X XX XX Re: 2010 bring a friendOn Sat, Oct 30, 2010 at I, in contrast, would like to have scan(1) only work on message headers and not deal with any body data. This could ease things as more clear separations (which tools deal with files, headers, body (=MIME)) could be made. I'd then like the ability to do something like show 5907.1.2 or maybe if 5907 is the current message just the ability to do something like show .1.2 I agree. Currently MIME support is just put upon MH. IMO we should fully integrate MIME into nmh. This would remove several ugly (nonintuitive) parts. Then, I'd like the ability to do something like next -part Here I'm not so sure. Because we would have three states then: folder, msg, and part. But I'm not decided on this yet. Let me know what you think. I don't want this to be like the attachment sending code where nobody had anything to say until a few years after it was done and then started complaining. :-) Again, the stumbling block here is m_getfld.c and my not wanting Van Jacobson, his children, and my children cursing me as per the comments. I don't want to blame Van Jacobson, as this might had been a very valuable improvement back then. The point is simply that the optimization drove m_getfld.c into a dead end for further development. Perhaps it's best to start with the code before he optimized it and track the changes since. Separate from the above, I would like to see as much as the pre-Posix gratuitous stuff removed from sbr. It's fine with me if going forward, new versions of nmh only run on Posix-compatible systems. I think a lot about all this these days. The difficulty is always the compatibility. I too am a hater of autoconf/automake; I like elegance, not the ugliest sledgehammer in existence. That said, I'd rather use these than create new ones. Many alternative approaches have their problems too. I like best how it is done by the suckless project [0] and the heirloom tools [1]. This involves a bit of manual configuration but saves a lot of complexity therewith. [0] http://suckless.org [1] http://heirloom.sf.net In my mind, the best way to start a clean-up project is for people to go into the existing code and add good comments. In the view of usability for developers,
Re: [Nmh-workers] cleaning out the cobwebs
[2010-11-03 11:05] Lyndon Nerenberg lyn...@orthanc.ca Again, the stumbling block here is m_getfld.c and my not wanting Van Jacobson, his children, and my children cursing me as per the comments. The day of the VAX is long gone, and with it, the need for this sort of bowing down to the necromancer. When a piece of code gets this disgusting the best path forward is to throw it out and rewrite it. Here we disagree. It's a waste of time commenting code that's just going to be ripped out. Have you had a look into m_getfld.c? Quoting: ``This module has a long and checkered history.'' Doesn't seem as if the code was so easy to write the first time. It probably will not be the second time. meillo ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
On 10-11-03 11:27 AM, markus schnalke wrote: Have you had a look into m_getfld.c? Yes :-( Doesn't seem as if the code was so easy to write the first time. It probably will not be the second time. It wasn't easy because it was all about micro-optimizations that reached into dark places that should never have been visited (i.e. the internals of many different implementations of stdio). Throwing that aside, what remains is pretty straight-forward to re-implement. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
Wow. Glad to see that there are still people interested in nmh out there. I'm going to try to respond to a whole pile of messages at once rather than flooding you with messages. Autoconf: As long as we stick to simple usage it's fine. In general, I find that the way that autoconf works, requiring heavily ifdef'd code, makes code pretty unreadable. But usage is generally understood for just getting things to build. Comatibility: I am fine with removing code that makes nmh run on VAXs, PDP-11s, Apollo workstations, and other obsolete systems. I'm fine if it doesn't run on RSX-11 or GECOS and so on. Anybody who is still using such systems can get by (in my opinion) with using the current version of nmh. So let's figure out what's really important. To me, that's Linux. I don't know is nmh gets enough usage on Apple or Microsoft systems to be worth any special effort. Don't think that it needs to work on Android or Chrome or iOS either. But, that's my opinion. Can we come to a concensus on the important target systems? MIME Support: Glad to see that someone is awake out there. I understand the desired to have scan stay out of message bodies. But, wen you look at it, MIME essentially put headers in message bodies. So I think that scan should be able to look at 'em. As I said in my earlier post, that would be an option; old scan behavior would still be available. I don't have any trouble with an additional piece of state to handle this. I do agree with the sentiment to better integrate MIME so that it's not the add-on that it was. So let's try to reach a concensus on what to do before anybody gets to work. Code Base: Please, if your're working on becoming familiar with the code base put in comments as you go. If everyone helps to figure out what it does it'll be easier to make changes later. I'm heading out of town for a week so won't be answering much email. Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
To me, that's Linux. I don't know is nmh gets enough usage on Apple or Microsoft systems to be worth any special effort. Don't think that it needs to work on Android or Chrome or iOS either. But, that's my opinion. Can we come to a concensus on the important target systems? Just as a note, I use nmh under MacOS X all of the time. It provides enough of a POSIX interface that I can't think of a reason why it should not be supported. Certainly when I build nmh under MacOS X I don't need to do any autoconf work. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
On 10-11-03 11:45 AM, Jon Steinhart wrote: So let's figure out what's really important. To me, that's Linux. You are a lonely voice in a large crowd. I have seven servers at home. None of them run Linux. I currently run nmh on multiple major releases of FreeBSD, Solaris, and OpenBSD. In the not too distant past I used it on HP/UX, AIX, and Irix. The reason I brought up the POSIX discussion is because I'm currently getting nmh to run (under ape) on Plan 9, which will never run autoconf and is a better place for it. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
I currently run nmh on multiple major releases of FreeBSD, Solaris, and OpenBSD. I forgot to include MacOS in there as well. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
Lyndon == Lyndon Nerenberg lyn...@orthanc.ca writes: Lyndon On 10-11-03 11:45 AM, Jon Steinhart wrote: So let's figure out what's really important. To me, that's Linux. Lyndon You are a lonely voice in a large crowd. Lyndon I have seven servers at home. None of them run Linux. I Lyndon currently run nmh on multiple major releases of FreeBSD, Lyndon Solaris, and OpenBSD. In the Lyndon not too distant past I used it on HP/UX, AIX, and Irix. Lyndon The reason I brought up the POSIX discussion is because I'm Lyndon currently getting nmh to run (under ape) on Plan 9, which Lyndon will never run autoconf Lyndon and is a better place for it. autoconf used to buy us a lot in the days when HPUX and AIX and IRIX couldn't actually get POSIX right. Those systems are mostly dead, except for a few who keep those systems around for fun. For the rest of us (including OSX, FreeBSD, Solaris, NetBSD, and yes.. Linux), POSIX is enough. I am not in favour of ripping autoconf, but I am also not in favour of maintaining it. I'd rather just have Makefile.posix checked in, and use that if I want, and if autoconf rots, oh well. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
Jon Steinhart wrote: While reading much nmh code these days, I also feel that parts of the code are ancient. I'd like to support any effort in renewing it. Autoconf is something I dislike. I suppose that I'm willing to do some work here too if I'm not alone. My main interest, which I expressed years ago, is to figure out what sbr/m_getfld.c is really doing and rewrite it so that I can add additional functionality without breaking anything. I'm not entirely sure what you mean by this. Yes, m_getfld is an incomprehensible piece of code. Yes, it really shouldn't be digging into libc internals in the 21st century. Yes, it has optimisation decisions made based on what is fastest on my VAX?. But that has nothing to do with implementing better handling of attachments, nicer MIME capabilities or anything else. m_getfld() has a very simple purpose: it lets you read headers and message bodies out of an RFC-822-style text file. You don't need to care about the internals unless they're actually buggy (and I don't know about any current bugs, though I did fix one or two a few years back). It doesn't need any new features because MIME doesn't change the format of RFC-822 messages, it just adds new things piggybacking on top, which the caller of m_getfld will eventually need to parse. Any attempt to rewrite or replace it ought to be preceded by the buildup of the kind of test suite mentioned in the comments in m_getfld.c and subsequently (alas) lost to history. (Some of the code in test/tests/inc is trying to make a start on that.) But if you just want to make nmh's handling of MIME or attachments better or improve its UI, you don't need to spend time doing anything with m_getfld anyway. -- PMM This made sense to me until the last sentence. The particular changes that I want to make involve parsing the mime stuff inside of the 822 style message bodies. I suppose that you could argue that I should make a new function that would parse the bodies. Maybe that's the way to go. Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
Jon Steinhart wrote: Any attempt to rewrite or replace it ought to be preceded by the buildup of the kind of test suite mentioned in the comments in m_getfld.c and subsequently (alas) lost to history. (Some of the code in test/tests/inc is trying to make a start on that.) But if you just want to make nmh's handling of MIME or attachments better or improve its UI, you don't need to spend time doing anything with m_getfld anyway. This made sense to me until the last sentence. The particular changes that I want to make involve parsing the mime stuff inside of the 822 style message bodies. I suppose that you could argue that I should make a new function that would parse the bodies. Maybe that's the way to go. Yes. m_getfld will give you the body text (in a series of chunks the size of the buffer you hand it, IIRC) and what you do with it after that is up to you. This is how nmh's existing MIME handling code works. (I suppose you could propose replacing m_getfld completely with something with a different and MIME aware API, but that would be an extensive project...) -- PMM Well, yeah, that is what I'm thinking about. Seems silly to have m_getfld call something that sort of looks like m_getfld but is different. Making it work down to all of the body parts would in my mind be architecturally better for nmh. But, as you say, more work. Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
Well, yeah, that is what I'm thinking about. Seems silly to have m_getfld call something that sort of looks like m_getfld but is different. Making it work down to all of the body parts would in my mind be architecturally better for nmh. But, as you say, more work. So why not create a new and improved but robust and backwards-compatible m_getfld by a different name to implement the new behavior? It can then be tested for awhile with the new features and once it proves reliable, replace the existing calls? (perhaps with an experimental build option for early adopters to do so now). It's a few more steps, but you otherwise seem to get the best of both worlds? Modern code for the future without discarding stable spaghetti of the present. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
Jon Steinhart wrote: Any attempt to rewrite or replace it ought to be preceded by the buildup of the kind of test suite mentioned in the comments in m_getfld.c and subsequently (alas) lost to history. (Some of the code in test/tests/inc is trying to make a start on that.) But if you just want to make nmh's handling of MIME or attachments better or improve its UI, you don't need to spend time doing anything with m_getfld anyway. This made sense to me until the last sentence. The particular changes that I want to make involve parsing the mime stuff inside of the 822 style message bodies. I suppose that you could argue that I should make a new function that would parse the bodies. Maybe that's the way to go. Yes. m_getfld will give you the body text (in a series of chunks the size of the buffer you hand it, IIRC) and what you do with it after that is up to you. This is how nmh's existing MIME handling code works. (I suppose you could propose replacing m_getfld completely with something with a different and MIME aware API, but that would be an extensive project...) -- PMM ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
Well, yeah, that is what I'm thinking about. Seems silly to have m_getfld call something that sort of looks like m_getfld but is different. Making it work down to all of the body parts would in my mind be architecturally better for nmh. But, as you say, more work. So why not create a new and improved but robust and backwards-compatible m_getfld by a different name to implement the new behavior? It can then be tested for awhile with the new features and once it proves reliable, replace the existing calls? (perhaps with an experimental build option for early adopters to do so now). It's a few more steps, but you otherwise seem to get the best of both worlds? Modern code for the future without discarding stable spaghetti of the present. I could do that. But, as I tried to say earlier, I can't do it because I don't *really* understand what m_getfld does. I have a general idea, but not enough to think that I could really duplicate it easily. Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
Ken Hornstein wrote: In my view, there are two reasons for autoconf: - Portability tests (all of those tests that make up the bulk of time it takes autoconf to run). - Selecting things like which compiler to use, features to build, install location, etc etc If the goal is to remove all of the reasons for the portability tests in autoconf, hey, that's great. Fully support that 100%. I'm not sure that will be possible in practice, but there's no reason we can't try. Yep. We can do this incrementally too, so we can do the stuff that really doesn't need to have autoconfery and ifdefs and leave the tricky stuff til later (for instance I think you're going to have a hard time getting rid of the gdbm probing, because there really are modern systems out there which put the db libraries and headers in different places). -- PMM ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
Lyndon Nerenberg wrote: I currently run nmh on multiple major releases of FreeBSD, Solaris, and OpenBSD. I forgot to include MacOS in there as well. Remind me to ask you to do some testing next time we do an nmh release :-) -- PMM ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
Jon Steinhart wrote: Yes. m_getfld will give you the body text (in a series of chunks the size of the buffer you hand it, IIRC) and what you do with it after that is up to you. This is how nmh's existing MIME handling code works. (I suppose you could propose replacing m_getfld completely with something with a different and MIME aware API, but that would be an extensive project...) Well, yeah, that is what I'm thinking about. Seems silly to have m_getfld call something that sort of looks like m_getfld but is different. Making it work down to all of the body parts would in my mind be architecturally better for nmh. But, as you say, more work. If you did want to replace it I would suggest that a new API ought to involve just getting a complete header/body part in one go rather than m_getfld's keep-looping-round-til-I-say-stop approach. That design made sense on the VAX (it is attempting to avoid memory allocations) but on a modern machine it just makes the calling code jump through hoops and liable to buffer overruns or random fixed length limits. m_getfld but with some extra states for MIME parts I think would not be a very useful direction to go in. -- PMM ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
[2010-11-01 20:57] Lyndon Nerenberg (VE6BBM/VE7TFX) lyn...@orthanc.ca The JLR question prompted me to take a quick scan through the code base. A lot of the conditional compilation is leftover from the pre- or early-POSIX days (e.g. string and network related functions that are now standardized), SMTP client hacks that are no longer applicable, and support for obsolete features (e.g. KPOP). At the least I think it's worthwhile to make a pass through the source, eliminating the HAVE_* conditionals that are no longer necessary in the age of ANSI/POSIX. It's also long overdue to clean up the SMTP client code to bring it into line with the current port 587 submission regime. Between the two I think we can get most of the way towards no longer depending on autoconf, which would be a big win for those of us building the code on lighter-weight hardware and OSes. While reading much nmh code these days, I also feel that parts of the code are ancient. I'd like to support any effort in renewing it. Autoconf is something I dislike. I have the tuits to do this, as it relates to a work project for which I'll have to do it anyway. Game? (Could you explain ``having the tuits'', please.) meillo ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
(Could you explain ``having the tuits'', please.) Alas, this seems to be a glaring omission from the Jargon File. Whilst proscrastinating and/or busy, one might respond to the expected completion date of a new task When I get a round to it. Thus there are round tuits: http://www.google.com/products?q=round+tuit et cetera, and this case, a general lack of available tuits: a mythical unit of ability to do work ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
They sell them at my local farmer's market. --Original Message-- From: markus schnalke Sender: nmh-workers-bounces+jch=honig@nongnu.org To: nmh workers Subject: Re: [Nmh-workers] cleaning out the cobwebs Sent: Nov 2, 2010 17:29 [2010-11-02 17:12] belg4...@pthbb.org (Could you explain ``having the tuits'', please.) Alas, this seems to be a glaring omission from the Jargon File. Whilst proscrastinating and/or busy, one might respond to the expected completion date of a new task When I get a round to it. Thus there are round tuits: http://www.google.com/products?q=round+tuit et cetera, and this case, a general lack of available tuits: a mythical unit of ability to do work Thanks. Seems I should buy some of these round tuits. ;-) meillo ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers Thanks Jeff ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] cleaning out the cobwebs
The JLR question prompted me to take a quick scan through the code base. A lot of the conditional compilation is leftover from the pre- or early-POSIX days (e.g. string and network related functions that are now standardized), SMTP client hacks that are no longer applicable, and support for obsolete features (e.g. KPOP). At the least I think it's worthwhile to make a pass through the source, eliminating the HAVE_* conditionals that are no longer necessary in the age of ANSI/POSIX. It's also long overdue to clean up the SMTP client code to bring it into line with the current port 587 submission regime. Between the two I think we can get most of the way towards no longer depending on autoconf, which would be a big win for those of us building the code on lighter-weight hardware and OSes. I have the tuits to do this, as it relates to a work project for which I'll have to do it anyway. Game? --lyndon ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
