On 8/6/07, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote: > Hi! > > After spenging a weekend over this, I know less than > before... > > The question is how we are going to improve the Tcl > initialization so people could benefit from that better > than now? > > As of today, what we have is: > > a. > introspective script based on the "old" way as 4.0 AS > did it (init the interp by loading all Tcl files then > run a script to pull-out namespaces, variables etc and > create a script that get saved with [ns_ictl save] > and run in each new interp by [ns_ictl update]) > > b. > the ttrace way of setting Tcl traces on selected commands > and have the "things" setup by those commands record in > shared nsv arrays. Then use Tcl [unknown] to pull out the > "things" on as-needed basis from shared arrays > > Well, none of those is really good. The a. is limited in > what it "introspects". The b. is pretty complex and in some > situations it does not work as expected (although there is > no design problem there, more probably just a bug or lack a > feature). > > Now, we do have [ns_ictl trace] where one can register things > to execute at interp creation, allocation etc. > So, I tried to do a simple thing: for each script executed > during the startup of the server I create > [ ns_ictl trace [list source $file]] > create-trace. > > This "mostly" works, but has two negative effects: > 1. all scripts needs to be re-adjusted as they are going to > be sourced more than once (for each new interp) > 2. in case 1000's of files are needed for the startup this may > pose significant delay in interp creation > > I think that old AS approach is the worst as it is really limited. > The Tcl-trace based approach is better but is known to have some > problems (I do not know which ones), yet, it is pretty powerful > and has some other nice side-effects (less memory footprint). > Lastly, the [ns_ictl trace] is simplest to understand and deploy > (this is also very important) but requires rewriting of existing > scripts and most probably needs somekind of caching to speedup > the load process when 1000's of startup files are involved. > > For me, the Tcl-trace or ns_ictl trace are the way to go. > Looking at those two, the latter is more appealing since of the > simplicity, but it may hit us hard speedwise. OTOH, the former > is faster and uses far less resources but is pretty complex in > implementation (this might be done simpler, yes, yet it is always > going to be more complex than ns_ictl trace). > > Now, what you all think? Should we do something there or should > we just stay with the old AS introspective script? >
What about making naviserver modules Tcl packages? That is, instead of saying: rewrite your scripts to survive being loaded multiple times via ns_ictl callbacks; we say: write Tcl packages. I think we want Tcl packages for a variety of reasons, but interestingly they also have a lazy loading mechanism via pkgIndex.tcl scripts. What do you think? I think we need to maintain backwards compatibility with the existing scheme (however it's actually implemented) regardless of what else we do, right? ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
