Extracting the entire contents of the ns_set out of the nsv to just get one key is terribly inefficient. In addition, ns_set would need to get redefined to do the on-demand 'extraction' for persistent ns-sets and to keep track which ones have already been extracted, which introduces some Tcl overhead to a C command that is used very heavily.
I'd bet if you just put AOLserver's version of tclset.c (or whatever the right file is that implements ns_sets) into Naviserver, it would work just fine. And I agree on backward-compatibility, I also think that it's extremely important. I also think that clear documentation of changes in Naviserver from AOLserver are severely lacking. It's not clear to me what is the state of pools/limits and all those things introduced in AOLserver 4.5 in Naviserver. -----Original Message----- From: Jeff Rogers [mailto:dv...@diphi.com] Sent: Monday, October 08, 2012 10:55 AM To: Alex Hisen Cc: John Buckman from BookMooch; aolserver-talk@lists.sourceforge.net Subject: Re: [AOLSERVER] naviserver to replace aolserver? I think the decision to make incompatible api changes was a misstep in naviserver. I understand the reasons - the arguments were useless, there are better facilities to replace it, it cleans up the code a lot - but I think compatibility is really important. The tcl core team places an extraordinary value on compatibility, some might argue to the detriment of forward progress, but it's not an either-or option. In the case of a re-combined aolserver/naviserver, I am arguing strongly in favor of compatibility: someone should be able to drop a new naviserver in place of a not-to-old aolserver, make a few changes to their config file, and run their existing codebase unchanged. My first thought is to have a "flavor" config setting that would change the callback arguments for registered filters/procs, and would load a tcl wrapper to use the alternate arguments for ns_return and the like. Alex Hisen wrote: > 2)On ns_share, we have a variety of code that goes: > proc myproc {} { > ns_share GLOBAL > ... $GLOBAL(mykey) ... > This is a much bigger problem - I can't just replace ns_share with nsv > or ns_share. All uses of the variable would have to be manually found > and rewritten to call nsv or ns_share OR, like I said, we'd have to > rewrite ns_share in Tcl with variable traces. Either one, not a trivial > effort. Probably easier to bring back the C code that implemented ns_share. I don't think it would be that awful to write a tcl implementation of ns_share that uses underlying nsvs for storage. AFAICT the C code uses tcl traces anyway, so it wouldn't work much differently. > 3)Persistent ns_sets really have no equivalent. Neither ns_share, nor > nsvs maintain the unique properties of ns_sets (i.e. order and multiple > same-named keys, case-insensitive accessors, etc), plus again the way > you to interact with the data is vastly different and also, it's > extremely easy to get data into persistent ns_sets from places that > normally deal with ns_sets such as database rows, config data, etc. Provided nothing is creating or interacting with them directly from C code, I think a pure tcl implementation of persistent ns_sets is possible without too much pain, as they can be represented as simple tcl lists and re-created from such a list. To get the set on first use (not sure what the best way to determine this is): ns_set create {} {*}[nsv_get persistent_sets setid] and on cleanup, do the inverse for all persistent sets in use: nsv_set persistent_sets setid [ns_set array $setid] If this ends up being not practical (I could well have overlooked something in my simplistic assumption above) then an alternative is to package up the aolserver ns_set implementation as a separate C module that replaces the built-in ns_set with its own version. -J ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ aolserver-talk mailing list aolserver-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aolserver-talk
