Re: [naviserver-devel] Roadmap

[Stephen D. <sd...@gm...>]

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 <eid...@we...> 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.