On second thought, the startup error might be due to the (I'm totally guessing) fact that you are not using virtual servers? My config might assume that you are, and since I always use them, I never saw the error...until I tried it on an AOLserver installed without virtual servers...I'll have to check on that, but it might explain the problem.
Another note for older AOLservers: tDOM is loaded using ns_ictl in tWSDL. This will need to be changed to the method recommended by tDOM. Also, you might already have tDOM loaded for AOLserver. In that case you should not load the tWSDL tdom package. You can do this by editing the config file:
twsdl/packages/tws/tcl/tws-local-conf.tcl
Remove 'tdom' from the ::tws::packages list.
Another hint: the procedures and data structures for tWSDL and TWiST are generated on startup or after visiting a service page. To inspect the code, you should use the inspect package. Link in the www directory so you can browse the exact procs and vars, but also note that this is per thread configuration. For TWiST, visit the service then immediately visit the inspect browser. Otherwise AOLserver will eventually exit the thread and the data will not there (for TWiST).
BTW, most of the tWSDL and TWiST API works in a command line mode using nstclsh (even tclsh!) and sourcing the twsdl/init.tcl file. If you then run the <ws>* api, you will see what variables are not set due to not being in a conn. You can set these one by one and re-run the failed API (usually <ws>namespace) and eventually get the service configured. This highlights the fact that AOLserver is a thin, but important, layer over tWSDL and TWiST. If you replace this thin layer, you can run either of these inside any other server.
One idea I am considering is to do something like this:
proc ws { args } { return "<ws>"}
[ws]namespace ...
[ws]proc ...
[ws]return ...
Then the developer can replace the ws proc above to return different things, such as ::myCustomMods::ws_, or whatever text you want. The above code runs the standard API.
The above decoration is somewhat like what is used for C#, and with args it might offer some additional setup. For instance, the namespace of the commands might hold additional hints as to what defaults to apply to the service (like the targetNamespace, etc.)
This is also an interesting way to do a 'soft import' of a command, since in Tcl command import is almost useless except as a convenience to specify a command name (variable remain in the original namespace).
