Hello guys, I'm coding some stuff, using zope.app.authentication and this package appears to do too many things, in my opinion. Would it be wise to cut off some of the functionalities ? The pure PAU components could go in a dedicated package, like zope.pluggableauthservice The whole handling of principals, groups and folder makes it a bit hard to read and introduces a lot of redundancy if we wish to roll our own things. What do you guys think ? Cheers - Souheil
On Fri, Jan 22, 2010 at 7:59 PM, Souheil CHELFOUH <trollfot@gmail.com> wrote:
I'm coding some stuff, using zope.app.authentication and this package appears to do too many things, in my opinion. Would it be wise to cut off some of the functionalities ? The pure PAU components could go in a dedicated package, like zope.pluggableauthservice
I don't have a good understanding of any of the security related features of Zope 3, but it looks like we already have a lot of packages. Would it make sense to put it into any of the existing ones? There's at least: zope.authentication zope.login zope.password zope.principalannotation zope.principalregistry zope.security zope.securitypolicy Hanno
I don't think so. The PAU is quite a big chunk and would really deserve to live on its own piece of land. zope.authentication is really about the authentication basics, not all the pluggability and plugin that PAU brings in. zope.app.authentication is just too confuse as it defines PAU and a whole set of persistent authentication-relatied components and other things that could be easily (logically) cut off. 2010/1/22 Hanno Schlichting <hanno@hannosch.eu>:
On Fri, Jan 22, 2010 at 7:59 PM, Souheil CHELFOUH <trollfot@gmail.com> wrote:
I'm coding some stuff, using zope.app.authentication and this package appears to do too many things, in my opinion. Would it be wise to cut off some of the functionalities ? The pure PAU components could go in a dedicated package, like zope.pluggableauthservice
I don't have a good understanding of any of the security related features of Zope 3, but it looks like we already have a lot of packages. Would it make sense to put it into any of the existing ones?
There's at least:
zope.authentication zope.login zope.password zope.principalannotation zope.principalregistry zope.security zope.securitypolicy
Hanno
On 01/22/2010 07:59 PM, Souheil CHELFOUH wrote:
Hello guys,
I'm coding some stuff, using zope.app.authentication and this package appears to do too many things, in my opinion. Would it be wise to cut off some of the functionalities ? The pure PAU components could go in a dedicated package, like zope.pluggableauthservice The whole handling of principals, groups and folder makes it a bit hard to read and introduces a lot of redundancy if we wish to roll our own things. What do you guys think ?
Yeah, I think it would be nice to give that code a refactoring. Whenever I work with it I feel the urge to do so. There's also subtle API annoyances that I'd like to get rid of but don't remember exactly right now. How about a specific proposal? Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hello, I took the liberty to start the work by a first simple move : splitting apart what is "strictly" about PAU's core and the rest. PAU and some plugins have been put in : http://svn.zope.org/repos/main/zope.pluggableauth/trunk/ The rest has been kept in: http://svn.zope.org/repos/main/zope.app.authentication/branches/zope.pluggab... The tests pass and nothing has been changed but the imports. I people could already give me their feelings about it, it would be very constructive. There is still a lot of code that might need work. My concern was about the factories and the events. They look unnecessary to me in the core. I'm not sure, however, that people want to split that part. I hope to get some feedback so I can go on with the work and not lose the current momentum. - Souheil 2010/1/26 Christian Theune <ct@gocept.com>:
On 01/22/2010 07:59 PM, Souheil CHELFOUH wrote:
Hello guys,
I'm coding some stuff, using zope.app.authentication and this package appears to do too many things, in my opinion. Would it be wise to cut off some of the functionalities ? The pure PAU components could go in a dedicated package, like zope.pluggableauthservice The whole handling of principals, groups and folder makes it a bit hard to read and introduces a lot of redundancy if we wish to roll our own things. What do you guys think ?
Yeah, I think it would be nice to give that code a refactoring. Whenever I work with it I feel the urge to do so.
There's also subtle API annoyances that I'd like to get rid of but don't remember exactly right now.
How about a specific proposal?
Christian
-- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
_______________________________________________ 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 )
Hi, On 01/26/2010 09:06 AM, Souheil CHELFOUH wrote:
Hello,
I took the liberty to start the work by a first simple move : splitting apart what is "strictly" about PAU's core and the rest. PAU and some plugins have been put in : http://svn.zope.org/repos/main/zope.pluggableauth/trunk/
The rest has been kept in: http://svn.zope.org/repos/main/zope.app.authentication/branches/zope.pluggab...
The tests pass and nothing has been changed but the imports.
I people could already give me their feelings about it, it would be very constructive. There is still a lot of code that might need work. My concern was about the factories and the events. They look unnecessary to me in the core. I'm not sure, however, that people want to split that part.
I hope to get some feedback so I can go on with the work and not lose the current momentum.
As Martijn left the steering group, we're currently in discussions on how to proceed internally. One thing I'd like to mention here is that we do need to be careful balancing momentum with other qualities of the work we do: you want feedback and I'd like to give feedback. I can't drop the regular work I do on the spot for that though. And I think architectural changes don't need to be implemented within days or weeks. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
Christian, I hear you and understand you. I'm not advertizing for an immediate and brainless action. What I did this week end is simply to split the PAU from all the components provided with it (well, most of it). That was motivated by my current work and by the will to see the dependencies become cleaner and the code shorter. I understand that the momentum is not everything, but when I can dedicate myself to a task, be motivated by it and paid for it, then, I don't see any reasons to hold back ;-) In this case, I'll just wait for your feedbacks, zope devs, and we'll take the time (obviously) to do the things correctly. Let me know what you guys think, about what has to be done, when you can - Souheil 2010/1/26 Christian Theune <ct@gocept.com>:
Hi,
On 01/26/2010 09:06 AM, Souheil CHELFOUH wrote:
Hello,
I took the liberty to start the work by a first simple move : splitting apart what is "strictly" about PAU's core and the rest. PAU and some plugins have been put in : http://svn.zope.org/repos/main/zope.pluggableauth/trunk/
The rest has been kept in: http://svn.zope.org/repos/main/zope.app.authentication/branches/zope.pluggab...
The tests pass and nothing has been changed but the imports.
I people could already give me their feelings about it, it would be very constructive. There is still a lot of code that might need work. My concern was about the factories and the events. They look unnecessary to me in the core. I'm not sure, however, that people want to split that part.
I hope to get some feedback so I can go on with the work and not lose the current momentum.
As Martijn left the steering group, we're currently in discussions on how to proceed internally.
One thing I'd like to mention here is that we do need to be careful balancing momentum with other qualities of the work we do: you want feedback and I'd like to give feedback. I can't drop the regular work I do on the spot for that though.
And I think architectural changes don't need to be implemented within days or weeks.
Christian
-- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
_______________________________________________ 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 )
Hi, On 01/26/2010 09:32 AM, Souheil CHELFOUH wrote:
Christian,
I hear you and understand you.
Thanks. :)
I'm not advertizing for an immediate and brainless action. What I did this week end is simply to split the PAU from all the components provided with it (well, most of it). That was motivated by my current work and by the will to see the dependencies become cleaner and the code shorter. I understand that the momentum is not everything, but when I can dedicate myself to a task, be motivated by it and paid for it, then, I don't see any reasons to hold back ;-)
Right. That's pretty much how I feel myself. ;)
In this case, I'll just wait for your feedbacks, zope devs, and we'll take the time (obviously) to do the things correctly.
I know that it's always nice to be able to immediately reap the fruits from your work and I hate it having to go with "about to be outdated" code with a project, but in the long run some patience will get us further. Thanks for understanding!
Let me know what you guys think, about what has to be done, when you can
Something we need to sort out is keeping "open reviews" or "open proposals" on the radar. Can you please add a blueprint here: https://blueprints.launchpad.net/zopetoolkit/ Also, can you add a proposal page to the documentation that points out what you already implemented and what you intend to achieve globally? Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hi, Christian Theune <ct@gocept.com> wrote:
On 01/26/2010 09:32 AM, Souheil CHELFOUH wrote:
I hear you and understand you.
Thanks. :)
I'm not advertizing for an immediate and brainless action. What I did this week end is simply to split the PAU from all the components provided with it (well, most of it). That was motivated by my current work and by the will to see the dependencies become cleaner and the code shorter. I understand that the momentum is not everything, but when I can dedicate myself to a task, be motivated by it and paid for it, then, I don't see any reasons to hold back ;-)
Right. That's pretty much how I feel myself. ;)
In this case, I'll just wait for your feedbacks, zope devs, and we'll take the time (obviously) to do the things correctly.
I know that it's always nice to be able to immediately reap the fruits from your work and I hate it having to go with "about to be outdated" code with a project, but in the long run some patience will get us further.
Thanks for understanding!
Let me know what you guys think, about what has to be done, when you can
Something we need to sort out is keeping "open reviews" or "open proposals" on the radar.
Can you please add a blueprint here: https://blueprints.launchpad.net/zopetoolkit/
Also, can you add a proposal page to the documentation that points out what you already implemented and what you intend to achieve globally?
Just my quick 2 euro cents here: As far as I can tell, what Souheil did so far is no architectural change, but a change like so many in the recent past where a zope.app.something package has been refactored into a zope.something package and keeping backwards compatibility in zope.app.something. I'm not sure how this became looking way bigger than it is, except for the explicit requests for feedback by Souheil. He requested feedback, I guess, as he might not yet be completely confident about making these changes and needs some support - I can fully understand that myself. regards, jw
Hi, On 01/26/2010 03:02 PM, Jan-Wijbrand Kolman wrote:
Hi,
Just my quick 2 euro cents here:
As far as I can tell, what Souheil did so far is no architectural change, but a change like so many in the recent past where a zope.app.something package has been refactored into a zope.something package and keeping backwards compatibility in zope.app.something.
I'm not sure how this became looking way bigger than it is, except for the explicit requests for feedback by Souheil. He requested feedback, I guess, as he might not yet be completely confident about making these changes and needs some support - I can fully understand that myself.
Thanks for stepping in -- in addition to Martijn whose ghost is now haunting me ... ;) I think there's a communication problem here. I was asserting something about slowing down architectural changes in general but also having the feeling that he's talking about architectural changes and thus asking for feedback. So Souheil naturally kept running with that ... Then I went off and talked about stuff I imagine "could happen" while doing architectural changes anyway ... so that's how it gre. So I guess I should be writing a proposal for that stuff. If it's a pure dependency refactoring, well then, that's what we already all agreed about. Isn't it? Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
Well, the first step is already to cut the dependencies and get a sane tree and a reusable package. The second step, however, if people feel like it, will be to refactor a bit and _that_ will need careful planning, yes. But, one thing at a time :) However, I'll polish a bit zope.plugabbleauth and it will be eligible for a release, I guess. 2010/1/26 Christian Theune <ct@gocept.com>:
Hi,
On 01/26/2010 03:02 PM, Jan-Wijbrand Kolman wrote:
Hi,
Just my quick 2 euro cents here:
As far as I can tell, what Souheil did so far is no architectural change, but a change like so many in the recent past where a zope.app.something package has been refactored into a zope.something package and keeping backwards compatibility in zope.app.something.
I'm not sure how this became looking way bigger than it is, except for the explicit requests for feedback by Souheil. He requested feedback, I guess, as he might not yet be completely confident about making these changes and needs some support - I can fully understand that myself.
Thanks for stepping in -- in addition to Martijn whose ghost is now haunting me ... ;)
I think there's a communication problem here. I was asserting something about slowing down architectural changes in general but also having the feeling that he's talking about architectural changes and thus asking for feedback. So Souheil naturally kept running with that ...
Then I went off and talked about stuff I imagine "could happen" while doing architectural changes anyway ... so that's how it gre.
So I guess I should be writing a proposal for that stuff.
If it's a pure dependency refactoring, well then, that's what we already all agreed about. Isn't it?
Christian
-- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
_______________________________________________ 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 )
On 01/26/2010 03:30 PM, Souheil CHELFOUH wrote:
Well, the first step is already to cut the dependencies and get a sane tree and a reusable package. The second step, however, if people feel like it, will be to refactor a bit and _that_ will need careful planning, yes. But, one thing at a time :)
However, I'll polish a bit zope.plugabbleauth and it will be eligible for a release, I guess.
Sounds like a plan. :) -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hi, Christian Theune <ct@gocept.com> wrote:
On 01/26/2010 03:30 PM, Souheil CHELFOUH wrote:
Well, the first step is already to cut the dependencies and get a sane tree and a reusable package. The second step, however, if people feel like it, will be to refactor a bit and _that_ will need careful planning, yes. But, one thing at a time :)
However, I'll polish a bit zope.plugabbleauth and it will be eligible for a release, I guess.
Sounds like a plan. :)
Cool! regards, jw
Sorry for bring an old thread back up, but it's relevant. On Tue, Jan 26, 2010 at 4:06 AM, Souheil CHELFOUH <trollfot@gmail.com> wrote:
The tests pass and nothing has been changed but the imports.
Actually, the base classes for SessionCredentialsPlugin changed, and no longer include these: persistent.Persistent zope.app.container.contained.Contained These are probably good to retain. The later should probably be replaced with zope.container.contained.Contained, but the value is the same. Though simple, dropping this can affect existing applications in obscure ways, since adapter lookups are likely to produce different results. Are there any objections to adding these base classes back in? -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "A storm broke loose in my mind." --Albert Einstein
participants (5)
-
Christian Theune -
Fred Drake -
Hanno Schlichting -
Jan-Wijbrand Kolman -
Souheil CHELFOUH