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
