Re: what's happening?
[EMAIL PROTECTED] writes: Chris Garrigues [EMAIL PROTECTED] writes: What was the date of the memo. I think we may need to celebrate mh's silver anniversary. --- Forwarded Message Received: from truth.rand.org by rand.org; Tue, 17 Apr 90 09:03:40 -0700 Received: from localhost by truth.rand.org; Tue, 17 Apr 90 09:03:48 PDT Message-Id: [EMAIL PROTECTED] To: [EMAIL PROTECTED], Robert_Anderson [EMAIL PROTECTED], Phyllis_Kantar phyl@rcc, Tora_Bikson [EMAIL PROTECTED], Willis_Ware [EMAIL PROTECTED] Subject: The memo that began mh Cc: Norman_Shapiro [EMAIL PROTECTED] Date: Tue, 17 Apr 90 09:03:47 PDT From: norm@truth Attached is the result of rekeying a hardcopy of the memorandum. An original softcopy is no longer available. The rekeying attempted to duplicate the hardcopy including typos. The hard copy was not dated, but is was sent sometime prior to February 17 1977 and probably sometime after January 17 1977. To: Bob Anderson From: Stock Gaines, Norm Shapiro Subject: THE NEXT MESSAGE SYSTEM [...] This is wonderful, Norm!! Thanks so much for posting this! I definitely want to add this to the docs directory once we have the new CVS archive up and working. nmh has got to be one of a very tiny number of open source packages whose codebase has remained active for so many years, so historical documents like this are very valuable, IMHO. When Richard started nmh he decided to throw out almost all the historical info, but I feel this is a mistake. I've already added back the MH ChangeLogs, since those were the most important lost files, but I when I get a chance I want to look through the other informational files in the MH distribution to check for other stuff worth saving. -- Dan Harkless [EMAIL PROTECTED] http://harkless.org/dan/
Re: what's happening?
A lot, but there's a refusal to kick the ball into the goal. There have been many significant bug fixes over the last couple of years, but the maintainers don't seem willing to issue a new release to the outside world (UNFORTUNATELY!). Well, it seems like the last maintainer vanished, and I _wanted_ to release a new version, but I can't access the repository due to some OpenSSH weirdness. Not sure what to do from here. --Ken
Re: what's happening?
Who has usually rolled releases in the past? Was that Dan? I've heard that there was a lot of unreleased changes in the CVS. But, I'm sure we can work through this and get another release out there. Yes, that was Dan, but he seems to be gone now. I think I've used up my energy trying to get a release out earlier this year. If you want to take the ball, feel free. --Ken
Re: what's happening?
I can help get a next release out. At the very least, I can help with testing, since I use nmh with my mail client.
Re: what's happening?
If I remember correctly, wasn't there still some problems remaining with the the code in CVS? I thought I remember some problems with date processing. If so, I would suggest rolling back those changes, if necessary. Then we should release a snapshot to a wider audience (since it has been a long time since the last release). That would at least get things rolling. Richard Coleman [EMAIL PROTECTED] Who has usually rolled releases in the past? Was that Dan? I've heard that there was a lot of unreleased changes in the CVS. But, I'm sure we can work through this and get another release out there. Yes, that was Dan, but he seems to be gone now. I think I've used up my energy trying to get a release out earlier this year. If you want to take the ball, feel free. --Ken
Re: what's happening?
If I remember correctly, wasn't there still some problems remaining with the the code in CVS? I thought I remember some problems with date processing. IMHO, the only problem was with Dan's perception of the date processing. I thought the changes were fine. If so, I would suggest rolling back those changes, if necessary. Then we should release a snapshot to a wider audience (since it has been a long time since the last release). That would at least get things rolling. Well, go ahead. --Ken
Re: what's happening?
At the time when I updated the code, it worked fine for my purposes, only differed significantly in: 1) parse failures for spam which often don't have legal (or legible) headers 2) Date: lines which did not include the timezone. I think previously it defaulted to assuming the local time zone, which I though was bogus. Now it defaults to UTC, which is arguably also bogus, but I think less so. Of course, I may be significantly misremembering. Another problem with the dtimep.c from 1.0.4 is that it doesn't compile. In order to build it, you need to run it through a sed script. End-users shouldn't necessarily need to regenerate the c file from the lex file, so it was an awkward situation. The new sbr/dtimep.c actually compiles on most platforms. Shantonu On Fri, 12 Apr 2002, Ken Hornstein wrote: If I remember correctly, wasn't there still some problems remaining with the the code in CVS? I thought I remember some problems with date processing. IMHO, the only problem was with Dan's perception of the date processing. I thought the changes were fine. If so, I would suggest rolling back those changes, if necessary. Then we should release a snapshot to a wider audience (since it has been a long time since the last release). That would at least get things rolling. Well, go ahead. --Ken
Re: what's happening?
It's interesting to see the folks that have been using MH/nmh for so long. I've tried a lot of email readers. I've switched away from MH/nmh on 4 or 5 occasions. But I always seem to come back eventually. What makes this so amazing is that MH/nmh is not that much code compared to many of the more modern mail readers. Outlook probably has 100 times the lines of code that MH/nmh does. But, MH/nmh seems to possess something that can't be found anywhere else. Richard Coleman [EMAIL PROTECTED] Richard Coleman [EMAIL PROTECTED] writes: ... I was thinking I would do a little hacking again. Delightful news. PS. I am one of the two authors of the 1977 memo that began mh. Norman Shapiro 798 Barron Avenue Palo Alto CA 94306-3109 (650) 565-8215 [EMAIL PROTECTED]
Re: what's happening?
Chris Garrigues [EMAIL PROTECTED] writes: What was the date of the memo. I think we may need to celebrate mh's silver anniversary. --- Forwarded Message Received: from truth.rand.org by rand.org; Tue, 17 Apr 90 09:03:40 -0700 Received: from localhost by truth.rand.org; Tue, 17 Apr 90 09:03:48 PDT Message-Id: [EMAIL PROTECTED] To: [EMAIL PROTECTED], Robert_Anderson [EMAIL PROTECTED], Phyllis_Kantar phyl@rcc, Tora_Bikson [EMAIL PROTECTED], Willis_Ware [EMAIL PROTECTED] Subject: The memo that began mh Cc: Norman_Shapiro [EMAIL PROTECTED] Date: Tue, 17 Apr 90 09:03:47 PDT From: norm@truth Attached is the result of rekeying a hardcopy of the memorandum. An original softcopy is no longer available. The rekeying attempted to duplicate the hardcopy including typos. The hard copy was not dated, but is was sent sometime prior to February 17 1977 and probably sometime after January 17 1977. To: Bob Anderson From: Stock Gaines, Norm Shapiro Subject: THE NEXT MESSAGE SYSTEM Copies: Dave Crocker, Dave Farber, Carl Sunshine, Steve Tepper, Steve Zucker While the creators of MS are to be congratulated in having produced a substantial advance over SND and MSG, the current system, in a couple of ways, falls short of the software for dealing with messages that we should have in UNIX. MS as it stands is in two fundamental and important ways at odds with the UNIX philosophy and approach. We think that another iteration on message software should take place which will provide us with software the dealing with messages that is again an advance over MS and will fit in naturally with UNIX in a way that MS does not, from which a number of practical advantages will follow. The two ways in which MS is basically incompatible with the UNIX approach are first that it is a monolithic system rather than being a set of functions which are callible from wherever is appropriate, and second that the storage of messages is not done by making appropriate use of the file and directory structure (an exceedingly elegant, simple and powerful one) already existing in UNIX. Let us discuss the UNIX way of storing messages first. As an alternative to the clumsy method of using a text file and a structure file, we suggest that instead a mailbox be simply a directory. Each message would then be a separate file in that directory. If it is necessary to keep additional information about the files in the directory, that can be done by entering in the message directory a file containing information about the messages in the directory. Notice how many of the things we are trying to do with the structure file get handled automatically if this occurs. For instance, each time a message is written or read, the file system already automatically updates this information. Therefore, a clear indication that we have a new message in a mail folder is that the instant of writing and reading is the same. If they are different then we can test the time last written to see if the message was received recently or not. Dave Crocker has in the past pointed out that the rm command has the disadvantage that it throws a file away. It would be quite appropriate to add a shell command called, say, dis (for discard) which moves a message from the directory it is in to a subdirectory of that directory which we may think of as the discarded messages directory. These messages can be cleaned out by some sort of a cleanup command or by software that carries out this task at appropriate times. The point is that IF the garbage retrieval function is desireable for messages, then it is so for files. Of course, in the directory structure we have no information concerning the contents of messages. However, there is some reason to be believe that the current design which retains pointers to each of the components of a message is of no advantage and may be more costly in execution time than if no such information were available. In any event, it is merely an effort towards efficiency and one which appears to have little value. The additional value which would accrue if messages were files is substantial. They then become accessible to other software in the system in a natural, convenient and highly useful way. The lack of such accessibility of messages is currently one of the major deficiencies of MS. As Steve Tepper has suggested, the draft message might itself be a directory to expedite its processing, although it is not clear that the advantages of this outweigh the advantages of leaving the whole draft as a single file. The second major difference we are suggesting between the current MS and the approach we believe is appropriate for UNIX is that the functions for dealing with messages should be embodied in individual command level routines which can be executed by themselves rather than only being available through a subsystem. The subsystem approach is appropriate for special situations such as NED, but
what's happening?
Well, I've been out of the loop on what's been happening to nmh. For those that don't know me, I originally started nmh (oh so many years ago). Due to where I work (Interland), I haven't used nmh much in the last year or so. But I've started using it again on my home systems and decided to see how the development was going. I've got a couple improvments that have been on my TODO list for quite some time. I was thinking I would do a little hacking again. Richard Coleman [EMAIL PROTECTED]