Re: [Zope-dev] who wants to maintain Zope 3?
Hello, * 2009-04-13 12:50, Hermann Himmelbauer wrote:
+1, to declaring Zope 3 dead. That should allow us to refactor the remaining packages much more aggressively and reduce the dependencies.
-1 from my standpoint. Two of my projects are fully based on the Zope 3 server, and switching to something else would be quite some pain.
I fully agree: our company is based on zope3 technology, and we have at least three big deployments based on zope3 (yes, the application server) using ZODB and PostgreSQL/storm. I do not know in the details what would it mean to switch to the zope toolkit/repoze/whatever is fashionable today, but I suppose it would be quite painful for us. If the question was "who is interested in zope3, the application server, and willing to maintain it", I'd answer "me". Best regards. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _____________________________________________________________________ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564
Hey, Fabio Tranchitella wrote: [snip]
If the question was "who is interested in zope3, the application server, and willing to maintain it", I'd answer "me".
Thanks for speaking up! Do you use the Zope 3 ZMI a lot? The Zope Toolkit right now is most of the Zope 3 libraries. The main thing we're getting rid of is the ZMI right now and cleaning up the dependency structure. After that there are various other avenues for innovation. We're not out to break people's code. The Zope Toolkit project is very much about supporting this code better, allowing it to evolve and stay relevant. I'm a huge user of the existing codebase itself and I'm not about to rewrite all my stuff. Regards, Martijn
Hello, * 2009-04-14 19:25, Martijn Faassen wrote:
Do you use the Zope 3 ZMI a lot?
It depends on your meaning of "a lot": we do not use it as main UI, not even for the back-end, nevertheless we often use it for managing our "applications". I mean, adding/renaming/moving/editing objects to the ZODB, as well as configuring local components. I am sure that we are using only a small subset of the features ZMI offers right now, but I suppose we are not the only one, and I really think that maintaining and supporting it is important for the community. Best regards. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _____________________________________________________________________ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564
Am Dienstag 14 April 2009 19:32:20 schrieb Fabio Tranchitella:
Hello,
* 2009-04-14 19:25, Martijn Faassen wrote:
Do you use the Zope 3 ZMI a lot?
It depends on your meaning of "a lot": we do not use it as main UI, not even for the back-end, nevertheless we often use it for managing our "applications". I mean, adding/renaming/moving/editing objects to the ZODB, as well as configuring local components.
Btw., that's exactly what I do - I started my project with Philipps book and that time believed that it's possible to adapt the ZMI to my needs, which was not the case. Today, I also use the ZMI for management issues, for evolving the database, adding objects, looking at the local error log etc. If I would not have it, I'd have to do those things in debug mode, which is a lot less convenient. Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
I thhink just dropping zmi is ploblematical without a management ui alternative. How would you propose managing things like per instance pluggable auth components. zcml is not enough and nor is any other static config. You need per instance persistent configuration and I am assuming grok and anything using zope 3 (traiditional server) would need to do this. So anyone buidling a instance based manageble tool would want to ship it with a management ui that would work on multiple zope toolkit based systems, T On Wed, Apr 15, 2009 at 1:20 AM, Martijn Faassen <faassen@startifact.com> wrote:
Hey,
Fabio Tranchitella wrote: [snip]
If the question was "who is interested in zope3, the application server, and willing to maintain it", I'd answer "me".
Thanks for speaking up!
Do you use the Zope 3 ZMI a lot?
The Zope Toolkit right now is most of the Zope 3 libraries. The main thing we're getting rid of is the ZMI right now and cleaning up the dependency structure. After that there are various other avenues for innovation.
We're not out to break people's code. The Zope Toolkit project is very much about supporting this code better, allowing it to evolve and stay relevant. I'm a huge user of the existing codebase itself and I'm not about to rewrite all my stuff.
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 )
Hey, Tim Hoffman wrote:
I thhink just dropping zmi is ploblematical without a management ui alternative. How would you propose managing things like per instance pluggable auth components. zcml is not enough and nor is any other static config. You need per instance persistent configuration and I am assuming grok and anything using zope 3 (traiditional server) would need to do this. So anyone buidling a instance based manageble tool would want to ship it with a management ui that would work on multiple zope toolkit based systems,
I handle pluggable auth components in code right now. Anyway, I think the following will and should happen: * the Zope Toolkit project will continue to remove the ZMI from the toolkit. * the ZMI will still be available as code, it just won't be in the toolkit. If enough people are interested in maintaining this codebase to make sure it continues to work, it'll be around. It's just not very focused code, and it's scattered all over the place. * I'd recommend some people get together and focus on building a much smaller, more tightly focused replacement of the ZMI that does the things people find important but is just a single package (or a few). Regards, Martijn
Am Mittwoch 15 April 2009 09:24:23 schrieb Martijn Faassen:
Hey,
Tim Hoffman wrote:
I thhink just dropping zmi is ploblematical without a management ui alternative. How would you propose managing things like per instance pluggable auth components. zcml is not enough and nor is any other static config. You need per instance persistent configuration and I am assuming grok and anything using zope 3 (traiditional server) would need to do this. So anyone buidling a instance based manageble tool would want to ship it with a management ui that would work on multiple zope toolkit based systems,
* I'd recommend some people get together and focus on building a much smaller, more tightly focused replacement of the ZMI that does the things people find important but is just a single package (or a few).
Hmmm, maybe it's a silly idea - but perhaps it would be possible to unify these efforts with Grok/repoze? Maybe develop something that's in the Zope toolkit and can be used on all these frameworks? Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
Hey, Hermann Himmelbauer wrote:
Am Mittwoch 15 April 2009 09:24:23 schrieb Martijn Faassen: [snip]
* I'd recommend some people get together and focus on building a much smaller, more tightly focused replacement of the ZMI that does the things people find important but is just a single package (or a few).
Hmmm, maybe it's a silly idea - but perhaps it would be possible to unify these efforts with Grok/repoze? Maybe develop something that's in the Zope toolkit and can be used on all these frameworks?
We could have an effort in the Zope Toolkit context to build a user interface that can be shared between Grok and Zope 3 (and possibly Zope 2 at some point), or at least components that can be shared. It would require a lot of coordination where now there is none however, and Grok already has quite a bit (that is optional). repoze.bfg to my knowledge has no UI at all. Anyway, talking about such possible efforts won't do much if there isn't someone who will actually drive this process. :) Regards, Martijn
Hi there, Martijn Faassen wrote:
Hermann Himmelbauer wrote:
Am Mittwoch 15 April 2009 09:24:23 schrieb Martijn Faassen: [snip]
* I'd recommend some people get together and focus on building a much smaller, more tightly focused replacement of the ZMI that does the things people find important but is just a single package (or a few).
Hmmm, maybe it's a silly idea - but perhaps it would be possible to unify these efforts with Grok/repoze? Maybe develop something that's in the Zope toolkit and can be used on all these frameworks?
Sounds charming :)
We could have an effort in the Zope Toolkit context to build a user interface that can be shared between Grok and Zope 3 (and possibly Zope 2 at some point), or at least components that can be shared. It would require a lot of coordination where now there is none however, and Grok already has quite a bit (that is optional).
repoze.bfg to my knowledge has no UI at all.
Anyway, talking about such possible efforts won't do much if there isn't someone who will actually drive this process. :)
I'd be willing to help although I don't feel qualified enough to drive such a process. Best regards, -- Uli
2009/4/14 Fabio Tranchitella <kobold@kobold.it>:
I fully agree: our company is based on zope3 technology, and we have at least three big deployments based on zope3 (yes, the application server) using ZODB and PostgreSQL/storm. I do not know in the details what would it mean to switch to the zope toolkit/repoze/whatever is fashionable today, but I suppose it would be quite painful for us.
You don't need to switch to the Zope Toolkit, because you are already using it. Switching to BFG may or may not be painful, it depends on if you have code that is dependent on zope.app.publisher, otherwise no. If so you may want to help with the zope.pipeline proposal that probably will end up creating a publisher that is more zope.app.publication-like, but more modular and modern. That should not be a big pain. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
participants (6)
-
Fabio Tranchitella -
Hermann Himmelbauer -
Lennart Regebro -
Martijn Faassen -
Tim Hoffman -
Uli Fouquet