Hi!
I believe you guys are more familiar with this stuff
as I am. Can you please comment?
Gustaf Neumann (XOTcl) is trying to get OACS to work
with our code and has some remarks. I'm forwarding the
relevant portion of an email sent to me today.
i made some changes to oacs such it works with naviserver. The biggest
problem was the changed argument passing conventions for filters. i am
not sure, that the agument passing conventions of naviserver are
the best
possible choice, since
ns_register_filter trace GET * myfilter
calls now "myfilter {} WHY"
instead of "myfilter WHY" as it was before. It should not be
necessary to pass a nonexisting argument around. I would finde
it more logically to have this as
"myfilter WHY"
or, when arguments are passed as
"myfilter WHY arg1 arg2 ...."
Since on has to alter the filter procs anyhow when moving from
aolserver,
this would not have beed a bad choice. With xotcl, i use e.g.
an object handling the filter requests, such as
Object create filter
filter proc preauth ....
filter proc postauth ...
filter proc trace ....
this worked nicely with the aolserver argument passing. now i have
to use
the strange looking method, that removes the empty first arg...
filter proc {} args {my eval $args}
Did you have some discussions about this? Is it to late to change
this?
In order to use oacs with naviserver, i had to introduce the following
not very beautifiul mapping rules to keep the changes minimal and
keep the server working for aolserver and naviserver.
all the best
-gustaf
if {[ns_info name] eq "NaviServer"} {
foreach filter {rp_filter rp_resources_filter
request_denied_filter} {
rename $filter ${filter}_aolserver
proc $filter {_ why} [list ${filter}_aolserver \$why]
}
rename rp_invoke_filter rp_invoke_filter_conn
proc rp_invoke_filter { filter_info why }
{ rp_invoke_filter_conn {} $filter_info $why }
rename rp_invoke_proc rp_invoke_proc_conn
proc rp_invoke_proc { argv } { rp_invoke_proc_conn
{} $argv }
rename rp_handler rp_handler_aolserver
proc rp_handler {_} {rp_handler_aolserver}
}
