Sounds like a packaging problem to me. Bundling modules into the core will only turn it into a development/release problem.
Large projects actually seem to be going the other way: Postgres are moving things out of core and onto gborg; X.org is busy splitting up into server, fonts, utils, etc. What about the many modules and features that don't make it into core, do we just acknowledge that they will be a complete pain to build and install? I'm so lazy that I package all my software into RPMs. I only have to do it once, and from then on it's a doddle to install consistently on multiple machines without referring to docs or making mistakes. If y'all are dead set against whatever packaging system is native to your OS, you still have options. The Gnome and KDE projects for example have created build scripts which automatically download the source from cvs, build, and install, managing dependencies and build order. Can we put all non-core modules in a 'modules' directory in cvs? I thought it would be cool if each one had some meta data associated with it, maybe use something like the DOAP format: http://usefulinc.com/doap There would be a little script which automatically builds web pages for all modules each night. Packages would be auto-built and placed int yum/apt repositories. There would be links to CVS, the bug tracker for that module, the latest entries in the ChangeLog... That's my grand vision for modules and packaging -- a small shell script will replace me! How does this sound? What OS are you installing on? On Mon, 7 Mar 2005 16:34:55 +0100, Bernd Eidenschink <[EMAIL PROTECTED]> wrote: > Hi Vlad, > > > > I have no idea. We are using the server with our own templating > > > framework based on tDOM but I do not think this is something > > > of general interest. > > > > I have light-weight templating i can extract and put into modules/tcl, > > that will be one small file and will support OACS-style templating > > where .adp and .tcl are define template. But it requires some work to be > > extracted > > from my "big" framework system. > > I would also like to extract some functionality from our toolkit. It would be > nice if there is a small toolkit with basic stuff like database abstraction, > page and session management, authentication and basic permissions. > I like the idea to rewrite it in a way so that it utilizes new naviserver > functions like the c-cookie-api or database stuff (I read from Stephen?). > In our framework we do not map and use the standard ADP-stuff, we use > registered filters and procs and ns_adp_parse files, but it should be > managable to rewrite it. > > > For public version in the future i would include as manu maintained > > modules as possible. > > What do you think about a "contrib" directory (like in PostgreSQL or other > packages): > > <QUOTE> > > The PostgreSQL contrib tree > --------------------------- > This subtree contains porting tools, analysis utilities, and plug-in > features that are not part of the core PostgreSQL system, mainly because > they address a limited audience or are too experimental to be part of > the main source tree. This does not preclude their usefulness. > > Each subdirectory contains a README file with information about the > module. > > </QUOTE> > > Something similar. This way it would be clearly stated that something is > useful and/or experimental and/or just new (Message: "Give it a try"). > > Maybe this would be a place for a chroot-installation-script, like my first > try here: > http://www.kinetiqa.de/aolserver/ > (But rewritten, it's a little bit old and worries about too many packages) > > Bernd.
