Re: Anyone home?
First off, let me say that I didn't mean to suggest stepping on anyone's toes -- I certainly feel that Dan and Doug have done the world a service, and I respect that. I threw out SF as an option because it would let us beat on an `interim release' or similar without disturbing the current mhost stuff. I almost suggested Savanah, but I wanted to avoid the license question; it sounds like that's a non-issue. If Doug's willing, we're probably better off just working from a new module on mhost. Given that mh and nmh are both pretty stable at this point, and that there are issues with major features and compatibility (such as the pernicious date parsing discussions), I'd suggest starting work on a new `major version', so we wouldn't need to feel so bad about the various incompatibilities. Aside from the bug fixes, I think we've agreed in the past that mh should have better support for MIME and IMAP, and that both will be somewhat complicated; I'm sure that there are other big projects to consider. I suggested 1 Jan as a minimum time to give everyone a chance to respond; like Ken, I am moved by the quick responses. Let's see what we can do. To directly address Peter's question: yes, I believe that the proposed changes could be nice for mh-e support, but they don't seem very close to `deployed' to me right now. I'm including Jon Stienhart's message below. chad --- Forwarded Message Message-Id: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: again - New code that simplifies user interface for MIME attachments to a draft MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=- =_aa0 Content-ID: [EMAIL PROTECTED] Date: Thu, 05 Jul 2001 08:01:34 -0700 From: Jon Steinhart [EMAIL PROTECTED] - --- =_aa0 Content-Type: text/plain; name=sendQ59nO_; x-unix-mode=0644; charset=us-ascii Content-ID: [EMAIL PROTECTED] Content-Description: English text Well, that was embarassing. A last minute fix created a bug in the stuff that I just sent. Here it is again with the bug fixed... I posted some code that improved the user interface for adding MIME attachments to messages some months ago. While the code worked fine, I didn't really like the way that I had implemented it and have subsequently done it over. Since I don't have write access to the CVS, please look it over and check it in if it looks OK to you. If it doesn't, let me know what you think should be changed. Here's the contents of the README-ATTACHMENTS file that is included with the patches: Jon Steinhart's ([EMAIL PROTECTED]) Attachment Handling Patches ~~~ Attached are a set of patches designed to improve the nmh user interface for handling MIME attachments. Why Did I Do This? ~~ Although nmh contains the necessary functionality for MIME message handing, the interface to this functionality is pretty obtuse. There's no way that I'm ever going to convince my partner to write mhbuild composition files! And even though I know how to write them, I often screw up when sending a message that contains a shell script because I forget that I have to double any # at the start of a line, which shell scripts have galore. These patches simplify the task of managing attachments on draft files. They allow attachments to be added, listed, and deleted. MIME messages are automatically created when drafts with attachments are sent. Did I Do This Correctly? Hard to say. Despite lots of time looking at the nmh code, I can't say that I get the philosophy behind its structure. I am aware of two deviations from what I saw in the nmh code. 1. I commented my changes. 2. It's been years since I've used a VT-100, so I don't try to make code fit into 80 columns anymore. Seems silly to me. What Did I Do? ~~ I made changes to the following files: h/ prototypes.h man/ anno.man send.man whatnow.man uip/ Makefile.in anno.c annosbr.c send.c sendsbr.c viamail.c (needed change for new sendsbr argument) whatnowsbr.c Attachments are associated with messages using header fields. For example, a draft that looks like this To: jon Subject: test of attachments X-MH-Attachment: /export/home/jon/foo X-MH-Attachment: /export/home/jon/bar X-MH-Attachment: /export/home/jon/test/foo has the files foo, bar, and foo as attachments. Although I use the header field name X-MH-Attachment to indicate attachments, the implementation allows any header field name. The advantage of using header fields is that the list of attachments travels with the draft so it remains valid across editing sessions. Note that the header fields for attachments are removed from
Re: Anyone home?
New module? No, that is just not the way CVS is supposed to be used. Maybe a seperate branch if radical changes are going to be made, but HEAD is the appropriate place for most development. Hmm. While I agree with you, and I'm certainly willing to try it, I have to say that most of the time I've seen people try to use separate branches for radically different versions of softare the results were at best `confusing'. That said, I'm all for trying it again.. :-) chad
Re: Anyone home?
chad wrote: I would say that if you are interested and don't get a response in a reasonable time, a new SourceForge project may be in order. I'd suggest ``1 January 2002'' as a reasonable cut-off, Hi all -- How's SourceForge doing these days? VA Software isn't in the best shape now, I hear. I've been trying to find a big chunk of time to move the online MH book to SourceForge, but now I'm wondering if I might move it there and the server would go away. Comments, anyone? Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: Anyone home?
On Thu, 2001-12-06 at 17:47, chad wrote: In looking over back mail recently, I noticed that no one responded to Jon Steinhart's interesting patches regarding mime attachments. If memory serves, he prodded the list more than once; at least once with no response in early July. I would say that if you are interested and don't get a response in a reasonable time, a new SourceForge project may be in order. I'd suggest ``1 January 2002'' as a reasonable cut-off, personally. there actually already is a sourceforge project for nmh. i set it up quite a while ago when there was something with mhost.com (can't remember what the exact issue was), but the development was never moved from mhost.com to this project. i too have been unable to work on the nmh project for quite a while now due to personal reasos, and don't think i'll be able to do so in the near future. if someone else does take over the project, i would still be interested in participating at some point. thanks, - ruud -- ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
Re: Anyone home?
How's SourceForge doing these days? VA Software isn't in the best shape now, I hear. I've been trying to find a big chunk of time to move the online MH book to SourceForge, but now I'm wondering if I might move it there and the server would go away. Comments, anyone? Make a backup. --Ken
Re: Anyone home?
No, I agree there hasn't been much work. I think the major sticking issue for a 1.0.5 was that Dan was not happy with the new date parsing code. The new code was a bit faster and actually compiled. The old parser was some crufty code that was being munged with sed in order to compile. However, the exact data semantics were not identical to 1.0.4. Well, if _I_ took over (which is just a suggestion at this point), I am perfectly happy to keep your date parsing code. A release needs to be made; not having one is (IMHO) simply Not Acceptable. --Ken
Re: Anyone home?
I would suggest Sourceforge not be used for a variety of reasons; First being the fact that it is a sinking ship. If people feel a Sourceforge-like site is really needed it would make more sense to me to use savannah.gnu.org which is now open to non-GNU projects. What is wrong with mhost.com though? I don't see anything wrong with mhost, per se ... other than Dan (the guy who was really driving nmh development) and Doug (the guy who hosts the site) seem to be busy now. That makes it difficult to manage the site (e.g., put new releases up for ftp). If we wanted to do a new release (which I think should REALLY REALLY happen) then likely we need to move things to a new site. I can host things here, which shouldn't be a problem until I happen to get a new job (which I have no plans on doing, but I just thought I should mention it). If someone else wants to host it, then that's fine with me too. I just want to get things moving again, and starting over with a new site is one way of doing that. But it certainly isn't the only way. --Ken
Re: Anyone home?
Ken Hornstein wrote: I don't see anything wrong with mhost, per se ... other than Dan (the guy who was really driving nmh development) and Doug (the guy who hosts the site) seem to be busy now. That makes it difficult to manage the Hi, sorry to be late getting in on this, but you guys started this thread while I was already in bed. I just woke up and figured I'd see what all the mail I was getting was about. :-) If someone wants to take over driving the developement, I'm more than happy to keep hosting it. It might be nice to see what's happened to Dan, to keep from ruffling any feathers. As well, I am hoping to start having some time to get back to doing some development work. I've backed off from my real job and have a nice position now doing some dev work and keeping normal sane hours. So it's within the realm of possibility that I could actually start writing code for fun again. That said, I don't want to overcommit, and if someone else wants to keep nmh going, that's probablly better. site (e.g., put new releases up for ftp). If we wanted to do a new release (which I think should REALLY REALLY happen) then likely we need to move things to a new site. I can host things here, which shouldn't If you have some reason to move it, I'll be happy to hand over the CVS, but I don't see that that's really necessary. Mhost is here, and I have no plans to take it down. It's self-sustaining at this point. It's mostly a hobby, but it doesn't cost me that much to run and it gives me a place to put up my climbing pictures and, of course, to host projects. -- Doug Morris Morris Communications Computer Services, Inc. http://www.mhost.com/
