Put the file
http://alice.wu-wien.ac.at:8000/xowiki/tkcon e.g. in packages/xotcl-core/tcl/tkcon-procs.tcl and start the first console by typing in e.g.
tkcon start via ds/shell. The best would be to create an own package (tkcon), define package parameters for the ports and hosts allowed to connect, and make a manage-page in (e.g. in tkcon/www/index.tcl), which shows, which consoles are currently used (from which host) and which are free, and allows a user to grab one....
"many procs don't work as expected without connection": yes, this is a classical problem of openacs + aolserver, since many scripts expect to be able to obtain connection specific information (user_id, url, query-parms, ...) from a connection thread. If these commands are issued from a background thread, many subcommands of ns_conn terminate with a tcl-error, which causes the current eval to terminate. xotcl-core + xowiki try to be more robust against these problems than plain openacs. However, it becomes also for xowiki a problem, when common openacs code is used, e.g. the master templates.
I did today some more work in this regard; please update xotcl-core and xowiki from cvs head to get the code, which is more robust in this respect. Get as well the updated version of tkcon-procs.tcl from http://alice.wu-wien.ac.at:8000/xowiki/tkcon). With the new version one can run e.g.
::xowiki::Package initialize -url /xowiki -actual_query "" -user_id 0
$package_id invoke -method view
from tkcon. The basic idea of the Package.initialize is to be able to pass connection specific information to the connection context.
It is true, by running via the approach via ds/shell + vwait, has one problem less, since in ds/shell there is a connection, and aolserver does not barf on connection related commands. However, one gets wrong information from ns_conn (e.g. the url is ds/shell), so this is not good either.
Also the new version with the separate thread has limitations, when e.g. form-variables are used. These could be set via the associative array form_parameter in ::xo::cc, but i have not tested that...
