Re: should nmh be an MTA or an MUA? (Was: Re: [Nmh-workers] nmh @ gsoc?)
In the message dated: Wed, 27 Jan 2010 20:53:46 EST, The pithy ruminations from Ken Hornstein on Re: should nmh be an MTA or an MUA? (Was: Re: [Nmh-workers] nmh @ gsoc?) were : = Have we not beaten this subject into the ground yet? = = Here's where we differ. For me, it's easier to configure sendmail, so that = the nmh configuration remains the same in any network environment. = = Alright ... so, my answer to this is: So what? = = Yes, it's easier for _you_. Great. But that doesn't translate to easier = for _everyone_. We've already seen numerous examples of people providing I never said that my was was easier for everyone...hence the use of the wording For me... I was simply offering a counter-example to a use case that you proposed as an absolute. = legitmate reasons for using the SMTP MTS. The SMTP MTS is not a new = feature in nmh; it's been there forever. Clearly people thought it was Right. Been there forever, with little maintenance (as evidenced by all the calls for TLS support). Building more MTA features into nmh is kind of like an arms race...without on-going maintenance to keep up with the requirements being introduced by ISPs, corporate environments, etc., nmh will often be unable to send mail. On the other hand, dedicated MTA tools are under faster development cycles, and can be used in more environments. = useful, even a bazillion years ago. Both MTS's will continue to be I'd argue that the MTA within nmh was more useful a bazillion years ago, when Vaxen roamed the earth and when there were fewer mail/authentication/security/ transport protocols. = supported for the foreseeable future. Anyone is free to configure nmh = however they want to meet their needs. What, exactly, is the problem here? Configuring nmh isn't the problem. If TLS support existed, it still wouldn't be a problem. The problem, as I see it, is limited resources for maintaining and enhancing nmh, as evidenced by the slow pace of development. The question that's being posed is where it is best to spend those limited resources. I suggest that adding MTA functions into nmh which already exist in external tools that can easily be used by nmh is not a good use of resources. You obviously disagree. = = And as for it being _easier_ ... well, literally, configuring the SMTP = MTS is as simple as placing this in your .mh_profile: = = send:-server your.mail.server.here -port your.mail.port here Yes...if nmh supports the protocol...which seems to be in question. = = There's already = extensive support in popular MTAs (sendmail, postfix, etc.) for multiple = delivery mechanisms (TLS, POP-before-SMTP, SMTP AUTH, MSA, etc), so = this doesn't need to be duplicated in nmh. I prefer to let the MTA accept mail = from nmh and then do the external transfer for me. = = This is a bit disingenuous; of the things you list, only one (TLS) Perhaps a bit sloppy on my part, but not disingenuous. I wasn't attempting to give a comprehensive list of mail protocols, nor did I ever say that nmh did not support those protocols. I was simply listing things off the top of my head to illustrate that there are many protocols, and that external MTAs offer more support. = is not supported by nmh. And honestly ... POP-before-SMTP? It's = not like you need to do anything to your client to support that. = = I also take objection to your subject line. This has been hashed Why not take your objections right out the door. The amount of discussion makes it clear that this is still a point of interest. = out extensively on this list; when using the SMTP MTS, nmh is _not_ = acting as a MTA, it is not looking up MX records and performing = final delivery. It is, in fact, acting like the large majority of I'm not going to spend half my day reading RFCs to see just how MTA is defined. The post manual page has references to both delivering mail directly, and to interacting with a local MTS (sendmail is given as an example). To me, it walks like an MTA and talks like an MTA. If you don't want nmh to act as an MTA, then why do you want to extend it's MTA-functions, instead of having it interact with a real MTA (the intention of post(8), as I read it)? It sounds like you want some of the features of an MTA (in this case, TLS), but not a full implementation. I can see why some people want that, and why the limited scope looks like it's consistent with the original [n]mh design in providing some transport functions. However, the original design came at a time when there were fewer SMTP options, and relied on tools outside nmh (ie., post(8) didn't have a uucp client). Does it make sense to put resources into providing functions that have already been implemented--and are being maintained--in MTAs that nmh is designed to interact with? = MUAs today (certainly any graphical email client) and using the = SMTP protocol to submit email into the email system. This is a = recognized and standardized method
Re: should nmh be an MTA or an MUA? (Was: Re: [Nmh-workers] nmh @ gsoc?)
The problem, as I see it, is limited resources for maintaining and enhancing nmh, as evidenced by the slow pace of development. The question that's being posed is where it is best to spend those limited resources. I suggest that adding MTA functions into nmh which already exist in external tools that can easily be used by nmh is not a good use of resources. You obviously disagree. Well, here's the thing about open source projects that are done by volunteers ... resources can't exactly be shuffled around to different projects. Why does nmh have SASL support? Because I needed, and I wrote the code. Why does nmh _not_ have TLS support? Because no one has written the code (in more cynical moments, I might say, Because I _didn't_ need it). Note that anyone is free to _write_ the code, and it's not clear to me that it's really all that hard ... but it hasn't happened yet. It's not like people working on TLS are somehow stealing programming time away from improving nmh in other ways ... people are free to improve nmh in whatever ways they see fit. Or not, as the case may be. I'm not going to spend half my day reading RFCs to see just how MTA is defined. The post manual page has references to both delivering mail directly, and to interacting with a local MTS (sendmail is given as an example). To me, it walks like an MTA and talks like an MTA. Well, I'm sorry ... if you don't understand exactly _what_ am MTA is, then how do you expect to participate in a discussion about them? I mean, you're the one who changed the subject line! And you should read the post(8) man page more carefully ... nowhere does it say that mail is delivered directly. All it mentions is a few extra configuration options available when using the SMTP MTS (note: MTS is purely nmh termology). Let me ask you this: do you consider Thunderbird to be an MTA? KMail? Sylpheed? If the answer to these questions is yes, then I would suggest that you try to understand exactly what an MTA is and is not. If the answer to these questions is no, then it's worth pointing out that nmh is doing the _exact same thing_ that these MUAs are doing in regards to SMTP message submission. It sounds like you want some of the features of an MTA (in this case, TLS), but not a full implementation. TLS is not a feature of an MTA. It is a feature of the SMTP protocol, which is implemented by both MUAs and MTAs. We already support SMTP AUTH (in fact, we support it better than most gateway programs people have listed here; TLS would merely be an additional SMTP protocol extension). --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: should nmh be an MTA or an MUA? (Was: Re: [Nmh-workers] nmh @ gsoc?)
Ken Hornstein wrote: I'm not going to spend half my day reading RFCs to see just how MTA is defined. [...] Well, I'm sorry ... if you don't understand exactly _what_ am MTA is, then how do you expect to participate in a discussion about them? I mean, you're the one who changed the subject line! And you should read the post(8) man page more carefully ... nowhere does it say that mail is delivered directly. All it mentions is a few extra configuration options available when using the SMTP MTS (note: MTS is purely nmh termology). Let me help, for those who fear RFCs: http://en.wikipedia.org/wiki/Mail_user_agent I direct your attention to the Functionality and configuration section. In summary: A Mail User Agent (MUA) retrieves mail from a Mail Transfer Agent (MTA) A Mail User Agent (MUA) formats mail for display, and allows editing of new messages. A Mail User Agent (MUA) submites messages to an MSA or MTA. I am befuddled how anyone would want to limit the how on any of these actions, beyond technical capabilities/support issues. Enforcing a *local* MSA is insane; an MUA should be able to contact as many MSA/MTAs as technically feasible. And I don't think it is beyond the scope of the Unix philosophy. Do one thing and do it well doesn't mean do that one thing only one way. Sure, 'show' shows plain text and HTML messages. You could argue it does two things. Or more. Based on plugins. So why don't we have a plugin/module that talks to an MSA with TLS? And it is very much accepted that TLS is a *STANDARD* way of delivering mail, even to a MSA running on a local box. Frankly, it sounds like there's disagreement about the support issues. My $0.02. Sean -- Sent from the 1st Circle ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: should nmh be an MTA or an MUA? (Was: Re: [Nmh-workers] nmh @ gsoc?)
I think the difficulty may depending on the TLS library to use. When I looked at years ago wrt openssl, it appeared to me that the work require rewriting I/O stuff in nmh. Of course, I was not an expert at the time, but I did not see a quick fix to the problem. Recently (post-1.3) I made a bunch of changes to the SMTP network code; part of that was running the I/O though the SASL encryption/decryption routines. Shouldn't be too bad to call openssl_whatever() instead of sasl_encode(). Obviously there will have to be some initial negotiation as well), but anyway, my point is some of that work should already be done. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh @ gsoc?
i know there have been a couple of fuse attempts at imap integration -- i don't recall how far they've gotten. if it weren't for possibly already having been done, i'd think that would be an almost ideal summer-of-code project, since it would be a somewhat stand-alone project, and something with pretty well-understood requirements. and there wouldn't be a lot of code archaeology needed to implement it, unlike some other possible projects. A good IMAP client isn't something you're going to write in a few months, and certainly not by a student with no prior IMAP implementation experience.. IMAP has a lot of subtle behaviours that make writing *good* clients difficult until you've had a non-trivial amount of experience actually implementing the protocol. At one company I worked at we went through three complete ground-up redesigns of our IMAP server over three years before we came up with something we were happy with. A FUSE based imapfs isn't a suitable candidate for a GSOC project. --lyndon ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh @ gsoc?
Lyndon == Lyndon Nerenberg lyn...@orthanc.ca writes: Lyndon A good IMAP client isn't something you're going to write in Lyndon a few months, and certainly not by a student with no prior Lyndon IMAP implementation experience.. IMAP has a lot of subtle Lyndon behaviours that make writing *good* clients difficult until Lyndon you've had a non-trivial amount of experience actually Lyndon implementing the protocol. At one company I worked at we Lyndon went through three complete ground-up redesigns of our IMAP Lyndon server over three years before we came up with something we Lyndon were happy with. Is a single threaded IMAP *CLIENT* really as complex as the server side? -- ] 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] nmh @ gsoc?
Thanks for the many responses and active discussion. I agree that MIME support should be improved. For people in non-English speaking Countries, like me, bad MIME handling is a big argument against nmh. But also the point of how to handle attachments in replies should be worked on. Also, threading is a main point. This must fit into the existing design. Hooks (or scripting support) might be a good point too. I can't decide for me yet. At least, one should give it a try. TLS seems to be already solved. However, why does nmh need TLS? Doesn't it delegate mail transfer to an MTA? IMAP is surely of interest. But I think this should not be the job of nmh, but of a FUSE layer below, as some already said. There might not be the danger of too many storage backends, but conceptional, such stuff does not belong into a MUA. (Because I don't use IMAP, this would probably not be a good job for me.) Lyndon said that nmh does not need someone like me to work on it. Don't get me wrong, I surely don't want to add lots of features. I don't want to break stuff. I don't think nmh should be changed. In contrast, I think nmh is great like it is, but there are always things to work on. This shall be work to support nmh, not to change it or to blow it up. Nmh bases on the Unix Philosophy -- I am convinced that this is the right way to design good software. The development on nmh slowed down much, but nmh is not dead. There might be few users, but the idea behind nmh is great ... and nmh is the only MUA to follow this idea. That alone is reason enough. I see a big chance for nmh in gsoc. Why not go for it? Appying under NetBSD's umbrella is surely a good way to go. Being an own mentor organization might make it more difficult to get accepted. But why not, if there is someone who cares for a good application? In any case, you have to provide descriptions, a roadmap, a goal, a vision and similar stuff. Maybe someone has experience. meillo ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh @ gsoc?
On Wed, 27 Jan 2010 23:21:10 +0100, markus schnalke said: TLS seems to be already solved. However, why does nmh need TLS? Doesn't it delegate mail transfer to an MTA? You may need it to talk to a remote MTA that insists on doing TLS. And there's valid use cases for it. Half the time my laptop is at home, so letting my local sendmail do the delivery isn't workable, lot of sites whinge at the fact that it's a cablemodem address. So if I want my mail delivered, my easiest is to forward through the MTA here at work. And it was easier to just tell nmh to forward rather than have it point at the local sendmail and reconfig that to forward. pgpG1WK8s6Hoa.pgp Description: PGP signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
should nmh be an MTA or an MUA? (Was: Re: [Nmh-workers] nmh @ gsoc?)
In the message dated: Wed, 27 Jan 2010 18:01:26 EST, The pithy ruminations from valdis.kletni...@vt.edu on Re: [Nmh-workers] nmh @ gsoc? were: = = On Wed, 27 Jan 2010 23:21:10 +0100, markus schnalke said: = TLS seems to be already solved. However, why does nmh need TLS? = Doesn't it delegate mail transfer to an MTA? Personally, I agree. = = You may need it to talk to a remote MTA that insists on doing TLS. And = there's valid use cases for it. = = Half the time my laptop is at home, so letting my local sendmail do the = delivery isn't workable, lot of sites whinge at the fact that it's a cablemodem I'm in the same positionmy laptop is the primary machine, and it's often on different networks, with varying outbound filtering. = address. So if I want my mail delivered, my easiest is to forward through the = MTA here at work. And it was easier to just tell nmh to forward rather than = have it point at the local sendmail and reconfig that to forward. Here's where we differ. For me, it's easier to configure sendmail, so that the nmh configuration remains the same in any network environment. There's already extensive support in popular MTAs (sendmail, postfix, etc.) for multiple delivery mechanisms (TLS, POP-before-SMTP, SMTP AUTH, MSA, etc), so this doesn't need to be duplicated in nmh. I prefer to let the MTA accept mail from nmh and then do the external transfer for me. Another advantage with this method is that it works with any process on my machine that wants to send mail (ie., log file monitor, the SteelVine software that monitors the health of my attached RAID array, calendar program that sends monthly reminders, etc.). Mark ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: should nmh be an MTA or an MUA? (Was: Re: [Nmh-workers] nmh @ gsoc?)
Have we not beaten this subject into the ground yet? Here's where we differ. For me, it's easier to configure sendmail, so that the nmh configuration remains the same in any network environment. Alright ... so, my answer to this is: So what? Yes, it's easier for _you_. Great. But that doesn't translate to easier for _everyone_. We've already seen numerous examples of people providing legitmate reasons for using the SMTP MTS. The SMTP MTS is not a new feature in nmh; it's been there forever. Clearly people thought it was useful, even a bazillion years ago. Both MTS's will continue to be supported for the foreseeable future. Anyone is free to configure nmh however they want to meet their needs. What, exactly, is the problem here? And as for it being _easier_ ... well, literally, configuring the SMTP MTS is as simple as placing this in your .mh_profile: send: -server your.mail.server.here -port your.mail.port here There's already extensive support in popular MTAs (sendmail, postfix, etc.) for multiple delivery mechanisms (TLS, POP-before-SMTP, SMTP AUTH, MSA, etc), so this doesn't need to be duplicated in nmh. I prefer to let the MTA accept mail from nmh and then do the external transfer for me. This is a bit disingenuous; of the things you list, only one (TLS) is not supported by nmh. And honestly ... POP-before-SMTP? It's not like you need to do anything to your client to support that. I also take objection to your subject line. This has been hashed out extensively on this list; when using the SMTP MTS, nmh is _not_ acting as a MTA, it is not looking up MX records and performing final delivery. It is, in fact, acting like the large majority of MUAs today (certainly any graphical email client) and using the SMTP protocol to submit email into the email system. This is a recognized and standardized method of injecting email into the network, and there is absolutely no reason for nmh to not support it. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh @ gsoc?
Lyndon said that nmh does not need someone like me to work on it. Well, he's just ONE guy. Ya, but I'll still take you all on!!! :-) --lyndon ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh @ gsoc?
Is a single threaded IMAP *CLIENT* really as complex as the server side? No. It's about ten times *more* complex than the server side. Most so-called IMAP clients are really POP clients that know how to switch mailboxes. --lyndon ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
FUSEd IMAP Re: [Nmh-workers] nmh @ gsoc?
It's not necessary to write an entire IMAP implementation from scratch, there are a few possible codebases to work with. List member David Keijser wrote of his attempt in Python this October: http://www.mail-archive.com/nmh-workers@nongnu.org/msg01803.html And there's also: http://code.google.com/p/imapfs/ -- Java, perhaps based on... http://imapfs.sourceforge.net -- Older Java The idea's also been around for some time, probably as long as FUSE: http://old.nabble.com/-fuse-devel---imap-:-Access-IMAP-using-fuse-td8066045.html -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Pungenday, the 28th of Chaos, in the YOLD 3176: Save the environment, use styrofoam oranges. --JP ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh @ gsoc?
A big advantage of nmh's code stability is that it provides a natural place to stop. Should we consider starting with a clean slate? An extensible architecture and modern language would make enhancements and maintenance much easier. And safer, e.g., nmh still uses mktemp because replacement is just too painful. Here is my $0.02 on that topic. I have no objection to anyone doing that. If people want to do that, hey, more power to them! It's not like I have it in my power to stop a group of people from doing that, even if I wanted to. But ... I'm not going to participate in that myself. I can't speak for anyone else, but my undergraduate days when I could spend weeks programming on a project just for fun are long gone. I've got a full-time job, a mortgage, a kid ... and I barely have enough time to balance my checkbook, much less do programming for _fun_. When I work on nmh, I have to give up something else, like watching TV or a movie with my family, exercise, or sleep (for the record, all of my significant programming work on nmh has been as part of larger projects at work). When I think about the amount of work involved in starting a nmh replacement from scratch ... well, it's just exhausting thinking about it. And I have to be blunt here ... while there are plenty of people who have good _ideas_ about nmh, what we seem to lack is an abundance of people who have the time and/or knowledge to _implement_ those ideas. Sure, we can talk about Grand New Ideas for New NEW MH until we're blue in the face ... but who's going to write that code? Me, I know that while it may be a hack, it will take less _time_ to change nmh to make it do what I want ... and time is what's really in short supply for me. And for the people who think nmh has reached the pinnacle of software development ... well, let me ask you: Why do you care what happens with nmh? You can still download MH 6.8.3, and every version of nmh ever released. If you think nmh 1.3 is perfect, well, if someone adds IMAP support, a native Java interpreter, or three copies of Emacs to nmh ... so what? The perfect nmh version 1.3 (or whatever) will still exist for people to use; I don't see anyone suggesting that we purge the Internet of all of the old ancient copies of nmh. Of course, it won't be easy to reach consensus on what should and should not be in it, what language, whether or not to use middleware, etc. But going through that process should give the gsoc student more exposure to real-world software development scenarios. A giant pile of ancient, poorly-documented legacy code? A cranky and brittle userbase? Sounds like the most real-world software development scenario imaginable! :-) --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh @ gsoc?
david wrote: A big advantage of nmh's code stability is that it provides a natural place to stop. Should we consider starting with a clean slate? An extensible architecture and modern language would make enhancements and maintenance much easier. And safer, e.g., nmh still uses mktemp because replacement is just too painful. Of course, it won't be easy to reach consensus on what should and should not be in it, what language, whether or not to use middleware, etc. But going through that process should give the gsoc student more exposure to real-world software development scenarios. it would also pretty much guarantee the gsoc student about 10 summers worth of work. :-) i know there have been a couple of fuse attempts at imap integration -- i don't recall how far they've gotten. if it weren't for possibly already having been done, i'd think that would be an almost ideal summer-of-code project, since it would be a somewhat stand-alone project, and something with pretty well-understood requirements. and there wouldn't be a lot of code archaeology needed to implement it, unlike some other possible projects. paul =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 41.2 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh @ gsoc?
Have you thought about applying for Google Summer of Code 2010? If you do, I am interessted in working on an nmh task. We have not ... but that might be worth doing, actually. I see one big hurdle - nmh doesn't really have a mentoring organization so to speak. If someone wants to set that up, then that would be cool ... but it's not something I'm personally interested in doing. Alternatively, we could glom onto another mentoring organization. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh @ gsoc?
Why? nmh doesn't need any new features, and the code is stable and portable. The best indicator that a chunk of code is mature is when it hasn't been touched for five years. It ain't broke, so leave it alone. --lyndon ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh @ gsoc?
In the message dated: Mon, 25 Jan 2010 13:37:15 EST, The pithy ruminations from Ken Hornstein on Re: [Nmh-workers] nmh @ gsoc? were: = Why? nmh doesn't need any new features, and the code is stable and = portable. = = The best indicator that a chunk of code is mature is when it hasn't been = touched for five years. It ain't broke, so leave it alone. = = Uuuhhh ... yeah, okay. That is certainly ONE possible interpretation. = Another possible (and much more likely) interpretation: no one uses nmh = very much anymore, so no one cares about fixing/improving it. I don't = know about you, but when I go to look at a software package and I see = the last new release was 5 years ago, my first thought isn't, Oh, it's = perfect! That's why they stopped developing it!; it's Oh, I guess = that project is dead. = [SNIP!] = Here are some pie-in-the-sky things I would like: = I'll add my wish-list: + minor bug fixes (for example, the NAMESZ limit that affects scan listings) + improved MIME handling, particularly for replies + improved attachment handling (supression(?) of replies to messages with attachments) + threading. I do some threading with exmh, but that's kind of a hack. One idea would be to present threads through ordered sequence lists, rather than by re-numbering each message. This would multiple sorted views of a folder (ie., sorted by date, subject, sender, threaded, etc.) without the overhead of renumbering files. + masquerading: we've probably all got multiple email accounts ($WORK, personal, gmail, etc.). I like to use [ex|n]mh as a single interface, but I want composed mail and replies to reflect different accounts (identities) correctly. I've written a wrapper to repl for this, but that functionality should probably be within nmh, so that the actions that arise from selecting a persona are available to all programs that send mail (repl, comp, forw). For example, selecting a persona may alter some or all of: From: address, Reply-To: address, Fcc folder, X-* headers, signature lines, quoting style, even different SMTP server[s] The very brevity of my wish lists reflects the mature level of the nmh code...or just my personal ossification. :) Thanks, Mark ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh @ gsoc?
know about you, but when I go to look at a software package and I see the last new release was 5 years ago, my first thought isn't, Oh, it's perfect! That's why they stopped developing it!; it's Oh, I guess that project is dead. I know. It's referred to as Slashdot syndrome. On an daily basis I'm using large swathes of code that haven't been touched in years, or even a decade. They stopped developing it because it works. Even five or ten years later. But today everybody wants to be a 'cool open software developer' which leads to insanity like Linux's cat(1). (I'm not accusing anyone here of being that way; my point is that's become a general malaise in today's software community.) - TLS support That one I'll give you. - IMAP support (I am not interested in arguing about whether or not this is a good idea, breaks the MH model, or other such nonsense - the undeniable truth is that there are people who are interested in it). I have wrestled with this one for years. By adding a VOP-like interface to the message store you could have two storage backends -- the native file store, and IMAP. But the pile-on will start immediately, and in no time we're dragging around 15 different storage backends, each with their own little quirks that need little tweaks to various MH commands, leading to the inevitable mess of conditional code, and the complete loss of the elegance and symmetry of what's there now. IMAP support is better handled completely outside of MH. With the advent of FUSE, the way to do this is to build an IMAP client that exports an MH-style file tree via FUSE. Then all you need to do is 'export MAILDROP=/mnt/imapfs' and everything just works. (Absent FUSE you can use loopback NFS mounts.) - Some sort of embeddedable language support for components files I'd rather see hooks in the component files that make it easy to invoke external commands. It's much more in spirit of the scriptability of MH. Execing things has higher overhead than an embedded language, but I doubt it would really be that noticeable. And I would certainly trade off the overhead of the exec() vs. the overhead of the additional code complexity that comes with embedded languages. And there would be more than one -- just like multiple message stores, if you open the door the flood *will* commence. --lyndon ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh @ gsoc?
berg...@merctech.com wrote: I'll add my wish-list: + minor bug fixes (for example, the NAMESZ limit that affects scan listings) + improved MIME handling, particularly for replies + improved attachment handling (supression(?) of replies to messages with attachments) + threading. I do some threading with exmh, but that's kind of a hack. One idea would be to present threads through ordered sequence lists, rather than by re-numbering each message. This would multiple sorted views of a folder (ie., sorted by date, subject, sender, threaded, etc.) without the overhead of renumbering files. + masquerading: we've probably all got multiple email accounts ($WORK, personal, gmail, etc.). I like to use [ex|n]mh as a single interface, but I want composed mail and replies to reflect different accounts (identities) correctly. I've written a wrapper to repl for this, but that functionality should probably be within nmh, so that the actions that arise from selecting a persona are available to all programs that send mail (repl, comp, forw). For example, selecting a persona may alter some or all of: From: address, Reply-To: address, Fcc folder, X-* headers, signature lines, quoting style, even different SMTP server[s] It would be great to have these in nmh. Just FYI, in the meantime, MH-E (a Emacs-based nmh frontend) does MIME handling (althought character encoding in headers isn't great yet because it gets them from nmh), threading, and masquerading. Dealing with attachments of replies is interesting... Peter ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh @ gsoc?
On an daily basis I'm using large swathes of code that haven't been touched in years, or even a decade. They stopped developing it because it works. Even five or ten years later. I've seen this in some cases ... but many times it's rather special-purpose code. I don't see it that much in what I would call system utilities, because those depend on features supplied by the operating system, and those DO move (hardware changes, operating system bugs force upgrades, et cetera). You want to have some fun? Try compiling the original MH on a modern operating system. I have wrestled with this one for years. By adding a VOP-like interface to the message store you could have two storage backends -- the native file store, and IMAP. But the pile-on will start immediately, and in no time we're dragging around 15 different storage backends, each with their own little quirks that need little tweaks to various MH commands, leading to the inevitable mess of conditional code, and the complete loss of the elegance and symmetry of what's there now. Do you honestly think that if someone writes an IMAP message store, there will be a pile on of additional message stores? I CANNOT see that happening. We do not have an active developer community; that is simply a fact. Most of the code is contributed by a half-dozen people, and is mostly driven by their needs. I cannot see those people each writing their own message store; to suggest otherwise is simply crazy. Notice that everyone who posted their wishlist included better MIME handling for replies in nmh; has this code been written? Nope. To return to the original point - I would be willing to ask the NetBSD Foundation (I'm a NetBSD developer) if they would be willing to be a sponsor organization for nmh, and do the leg work to make that happen. This means that they would get a small cut of the Google SoC stipend. If someone else wants to do the leg work for nmh directly (and get the stipend cut), then I have no objection. Last year the mentoring organization for Google SoC projects received $500; I think anyone doing the SoC legwork for nmh deserves that money. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh @ gsoc?
1) CREDIL.org could act as a mentoring organization. 2) THINGS needed in my mind: a) better MIME b) IMAP support. (I know various people have figured out how to do this with fuse, but I think it's far from stable, and maybe it could be better integrated) c) outgoing SMTP/SUBMIT authentication support, TLS d) some kind of vCard interface for exmh, mh-e. e) some updates to debian/redhat packaging (those organizations might want to co-mentor) f) some way to interface and/or share address book info from thunderbird/gmail/etc. and nmh/mh-e/bbdb/exmh. A standard address book API for POSIX would be cool here. g) unit testing and refactoring. (I haven't used exmh for ten+ years, mind you, since I started using mh-e) ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh @ gsoc?
c) outgoing SMTP/SUBMIT authentication support, TLS Done! (Except for the TLS part, though). nmh has had this for years, via Cyrus-SASL. Also supports encryption if the SASL mechanism supports it. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
