Re: [Zope-dev] Zope 4 roadmap
Op 17 nov 2011, om 20:57 heeft Tres Seaver het volgende geschreven: Hello, On 11/17/2011 02:05 PM, Laurence Rowe wrote: On 17 November 2011 15:23, Martin Aspeli optilude+li...@gmail.com wrote: On 17 November 2011 14:46, Laurence Rowe l...@lrowe.co.uk wrote: snip - Move authentication out to WSGI middleware. +1 - anything we can do to make AccessControl simpler and more debuggable would be a big win. Note that there is a counter-trend here among the Pyramid crew: many developers *want* tight integration of authentication, particularly the login forms. And there is a major issue with this is that for the moment your authentication depends from where you are in your Zope 2 application. Maybe in some part of the application the authentication will be done using LDAP, and not in some other: you can have a acl_users only for some part of the application, and users there are available locally and not globally. That is because the authentication is done after the traversing. If you want to do this in a WSGI middleware, you will have to do the traversing in a WSGI middleware before, otherwise lot of people won't be able to migrate theirs applications to Zope 4, because the paradigm changed. I don't think this is a good idea because of that. Regards, Sylvain, -- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 roadmap
On 11/22/2011 11:13 AM, Sylvain Viollon wrote: Op 17 nov 2011, om 20:57 heeft Tres Seaver het volgende geschreven: Note that there is a counter-trend here among the Pyramid crew: many developers *want* tight integration of authentication, particularly the login forms. I'm not sure I fully agree with that observation. I think the trend is that trying to do the UI part of authentication in middleware turned out to be a mistake and people are moving away from that. But everything else does not need tighter integration. And there is a major issue with this is that for the moment your authentication depends from where you are in your Zope 2 application. Maybe in some part of the application the authentication will be done using LDAP, and not in some other: you can have a acl_users only for some part of the application, and users there are available locally and not globally. That is because the authentication is done after the traversing. If you want to do this in a WSGI middleware, you will have to do the traversing in a WSGI middleware before, otherwise lot of people won't be able to migrate theirs applications to Zope 4, because the paradigm changed. Realistically though: how often is that used? Is that enough to warrant the extra complexity? WIchert. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 roadmap
On 22 November 2011 10:13, Sylvain Viollon sylv...@infrae.com wrote: Op 17 nov 2011, om 20:57 heeft Tres Seaver het volgende geschreven: Hello, On 11/17/2011 02:05 PM, Laurence Rowe wrote: On 17 November 2011 15:23, Martin Aspeli optilude+li...@gmail.com wrote: On 17 November 2011 14:46, Laurence Rowe l...@lrowe.co.uk wrote: snip - Move authentication out to WSGI middleware. +1 - anything we can do to make AccessControl simpler and more debuggable would be a big win. Note that there is a counter-trend here among the Pyramid crew: many developers *want* tight integration of authentication, particularly the login forms. And there is a major issue with this is that for the moment your authentication depends from where you are in your Zope 2 application. Maybe in some part of the application the authentication will be done using LDAP, and not in some other: you can have a acl_users only for some part of the application, and users there are available locally and not globally. That is because the authentication is done after the traversing. If you want to do this in a WSGI middleware, you will have to do the traversing in a WSGI middleware before, otherwise lot of people won't be able to migrate theirs applications to Zope 4, because the paradigm changed. I don't think this is a good idea because of that. Do you have multiple acl_users folders in a single Silva site? Or is it simply the same case as Plone where you might have multiple sites within the one ZODB? In the long run I expect that Plone will move to configuring multiple sites in a single instance through the WSGI configuration (rather than by creating sites through the ZMI.) In this scenario it would be possible to have different authentication configurations for each site in the WSGI config. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 roadmap
Op 22 nov 2011, om 16:36 heeft Laurence Rowe het volgende geschreven: Hello, Do you have multiple acl_users folders in a single Silva site? Or is it simply the same case as Plone where you might have multiple sites within the one ZODB? We do have an external users, that can be activated only for a part of a site to give temporary access to some locally defined users, that works with local acl_users within the same site. Those users are not global. Usually Silva sites are very large site, and not managed by one person, but by couple of them. They manages theirs external users independently through the Silva UI, where they want, without paying attention to what the other guy did. We can as well create multiple Silva root within the ZODB, but like Plone, but people don't do it that much. This is not a big issue for me, as I can change my code to adapt to the situation, but I think it is a major change in how Zope works, and that might be a blocking point for some people when they will want to upgrade. That might fragmentize the Zope 2 user group. In the long run I expect that Plone will move to configuring multiple sites in a single instance through the WSGI configuration (rather than by creating sites through the ZMI.) In this scenario it would be possible to have different authentication configurations for each site in the WSGI config. That's an idea, but you will have 'to restart' to apply the changes. Regards, Sylvain, -- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 roadmap
On 17 November 2011 14:46, Laurence Rowe l...@lrowe.co.uk wrote: Here's my current understanding of the Zope 4 roadmap. Zope 4 -- Significant progress has already been made on the following features and I expect they should all land in time for a Zope 4 release: - Storing parent pointers (elro, davisagli): we have a branch of Zope that changes OFS to store parent pointers on objects implementing ILocation and fixed the issues that arose in copy/cut/paste and zexp export code. There's an issue remaining with Acquisition, where we lost some protection against cycle protection - Hanno continues working on this. See also: http://wiki.zope.org/zope2/SetParentAndNameInOFS +1 - Remove XML zexp export (davisagli). +1 - Catalog using intids (rossp): we have branches of Zope, ZCatalog and CMF which change the catalog to use intids as their internal uid and rid. This needs more testing, but looks very promising. Currently it uses plone.app.intid / five.intid to maintain an intid to physical path mapping. Once the parent pointer work is stable, we can stop doing this and load objects directly from the database connection +0 - can we articulate the benefit of doing this? - Chameleon (chaoflow): Florian worked on making Zope use Chameleon by default. This works for the most parts, but there's some problems left in tests, as Chameleon wants an utility to be registered but a lot of tests in Zope and CMF don't use ZCML test layers. +1 - WebOb (garbas): Rok worked on bringing in WebOb as an underpinning for the request/response objects and making both API's available at the same time. I think the request is done and a good deal of the response works. Doing this means we can deprecate parts of the old request API and encourage the use of the more standard WebOb API. +1, though we'll need to balance the desire to be a better WSGI citizen with adding yet more complexity to BaseRequest and BaseResponse. - WSGI (matthewwilkes, hannosch): We fixed the bugs that had been reported about using the current WSGI support (mod_wsgi problems, forced dependency on repoze.who) on trunk and the 2.13 branch. Afterwards Matthew continued on a branch to remove the ZServer/medusa from Zope and leave only the WSGI publisher in place. +1 - I think WSGI should be the only way to deploy Zope 4. - Decorators for AccessControl (chaoflow). +1 Future releases (Zope 5, 6, etc.) - There has been some discussion on these topics but not much in the way of code yet: - Traversal Simplification. Remove attribute lookup from default traversal. +1, although this will require a lot of fixes in Zope consumers. I think we need a substantially simpler traversal mechanism that people actually understand. I've pdb'd BaseRequest.traverse more times than I care to remember and I still only vaguely understand it. - Unicode IDs in OFS +1 - Remove __allow_access_to_unprotected_subobjects__=1 from OFS.SimpleItem.Item +1, though again will break quite a lot. It's scary from a security perspective, though. - New ZMI +0 - we certainly need better XSRF protection and accessibility and look and feel are not great, though I think we should also consider what we actually use the ZMI for. A low-level object browser is really useful as a last resort admin tool. A number of the other things (like the various CMF tools, PAS, etc) could just as well expose their own views more independently of the ZMI, though we'd still need a way to discover those views. Perhaps something more simliar to the Plone control panel where tools can register views that just appear in a list of things you may need to manage may be useful, but it'll need some way of rooting that to e.g. Plone sites. - Move authentication out to WSGI middleware. +1 - anything we can do to make AccessControl simpler and more debuggable would be a big win. Long term - - Move to WebOb as our request object. The wider Python web framework community seems to have settled on WebOb as their request object of choice, so to facilitate sharing of software components with other projects we should consider making WebOb our request object too (instead of just wrapping it). This will require buy-in from the wider ZTK community as the ZTK components will need +1 - Move to Python 3. +0 Martin ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 roadmap
On 17 November 2011 15:23, Martin Aspeli optilude+li...@gmail.com wrote: On 17 November 2011 14:46, Laurence Rowe l...@lrowe.co.uk wrote: Here's my current understanding of the Zope 4 roadmap. Zope 4 -- Significant progress has already been made on the following features and I expect they should all land in time for a Zope 4 release: - Storing parent pointers (elro, davisagli): we have a branch of Zope that changes OFS to store parent pointers on objects implementing ILocation and fixed the issues that arose in copy/cut/paste and zexp export code. There's an issue remaining with Acquisition, where we lost some protection against cycle protection - Hanno continues working on this. See also: http://wiki.zope.org/zope2/SetParentAndNameInOFS +1 - Remove XML zexp export (davisagli). +1 - Catalog using intids (rossp): we have branches of Zope, ZCatalog and CMF which change the catalog to use intids as their internal uid and rid. This needs more testing, but looks very promising. Currently it uses plone.app.intid / five.intid to maintain an intid to physical path mapping. Once the parent pointer work is stable, we can stop doing this and load objects directly from the database connection +0 - can we articulate the benefit of doing this? Currently items are keyed by path in ZCatalog as they must be pulled out with their correct acquisition context (five.intid must also maintain a mapping based on path for the same reason.) When we have parent pointers we will be able to use zope.intid directly instead of five.intid (which many of us have had bad experiences with.) Using intids will mean that renaming or moving items does not require them to be unindexed and reindexed in the portal_catalog as they will maintain their same intid and will open up the possibility of intersecting result sets from a the portal_catalog with a zc.relation catalog. - Chameleon (chaoflow): Florian worked on making Zope use Chameleon by default. This works for the most parts, but there's some problems left in tests, as Chameleon wants an utility to be registered but a lot of tests in Zope and CMF don't use ZCML test layers. +1 - WebOb (garbas): Rok worked on bringing in WebOb as an underpinning for the request/response objects and making both API's available at the same time. I think the request is done and a good deal of the response works. Doing this means we can deprecate parts of the old request API and encourage the use of the more standard WebOb API. +1, though we'll need to balance the desire to be a better WSGI citizen with adding yet more complexity to BaseRequest and BaseResponse. - WSGI (matthewwilkes, hannosch): We fixed the bugs that had been reported about using the current WSGI support (mod_wsgi problems, forced dependency on repoze.who) on trunk and the 2.13 branch. Afterwards Matthew continued on a branch to remove the ZServer/medusa from Zope and leave only the WSGI publisher in place. +1 - I think WSGI should be the only way to deploy Zope 4. - Decorators for AccessControl (chaoflow). +1 Future releases (Zope 5, 6, etc.) - There has been some discussion on these topics but not much in the way of code yet: - Traversal Simplification. Remove attribute lookup from default traversal. +1, although this will require a lot of fixes in Zope consumers. I think we need a substantially simpler traversal mechanism that people actually understand. I've pdb'd BaseRequest.traverse more times than I care to remember and I still only vaguely understand it. - Unicode IDs in OFS +1 - Remove __allow_access_to_unprotected_subobjects__=1 from OFS.SimpleItem.Item +1, though again will break quite a lot. It's scary from a security perspective, though. - New ZMI +0 - we certainly need better XSRF protection and accessibility and look and feel are not great, though I think we should also consider what we actually use the ZMI for. A low-level object browser is really useful as a last resort admin tool. A number of the other things (like the various CMF tools, PAS, etc) could just as well expose their own views more independently of the ZMI, though we'd still need a way to discover those views. Perhaps something more simliar to the Plone control panel where tools can register views that just appear in a list of things you may need to manage may be useful, but it'll need some way of rooting that to e.g. Plone sites. - Move authentication out to WSGI middleware. +1 - anything we can do to make AccessControl simpler and more debuggable would be a big win. Long term - - Move to WebOb as our request object. The wider Python web framework community seems to have settled on WebOb as their request object of choice, so to facilitate sharing of software components with other projects we should consider making WebOb our request object too (instead of just wrapping it). This will require buy-in from the
Re: [Zope-dev] Zope 4 roadmap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/17/2011 02:05 PM, Laurence Rowe wrote: On 17 November 2011 15:23, Martin Aspeli optilude+li...@gmail.com wrote: On 17 November 2011 14:46, Laurence Rowe l...@lrowe.co.uk wrote: snip - Move authentication out to WSGI middleware. +1 - anything we can do to make AccessControl simpler and more debuggable would be a big win. Note that there is a counter-trend here among the Pyramid crew: many developers *want* tight integration of authentication, particularly the login forms. Long term - - Move to WebOb as our request object. The wider Python web framework community seems to have settled on WebOb as their request object of choice, so to facilitate sharing of software components with other projects we should consider making WebOb our request object too (instead of just wrapping it). This will require buy-in from the wider ZTK community as the ZTK components will need +1 BBB concerns are likely going to keep us from replacing the request entirely. What really matters for re-use is that our requests provide the same commonly-used subset of the WebOb request API. - Move to Python 3. +0 I expect this will only become important several years down the line, but the more we use other people's code who have already ported to Python 3, the less code we will have to port ourselves. FWIW, the port to Python3 of substantial existing web framework code is already a dubious proposition: nearly everybody doing it these days is suffering pain (making their own code more complicated by straddling) in order to gain hypothetical future benefits. I would leave it off the roadmap completely until that landscape changes substantially. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7FZywACgkQ+gerLs4ltQ6IcwCgsJ6yQsbLOwOJ18JnV51nxqAg hi4AoIFtnSJqWc5jCPrZdUEVQ1R9N6NO =gaBY -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 roadmap
On Thu, Nov 17, 2011 at 20:57, Tres Seaver tsea...@palladion.com wrote: FWIW, the port to Python3 of substantial existing web framework code is already a dubious proposition: nearly everybody doing it these days is suffering pain (making their own code more complicated by straddling) in order to gain hypothetical future benefits. The framework as a whole should not straddle versions. Just as we drop backwards incompatibility for Zope 4 and then Zope 5 and then Zope 6, etc, in one of these moves we drop backwards incompatibility by moving from Python 2 to Python 3. That in fact is probably a good reason for a new release all by itself. :-) The same thing goes for Plone. Once Zope X does the move, Plone Y does. Only the packages and products for Plone should need to straddle versions. //Lennart ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
