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] Fixing decoding of quoted messages in replies
[2010-10-26 19:18] Peter Maydell pmayd...@chiark.greenend.org.uk markus schnalke wrote: during the next weeks I intend to fix the annoying problem of still encoded message text in quoted replies. That would certainly be a cool thing to have working. I'm still becoming familiar with the code base, in order to find out how everything works and how to do it in a fairly good way. You might be interested in this: http://www.mail-archive.com/nmh-workers@nongnu.org/msg01508.html The referenced mail helped a lot, thanks. Basically there are a number of intertwined problems. My major concern would be that in fixing de-encoding when composing replies we don't accidentally paint ourselves into a corner for the UI/config settings for getting the larger issues right. Right. meillo ___ 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] Fixing decoding of quoted messages in replies
[2010-10-31 19:22] Ralph Corderoy ra...@inputplus.co.uk I was thinking of a scan(1) replacement that would colour-code the results, if I wanted. You can do this by piping the output through a highlighter program, or even by using a customized format file for scan. To begin with, I'd be happy with configuration being in Python. I hope you don't find supporters for that. ;-) And then an mhshow(1) that assumes a UTF-8 terminal and converts headers and body to that for one seamless less(1) It should surely not assume anything but find out (MM_CHARSET) what is wanted. Also not less(1) but moreproc. But on the seamless output, I agree. instance without a Press return to show content... prompt. -nopause fix that, or? meillo ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Fixing decoding of quoted messages in replies
[2010-10-26 21:03] Oliver Kiddle okid...@yahoo.co.uk markus schnalke wrote: (1) Showing messages with different charsets requires a line like mhshow-charset-iso-8859-1: iconv -f iso-8859-1 | %s in the profile if your terminal is on UTF-8. It might be worth to include such processing directly into nmh in order to make it more usable out-of-the-box. Iconv is already available (if compiled in). That would be good but you lose some flexibility. In some cases, I use the //TRANSLIT option on iconv. Also, I actually treat iso-8859-1 as windows-1252 because mails from Windows systems are sometimes incorrectly identified as iso-8859-1. mhshow-charset- entries should have precedence, of course. Then everything would be like now but text in foreign charsets gets converted to the native charset if nothing else is said. meillo ___ 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] Fixing decoding of quoted messages in replies
And then an mhshow(1) that assumes a UTF-8 terminal and converts headers and body to that for one seamless less(1) I personally want mhshow to go away. It should all be integrated into show. ___ 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
