Forum OpenACS Q&A: Re: site-map problems with aolserver 4

Collapse
13: Re: site-map problems with aolserver 4 (response to 1)
Posted by Andrew Piskorski on 04/25/03 06:30 AM
ns_eval, funky, yet another little bit of AOLserver API I've never personally used.

Vinod, good catch! If that's really the only use of ns_eval in OpenACS, and replacing it with nsv fixes the problem, yes definitely you should make the change! (And grep for any other use of tcl_site_nodes, etc.) Nsv should be both clearer and faster, anyway.

Also, sounds like ns_eval may be buggy in AOLserver 4.0, so please do submit a bug report on SourceForge.

Ah, in AOLserver 3, ns_eval was a C command, but in 4.0 it's a Tcl proc, in "aolserver/nsd/init.tcl". It's quite short. More importantly, the comments in the code make it clear that the above tcl_site_nodes usage is a misuse and abuse of ns_eval, not what ns_eval is intended for: 

# ns_eval -- 
# 
#   Evaluate a script which should contain 
#   new procs commands and then save the 
#   state of the procs for other interps 
#   to sync with on their next _ns_atalloc.
Collapse
14: Re: site-map problems with aolserver 4 (response to 13)
Posted by Vinod Kurup on 04/29/03 08:42 PM
tcl_site_nodes is used in only 1 place. It's supposed to be a cache of site node information, but it's implemented as a global var (which are global only to 1 interpreter), so it really doesn't do what it's supposed to do:

Slightly simplified code from rp_filter (in request-processor-procs.tcl) 


    global tcl_site_nodes
    if [catch { array set node $tcl_site_nodes([ad_conn url]) }] {
        array set node [site_node [ad_conn url]]
        set tcl_site_nodes([ad_conn url]) [array get node]
    }
The answer would be to make it an NSV, but I noticed that there's already an NSV that maintains this info properly (inside the site_node call above). So, I can just get rid of tcl_site_nodes var, right? A patch is forthcoming...