Re: [naviserver-devel] cleanup before first import (questions)

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

Are these changes/deletions best done before initial import?  If
anything needs to be moved, we should probably do that early on to
preserve as much history as possible.


On Sat, 12 Feb 2005 17:53:30 +0100, Zoran Vasiljevic <zv...@ar...> wrote:
> 
> This is the current layout:
> 
> aclocal.m4  configure.in  include      install-sh     nscgi  nsdb   nspd    nsssl     sample-config.tcl  tests
> ChangeLog   CVS           index.html   license.terms  nscp   nsext  nsperm  nsthread  tcl                win32
> configure   doc           ini2tcl.tcl  Makefile       nsd    nslog  nssock  README    tcl2ini.tcl
> 
> a)
> I would scrap entirely:
>    ini2tcl.tcl
>    tcl2ini.tcl
>    index.html


Yeah, I think these have past their sell-by date.


> b)
> What about nsssl? I never used it. Is this something which is
> internationaly viable or is it US-only? Do people normally use
> the nsopenssl instead of this beast? What do you think?
> I see some ugly export notices there which are pretty old and
> obsolete.


I've never used this.  Some modules are obviously core to a webserver
and should be shipped by default: nslog, nscgi etc.  I'm not sure
whether it's best to remove this or to swap it with nsopenssl.  I
guess we can alway add nsopenssl to core later when it stabilises.


> c)
> I will leave the license info in the files as-is.
> Also, license.terms will stay the same (MPL).


Yup.


> d)
> Tests are pretty neglected, Tests require you to poke the
> server from the browser which is partly ok, but I'd rather
> do "make test" instead.
> I could imagine writing test suite with the Tcl test
> environment which can then be called out of the makefile
> after the compilation. It might be that something should
> be extra written/compiled in order to test code requiring
> browser access or such. Haven't thought that much about
> it yet. Only noting that the current test suite is ridiculous.
> I could imagine dropping this part (except the top-level dir)
> entirely and writing new test suite from scratch.


I don't understand why the Tcl test stuff isn't used.  It does seem to
insist on writing to stdout which sucks if you're testing from a web
page, but I'm sure that's not insurmountable and as you say, ideally
you want to 'make test' anyway.

Dump this stuff..


> e) Docs are useless. I will however keep the files and
> will replace the content over the time as I convert stuff
> found on aolserver site and on wiki into a manageable
> sources in doctools.


Groovy.
 

> So far for now. More might come... If you have any other
> idea or suggestion, please step out before I commit all.



How about a top level cvs structure of:

/server
/modules
/website


I'm interested in moving more towards a standard autotools setup to
make RPM/Deb building easier.  There's all kinds of things that
*could* be done, like moving all the sources into a top level ./src
directory, using libtool to explicitly build a libnsd, and so on, but
that's probably too much to tackle right now.

What you've mentioned above looks like a good start.