From: Zoran V. <zv...@ar...> - 2005-12-31 07:08:45
|
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 |