Am 31.12.2005 um 01:15 schrieb Gustaf Neumann:
Class Filter
Filter instproc preauth args { .... }
Filter instproc postauth args { .... }
Damn, you are right. In which case we'd do:
ns_register_filter <reason> GET /junk myfilter myarg1 myarg2 ...
and it would call the filter as:
myfilter <reason> myarg2 myarg3
Understand. This would allow you to:
Class TheFilter
TheFilter proc preauth {arg1 arg2} {...}
TheFilter proc postauth {arg1 arg2 arg3} {...}
ns_register_filter preauth GET /junk TheFilter arg1 arg2
ns_register_filter postauth GET /junk TheFilter arg1 arg2 arg3
and we'd call
TheFilter preauth arg1 arg2
TheFilter postauth arg1 arg2 arg3
The proc way would be:
proc TheFilter {reason args} {...}
and it would naturally fit in, as with OO syntax.
Well, this certainly makes sense to me. This is clean and elegant.
Hm... this will however be an incompatible change to the way AOL
server is handling the task, but will be way more sexy.
This is what I mean (others can comment): I'd go after this change.
For the people not using any optional arguments, there would be no
compatibility issues. For those using the arguments, they'd have to
rewrite the code. But it is for the better, not worse.
Stephen, Vlad, what do you think? I have no problem with that
as we are not using any of the optional args in our code.
We might examine to modify ns_register_proc the same way.
Cheers,
Zoran