It's now been 72 hours since we posted the vote regarding the default setting. If we are counting PMC votes, then the vote was inconclusive. So AFAIAC, whoever does the work can make the decision as to the default.
:) Just be sure to make the commit before I do! :) -Ted. On 8/28/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote:
> Yes, and making "dynamic method invocation" > switchable doesn't affect > anyone's ability to do any of this. Agreed. > Could you please roll back r436991 and r436971 since > without a switch, > we cannot explore alternatives that don't require > special-case code, > nor can we suppress dynamic method invocation for > applications that do > not wish to use it. I'm happy to reintroduce a switch, but... - It won't be called "compatibility switch", which implies something else that isn't the root cause for concern here. - It will be classified as a "security switch". - It should be _off_ by default (meaning that it is the same as WW), considering how widely spread the usage is and how there is still serious discussion about even turning it off by default. I think that is the only fair outcome. Like I said in my previous posts, I strongly object to turning it off by default, as I believe there is a far greater number of users who rely on it than who avoid it, as evidenced by these URLs, Hani's recent message, Nick Hill's comments, and Ian Roughley's comments, as well as the open issue with the solution for the cancel button depending on dynamic method invocation via the "method:" parameter name prefix. Is that fair?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
