[Zope-Checkins] SVN: zdaemon/trunk/src/zdaemon/ Provide doc strings for these two base classes.
Log message for revision 99071:
Provide doc strings for these two base classes.
Changed:
U zdaemon/trunk/src/zdaemon/tests/testzdoptions.py
U zdaemon/trunk/src/zdaemon/zdoptions.py
-=-
Modified: zdaemon/trunk/src/zdaemon/tests/testzdoptions.py
===
--- zdaemon/trunk/src/zdaemon/tests/testzdoptions.py2009-04-10 09:35:06 UTC
(rev 99070)
+++ zdaemon/trunk/src/zdaemon/tests/testzdoptions.py2009-04-10 09:50:13 UTC
(rev 99071)
@@ -104,9 +104,17 @@
self.assertEqual(helptext, expected)
def test_default_help(self):
+# test what happens if OptionsClass is used directly.
+# Not sure this ever happens :-S
+self.help_test_helper(self.OptionsClass,{},self.OptionsClass.__doc__
or 'No help available.')
+
+def test_default_subclass_help(self):
# test what happens when the subclass doesn't do anything
# with __doc__
-self.help_test_helper(self.OptionsClass,{},'No help available.')
+class SubClass(self.OptionsClass):
+pass
+# __doc__ isn't inherited :-(
+self.help_test_helper(SubClass,{},'No help available.')
def test_default_help_with_doc_kw(self):
# test what happens when the subclass doesn't do anything
Modified: zdaemon/trunk/src/zdaemon/zdoptions.py
===
--- zdaemon/trunk/src/zdaemon/zdoptions.py 2009-04-10 09:35:06 UTC (rev
99070)
+++ zdaemon/trunk/src/zdaemon/zdoptions.py 2009-04-10 09:50:13 UTC (rev
99071)
@@ -21,7 +21,21 @@
import ZConfig
class ZDOptions:
+a zdaemon script.
+Usage: python script.py [-C URL] [zdrun-options] [action [arguments]]
+
+Options:
+-C/--configure URL -- configuration file or URL
+-h/--help -- print usage message and exit
+
+Actions are commands like start, stop and status. If -i is
+specified or no action is specified on the command line, a shell
+interpreting actions typed interactively is started (unless the
+configuration option default_to_interactive is set to false). Use the
+action help to find out about available actions.
+
+
doc = None
progname = None
configfile = None
@@ -341,7 +355,31 @@
class RunnerOptions(ZDOptions):
+a zdaemon runner.
+Usage: python script.py [-C URL][-h] [zdrun-options] [action [arguments]]
+
+Options:
+-C/--configure URL -- configuration file or URL
+-h/--help -- print usage message and exit
+-b/--backoff-limit SECONDS -- set backoff limit to SECONDS (default 10)
+-d/--daemon -- run as a proper daemon; fork a subprocess, close files etc.
+-f/--forever -- run forever (by default, exit when backoff limit is
exceeded)
+-h/--help -- print this usage message and exit
+-s/--socket-name SOCKET -- Unix socket name for client (default zdsock)
+-u/--user USER -- run as this user (or numeric uid)
+-m/--umask UMASK -- use this umask for daemon subprocess (default is 022)
+-x/--exit-codes LIST -- list of fatal exit codes (default 0,2)
+-z/--directory DIRECTORY -- directory to chdir to when using -d (default
off)
+action [arguments] -- see below
+
+Actions are commands like start, stop and status. If -i is
+specified or no action is specified on the command line, a shell
+interpreting actions typed interactively is started (unless the
+configuration option default_to_interactive is set to false). Use the
+action help to find out about available actions.
+
+
uid = gid = None
def __init__(self):
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/src/Zope2/Startup/ make runzope -h work onc the new zdaemon release is used.
Log message for revision 99072: make runzope -h work onc the new zdaemon release is used. Changed: U Zope/trunk/src/Zope2/Startup/options.py U Zope/trunk/src/Zope2/Startup/run.py -=- Modified: Zope/trunk/src/Zope2/Startup/options.py === --- Zope/trunk/src/Zope2/Startup/options.py 2009-04-10 09:50:13 UTC (rev 99071) +++ Zope/trunk/src/Zope2/Startup/options.py 2009-04-10 10:02:10 UTC (rev 99072) @@ -20,7 +20,30 @@ class ZopeOptions(zdaemon.zdoptions.ZDOptions): +The Zope zdaemon runner script. +Usage: python Zope2/run.py [-C URL][-h] [zdrun-options] [action [arguments]] + +Options: +-C/--configure URL -- configuration file or URL +-h/--help -- print usage message and exit +-b/--backoff-limit SECONDS -- set backoff limit to SECONDS (default 10) +-d/--daemon -- run as a proper daemon; fork a subprocess, close files etc. +-f/--forever -- run forever (by default, exit when backoff limit is exceeded) +-h/--help -- print this usage message and exit +-s/--socket-name SOCKET -- Unix socket name for client (default zdsock) +-u/--user USER -- run as this user (or numeric uid) +-m/--umask UMASK -- use this umask for daemon subprocess (default is 022) +-x/--exit-codes LIST -- list of fatal exit codes (default 0,2) +-z/--directory DIRECTORY -- directory to chdir to when using -d (default off) +action [arguments] -- see below + +Actions are commands like start, stop and status. If -i is +specified or no action is specified on the command line, a shell +interpreting actions typed interactively is started (unless the +configuration option default_to_interactive is set to false). Use the +action help to find out about available actions. + + schemadir = os.path.dirname(os.path.abspath(__file__)) schemafile = zopeschema.xml - Modified: Zope/trunk/src/Zope2/Startup/run.py === --- Zope/trunk/src/Zope2/Startup/run.py 2009-04-10 09:50:13 UTC (rev 99071) +++ Zope/trunk/src/Zope2/Startup/run.py 2009-04-10 10:02:10 UTC (rev 99072) @@ -43,9 +43,9 @@ opts = options.ZopeOptions() if configfile: opts.configfile = configfile -opts.realize(doc=Sorry, no option docs yet., raise_getopt_errs=0) +opts.realize(raise_getopt_errs=0) else: -opts.realize(doc=Sorry, no option docs yet.) +opts.realize() handlers.handleConfig(opts.configroot, opts.confighandlers) import App.config ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
Re: [Zope-dev] naming Zope
On Fri, Apr 10, 2009 at 01:36, Shane Hathaway sh...@hathawaymix.org wrote: Grr. Way to end a bikeshed discussion. Now what are we going to drone on about? Wait, wait, it should be called Zope Platform! -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] naming Zope
Martijn Faassen wrote at 2009-4-8 15:31 +0200: ... In order to make Zope 2 and Zope 3 fit the pattern, it'd be nice if they had names that fit the Zope is a project, not software pattern. We could rename Zope 2 to Zope Classic, as was suggested. I think we should also rename Zope 3 to something else (that doesn't imply it's the modern future, as there are other alternatives at least as modern around that are more recently developed - we want to get out of that bind). Zope 2 and Zope 3 is not ideal but by now familiar. I do not think a renaming effort would be worth at the current time. Avoid misleading names in the future think renaming Zope 2 to Zope Classic will be easy. If the Zope 2 developers are okay with this, let's go right ahead. I will continue to speak of Zope 2 (not Zope Classic). -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] naming Zope
Wichert Akkerman wrote at 2009-4-9 10:40 +0200: Previously Shane Hathaway wrote: discussion type=bikeshed Tres Seaver wrote: WRT the Framework name: framework is a misleading name for the collection of packages salvaged from the new Coke effort: it is actually a *bunch* of frameworks, in the classic software engineering sense, along with some pure libraries. Zope Toolkit, perhaps? (No relationship to Portal Toolkit. :-] ) +1 If you want to attract non-Zope people, then Zope Toolkit may not be optimal. The term suggests: the toolkit for Zope users. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] naming Zope
On Fri, Apr 10, 2009 at 09:23, Dieter Maurer die...@handshake.de wrote: I will continue to speak of Zope 2 (not Zope Classic). Right. The classic/legacy renaming is only necessary if we were to move to Zope 4, which we aren't, or continue to talk about Zope 3, which we aren't. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form and KGS 3.4 - can't build 1.9.x branch
Stephan Richter wrote: On Thursday 09 April 2009, Martin Aspeli wrote: Clearly, I'm getting too new a version of RestrictedPython, but this is running against the 3.4 KGS, so I don't see how that could really happen. This is not a problem. Ignore those errors as they happen in the Python 2.6 support code.Everything installed fine. Got RestrictedPython 3.5.0. Mmm... it doesn't let me run the tests though: $ ./bin/test Test-module import failures: Module: z3c.form.browser.tests Traceback (most recent call last): File /users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/browser/tests.py, line 16, in ? from z3c.form import testing File /users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/testing.py, line 28, in ? from zope.app.testing import setup File /Users/optilude/.buildout/eggs/zope.app.testing-3.6.0-py2.4.egg/zope/app/testing/setup.py, line 47, in ? from zope.container.traversal import ContainerTraversable File /Users/optilude/.buildout/eggs/zope.container-3.8.1-py2.4-macosx-10.3-i386.egg/zope/container/traversal.py, line 26, in ? from zope.publisher.interfaces import IDefaultViewName, NotFound ImportError: cannot import name IDefaultViewName Module: z3c.form.tests.test_doc Traceback (most recent call last): File /users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/tests/test_doc.py, line 23, in ? from zope.app.testing import placelesssetup File /Users/optilude/.buildout/eggs/zope.app.testing-3.6.0-py2.4.egg/zope/app/testing/placelesssetup.py, line 26, in ? from zope.container.testing \ File /Users/optilude/.buildout/eggs/zope.container-3.8.1-py2.4-macosx-10.3-i386.egg/zope/container/testing.py, line 29, in ? from zope.container.traversal import ContainerTraversable File /Users/optilude/.buildout/eggs/zope.container-3.8.1-py2.4-macosx-10.3-i386.egg/zope/container/traversal.py, line 26, in ? from zope.publisher.interfaces import IDefaultViewName, NotFound ImportError: cannot import name IDefaultViewName Test-modules with import problems: z3c.form.browser.tests z3c.form.tests.test_doc Total: 0 tests, 0 failures, 0 errors in 0.000 seconds. (optilude)(~/Development/Plone/Code/Products/z3c.form) $ My working set is pretty weird too. Lots of 3.5.x and 3.6.x and even a 3.8.x. $ cat bin/test #!/opt/local/Library/Frameworks/Python.framework/Versions/2.4/Resources/Python.app/Contents/MacOS/Python import sys sys.path[0:0] = [ '/users/optilude/Development/Plone/Code/Products/z3c.form/src', '/Users/optilude/.buildout/eggs/zope.testing-3.7.1-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.interface-3.5.0-py2.4-macosx-10.3-i386.egg', '/Users/optilude/.buildout/eggs/setuptools-0.6c9-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.app.i18n-3.4.4-py2.4.egg', '/Users/optilude/.buildout/eggs/z3c.template-1.1a1-py2.4.egg', '/Users/optilude/.buildout/eggs/z3c.coverage-0.1.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.app.container-3.7.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.security-3.6.0-py2.4-macosx-10.3-i386.egg', '/Users/optilude/.buildout/eggs/zope.schema-3.5.2-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.publisher-3.5.5-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.pagetemplate-3.4.1-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.location-3.5.3-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.lifecycleevent-3.5.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.i18nmessageid-3.4.3-py2.4-macosx-10.3-i386.egg', '/Users/optilude/.buildout/eggs/zope.i18n-3.6.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.event-3.4.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.configuration-3.4.1-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.component-3.5.1-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.app.testing-3.6.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.app.pagetemplate-3.5.0-py2.4.egg', '/Users/optilude/.buildout/eggs/ZODB3-3.9.0a12-py2.4-macosx-10.3-i386.egg', '/Users/optilude/.buildout/eggs/zope.app.publisher-3.6.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.app.component-3.6.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.tal-3.5.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.copypastemove-3.5.1-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.dublincore-3.4.2-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.traversing-3.5.2-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.size-3.4.0-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.exceptions-3.5.2-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.container-3.8.1-py2.4-macosx-10.3-i386.egg', '/Users/optilude/.buildout/eggs/zope.proxy-3.5.0-py2.4-macosx-10.3-i386.egg', '/Users/optilude/.buildout/eggs/zope.deferredimport-3.5.0-py2.4.egg', '/Users/optilude/.buildout/eggs/pytz-2009a-py2.4.egg', '/Users/optilude/.buildout/eggs/zope.deprecation-3.4.0-py2.4.egg',
[Zope-dev] Zope Tests: 8 OK
Summary of messages to the zope-tests list. Period Thu Apr 9 12:00:00 2009 UTC to Fri Apr 10 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Thu Apr 9 20:44:47 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011427.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Thu Apr 9 20:46:49 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011428.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Thu Apr 9 20:48:49 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011429.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Thu Apr 9 20:50:49 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011430.html Subject: OK : Zope-trunk Python-2.6.1 : Linux From: Zope Tests Date: Thu Apr 9 20:52:49 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011431.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Thu Apr 9 20:54:50 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011432.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Thu Apr 9 20:56:53 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011433.html Subject: OK : Zope-trunk-alltests Python-2.6.1 : Linux From: Zope Tests Date: Thu Apr 9 20:58:53 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011434.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Heads up: Zope Framework - Zope Toolkit
Hi there, The Zope Framework is now renamed to be the Zope Toolkit. Framework proved to be a controversial name that implies a range of things to people we do not want to imply - in particular that you have to buy into the whole in order to use some of its parts. Zope Toolkit is a more neutral name that still implies we manage this as a whole, but doesn't imply you have to buy into the whole in order to use some of the parts. The Zope Toolkit contains a lot of libraries and frameworks, and also an overarching approach to how such frameworks are generally constructed (the component architecture). We now therefore have a Zope Toolkit Steering Group. :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
Hi there, One fundamental question about this that I have is why we want to protect the user against such loopholes anyway? Isn't zope.security a protection system against *accidental* mistakes in building secure applications? I.e. I call a method and then I find out I have no such access. Do we really need to protect the developer against more arcane workarounds? If I *want* to work around the security system deliberately I can simply remove the security proxy and be done with it. It's not like the system is protecting against this anyway. Protecting against workarounds is useful if you allow through the web manipulation of code itself. But who is actually doing this? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
On Apr 10, 2009, at 9:25 AM, Martijn Faassen wrote: Hi there, One fundamental question about this that I have is why we want to protect the user against such loopholes anyway? Isn't zope.security a protection system against *accidental* mistakes in building secure applications? No I.e. I call a method and then I find out I have no such access. Do we really need to protect the developer against more arcane workarounds? If I *want* to work around the security system deliberately I can simply remove the security proxy and be done with it. It's not like the system is protecting against this anyway. Protecting against workarounds is useful if you allow through the web manipulation of code itself. But who is actually doing this? The purpose of the protection system is to protect an application against untrusted code provided by people other than the application develoer. If an application has no untrusted code, then the protection system isn't necessary. I'll guess that 99% of applications don't support untrusted code and don't need the Zope protection system(s). The applications people build with Grok probably fall in this category, or one would hope. :) There are some applications, such as Zope 2, Plone, and many of our (ZC's) applications that support untrusted code and, for these systems, the protection system is critical. It doesn't protect the application developer from herself, it protects her from the people writing the untrusted code. (Note that, in some ways, HTTP requests represent untrusted code. This case can often be handled by simple resource-protection schemes, although some applications can still benefit from the Zope 3 protection scheme, which can help mediate access to content when fine- grained control is needed.) Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form and KGS 3.4 - can't build 1.9.x branch
Adam GROSZER wrote: Hello, I would add TEMPORARYLY (for testing) the KGS to buildout.cfg: [buildout] extends = http://download.zope.org/zope3.4/3.4.0/versions.cfg versions = versions develop = . benchmark parts = test checker coverage-test coverage-report docs i18n benchmark python ... But do not commit that! I think people will use KGS in their buildout if they want and that will nail versions appropriately. Later we might backport the [3.5/trunk]-compatibility which I'd like to finish this weekend to 1.9. The tests now fail with: $ ./bin/test Running unit tests: Failure in test /users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/tests/../zcml.txt Failed doctest test for zcml.txt File /users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/tests/../zcml.txt, line 0 -- File /users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/tests/../zcml.txt, line 67, in zcml.txt Failed example: from z3c.template.interfaces import IPageTemplate Exception raised: Traceback (most recent call last): File /Users/optilude/.buildout/eggs/zope.testing-3.5.6-py2.4.egg/zope/testing/doctest.py, line 1356, in __run compileflags, 1) in test.globs File doctest zcml.txt[19], line 1, in ? from z3c.template.interfaces import IPageTemplate ImportError: No module named template.interfaces -- File /users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/tests/../zcml.txt, line 68, in zcml.txt Failed example: template = zope.component.queryMultiAdapter((None, request, None, None, myWidget), interface=IPageTemplate, name='input') Exception raised: Traceback (most recent call last): File /Users/optilude/.buildout/eggs/zope.testing-3.5.6-py2.4.egg/zope/testing/doctest.py, line 1356, in __run compileflags, 1) in test.globs File doctest zcml.txt[20], line 2, in ? myWidget), interface=IPageTemplate, name='input') NameError: name 'IPageTemplate' is not defined -- File /users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/tests/../zcml.txt, line 73, in zcml.txt Failed example: template Exception raised: Traceback (most recent call last): File /Users/optilude/.buildout/eggs/zope.testing-3.5.6-py2.4.egg/zope/testing/doctest.py, line 1356, in __run compileflags, 1) in test.globs File doctest zcml.txt[21], line 1, in ? template NameError: name 'template' is not defined -- File /users/optilude/Development/Plone/Code/Products/z3c.form/src/z3c/form/tests/../zcml.txt, line 78, in zcml.txt Failed example: print template(myWidget) Exception raised: Traceback (most recent call last): File /Users/optilude/.buildout/eggs/zope.testing-3.5.6-py2.4.egg/zope/testing/doctest.py, line 1356, in __run compileflags, 1) in test.globs File doctest zcml.txt[22], line 1, in ? print template(myWidget) NameError: name 'template' is not defined Ran 740 tests with 1 failures and 0 errors in 4.211 seconds. (optilude)(~/Development/Plone/Code/Products/z3c.form) I don't really feel confident to fix bugs in z3c.form until I can have a stable build environment, but I may check in some fixes anyway if I find time this weekend and aim to keep the number of failures constant. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
Jim Fulton wrote: On Apr 10, 2009, at 9:25 AM, Martijn Faassen wrote: [snip] Protecting against workarounds is useful if you allow through the web manipulation of code itself. But who is actually doing this? The purpose of the protection system is to protect an application against untrusted code provided by people other than the application develoer. If an application has no untrusted code, then the protection system isn't necessary. I'll guess that 99% of applications don't support untrusted code and don't need the Zope protection system(s). The applications people build with Grok probably fall in this category, or one would hope. :) There are some applications, such as Zope 2, Plone, and many of our (ZC's) applications that support untrusted code and, for these systems, the protection system is critical. It doesn't protect the application developer from herself, it protects her from the people writing the untrusted code. I know that Plone is moving away from untrusted code, and Zope 2 isn't using zope.security anyway. That leaves ZC's applications, which I imagine are based on zope.security? (Note that, in some ways, HTTP requests represent untrusted code. This case can often be handled by simple resource-protection schemes, although some applications can still benefit from the Zope 3 protection scheme, which can help mediate access to content when fine- grained control is needed.) I take it that zope.security is supporting three use cases: a) prevent an application developer for making mistakes concerning security, or alternatively, forcing developers to think about security in-depth. b) prevent someone from viewing something with a public view because they don't have access to content-level methods and attributes. (which I take is your HTTP request as untrusted code scenario). (alternate strategies are Grok's, which has view-level security but allows content-level declarations about what's accessible or not. But prominent Grok users are clamoring for something closer to the traditional approach with real content level protections) c) allow Python/template untrusted code As far as I now know, the only actual applications of zope.security to accomplish c) are ZC's. a) and b) would be served well enough if zope.security only cared about preventing accidental security violations. If this is correct, this is interesting; we are taking on a burden for a rather limited set of use cases. Unfortunately these are ZC's use cases. Would there be a way to isolate these use cases so that other users in the community did not have to worry about this anymore? I ask because the topic has come up a few times already (now, and with the Python-based i18n message ids a while back). It could be that c) grows more important again over time in case of a rebirth of the ZMI, but that doesn't look like it's about to happen any time soon. And if it does it might happen in a more limited way that doesn't require a sophisticated untrusted code infrastructure. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
On Apr 10, 2009, at 10:43 AM, Martijn Faassen wrote: ... I know that Plone is moving away from untrusted code, I predict they won't, but we'll see. and Zope 2 isn't using zope.security anyway. That's immaterial. I was talking about the use case. That leaves ZC's applications, which I imagine are based on zope.security? Yes, not that it is really relevant to the discussion. (Note that, in some ways, HTTP requests represent untrusted code. This case can often be handled by simple resource-protection schemes, although some applications can still benefit from the Zope 3 protection scheme, which can help mediate access to content when fine- grained control is needed.) I take it that zope.security is supporting three use cases: a) prevent an application developer for making mistakes concerning security, Yes or alternatively, forcing developers to think about security in-depth. That is obviously not a goal. No one is forcing anyone to do anything. You don't have to use zope.security. b) prevent someone from viewing something with a public view because they don't have access to content-level methods and attributes. (which I take is your HTTP request as untrusted code scenario). It is an example of that scenario, yes. (alternate strategies are Grok's, which has view-level security but allows content-level declarations about what's accessible or not. But prominent Grok users are clamoring for something closer to the traditional approach with real content level protections) Interesting. Note that Zope 3's protection system addresses this case while Zope 2's system doesn't. This is one of the reasons I'd like to see Zope 2 move to the Zope 3 protection system. c) allow Python/template untrusted code Yes. This is where proper handling of rocks is most important. As far as I now know, the only actual applications of zope.security to accomplish c) are ZC's. I'm sure there are others. Zope 2's protection scheme addresses this use case as well, although not as well. a) and b) would be served well enough if zope.security only cared about preventing accidental security violations. I'm not sure what you mean by accidental here, but I suspect I disagree. I would agree that handling of rocks is far less important in this context. If this is correct, this is interesting; we are taking on a burden for a rather limited set of use cases. What burden? The protection system benefits all the use cases. It's also a burden that is easily removed if you don't have these use cases. Unfortunately these are ZC's use cases. They are not just ZC's use cases. Would there be a way to isolate these use cases so that other users in the community did not have to worry about this anymore? I ask because the topic has come up a few times already (now, and with the Python-based i18n message ids a while back). Sure. If you (think you) don't need a protection system, or think you can design a lighter weight one that meets your needs, then don't use zope.security. By far, most of the pain of Zope 3 protection system, as well as it's power, comes from the use of security proxies. The handling of rocks is a minor issue. It's worth noting that applications that don't allow untrusted code (other than the request) but that still want to use the protection system to protect content can can be much more liberal about what is treated as a rock by declaring rock classes themselves. The mechanisms support this now, although there may not be an API. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form and KGS 3.4 - can't build 1.9.x branch
On Friday 10 April 2009, Martin Aspeli wrote: /Users/optilude/.buildout/eggs/zope.container-3.8.1-py2.4-macosx-10.3-i386 .egg/zope/container/traversal.py, line 26, in ? from zope.publisher.interfaces import IDefaultViewName, NotFound ImportError: cannot import name IDefaultViewName zope.container 3.8.1 seems pretty high. I have noticed that if you use the latest versions of everything, things break recently. Sigh. This is exactely why we have the KGS. (Not your fault though.) Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
Hey, Jim Fulton wrote: On Apr 10, 2009, at 10:43 AM, Martijn Faassen wrote: and Zope 2 isn't using zope.security anyway. That's immaterial. I was talking about the use case. It's hard to tell whether Zope 2 will ever adopt zope.security to fulfill this use case - I have the impression the big apps are trying to move away from Zope 2, and Plone at least seems to be moving away from untrusted code. I think that's interesting in figuring out where we can and cannot go with zope.security. [snip] I take it that zope.security is supporting three use cases: a) prevent an application developer for making mistakes concerning security, Yes or alternatively, forcing developers to think about security in-depth. That is obviously not a goal. No one is forcing anyone to do anything. You don't have to use zope.security. Some systems come with zope.security out of the box, such as traditional Zope 3, meaning normal development with it forces developers to think about this. I'm not saying this is a bad thing; it is a different perspective on preventing an application developer from making mistakes. b) prevent someone from viewing something with a public view because they don't have access to content-level methods and attributes. (which I take is your HTTP request as untrusted code scenario). It is an example of that scenario, yes. Do you have other examples? [snip] c) allow Python/template untrusted code Yes. This is where proper handling of rocks is most important. As far as I now know, the only actual applications of zope.security to accomplish c) are ZC's. I'm sure there are others. Yes, as Stephan said, Keas. Zope 2's protection scheme addresses this use case as well, although not as well. a) and b) would be served well enough if zope.security only cared about preventing accidental security violations. I'm not sure what you mean by accidental here, but I suspect I disagree. I would agree that handling of rocks is far less important in this context. Okay, let's just agree on the latter. :) [snip] Would there be a way to isolate these use cases so that other users in the community did not have to worry about this anymore? I ask because the topic has come up a few times already (now, and with the Python-based i18n message ids a while back). [snip] It's worth noting that applications that don't allow untrusted code (other than the request) but that still want to use the protection system to protect content can can be much more liberal about what is treated as a rock by declaring rock classes themselves. The mechanisms support this now, although there may not be an API. This is what I was aiming at. Would it be possible to have a zope.sandbox that builds on zope.security that does the whole untrusted execution thing, and then we have another profile of zope.security that just allows everything considered immutable as rocks? Can such things exist in parallel in the same code base? I'm not saying that if so, we're going to do the work immediately. I just want to explore what directions we could go in if someone does want to do the work. People trying to port zope.security dependent code to the google app engine seem to have yet another use case. This is fulfilled right now by a hacked up fork that at least makes import works, even though none of the actual functionality is there. We might want to put a knob in zope.security to support this hack out of the box too. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] naming Zope
Stephan Richter wrote: On Friday 10 April 2009, Dieter Maurer wrote: think renaming Zope 2 to Zope Classic will be easy. If the Zope 2 developers are okay with this, let's go right ahead. I will continue to speak of Zope 2 (not Zope Classic). +1. I think we gain nothing by renaming Zope 2 to anything else. I agree with all arguments made in favor of keeping the Zope 2 name. It's not necessary anymore to pile this on; before Dieter even spoke up today this branch of the discussion was dead anyway. :) I'd rather have your opinions about the future of Zope 3 elsewhere in this thread... Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
Zvezdan Petkovic wrote: On Apr 10, 2009, at 11:32 AM, Hanno Schlichting wrote: We do have the use-case of allowing trusted people to add templates or code TTW and many other things like data level and view based security. The RestrictedPython case however is something we will gladly give up. Trusted people!? Are you checking their ID at the door? All you have in terms of trust are their credentials. Sure, that's called authentication. Happens to be the same in any technical or physical world. You don't want to allow many, many things TTW, even if they logged in with the trusted credentials. We are in the business of content management. The most valuable information the system and the entire physical machine has is the content in the system. You don't run web applications on any kind of shared servers where the system has any more valuable data. A person who is allowed to steal or delete the entire content is what I call trusted. The potential additional damage of that person breaking out of the web application is a minor concern compared to this. Allowing any kind of TTW development is always going to be an explicit opt-in, but if you are willing to allow this, we won't try to stop you with limited access anymore. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] who wants to maintain Zope 3?
Hi there, Is anyone interested in maintaining Zope 3? With Zope 3 I mean: * the thing with the ZMI - do you care about the ZMI? * the thing that can be installed as a particular development platform - do you care about the installation story for Zope 3? (as opposed to Grok or your own application's?) * the thing that has some kind of documentation website - do you care about providing documentation for Zope 3 as opposed to documentation for Grok or individual libraries? People who are interested in these aspects please speak up, so we can figure out what this all means for the future of Zope 3. If nobody is interested, we should perhaps stop talking about it entirely. If people are just interested in the ZMI, perhaps we should form a ZMI project. What I'm *not* talking about is: * maintaining, documenting and installing Grok. * maintaining and documenting any particular Zope Toolkit library (outside of those bits that do ZMI-stuff, those aren't supposed to be in the toolkit) We know people are interested in doing all that. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
On Apr 10, 2009, at 12:26 PM, Martijn Faassen wrote: ... b) prevent someone from viewing something with a public view because they don't have access to content-level methods and attributes. (which I take is your HTTP request as untrusted code scenario). It is an example of that scenario, yes. Do you have other examples? The view doesn't have to be public. For example, the view might only be accessible to people with a particular role, and you might further limit what they can do based on the data they can access. ... It's worth noting that applications that don't allow untrusted code (other than the request) but that still want to use the protection system to protect content can can be much more liberal about what is treated as a rock by declaring rock classes themselves. The mechanisms support this now, although there may not be an API. This is what I was aiming at. Would it be possible to have a zope.sandbox that builds on zope.security that does the whole untrusted execution thing, and then we have another profile of zope.security that just allows everything considered immutable as rocks? Can such things exist in parallel in the same code base? I don't see the point of a separate package. This is a very small corner of zope.security. A simple API for extending the definition of rocks would be enough to deal with this particular issue. Note that considered immutable is rather vague. UUIDs aren't immutable if you're willing to be only slightly devious. But if you aren't worried about that in an application, then that isn't a problem. You might even choose to make truly mutable objects into rocks if you know your application is going to play nice. ... People trying to port zope.security dependent code to the google app engine seem to have yet another use case. This is fulfilled right now by a hacked up fork that at least makes import works, even though none of the actual functionality is there. We might want to put a knob in zope.security to support this hack out of the box too. Or tell them to use something else altogether. It all depends on their use cases. If they want a seatbelt rather than a space suit, I suppose a python-based proxy could be good enough, although it would likely be too slow for that environment. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
On Apr 10, 2009, at 12:31 PM, Hanno Schlichting wrote: We are in the business of content management. The most valuable information the system and the entire physical machine has is the content in the system. You don't run web applications on any kind of shared servers where the system has any more valuable data. A person who is allowed to steal or delete the entire content is what I call trusted. The potential additional damage of that person breaking out of the web application is a minor concern compared to this. Allowing any kind of TTW development is always going to be an explicit opt-in, but if you are willing to allow this, we won't try to stop you with limited access anymore. So, it's quite black and white. I would argue that there are several classes of users. At least these: 1. Trusted users inside your organization that makes the software.The role they get through their credentials has highest trust level and they could be allowed to do the most TTW. 2. Trusted users inside your customer organization. Those are usually the techies in the customer organization who configure your software to run the way they want. The role they get through their credentials has some trust level. They can change certain things TTW. 3. Untrusted users in your customer organization. These users get a role through their credentials that allows them to configure the software parts, but cannot do any TTW changes. 4. Untrusted customers of your customer organization. Plain web users. They just view the content. The granularity levels can be even finer between 1, 2, and 3 above. This allows for various shades of grey. However, since anybody's credentials can be stolen, I do not want to allow rock changes and arbitrary imports even to the users in class 1 above. Because: 1. they have the highest trust level in that web app, but 2. they are just an ordinary user on a machine running that web app, and 3. there are people who have higher credentials on that machine -- sysadmins. That's why leaving zope.security safer by default is the right thing. If you want to allow more, wrap around it someorg.lesssecurity or even someorg.nosecurity. Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
Hey, Jim Fulton wrote: [snip] I don't see the point of a separate package. This is a very small corner of zope.security. Sure, it could be solved within zope.security as well. A simple API for extending the definition of rocks would be enough to deal with this particular issue. Note that considered immutable is rather vague. UUIDs aren't immutable if you're willing to be only slightly devious. But if you aren't worried about that in an application, then that isn't a problem. You might even choose to make truly mutable objects into rocks if you know your application is going to play nice. Right, I meant considered immutable in the dynamically typed sense. I can make classes that I consider to be immutable after creation in Python, even though I don't actually enforce it by preventing people from setting attributes on them. People trying to port zope.security dependent code to the google app engine seem to have yet another use case. This is fulfilled right now by a hacked up fork that at least makes import works, even though none of the actual functionality is there. We might want to put a knob in zope.security to support this hack out of the box too. Or tell them to use something else altogether. It all depends on their use cases. If they want a seatbelt rather than a space suit, I suppose a python-based proxy could be good enough, although it would likely be too slow for that environment. The use case appears to be to use code that depends on zope.security on the google app engine. We have quite few libraries that do that out there. I think they just simply hack the proxy creation out completely, meaning that zope.security is basically a no-op. I asked what exactly is going on in another thread, so we just wait until we find out. :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
Martijn Faassen wrote: Stephan Richter wrote: On Friday 10 April 2009, Jim Fulton wrote: Unfortunately these are ZC's use cases. They are not just ZC's use cases. Keas is relying on that safety heavily too. Anyone who wants to build a secure DSL based on Python really wants zope.security. Okay, second case of such usage noticed. One thing that worries me is that PyPy folks keep saying it probably isn't really secure, though they refuse to specify why not when Chris Withers tried to find out last year at EuroPython. I suspect that's because Python allows anything by default; zope.security and RestrictedPython only provide a way to close known holes. The security model of Javascript running in a browser is very similar, though, and that seems to be good enough for most people. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
On Apr 10, 2009, at 3:20 PM, Shane Hathaway wrote: Martijn Faassen wrote: Stephan Richter wrote: On Friday 10 April 2009, Jim Fulton wrote: Unfortunately these are ZC's use cases. They are not just ZC's use cases. Keas is relying on that safety heavily too. Anyone who wants to build a secure DSL based on Python really wants zope.security. Okay, second case of such usage noticed. One thing that worries me is that PyPy folks keep saying it probably isn't really secure, though they refuse to specify why not when Chris Withers tried to find out last year at EuroPython. I suspect that's because Python allows anything by default; zope.security and RestrictedPython only provide a way to close known holes. Wrong in the case of zope.security. zope.security uses security proxies that only allow what is specifically allowed and deny everything else. Because zope.proxy is written in C, there's no way to defeat it in Python. The other potential holes I'm aware of are with: - rocks, which I'm very conservative with, and - __builtins__. You have to construct builtins very carefully, which we do and make sure you avoid certain problematic builtins, which we also do. It's hard to guess what they might be referring to, since they don't provide any specifics. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
Hi Martijn Betreff: [Zope-dev] who wants to maintain Zope 3? Hi there, Is anyone interested in maintaining Zope 3? With Zope 3 I mean: * the thing with the ZMI - do you care about the ZMI? Of corse do we all need the UI part for manage the components we install. But the old style ZMI views are obsolate this days. Right now we have to write this part for each project by ourself if they need to depend on z3c.form and z3c.pagelet. * the thing that can be installed as a particular development platform - do you care about the installation story for Zope 3? (as opposed to Grok or your own application's?) Yes, I don't use it but I think we should have something available as a starting point for newcomers. This could be something like zopeproject or a minimalistic setup with as less as possible zope.*, z3c.* and repoze packages. * the thing that has some kind of documentation website - do you care about providing documentation for Zope 3 as opposed to documentation for Grok or individual libraries? People who are interested in these aspects please speak up, so we can figure out what this all means for the future of Zope 3. I think we should take a look if we can build a minimal setup which Plone, Grok and other projects can use. Do you think there could be such a based configuration? Or is there to much difference in each of Plone, Grok, repoze etc? If nobody is interested, we should perhaps stop talking about it entirely. If people are just interested in the ZMI, perhaps we should form a ZMI project. The question is, can we find browser page pattern which Grok, Plone, repoze and others can use? Everybody needs to have at least management views for manage the components they install in some ways. So the question is not if we skip the ZMI or not. I think the question is can we improve and share such views in the different projects or do we have to develop views for each of them? Regards Roger Ineichen ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope] RIP Zope 2!
Tim Nash wrote at 2009-4-5 14:05 -0700: Also, I have been critical of the zope 3 line because I love zope 2 and it appears to me that zope 3 is killing zope 2. I share your feeling. With my current experience, the Zope 3 way to handle skins is considerably more work then the previous CMF skinning. True, you have a separate namespace for views and thus avoid name clashes in edge cases -- but is this really worth the extra effort? -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] dtml-in pagination
Bobby wrote at 2009-4-7 09:58 -0700: td colspan=3 a href=?table=dtml-var tableorder_by=dtml-var order_bysort=dtml-var sortstart=dtml-var previous-sequenceprevious/a a href=?table=dtml-var tableorder_by=dtml-var order_bysort=dtml-var sortstart=dtml-var next-sequencenext/a /td /tr /dtml-if sequence-end /dtml-in Not sure, whether you will find it useful. But, you may have a look at http://www.handshake.de/~dieter/pyprojects/zope/book/chap3.html#c37ac15c14b4;. Search there for 4.3.5.2.3. Batch control. -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] RIP Zope 2!
On Fri, Apr 10, 2009 at 08:55, Dieter Maurer die...@handshake.de wrote: With my current experience, the Zope 3 way to handle skins is considerably more work then the previous CMF skinning. True, you have a separate namespace for views and thus avoid name clashes in edge cases -- but is this really worth the extra effort? Yes, without any doubt whatsoever. And when it comes to effort, you have a point. Zope 3 in itself is too fragmented, too low level and too XML-y. Grok solves that. Zope 3 was also too big and monolithic. The eggification process solved that (and made Zope3 pointless as an application server, and it became a toolkit/framework). And some central parts of Zope 3, in particular the publisher, are too complex. Repoze and Repoze.bfg solved that. That means that for most cases, except when you need Zope 2 compatibility, The Thing That Once Was Known as Zope 3 are now finally ready. Obviously there is not much point in porting projects, but if you start a new project, the extra work of learning Grok or repoze.BFG could very well be worth the effort. I love Zope 2 as well, although I forget sometimes, since I never work with Zope 2, I work with Plone. Which I don't love (but Plone 4 looks like I will love it again). But with the Zope Toolkit I can do everything I want to do with Zope 2, with less code and less magic handwaving, and less (un)expected problems. We who know Zope 2 can develop in it easily and without problems. But it WAS a pain to get to that point. Zope 3 had a completely different set of pains. IMO, Grok has a much lesser pain level. Yes, Zope 3 did kill off a lot of interest in Zope 2, and was a contributing factor to the fact that Zope 2 doesn't attract new developers. But it wasn't the only one. It was already losing mindshare because it was too painful to use, and Python people didn't like it. People went from Zope to Python, not the other way around. With a time machine, much could have been done differently. But it's too late now. Time has ran away from Zope 2, Zope 3 never took off. It's time to take the experiences and the vast codebase, and move forward. And I guess Zope Toolkit, Grok and BFG is that way forward. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
