On Thursday 11 April 2002 5:16 pm, Casey Duncan wrote: >The most troublesome case is where foo accepts any number of arguments >(such as a DTML method or ZPT or any other method with **kw), and you >cannot know whether it changes objects or simply returns some string or >something.
Yes, that is a limitation of my proposal. It doesnt cover non-idempotent DTML and ZPT. (DTML and ZPT is idempotent by definition when used for presentation logic.) I dont think that limitation is fatal. > I don't think it is helpful to assume that "because a method >takes arguments, it is dangerous". I can write destructive methods that >take no arguments too. Sure you could. Lets assume you have, and have declared it non-idempotent as described in my proposal. Firstly, you would not be calling it from DTML or ZPT if you were using those only for presentation logic. presentation logic by definition cant be destructive. Anyway, even if you were writing a destructive DTML method, I bet you would write it as one of: <dtml-call my_destructive_method> <dtml-call "my_destructive_method()"> <dtml-var "my_destructive_method()"> <dtml-in "my_destructive_method()"> <dtml-with "my_destructive_method()"> but not: <dtml-var my_destructive_method> <dtml-in my_destructive_method> <dtml-with my_destructive_method> Those last three forms are today legal. My proposal would make them an error, but only because your new destrucive method has been declared non-idempotent. I think thats an improvement, but only a slight one. It is much less important than Oliver's original proposal which was to control methods called by ZPublisher, not by DTML. I would be happy to go with a reduced proposal that leaves DTML unchanged, and made it an error to issue a GET request for http://host/path/my_destructive_method (but only because my_destrucive_method has been declared non-idempotent) >Also, are we talking about only fixing the "action on GET" for the ZMI >or for all Zope apps? Much like when new style security declaration were introduced. Initially only ZMI had them, but new products could use them too. >If I were to implement this, a very simple approach seems attractive: >Lock the ZODB on GET requests so that no transactions can be committed. >However, I'm not sure I want to go there. Hmmmm. I wonder whether read-only transactions could be the basis for a ZODB optimisation....... _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )