[JB] As for the suggestions about re-organziation to improve customizability, you are fundamentally right. My design focus was service (www.mail-archive.com) oriented as opposed to product oriented. If the focus is product oriented, re-organization to support customization would be very helpful. I am not currently planning a re-organization of this sort, as doing a good job, while not compromising simplicity, will be difficult and time consuming. My energies are still service oriented. However, don't let that stop you, and if you make clean changes, please send'em in!
[AL] Understood that your priority is service oriented, not developing product. However you have taken the first step of releasing code with reasonable expectation that as well as helping others it may help your service from feedback. My view is that apart from benefit to others you will need to take the second step of re-organization to support customization (though not much more than re-organization) in order to get much benefit for your service, precisely BECAUSE doing a good job while not compromising simplicity will be difficult and time consuming. It will be less difficult and time consuming for you because of your familiarity with the code than for others so is likely to be delayed if left to others and you are less likely to compromise simplicity than others would. At present anybody implementing will be more inclined to just do the customization they need for their own site without taking on the re-organization job (or just customize MHonArc directly for a single local site administered directly as usual rather than retaining your approach of enabling remote users to add lists by email). Once you have done the re-organization (without also taking further steps to make customization as simple as possible since that is not your priority), including mailme in the ports/packages collections for standard Unixes like FreeBSD and various Linux distributions will enable significant numbers of people to run local archive services based on yours, as a result of which there would be a flow of patches, suggestions and perhaps significant add-ons that really would benefit your service (as well as further improvements in customization made feasible by the re-organization). Standard Linux RPM and FreeBSD pkg_add facilities with dependencies on MHonArc, Ht://Dig, MH and any other "required" packages to be installed first with "plain vanilla" customization could result in large numbers running it, not as a public archive service like yours, but simply for convenience in subscribing to mailing lists in the same way that you browse your own service for the lists you are interested in following. BTW, re-organization should take account of the possibility of switching from shell to perl so that somebody could implement a package for Windows platforms too. Since MHonArc is capable of running under Windows there would be potential for even larger numbers of users (though a smaller proportion would submit patches). [JB] As to your specific suggestions, I think keeping the rcfile intact (as opposed to generated in pieces) might be important in keeping things understandable. However, internal organization of that file and embedded comments might be improved [i.e. organize the file into separate sections (along the lines you mentioned?) and documentinteractions] [AL] Understood. Perhaps there should be an rcfile.model with paramaters some of which are also used in digger.model etc (and per list option - generate $HOME/archive/$MAILLIST/rcfile from rcfile.model at list subscription time instead of $HOME/rcfile at install time). My suggestions were just off the top of my head. You know what needs to be done. Even if you don't agree with above advice to do the re-organization yourself perhaps you could write a plan for it spelling out exactly what should be done and how, which might encourage others to do it or might eventually be used by yourself (with possible benefit of further suggestions from others before proceeding), but either way would be more likely to avoid compromising the simplicity than if left to others to design as well as code.
