On 3/8/07, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
> Very nice, i wonder how it will work for legacy code
>
We should figure out exactly what we need to support. Not just to be
backward compatible, but to make sure this works for everyone.
Shout out if you have anything particular in mind!
As far as binary naviserver modules go, the current entry point is:
int
Ns_ModuleInit(CONST char *server, CONST char *module)
{
...
Tcl binary extensions however, look like so:
int
Foo_Init(Tcl_Interp *interp)
{
...
Initialisation wil be a two part process. Foo_Init will be called once
for each interp. The first time it should initialise mutexes etc. It
should also register some kind of Tcl configuration command, e.g.
foo_ctl.
Then in the module pkgIndex.tcl, which will be loaded once for each
interp, a config callback should be registered with NaviServer, e.g.
_foo_config. _foo_config will be called once for each instance of the
module for each virtual server during the pre-startup config phase.
I guess it doesn't matter that it's registered for each new thread --
it's just an entry in a hash table...
_foo_config will examine the config file and call foo_ctrl as needed,
which may just resolve to a call to the old Ns_ModuleInit() routine
under the covers.
So there are a couple of levels of backwards compatibility. It could
be that a module provides both Ns_ModuleInit() and Foo_Init()
routines, so that it can be loaded by old and new servers.
We could also say that, if the string that appears in the modules
section of the config file resolves to a file on disk then we try to
load it the old way, otherwise we treat it as the name of a package
and try to package require it.
We could also provide the old code that does the crazy path walking to
load .tcl files, and possibly even enable it if the config file still
defines a 'sharedlibrary' or 'privatelibrary'. But my impression is
that people aren't using this. Or at least, they're dropping a single
file into the private library and using that to bootstrap their own
startup process.
In the glorious future, you would add /srv/example.com to the Tcl
auto_path variable (for example, by setting TCLLIBPATH), and drop a
pkgIndex.tcl file into /srv/example.com/mytcl. From there, you can
kickstart your old .tcl sourcing procedure, or you can just add more
modules to that directory.
ns_section "ns/server/serverx/modules"
ns_param sock1 nssock
ns_param sock2 nssock
ns_param mytcl mytcl
ns_param myothertcl myothertcl
/usr/lib/naviserver/nssock/nssock.so
/usr/lib/naviserver/nssock/pkgIndex.tcl
...
/srv/example.com/mytcl
/srv/example.com/mytcl/pkgIndex.tcl
/srv/example.com/mytcl/mytcl.tcl
...
I think the procedure for creating new threads in the right state
would be to replay the series of package require commands, as needed
by the entries in the modules section. Each module that that brings in
can have it's own package require dependencies (something we don't
have right now).
If anything fancier than that is needed then a module can register
ns_ictl traces in it's config callback.
I'll find out if it's a completely stupid idea when I try implementing it...
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
