Where is the latest ns* module? Why do I have to manually edit a module's Makefile? Why are these modules scattered all of the net? How come we have the same module in multiple places? Why does the coding style in one module look completely different than the coding style for another module? Why do neither of those conform to the style that the AOLserver core uses?
Right now, nssoap is a separate project; there are two nsxml's on sourceforge, one in the AOLserver area, and one in the acs-misc area. There's an nsgraph module on it's own. nspostgres is in both AOLserver at sourceforge and is at the OpenACS site (my fault: I asked for it to be imported into AOLserver@SF so I could apply the standard AOLserver C coding styles and maintain it). And more. Many of the modules I've worked with compile differently. nstomcat, for example, makes you copy the sources from it into the Tomcat source tree, and then run make. Other modules require you to hand-edit their Makefiles to get them to work instead of passing params on the command line to make. === The world seems to be going Java, but I, apparently, am a neanderthal. I prefer C, Tcl, AOLserver. However, I need the ability to do XML/XSLT to PDF, HTML and other formats, *easily*, without having to re-engineer the modules I want to use to get the job done, or write them from scratch. I simply don't have the time, and I am *certainly* no coding genius, nor do I plan to spend much of my spare time staring into the phosphor. Looking around the net recently, I've seen a lot of Java projects that attempt to do what I'm looking for. These include Cocoon, WebMacro, the ACS, and Enhydra, to name just a few. Most of these projects seem aimed to solve the problem of handling the heavy work of web publishing/collaboration while letting you focus on your apps at a high level. I like the idea of being able to plug in a .jar file and have instant access to a tool I need, such as an XML parser, and it looks like I'll be going the all-Java route in the near-future. === So, I need to be able to grab a new module, compile, install and configure it and just have it *work*, without a lot of monkeying around. And when I do need to monkey around with a module, I would like it to follow a standard coding style so I can easily work with it. Here are my suggestions: * Move all ns* modules into the AOLserver sourceforge area. (Yes, *ALL* of them). * Add the people who work on these modules to the AOLserver committer's list * Apply the standard build procedures to each module * Apply the standard C coding style to each module * Build regression tests for each module (a *must*) * Write basic docs that cover a module's compilation, config and use I can contribute my time to applying the standard build procedures and reformatting/refactoring the code to conform to the AOLserver coding style. Some discussion needs to be done with regard to regression testing, and a template doc needs to be generated. With a consistent, well-tested codebase, using or fixing AOLserver modules should become significantly easier. And it's not that much more work doing it right the first time. Is anyone interested? /s.
