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
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
Roger Ineichen wrote:
Betreff: [Zope-dev] who wants to maintain Zope 3? Is anyone interested in maintaining Zope 3?
/me is certainly not
With Zope 3 I mean:
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?
The "minimal setup" is called Zope Toolkit. None of the mentioned projects is interested in any of the Zope 3 packages, except where those are still tied into the whole.
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.
+1, to declaring Zope 3 dead. That should allow us to refactor the remaining packages much more aggressively and reduce the dependencies.
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 don't see any example where something in this direction could be shared. The entire model of "context/@@standard_macros" to provide a unified look and feel hasn't worked out, from what I can tell. On the technical side at least Plone is going to switch over to Chameleon as its page template story and use Grok patterns for building pages. I don't think this kind of buy-in is something everyone else is willing to share. Hanno
Hi Hanno
Betreff: Re: [Zope-dev] who wants to maintain Zope 3?
Roger Ineichen wrote:
Betreff: [Zope-dev] who wants to maintain Zope 3? Is anyone interested in maintaining Zope 3?
/me is certainly not
I don't understand why you are not interested in Zope 3. Are you really not using Zope 3 packages like: zope.interface zope.component zope.schema etc. I'm really confused
With Zope 3 I mean:
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?
The "minimal setup" is called Zope Toolkit. None of the mentioned projects is interested in any of the Zope 3 packages, except where those are still tied into the whole.
I don't understand what you are talking about. Probably we don't understand the same if we talk about Zope 3 packages. Zope 3 packages in my point of view are the packages we as Zope 3 developer developed the last couple years. They are available at Pypi starting with zope.* and several other packages starting with a z3c.* as namespace. What do you mean with Zope 3 packages?
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.
+1, to declaring Zope 3 dead. That should allow us to refactor the remaining packages much more aggressively and reduce the dependencies.
What do you mean with remaining packages? And what do you mean with aggressivley reduce dependency? Hanno, it doesn't matter how we call the zope.* packages, zope 3 or zope or just foobar. But we defently need a team which takes care on such a core. It doesn't help if we just propose the marketing Brand Zope 3 is dead or something else. We all can benefit if we can confirm on a code base and have the same vision in which direction at least this code base should evolve. Regards Roger Ineichen
Roger Ineichen wrote:
Betreff: Re: [Zope-dev] who wants to maintain Zope 3?
Roger Ineichen wrote:
Betreff: [Zope-dev] who wants to maintain Zope 3? Is anyone interested in maintaining Zope 3? /me is certainly not
I don't understand why you are not interested in Zope 3. Are you really not using Zope 3 packages like:
zope.interface zope.component zope.schema etc.
I'm really confused
Please follow up on reading the Zope Toolkit (formerly known as Zope Framework) discussions. Maybe someone has a good summary of those. We clarified the vocabulary over the last weeks, so that the reusable libraries of Zope 3 like zope.interface are now known as the Zope Toolkit. The term Zope 3 refers to the zope.app.* web application including the ZMI, which happens to be a consumer of the Zope Toolkit in the same way Grok or Zope2 are. The whole point of Martijns mail is to find out if someone is interested in the ZMI, full-featured web application part what is now known as Zope 3. We already know that many people are interested in the Zope Toolkit including myself. Hanno
Roger Ineichen wrote:
Betreff: Re: [Zope-dev] who wants to maintain Zope 3?
Roger Ineichen wrote:
Betreff: [Zope-dev] who wants to maintain Zope 3? Is anyone interested in maintaining Zope 3? /me is certainly not
I don't understand why you are not interested in Zope 3. Are you really not using Zope 3 packages like:
zope.interface zope.component zope.schema etc.
I'm really confused
The whole point about this discussion is whether we want to continue to use the "Zope 3" name at all. zope.interface and friends are part of the Zope Toolkit. That's not something you install a a whole; it's a collection of parts (that can work together and that others build on to create wholes). Do people want a particular whole that's like the current Zope 3? Regards, Martijn
Hanno Schlichting wrote at 2009-4-11 15:05 +0200:
... +1, to declaring Zope 3 dead. That should allow us to refactor the remaining packages much more aggressively and reduce the dependencies.
You (Zope developers) are very fast in declaring things dead and destroy things application developers have build upon. I see myself rather as an application developer and conclude that Zope may no longer be adequate to build large applications on top of it -- applications that need to live and be maintained for many years to come. I am unconcerned with Zope 3 in particular, because I have not been an early adopter. But, I see the same behaviour also with Zope 2 and its features.... -- Dieter
On Sun, Apr 12, 2009 at 08:51, Dieter Maurer <dieter@handshake.de> wrote:
I see myself rather as an application developer and conclude that Zope may no longer be adequate to build large applications on top of it -- applications that need to live and be maintained for many years to come.
Well, the existing Zope releases will not disappear or go away. The "worst" that can happen for you as a Zope 2 developer is that 2.12 becomes the last release. Is that really a problem? But yes, the only developments in Zope 2 the last five years or so has been more inclusion of Zope Toolkit technologies. But without that Zope 2 would have stopped as 2.7, more or less. So if you don't use any of the component architecture, Zope 2 releases since 2.8 has been mostly pointless. And again: Is that a problem? And Zope 2.x will continue as long as people want it to. You are yourself amazingly well suited to fix bugs, as you are one of the Zope people who knows Zope 2 inside out. If you need new releases, there is no reason why there shouldn't be new relesases. In short, I'm not sure what you are worried about. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Lennart Regebro wrote at 2009-4-12 17:18 +0200:
On Sun, Apr 12, 2009 at 08:51, Dieter Maurer <dieter@handshake.de> wrote:
I see myself rather as an application developer and conclude that Zope may no longer be adequate to build large applications on top of it -- applications that need to live and be maintained for many years to come.
Well, the existing Zope releases will not disappear or go away. The "worst" that can happen for you as a Zope 2 developer is that 2.12 becomes the last release. Is that really a problem?
I fear it is a problem: maintenance includes extensions based on the platform build so far. For these extensions, newer ways of doing things may be wanted.
But yes, the only developments in Zope 2 the last five years or so has been more inclusion of Zope Toolkit technologies. But without that Zope 2 would have stopped as 2.7, more or less. So if you don't use any of the component architecture, Zope 2 releases since 2.8 has been mostly pointless. And again: Is that a problem?
We skipped indeed Zope 2.9 and Zope 2.10 -- but my newer colleagues think they lost something. But, to be clear: I am not against providing modern Zope features in Zope 2. My objections are against instability of the interfaces for these features. For example: When upgrading from Zope 2.8 to Zope 2.11, I had to fight for several hours because Zope 3 interfaces have been changed: * a convenience method "getView" has been removed from "zapi". True, it did not do much over "getMultiAdapter", but it had a speaking name and why should a convenience method, even if considered a bit redundant, harm much? * skinning has been changed completely -- the former skin control methods have been removed I agree that the new skin control is better, but why not emulate the older methods with the newer ones? * in some signatures, the parameter order has changed. To be honest, the quite high amount of time was not only caused by the Zope 3 changes but also by stupidity in our application.
... In short, I'm not sure what you are worried about.
Increasing maintenance costs for long living applications caused by cosmetic changes in the Zope platform. -- Dieter
On Mon, Apr 13, 2009 at 08:14, Dieter Maurer <dieter@handshake.de> wrote:
When upgrading from Zope 2.8 to Zope 2.11, I had to fight for several hours because Zope 3 interfaces have been changed:
True, you went from Zope 3.0 to 3.3 in one swoop there, and the changes was significant. But most of this changed because the first versions were mistakes. It was after all 3.0. With more experience of using the ZCA changes was needed. The path from 3.0 to 3.3 was mostly done via deprecations, but when you skip two versions, you won't see those. One of the major mistakes with Zope2 is that old ways of doing thing was *never* removed. This makes for both messy internals, and messy product code, as you can use several ways for doing one thing. Zope 3 probably went overboard in it's desire to keep things clean as a result. But you did go from the 2005 version of Zope to the 2008 version of Zope, some upgrade pain is expected. Maybe you have been spoiled by Python and Zope 2 not having much upgrade pain before, bit I honestly don't think it's a good sign for a framework to be so stagnant that three years of development doesn't break somethings. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Hey, Dieter Maurer wrote:
Hanno Schlichting wrote at 2009-4-11 15:05 +0200:
... +1, to declaring Zope 3 dead. That should allow us to refactor the remaining packages much more aggressively and reduce the dependencies.
You (Zope developers) are very fast in declaring things dead and destroy things application developers have build upon.
That's rich given the conservatism and frankly, inertia, that we've had here for years, often in the name of backwards compatibility. Not inertia in all areas, but in far too many. Regards, Martijn
Am Samstag 11 April 2009 15:05:31 schrieb Hanno Schlichting:
Roger Ineichen wrote:
Betreff: [Zope-dev] who wants to maintain Zope 3? Is anyone interested in maintaining Zope 3?
/me is certainly not
With Zope 3 I mean:
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?
The "minimal setup" is called Zope Toolkit. None of the mentioned projects is interested in any of the Zope 3 packages, except where those are still tied into the whole.
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.
+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 personally find it interesting that people are that fast with turning around and killing off things. I personally based my decision for Zope 3 on Philipps book ("Web Compontent Development with Zope 3"), whereas the latest edition came out just 1 year ago. I adapted the concepts in this book to my needs (e.g. by using z3c-based packages) and it's now a viable way for me and my projects. I understand that people like Zope 2 for historical reasons and Grok for it's simplicity, but I would really wonder that there's no target audience for various ideas/patterns in Zope 3 (security model, ZCML...). I personally heard that repoze.bfg may be the way to go, however, I'm very much in doubt even considering switching, as I wouldn't want to hear 1 year later "Let's kill off repoze.bfg". Moreover, I expect that there are many people like me, who started with Zope 3 with Philipp's book, so, would we really want to - ummm - "declare them dead"? If we do so, to my mind there has to be some migration path to something else, may it be Repoze, or whatever. But just killing off Zope 3 is like saying "Sorry guys, you just chose the wrong technology." Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
Hermann Himmelbauer wrote:
-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.
FWIW, I think you're absolutely right. We can't just declare it "dead" because it is convenient to our goal of having clearer definitions about what we're working with. A piece of open source software is dead if no-one uses it and no-one maintains it. At least then, existing users can't count on bug fixers or security fixes. I think Martijn's point in starting this thread was to try to identify who wants to maintain Zope 3 as an app server and as something that gets released going forward. Let's give those people a chance to respond. Declaring things dead has a tendency to become a self-fulfilling prophecy, and probably not something we should do lightly. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Hi Martin
-----Ursprüngliche Nachricht----- Von: zope-dev-bounces+dev=projekt01.ch@zope.org [mailto:zope-dev-bounces+dev=projekt01.ch@zope.org] Im Auftrag von Martin Aspeli Gesendet: Montag, 13. April 2009 13:07 An: zope-dev@zope.org Betreff: Re: [Zope-dev] who wants to maintain Zope 3?
Hermann Himmelbauer wrote:
-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.
FWIW, I think you're absolutely right. We can't just declare it "dead" because it is convenient to our goal of having clearer definitions about what we're working with.
A piece of open source software is dead if no-one uses it and no-one maintains it. At least then, existing users can't count on bug fixers or security fixes.
I think Martijn's point in starting this thread was to try to identify who wants to maintain Zope 3 as an app server and as something that gets released going forward. Let's give those people a chance to respond.
Declaring things dead has a tendency to become a self-fulfilling prophecy, and probably not something we should do lightly.
This sounds much better then the earlier mails ;-) I'm willing to help to find a way to move the old code parts to a newer and better concept. Note, I don't use this code in my own projects and I don't propose to do that just for fun. But if someone proposes to do it, I'm willing to help. I think we have to support a smooth migration path for the old ZMI views and we can't just skip them. Releasing a Zope 3 app server is another part. I'm not sure if Stephan Richter, he told once, will support it for the future? I still think the Grok, Repoze, Plone, Zope 2 and Zope 3 developer should talk together and find a concept and see how we can find a code base which will fit for each other. This probably only means that we move the zmi part out of the existing zope.* and z3c.* packages. And each project could offer a own management concept and views for the same code base. Regards Roger Ineichen
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 )
Previously Martin Aspeli wrote:
Hermann Himmelbauer wrote:
-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.
FWIW, I think you're absolutely right. We can't just declare it "dead" because it is convenient to our goal of having clearer definitions about what we're working with.
We can effectively not maintain it anymore and stop making release. Which would not be a major change from Zope 3 releases the last few years :) Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Martin Aspeli wrote:
Declaring things dead has a tendency to become a self-fulfilling prophecy, and probably not something we should do lightly.
I didn't mean to imply that we should declare Zope 3 dead based on this mailing list thread. This is a big decision that might warrant a Zope Foundation vote. I'd merely suggest that if nobody responds to this thread announcing interest in Zope 3 the app server, then it might be time to consider it dead. Neither at PyCon nor during many of the last threads we found a single user of Zope 3 the app server. By now I count three people using Zope 3 for a small number of projects. But none of them seems to have the resources to continue the maintenance or future development of Zope 3. If this turns out to be the only users of the Zope 3 app server, the community and foundation might be better of making this public in form of stopping to advertise Zope 3 on its websites and clearly stating that this is a dead end. Hanno
On Apr 14, 2009, at 10:34 AM, Hanno Schlichting wrote: ...
I'd merely suggest that if nobody responds to this thread announcing interest in Zope 3 the app server, then it might be time to consider it dead. Neither at PyCon nor during many of the last threads we found a single user of Zope 3 the app server.
Many people have said they're using the Zope 3 app server, where app server is the collection of components used to run applications using Zope 3 components. What no one is interested in is the *application* that was distributed in the Zope 3 distribution. ...
By now I count three people using Zope 3 for a small number of projects. But none of them seems to have the resources to continue the maintenance or future development of Zope 3.
For many of us, the components that make up Zope 3 have become boring and don't require a lot of maintenance.
If this turns out to be the only users of the Zope 3 app server, the community and foundation might be better of making this public in form of stopping to advertise Zope 3 on its websites and clearly stating that this is a dead end.
I think we have to be a lot more careful about our terminology. What definition of "app server" are we using? What the heck is the "Zope Toolkit"? Is there a page somewhere that defines what it is? I thought Zope 3 was being renamed "Zope Toolkit", but given recent discussions, I'm not sure. Jim -- Jim Fulton Zope Corporation
Hey, Jim Fulton wrote:
What the heck is the "Zope Toolkit"? Is there a page somewhere that defines what it is?
http://docs.zope.org/zopetoolkit/about/index.html
I thought Zope 3 was being renamed "Zope Toolkit", but given recent discussions, I'm not sure.
That never was the idea. The idea was to separate the concept of the toolkit from the concept of "Zope 3". Zope 3 (if people want to maintain it) is a user of the Zope Toolkit just like the other users. The Zope Toolkit inherits its libraries from Zope 3 but is trying to take on a lot less code. The goal is to take on *less* of a burden to maintain than the full Zope 3, and to move a bit faster than we have been. The Zope Toolkit is a project that: * aims at maintaining and releasing the various Zope libraries * aims at supporting the projects that some of use these libraries individually (repoze, bfg, twisted) * aims at supporting the projects that use most of these libraries as a set (Grok, Zope 2, Zope 3). * doesn't include the ZMI bits * won't have a way to install it (but Grok and Zope 2 and Zope 3 might come to share a large part of the installation method) * will try to shrink the codebase as much as it will try to grow it. To this effect the refactoring efforts, with the aim to throw out libraries (from the toolkit, not from the universe of packages) quite aggressively. Hopefully much of zope.app.* can go, as the useful non-ZMI bits get salvaged. The Zope Toolkit is *not* like Zope 3 in an important sense: there's no attempt to provide information about how to install it and start developing with it. We'll have this information for the individual libraries in the tookit, and for Zope 2 and Grok and so on, but not for the Zope Toolkit itself. Regards, Martijn
On Apr 14, 2009, at 11:20 AM, Martijn Faassen wrote:
Hey,
Jim Fulton wrote:
What the heck is the "Zope Toolkit"? Is there a page somewhere that defines what it is?
http://docs.zope.org/zopetoolkit/about/index.html
I thought Zope 3 was being renamed "Zope Toolkit", but given recent discussions, I'm not sure.
That never was the idea. The idea was to separate the concept of the toolkit from the concept of "Zope 3". Zope 3 (if people want to maintain it) is a user of the Zope Toolkit just like the other users. The Zope Toolkit inherits its libraries from Zope 3 but is trying to take on a lot less code.
The goal is to take on *less* of a burden to maintain than the full Zope 3, and to move a bit faster than we have been.
The Zope Toolkit is a project that:
* aims at maintaining and releasing the various Zope libraries
* aims at supporting the projects that some of use these libraries individually (repoze, bfg, twisted)
* aims at supporting the projects that use most of these libraries as a set (Grok, Zope 2, Zope 3).
* doesn't include the ZMI bits
I don't think these "bits" are cleanly separated. For example, if a content component has some views, are those ZMI bits? Can you identify projects that are in or out of the toolkit? What about zope.publisher? zope.security? zope.app.publication?
* won't have a way to install it (but Grok and Zope 2 and Zope 3 might come to share a large part of the installation method)
* will try to shrink the codebase as much as it will try to grow it. To this effect the refactoring efforts, with the aim to throw out libraries (from the toolkit, not from the universe of packages) quite aggressively. Hopefully much of zope.app.* can go, as the useful non- ZMI bits get salvaged.
The Zope Toolkit is *not* like Zope 3 in an important sense: there's no attempt to provide information about how to install it and start developing with it. We'll have this information for the individual libraries in the tookit, and for Zope 2 and Grok and so on, but not for the Zope Toolkit itself.
I agree with the idea of simply supporting a library of components. I'm uncomfortable with the idea of saying you're going to "shrink the codebase" without saying what's going. I don't want to see a separate "Zope 3 " project distinct from the "Zope Toolkit". I do want to see the components we're using live within a project. If the "Zope Toolkit" doesn't include components in common use, then I don't think it has a lot of value. Jim -- Jim Fulton Zope Corporation
Hey, Jim Fulton wrote:
I don't think these "bits" are cleanly separated. For example, if a content component has some views, are those ZMI bits?
Yes. zope.container doesn't define views. zope.app.container did (and does). "browser" directories are generally not part of the Zope Toolkit, though there are some exceptions (zope.app.publisher.browser, zope.app.form.browser).
Can you identify projects that are in or out of the toolkit? What about zope.publisher? zope.security? zope.app.publication?
Currently all three are in. zope.publisher + zope.app.publication might not remain in permanently if a better way of doing things evolves, but that's up in the air right now. [snip]
I agree with the idea of simply supporting a library of components. I'm uncomfortable with the idea of saying you're going to "shrink the codebase" without saying what's going.
The ZMI is the bit that is going right now. Since we're factoring non-ZMI bits out of zope.app.*, eventually that'll mean a whole range of zope.app.* packages will not be maintained by the Zope Toolkit developers. The other bits are up for discussion. We don't intend to stop people from maintaining other packages outside the toolkit.
I don't want to see a separate "Zope 3 " project distinct from the "Zope Toolkit". I do want to see the components we're using live within a project. If the "Zope Toolkit" doesn't include components in common use, then I don't think it has a lot of value.
I'm not in the business of maintaining Zope 3 myself; I mainly care about how Grok uses it, and how I can integrate libraries in the ecosystem into my apps. The Zope Toolkit includes components in common use by Grok, Zope 2, and Zope 3. The Zope 3 project always attempted to be far more than just being a bunch of libraries. It attempted to be a system you can install and find documentation for and start developing with. When you install it, you see a user interface. It had a group of people who cared about it that you could talk to. There are a lot of concepts associated with Zope 3. What I'm trying to do is to separate these concepts, which is why we're going through some confusion. The Zope Toolkit is something that doesn't have an installation story for the whole. It does have some documentation about the whole: how it is developed primarily. But instead of having documentation for the whole ("Build your app with the Zope Toolkit, here's how to get started!" is not going to be there), it will focus on documentation about how to use the individual libraries. It leaves how to use it as an integrated whole to other projects. The Zope Toolkit has implementations of content objects such as the container. It doesn't have a user interface; it just has a way to construct user interfaces. The Zope Toolkit is there to serve the people who use it. That's people who use a large range of these libraries, or just some of them, and projects that build on top of these libraries. The question at hand is whether people care about a project that presents itself as a "whole", uses a lot of the Zope Toolkit, and has an installation story (and possibly a user interface), and that isn't Grok or Zope 2, but like Zope 3. If so, we could have a Zope 3 project that cares about those things (naming discussion aside). Regards, Martijn
Hi Martijn
Betreff: Re: [Zope-dev] who wants to maintain Zope 3?
Hey,
Jim Fulton wrote:
I don't think these "bits" are cleanly separated. For example, if a content component has some views, are those ZMI bits?
Yes. zope.container doesn't define views. zope.app.container did (and does). "browser" directories are generally not part of the Zope Toolkit, though there are some exceptions (zope.app.publisher.browser, zope.app.form.browser).
Can you identify projects that are in or out of the toolkit? What about zope.publisher? zope.security? zope.app.publication?
Currently all three are in.
zope.publisher + zope.app.publication might not remain in permanently if a better way of doing things evolves, but that's up in the air right now.
[snip]
I agree with the idea of simply supporting a library of components. I'm uncomfortable with the idea of saying you're going to "shrink the codebase" without saying what's going.
The ZMI is the bit that is going right now. Since we're factoring non-ZMI bits out of zope.app.*, eventually that'll mean a whole range of zope.app.* packages will not be maintained by the Zope Toolkit developers. The other bits are up for discussion.
We don't intend to stop people from maintaining other packages outside the toolkit.
I don't want to see a separate "Zope 3 " project distinct from the "Zope Toolkit". I do want to see the components we're using live within a project. If the "Zope Toolkit" doesn't include components in common use, then I don't think it has a lot of value.
I'm not in the business of maintaining Zope 3 myself; I mainly care about how Grok uses it, and how I can integrate libraries in the ecosystem into my apps.
The Zope Toolkit includes components in common use by Grok, Zope 2, and Zope 3.
The Zope 3 project always attempted to be far more than just being a bunch of libraries. It attempted to be a system you can install and find documentation for and start developing with. When you install it, you see a user interface. It had a group of people who cared about it that you could talk to. There are a lot of concepts associated with Zope 3.
What I'm trying to do is to separate these concepts, which is why we're going through some confusion.
The Zope Toolkit is something that doesn't have an installation story for the whole. It does have some documentation about the whole: how it is developed primarily. But instead of having documentation for the whole ("Build your app with the Zope Toolkit, here's how to get started!" is not going to be there), it will focus on documentation about how to use the individual libraries. It leaves how to use it as an integrated whole to other projects. The Zope Toolkit has implementations of content objects such as the container. It doesn't have a user interface; it just has a way to construct user interfaces.
The Zope Toolkit is there to serve the people who use it. That's people who use a large range of these libraries, or just some of them, and projects that build on top of these libraries.
The question at hand is whether people care about a project that presents itself as a "whole", uses a lot of the Zope Toolkit, and has an installation story (and possibly a user interface), and that isn't Grok or Zope 2, but like Zope 3. If so, we could have a Zope 3 project that cares about those things (naming discussion aside).
Yes, absolutly. I will help to support such a Zope Toolkit management app which will allow to get rid of the zmi part. Regards Roger Ineichen
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 )
On Tue, Apr 14, 2009 at 16:46, Jim Fulton <jim@zope.com> wrote:
Many people have said they're using the Zope 3 app server, where app server is the collection of components used to run applications using Zope 3 components.
What no one is interested in is the *application* that was distributed in the Zope 3 distribution. [...] What definition of "app server" are we using?
What the heck is the "Zope Toolkit"? Is there a page somewhere that defines what it is? I thought Zope 3 was being renamed "Zope Toolkit", but given recent discussions, I'm not sure.
Just the fact that this confusion of terminology, and that nobody means the same thing with "Zope 3" is in itself a strong indicator that Zope 3 should die. That may only mean the *name* Zope 3. It apparently means nothing an everything, and is still causing confusion. Stephan Richter has says he is willing to maintain Zope 3, whatever he means with that. :-) I think that's great. But I think it would be a good thing if it is renamed. To what should reasonably be up to Stephan. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Hanno Schlichting wrote:
By now I count three people using Zope 3 for a small number of projects. But none of them seems to have the resources to continue the maintenance or future development of Zope 3.
Whilst you're absolutely right, just a word of warning: a lot of people do not read mailing lists regularly or feel compelled to participate in them. This is the zope-dev list, which means that it's read primarily by Zope developers. If you're trying to gauge *users* of Zope 3, then the zope-user list may be a more appropriate place to ask, and even then, don't assume you'll get a representative sample of actual users. martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Aspeli wrote:
Hanno Schlichting wrote:
By now I count three people using Zope 3 for a small number of projects. But none of them seems to have the resources to continue the maintenance or future development of Zope 3.
Whilst you're absolutely right, just a word of warning: a lot of people do not read mailing lists regularly or feel compelled to participate in them. This is the zope-dev list, which means that it's read primarily by Zope developers. If you're trying to gauge *users* of Zope 3, then the zope-user list may be a more appropriate place to ask, and even then, don't assume you'll get a representative sample of actual users.
We aren't asking non-developer users for opinions: this is about how we allocate scarce resources (our time), and how to organized the branding such that *we* have a clear story to present. As is typical of open source projects, the only folks who get to vote are the ones who contribute effort. Folks who are just consuming the product can go on using the existing branded things (Grok, Zope2, Zope3-as-released-today). They may not be able to *upgrade* their Zope3 apps without some effort, depending on how this discussion goes. One outcome of this discussion is almost certainly going to be that we tell current and prospective users that we aren't using the name "Zope3" any longer as a brand (with its implications of replacing Zope2). In some ways, this discussion is like the Plone developers" "platform vs. application" debate (which isn't yet resolved AFAIK). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ5foh+gerLs4ltQ4RAvXTAJ9HGkqIgM3T0KYmcdmItmGRvP4a1wCgmAzK +XkEsDIDQr8Sc3QGHC4dG98= =fyn6 -----END PGP SIGNATURE-----
Hey, Tres Seaver wrote: [snip]
Folks who are just consuming the product can go on using the existing branded things (Grok, Zope2, Zope3-as-released-today). They may not be able to *upgrade* their Zope3 apps without some effort, depending on how this discussion goes. One outcome of this discussion is almost certainly going to be that we tell current and prospective users that we aren't using the name "Zope3" any longer as a brand (with its implications of replacing Zope2).
This remains to be seen. My main goal with this discussion was to figure out who wants to *maintain* the concept of a Zope 3 as a "whole" you can talk about and install and that may or may not have some ZMI. We found out there is a concept of "high-maintenance" (maintaining the code and the community) and "low-maintenance" (maintaining the code so it still works). People are quite interested in low-maintenance but not very interested in the high-maintenance proposition. The main tasks of such maintainers will be to make sure things can be installed, continue to work with newer versions of libraries in the Zope Toolkit, and perhaps to preserve the ZMI in some form. Most of the tasks will be out of their hands and will be done in the context of the Zope Toolkit. So, we appear to have some stakeholders and maintainers. Good. They need to talk to each other and get organized. Separate from this discussion is whether this thing should be *called* Zope 3 or be renamed to someone else. Unless someone plausible stands up and says "I'm the Zope 3 maintainer and we're going to call it X" I'd like to let the dust settle for a bit and continue with that discussion later. Give those who are interested in maintaining Zope 3 some time to organize and adjust first. Regards, Martijn
Tres Seaver wrote:
We aren't asking non-developer users for opinions: this is about how we allocate scarce resources (our time), and how to organized the branding such that *we* have a clear story to present. As is typical of open source projects, the only folks who get to vote are the ones who contribute effort.
I was referring to the fact that some people seem to be drawing conclusions about the number of *users* of Zope 3 (in various shapes) from this thread.
In some ways, this discussion is like the Plone developers" "platform vs. application" debate (which isn't yet resolved AFAIK).
It's a platfication! Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On Mon, Apr 13, 2009 at 12:49, Hermann Himmelbauer <dusty@qwer.tk> wrote:
I personally find it interesting that people are that fast with turning around and killing off things. I personally based my decision for Zope 3 on Philipps book ("Web Compontent Development with Zope 3"), whereas the latest edition came out just 1 year ago. I adapted the concepts in this book to my needs (e.g. by using z3c-based packages) and it's now a viable way for me and my projects.
It might be important to point out that this book will continue to be relevant. That book is about ho to develop with the Zope Toolkit, except that it didn't exist when it was written, not even as a concept. Zope 3 was then a monolithic server. It isn't any more. The answer is if somebody wants to maintain the Zope 3 Applictation server, and go on to release a Zope 3.5, 3.6 etc. The libraries will be maintained, and Zope 3 will continue to work for a long time, and bugfixes will happen, even if no releases are done. And we don't need to declare it dead in any way. If nobody steps up to be the next Zope 3 maintainer, then it *is* dead, even if it isn't declared so, and even if we don't want it to be dead. Open source is driven by what people do. If nobody wants to maintain Zope 3, then it will not get any more releases, no matter if we want it to be dead or not.
I understand that people like Zope 2 for historical reasons and Grok for it's simplicity, but I would really wonder that there's no target audience for various ideas/patterns in Zope 3 (security model, ZCML...).
There is, but those who prefer ZCML over Grok seems to gravitate towards BFG as opposed to Zope 3.
Moreover, I expect that there are many people like me, who started with Zope 3 with Philipp's book, so, would we really want to - ummm - "declare them dead"?
It's extremely important to understand the differences between Zope 3, and Zope 3 technologies. The only thing that looks dead is Zope 3 as a big monolithic application server. Few people are interested in that. You seem to be. Hence the question: Who wants to maintain it. Do you?
If we do so, to my mind there has to be some migration path to something else, may it be Repoze, or whatever. But just killing off Zope 3 is like saying "Sorry guys, you just chose the wrong technology."
See, this is the naming problem. You did not chose the wrong technology. You didn't even chose the wrong app server, because there wasn't any choice. Now there is: Zope 3, Grok & BFG. All using the same technology. So far you are one of the few having any interest in Zope 3. Up until this thread, nobody showed any interest. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On 4/13/09 10:33 AM, Lennart Regebro wrote:
I understand that people like Zope 2 for historical reasons and Grok for it's simplicity, but I would really wonder that there's no target audience for various ideas/patterns in Zope 3 (security model, ZCML...).
There is, but those who prefer ZCML over Grok seems to gravitate towards BFG as opposed to Zope 3.
I'll note that you need to write only 1 line of ZCML in BFG to write most BFG applications (the line that tells BFG to scan a package for decorators). BFG is not at all like Zope 3 in this respect. BFG actually uses Grok's "martian" package to help with the one common case of declaring an adapter (a view adapter). BFG app developers are not really expected to interact with the ZCA via adapter and utility lookups (APIs are provided on top of every other use of the CA by the famework), so essentially you can write most applications in BFG without knowing anything about interfaces, adapters, or the ZCA at all. That said, I'm personally not ZCML-hostile, and as a result I write applications on top of BFG which have lots of ZCML in them. But that's not as a result of the framework; it's an result of how I like to write applications. - C
Am Montag 13 April 2009 16:33:02 schrieb Lennart Regebro:
On Mon, Apr 13, 2009 at 12:49, Hermann Himmelbauer <dusty@qwer.tk> wrote:
I personally find it interesting that people are that fast with turning around and killing off things. I personally based my decision for Zope 3 on Philipps book ("Web Compontent Development with Zope 3"), whereas the latest edition came out just 1 year ago. I adapted the concepts in this book to my needs (e.g. by using z3c-based packages) and it's now a viable way for me and my projects.
Yes, that's certainly true. But it is probably quite unlikely that people step up to do so, in case key developers communicate "kill it off / declare it dead", instead of people pointing out that it's actually still used.
Moreover, I expect that there are many people like me, who started with Zope 3 with Philipp's book, so, would we really want to - ummm - "declare them dead"?
It's extremely important to understand the differences between Zope 3, and Zope 3 technologies. The only thing that looks dead is Zope 3 as a big monolithic application server. Few people are interested in that. You seem to be. Hence the question: Who wants to maintain it. Do you?
Unfortunately, I'm not in the position to do so. (Lack of time, not enough experience)...
So far you are one of the few having any interest in Zope 3. Up until this thread, nobody showed any interest.
That's why I have spoken up. And I'd really wonder if I'm the only one. 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: [snip]
It's extremely important to understand the differences between Zope 3, and Zope 3 technologies. The only thing that looks dead is Zope 3 as a big monolithic application server. Few people are interested in that. You seem to be. Hence the question: Who wants to maintain it. Do you?
Unfortunately, I'm not in the position to do so. (Lack of time, not enough experience)...
Everybody thinks they lack the time and the experience. If a few of those people got together and found out a way to work together, you could do a lot. Especially since the Zope Toolkit is actually maintaining most of the code involved. You'd just need to take care that the ZMI still works, that there's a way to install Zope 3, and that there's some documentation for people who want to use Zope 3 too. Regards, Martijn
Roger Ineichen wrote:
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.
Really? I don't care about this particular UI at all..
* 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.
-> grok, plone, repoze.bfg
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?
NO. Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roger Ineichen wrote:
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?
I'm not sure what you mean by "browser page pattern." BFG uses a ZCML directive which looks a bit like the classic Z3 one: <bfg:view for=".models.MyModel" view=".views.my_model_view" name="some_name.html" permission="view" /> or the equivalent decorator: @bfg_view(name='some_name.html', for_=MyModel permission='view') def my_model_view(context, request): return render_template_to_response('templates/my_view.pt') It avoids the "catll the factory, the call the result" dance of classic Z3 views, as well as the need to dummy up a view class behind the scenes. I don't think there is much in common here at the implementation level (although the ZCML spelling is fairly close).
Everybody needs to have at least management views for manage the components they install in some ways.
The "Python web frameworks" (Pylons, TurboGears, BFG) don't configure their applications "inside" a container supplied by the appserver: they wire them in via an external configuration mechanism (e.g., a Paste INI file, or a script called at startup). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ4Nms+gerLs4ltQ4RAssVAKCYocUk/s+Kkvi4w9Lmw5OQDBADKwCgyuUJ cWjourA6u+3DsAS287zngK4= =aARY -----END PGP SIGNATURE-----
Hey, Roger Ineichen wrote:
* 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.
I don't need the UI part myself for many applications. It'd be nice to have a common UI for managing utilities and such at some stage, but I see this as a project separate from Zope 3 . (it could be part of a Grok UI for instance in the case of Grok)
* 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.
Don't forget that an actual starting point for newcomers needs documentation, preferably on some web site. Grok and repoze.bfg do a decent job in that department. I don't think there should be a starting point to start developing with the "Zope Toolkit" by itself. If people want another starting point that's more similar to traditional Zope 3 they should create one, but I don't think it should be called Zope 3. "zopeproject" is a rather ambiguous name as well...
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?
I think there is significant overlap between Plone and Grok (and traditional Zope 3 setups). I'd be happy to move Grok to a common directory layout. To my knowledge they're all using paster now. repoze I'm not sure about, as it doesn't use buildout as its standard way to install. I think that at most the Zope Toolkit can support libraries and methodologies that help with installation, not the whole tool itself. Grok for instance will still need to maintain its own installation tool, but the tool could delegate some work to shared libraries. [snip]
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?
I don't understand this question. You can already use Grok's views in Zope 3 projects, and in Zope 2 projects as well if you install five.grok, as far as I'm aware. bfg is quite different in its approach, so I'm not sure there. But this seems to be another discussion altogether? Regards, Martijn
Martijn Faassen wrote:
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.
Yes, but I'd like to *ban* the name ZMI, that is a Zope 2 construct and should be left as such... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Hi I have a couple of questions about "Zope 3" rather than Zope Toolkit, as it seems not many people are using Zope 3 the application server. I have been working on a project using Zope 3 (the app server ) for nearly 8 months . The project is not finished (other stuff keeps coming up which distracts the group ) but it is a fair way along. We are using Zope 3 pretty much as it comes from zopeproject, and storm orm for a large part of the persistence layer (plus ZODB). We decided to go down this path because we wanted the full security model from zope3, and it seemed to harder to work with that pure model within grok at the time. We use the zmi on and off just as a short cut for quick and dirty object viewing, but are building a completely different UI based around YUI. It seems from all the discussion of late that we might of chosen a architectural dead end (though I don't think so). If someone where coming to the Zope party now and needed the full blown security model and view mechanisms, and the zcml tied to that model what would the choice be going forward? repoze.bfg has pretty much gutted that model (which is fine as a simpler model is definately required, I am planning to revisit bfg with my zope on gae work) grok sort of fell in a whole for us when we started the project as it wasn't obvious how to go about doing the full security model etc... (mainly I think because a lack of docs etc... when we made our decision) Any thoughts on this decision, direction that we have taken, and what if could be the alternative if the Zope 3 app server itself withered? Rgds Tim Hoffman
On 4/11/09 8:10 PM, Tim Hoffman wrote:
If someone where coming to the Zope party now and needed the full blown security model and view mechanisms, and the zcml tied to that model what would the choice be going forward?
repoze.bfg has pretty much gutted that model (which is fine as a simpler model is definately required, I am planning to revisit bfg with my zope on gae work)
As far as I know, the only bit that BFG doesn't have out of the box (or at least in combination with an authentication system like repoze.who) that Zope 2 or Zope 3 does is the concept of allowing untrusted users to write code (e.g. "TTW code"). All other concepts present in Zope 2/3 that I know of can be composed using the out-of-the-box BFG primitives of context-sensitive security (via ACLs attached to model objects), view permissions, and principals. Because the only code that is published to the web within BFG is view code, no other security is required for "belt and suspenders"; for example, you don't need to protect model methods because there's just no way they'll be invoked within a BFG application. For more information, see http://docs.repoze.org/bfg/narr/security.html . - C
Hi Chris can I specify security annotations on objects persisted in the zodb as per zope3/zope2 which are over and above the class/view decleration. bfg wasn't around when we started so I have looked too closely at bfg from security point of view T On Sun, Apr 12, 2009 at 9:14 AM, Chris McDonough <chrism@plope.com> wrote:
On 4/11/09 8:10 PM, Tim Hoffman wrote:
If someone where coming to the Zope party now and needed the full blown security model and view mechanisms, and the zcml tied to that model what would the choice be going forward?
repoze.bfg has pretty much gutted that model (which is fine as a simpler model is definately required, I am planning to revisit bfg with my zope on gae work)
As far as I know, the only bit that BFG doesn't have out of the box (or at least in combination with an authentication system like repoze.who) that Zope 2 or Zope 3 does is the concept of allowing untrusted users to write code (e.g. "TTW code").
All other concepts present in Zope 2/3 that I know of can be composed using the out-of-the-box BFG primitives of context-sensitive security (via ACLs attached to model objects), view permissions, and principals. Because the only code that is published to the web within BFG is view code, no other security is required for "belt and suspenders"; for example, you don't need to protect model methods because there's just no way they'll be invoked within a BFG application.
For more information, see http://docs.repoze.org/bfg/narr/security.html .
- C
On 4/11/09 10:20 PM, Tim Hoffman wrote:
Hi Chris
can I specify security annotations on objects persisted in the zodb as per zope3/zope2 which are over and above the class/view decleration.
Yes, for instance, in some code that manipulates a persistent object, you can do something like: from repoze.bfg.security import Authenticated from repoze.bfg.security import Allow blogentry.__acl__ = [(Allow, 'fred', 'edit'), (Allow, Authenticated, 'view')] When that object (or one of its children) becomes the "context" of a view (maybe when you traverse to a URL which represents the blog entry object's default view), the combination of the view's permission and the principals attached to the request is compared against the object's ACL. Access is allowed or denied. For example: from repoze.bfg.view import bfg_view from mypackage.interfaces import IBlogEntry @bfg_view(for_=IBlogEntry, permission='edit') def blogentry_edit_view(context, request): ... ... only a principal named 'fred' would be allowed to invoke this view if 'context' was the blogentry you attached the above ACL to. There is an "acquisition" model for ACLs which looks at the parents of the context in the model graph (often up a tree of persistent objects) to find an ACL if one is not defined on the context. - C
Ok so pretty much the same as the traditional Zope 3 model. Are you still using the 'c' based zope.security or built your own. On a side note I have got a big chunk of zope3 running on gae (had to gut zope.security and zope.proxy) and plan on revisiting the whole effort looking at bfg, but I would need to revert to zpt because cheetah is dependant on lxml and its no 'c' for me, any suggestions or ideas on the effort involved. (I have zpt running with similiar functionality to zope.app.pagetemplate level rather thatn zope.pagetemplate) with full macro lookups etc.... Thanks for the info T On Sun, Apr 12, 2009 at 11:23 AM, Chris McDonough <chrism@plope.com> wrote:
On 4/11/09 10:20 PM, Tim Hoffman wrote:
Hi Chris
can I specify security annotations on objects persisted in the zodb as per zope3/zope2 which are over and above the class/view decleration.
Yes, for instance, in some code that manipulates a persistent object, you can do something like:
from repoze.bfg.security import Authenticated from repoze.bfg.security import Allow blogentry.__acl__ = [(Allow, 'fred', 'edit'), (Allow, Authenticated, 'view')]
When that object (or one of its children) becomes the "context" of a view (maybe when you traverse to a URL which represents the blog entry object's default view), the combination of the view's permission and the principals attached to the request is compared against the object's ACL. Access is allowed or denied. For example:
from repoze.bfg.view import bfg_view from mypackage.interfaces import IBlogEntry
@bfg_view(for_=IBlogEntry, permission='edit') def blogentry_edit_view(context, request): ...
... only a principal named 'fred' would be allowed to invoke this view if 'context' was the blogentry you attached the above ACL to.
There is an "acquisition" model for ACLs which looks at the parents of the context in the model graph (often up a tree of persistent objects) to find an ACL if one is not defined on the context.
- C _______________________________________________ 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 )
On 4/11/09 11:49 PM, Tim Hoffman wrote:
Ok so pretty much the same as the traditional Zope 3 model.
Are you still using the 'c' based zope.security or built your own.
We don't depend on zope.security and there is no C in the BFG security code itself.
On a side note I have got a big chunk of zope3 running on gae (had to gut zope.security and zope.proxy) and plan on revisiting the whole effort looking at bfg, but I would need to revert to zpt because cheetah
Chameleon, I think you mean.
is dependant on lxml and its no 'c' for me, any suggestions or ideas on the effort involved. (I have zpt running with similiar functionality to zope.app.pagetemplate level rather thatn zope.pagetemplate) with full macro lookups etc....
Malthe has expressed interest in removing the lxml dependency from Chameleon, but I think he needs funding. Others have also expressed an interest in this and we'd probably kick in to a pool of funds towards this if you ever get to a point where it became something you wanted to do. I really don't know how much effort is involved, but for the record, Chameleon only depends relatively shallowly on lxml (mostly for xpath expressions), and removing lxml will make no difference in rendering speed. - C
Hi Chris On Sun, Apr 12, 2009 at 11:55 AM, Chris McDonough <chrism@plope.com> wrote:
On 4/11/09 11:49 PM, Tim Hoffman wrote:
Ok so pretty much the same as the traditional Zope 3 model.
Are you still using the 'c' based zope.security or built your own.
We don't depend on zope.security and there is no C in the BFG security code itself.
On a side note I have got a big chunk of zope3 running on gae (had to gut zope.security and zope.proxy) and plan on revisiting the whole effort looking at bfg, but I would need to revert to zpt because cheetah
Chameleon, I think you mean.
Oops yeah! ;)
is dependant on lxml and its no 'c' for me, any suggestions or ideas on the effort involved. (I have zpt running with similiar functionality to zope.app.pagetemplate level rather thatn zope.pagetemplate) with full macro lookups etc....
Malthe has expressed interest in removing the lxml dependency from Chameleon, but I think he needs funding. Others have also expressed an interest in this and we'd probably kick in to a pool of funds towards this if you ever get to a point where it became something you wanted to do. I really don't know how much effort is involved, but for the record, Chameleon only depends relatively shallowly on lxml (mostly for xpath expressions), and removing lxml will make no difference in rendering speed.
ok but I assume it's not too much of a problem to swap out chameleon altogther in the meantime and go back to zpt (unfortunately I don't have money for this project ;-( Again thanks for the info. My plan to is to rollout a small site I am building in zope3 on gae, and then go back and do a major refactor on what I have learnt, and look at bfg as the model going forward. Cheers Tim
On 4/12/09 12:02 AM, Tim Hoffman wrote:
Hi Chris
On Sun, Apr 12, 2009 at 11:55 AM, Chris McDonough<chrism@plope.com> wrote:
On 4/11/09 11:49 PM, Tim Hoffman wrote:
Ok so pretty much the same as the traditional Zope 3 model.
Are you still using the 'c' based zope.security or built your own. We don't depend on zope.security and there is no C in the BFG security code itself.
On a side note I have got a big chunk of zope3 running on gae (had to gut zope.security and zope.proxy) and plan on revisiting the whole effort looking at bfg, but I would need to revert to zpt because cheetah Chameleon, I think you mean.
Oops yeah! ;)
is dependant on lxml and its no 'c' for me, any suggestions or ideas on the effort involved. (I have zpt running with similiar functionality to zope.app.pagetemplate level rather thatn zope.pagetemplate) with full macro lookups etc.... Malthe has expressed interest in removing the lxml dependency from Chameleon, but I think he needs funding. Others have also expressed an interest in this and we'd probably kick in to a pool of funds towards this if you ever get to a point where it became something you wanted to do. I really don't know how much effort is involved, but for the record, Chameleon only depends relatively shallowly on lxml (mostly for xpath expressions), and removing lxml will make no difference in rendering speed.
ok but I assume it's not too much of a problem to swap out chameleon altogther in the meantime and go back to zpt (unfortunately I don't have money for this project ;-(
Yeah, that's really no problem. As long as you have C-free versions of zope.interface and zope.proxy laying around already (which is really just a matter of preventing those packages' C code from compiling I think), getting BFG running on GAE without Chameleon really just should be a matter of removing the lxml dependency from the setup.py of bfg itself.
Again thanks for the info.
My plan to is to rollout a small site I am building in zope3 on gae, and then go back and do a major refactor on what I have learnt, and look at bfg as the model going forward.
Sounds like a plan... I hope to learn from what you do to get rid of some non-lxml C dependencies we have too (ala zope.interface, zope.proxy, zope.hookable, zope.i18nmessageid, etc); maybe we can fold some of this work into the normal or alternate version of these packages. - C
Hey, Chris McDonough wrote: [snip]
Sounds like a plan... I hope to learn from what you do to get rid of some non-lxml C dependencies we have too (ala zope.interface, zope.proxy, zope.hookable, zope.i18nmessageid, etc); maybe we can fold some of this work into the normal or alternate version of these packages.
Please, the normal versions if at all possible. Tres already did a lot of work on zope.component to remove these dependencies from that. We'll have to make all of these packages work without C dependencies, not just for GAE but also for porting to other Python interpreters. Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris McDonough wrote:
On 4/11/09 11:49 PM, Tim Hoffman wrote:
Ok so pretty much the same as the traditional Zope 3 model.
Are you still using the 'c' based zope.security or built your own.
We don't depend on zope.security and there is no C in the BFG security code itself.
BFG doesn't support the notion of "untrusted" code, and hence doesn't need the "space suits" provided in C by zope.securty / zope.proxy.
On a side note I have got a big chunk of zope3 running on gae (had to gut zope.security and zope.proxy) and plan on revisiting the whole effort looking at bfg, but I would need to revert to zpt because cheetah
Chameleon, I think you mean.
is dependant on lxml and its no 'c' for me, any suggestions or ideas on the effort involved. (I have zpt running with similiar functionality to zope.app.pagetemplate level rather thatn zope.pagetemplate) with full macro lookups etc....
Malthe has expressed interest in removing the lxml dependency from Chameleon, but I think he needs funding. Others have also expressed an interest in this and we'd probably kick in to a pool of funds towards this if you ever get to a point where it became something you wanted to do. I really don't know how much effort is involved, but for the record, Chameleon only depends relatively shallowly on lxml (mostly for xpath expressions), and removing lxml will make no difference in rendering speed.
It might even be easiest to ship an app (as opposed to developing it) with the generated python code on disk, and configure it not to regenerate at all: at that point, lxml would be a "build-time" dependency. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ4gkV+gerLs4ltQ4RArwfAKDLfbxPDe6Q+XGgNAGS3hULmxLgugCg3Dp4 TzU7EVswrEIgyFHbm/sWRz4= =hd/E -----END PGP SIGNATURE-----
Hey, Tim Hoffman wrote:
can I specify security annotations on objects persisted in the zodb as per zope3/zope2 which are over and above the class/view decleration.
I'll just note you can do this in Grok. Grok has per-model security declarations, just like Zope 3's. It just doesn't have model-level security *checks* - the only check happens on the view end. I'm not sure whether bfg does use security proxies at all or not (if so, apparently not zope.security's). Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:
Hey,
Tim Hoffman wrote:
can I specify security annotations on objects persisted in the zodb as per zope3/zope2 which are over and above the class/view decleration.
I'll just note you can do this in Grok. Grok has per-model security declarations, just like Zope 3's. It just doesn't have model-level security *checks* - the only check happens on the view end.
The stock security policy for BFG uses ACLs stored on model objects, and is willing to "acquire" them. The ACLs represent grant's or denials of permissions to principals. The BFG publisher uses the permission associated with the view to verify access to the view by the current principals. All in all, this part is very Zope-like.
I'm not sure whether bfg does use security proxies at all or not (if so, apparently not zope.security's).
Space-suits are only useful if you want to protect specific attributes or methods of model objects. BFG has no concept of untrusted code, and therefore doesn't use them. You *could* build a BFG-based application which used them (e.g., wrapping the root object in a space-suit at the beginning of publishing traversal); none of us need or want that. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ5fyH+gerLs4ltQ4RAhyYAKDTAJNQKd9y4NmT4PuZrCAEQy6CZgCgxFgO WdKQX3XsjmGYrF/LM3idcug= =AADT -----END PGP SIGNATURE-----
On Sun, Apr 12, 2009 at 02:10, Tim Hoffman <timh@zute.net> wrote:
We are using Zope 3 pretty much as it comes from zopeproject, and storm orm for a large part of the persistence layer (plus ZODB).
I have to say I think it's great that somebody that does this finally is speaking up. There shurely are more than you, but they have been silent in teh discussions, and it's important that your viewpoint isn't lost. I'm also happy you seem to have gotten good answers on how to go forward. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Tim Hoffman wrote: [snip]
It seems from all the discussion of late that we might of chosen a architectural dead end (though I don't think so).
It's definitely not an architectural dead-end. I think the codebase we used to call Zope 3 has been evolving faster in these few months in 2009 than it has in many years, and I hope to keep up this energy. It's just that most of that evolution is in the Zope Toolkit layer. I know that the Grok and Zope 2 people have functional mechanisms about maintaining the stuff they build on top of the Zope Toolkit (including writing documentation, etc). I want there to be awareness that we need people willing to chip in maintaining the Zope 3 bits too (and that we need to work on figuring out what these bits are). If people are *not* willing, there's a risk that it won't be maintained. It could also be that we decide to rename Zope 3 to something else (to get rid of some of the confusion with Zope 2), but that's a separate debate I think we should separate from this and we'll let that rest for a while.
If someone where coming to the Zope party now and needed the full blown security model and view mechanisms, and the zcml tied to that model what would the choice be going forward?
Zope 3.
repoze.bfg has pretty much gutted that model (which is fine as a simpler model is definately required, I am planning to revisit bfg with my zope on gae work)
grok sort of fell in a whole for us when we started the project as it wasn't obvious how to go about doing the full security model etc... (mainly I think because a lack of docs etc... when we made our decision)
Grok currently doesn't support the full-blown Zope 3 security model, though there's definitely a wide interest in adding this. It hasn't happened yet though - it just needs people to sit down and do it; I think it's fairly low hanging fruit.
Any thoughts on this decision, direction that we have taken, and what if could be the alternative if the Zope 3 app server itself withered?
If the Zope 3 app server withered, if you want compatibility with the existing story, I'd go for Grok + full security checks model, as I assume it *will* be created. If you don't need or want compatibility you could explore bfg. That said, I have good hopes (and doing my best) to make far more of the Zope Toolkit libraries stay relevant than just the small selection that BFG uses. After all, Grok and Zope 2 and presumably also Zope 3 in some form will still be around! I think the basic Zope 3 approach works pretty well (especially with Grok-style configuration) and I think there's quite a bit of evolution possible to make it a lot better (aggressive WSGI-ification and a much increased focus on user interface components are two areas I want to look into next) Regards, Martijn
Martijn Faassen wrote at 2009-4-10 18:33 +0200:
Is anyone interested in maintaining Zope 3?
You should leave a bit more time before you take any drastic actions... There are holidays, time of intensive other activity, ....
... * 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?
I find "http://apidoc.zope.org/++apidoc++/" very helpful -- for Zope 2 users. I would not like to loose it.... -- Dieter
Dieter Maurer wrote:
Martijn Faassen wrote at 2009-4-10 18:33 +0200:
Is anyone interested in maintaining Zope 3?
You should leave a bit more time before you take any drastic actions...
There are holidays, time of intensive other activity, .....
It'll take time before we all settle on a reasonable way of working, and before everybody has understood what the new way is. That's what I'm trying to do: we're in the process of changing the way this community works. That takes time, but also continuous steps forward. We'll take a gradual path to drastic changes. :)
... * 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?
I find "http://apidoc.zope.org/++apidoc++/" very helpful -- for Zope 2 users. I would not like to loose it....
Agreed. Nobody is proposing we lose it. It's also on docs.zope.org/zope3 - I wonder if there's a difference. But Zope 3 needs more than just api documentation. api documentation is useful but not sufficient to support developers and users that aren't experienced already. It needs something like grok.zope.org, telling people what Zope 3 is about, and how to start using it. Concerning apidoc, I think we should explore how we could make apidoc work without as many dependencies as it pulls in now, though in its very nature it will have to pull in many. It might also be interesting to explore how we could use apidoc in a different way, where instead of supplying api docs for "full stack" system we can do it library-by-library. apidoc right now serves a dual purpose: API provide documentation for the libraries, and an introspector to look at the actual state of the system, whatever is installed.. We should also look about how we can make the individual libraries and apidoc stop talking about "Zope 3" where they do, and just reference the "Zope Toolkit" or not Zope at all. Regards, Martijn
On Fri, Apr 10, 2009 at 11:33 AM, Martijn Faassen <faassen@startifact.com> wrote:
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.
Does Zope Tookit support building a web application out of the box without relying on Grok, Zope 2 or any other framework ? (I am Ok to use a Buildout for building application from Zope Toolkit packages) If the answer to this question is "No", then I am interested to maintain the packages necessary to create a simple application out of the box. This is just an academic interest :) Regards, Baiju M
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Baiju M wrote:
On Fri, Apr 10, 2009 at 11:33 AM, Martijn Faassen <faassen@startifact.com> wrote:
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.
Does Zope Tookit support building a web application out of the box without relying on Grok, Zope 2 or any other framework ? (I am Ok to use a Buildout for building application from Zope Toolkit packages)
If the answer to this question is "No", then I am interested to maintain the packages necessary to create a simple application out of the box. This is just an academic interest :)
I would say that the answer is "no". Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ44d0+gerLs4ltQ4RAimzAJ9fm2W/V8R44AjXoa/wEOmVNWBJ6gCePSkc wJudZQswGVm1IL4ntjPrdnQ= =9ZTG -----END PGP SIGNATURE-----
Hey, Baiju M wrote: [snip]
Does Zope Tookit support building a web application out of the box without relying on Grok, Zope 2 or any other framework ? (I am Ok to use a Buildout for building application from Zope Toolkit packages)
This is a very good question. My answer is "no, it doesn't". It might support tools to help construct such "out of the box" experiences, but it won't be something you can install and just get started with unless you really want to roll your own framework.
If the answer to this question is "No", then I am interested to maintain the packages necessary to create a simple application out of the box. This is just an academic interest :)
Great! We should definitely have Zope 2 and Plone and Grok and Zope 3 work together and share experience. I have the feeling each project is working isolated from each other now, and with Grok we're moving to paste and I just have the feeling we're inventing some of our own wheels that could be shared, or alternatively that we shouldn't be doing that way. Currently for instance we generate "debug.ini" and such and put them in "parts" as they have hardcoded path names. That can't be right... Regards, Martijn
Hi Martijn
-----Ursprüngliche Nachricht----- Von: zope-dev-bounces@zope.org [mailto:zope-dev-bounces@zope.org] Im Auftrag von Martijn Faassen Gesendet: Dienstag, 14. April 2009 17:54 An: zope-dev@zope.org Betreff: Re: [Zope-dev] who wants to maintain Zope 3?
Hey,
Baiju M wrote: [snip]
Does Zope Tookit support building a web application out of the box without relying on Grok, Zope 2 or any other framework ? (I am Ok to use a Buildout for building application from Zope Toolkit packages)
This is a very good question. My answer is "no, it doesn't". It might support tools to help construct such "out of the box" experiences, but it won't be something you can install and just get started with unless you really want to roll your own framework.
If the answer to this question is "No", then I am interested to maintain the packages necessary to create a simple application out of the box. This is just an academic interest :)
Great!
We should definitely have Zope 2 and Plone and Grok and Zope 3 work together and share experience. I have the feeling each project is working isolated from each other now, and with Grok we're moving to paste and I just have the feeling we're inventing some of our own wheels that could be shared, or alternatively that we shouldn't be doing that way. Currently for instance we generate "debug.ini" and such and put them in "parts" as they have hardcoded path names. That can't be right...
Take a look at the z3c.recipe.paster:serve recipe You can define your WSGI app in a buildout.cfg file like: [app] recipe = z3c.recipe.paster:serve eggs = MYPYPI ini = [filter-app:main] use = egg:Paste#translogger next = zope [app:zope] use = egg:MYPYPI fsStorage = ${buildout:directory}/parts/fsstorage tmpStorage = ${buildout:directory}/parts/tmpstorage [server:main] use = egg:Paste#http host = localhost port = 8080 zope.conf = ${var:zconfig} devmode on <eventlog> <logfile> formatter zope.exceptions.log.Formatter path ${buildout:directory}/parts/logs/error.log </logfile> <logfile> formatter zope.exceptions.log.Formatter path STDOUT </logfile> </eventlog> site.zcml = <configure xmlns="http://namespaces.zope.org/zope" xmlns:meta="http://namespaces.zope.org/meta"> <meta:provides feature="devmode" /> <include package="mypypi" file="app.zcml" /> </configure> after run buildout you can call bin/app Regards Roger Ineichen _____________________________ END OF MESSAGE
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 )
On Friday 10 April 2009, Martijn Faassen wrote:
Is anyone interested in maintaining Zope 3?
I am and anyone not using Grok or BFG should be. The Zope 3 KGS maintains package compatibilities that reach beyond the Zope 3 Toolkit. For example, it maintains compatibility over a very large set of z3c packages.
With Zope 3 I mean:
* the thing with the ZMI - do you care about the ZMI?
I think boxing in Zope 3 being the ZMI app is not useful. I have not used the ZMI since 2 years now and I am still considering myself writing Zope 3 apps.
* 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 installation story today is: Roll your own configuration of ZCML.
* 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?
I am not interested about that. Again, I think Zope 3, the set of packages, which is a superset of the Toolkit KGS is very important to maintain. I think even for Grok people, since the exposed z3c libraries are widely useful. I have no problem keeping the Zope 3 KGS releases alive. Sooner or later we should stop the large TAR ball releases though. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Hey, Stephan Richter wrote:
On Friday 10 April 2009, Martijn Faassen wrote: [snip]
With Zope 3 I mean:
* the thing with the ZMI - do you care about the ZMI?
I think boxing in Zope 3 being the ZMI app is not useful. I have not used the ZMI since 2 years now and I am still considering myself writing Zope 3 apps.
The reason for the unpacking of terminology I did here was exactly to unbox the ZMI. If the ZMI isn't relevant to Zope 3 we should say so, and act on it, not keep it on indefinitely. But it's what people see now when they first install Zope 3, and it's an awful large part of the code they see too. In our package refactoring we've been quite careful to try to keep the ZMI code working, leaving it behind in zope.app.* packages and such. If *nobody* is interested in maintaining this we could draw interesting conclusions about how to go forward with this stuff...
* 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 installation story today is: Roll your own configuration of ZCML.
And buildout, and so on. That's not really a story that people can find out about easily, can they?
* 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?
I am not interested about that.
Okay, so no "getting started" documentation for you.
Again, I think Zope 3, the set of packages, which is a superset of the Toolkit KGS is very important to maintain. I think even for Grok people, since the exposed z3c libraries are widely useful.
So we have different concepts surrounding Zope 3: important * something that presents itself to beginners in documentation and with an installation story. Something like what Grok does. * a set of packages (KGS) that is wider than the Zope Toolkit KGS. * the stuff that keeps your existing Zope 3 applications working.
I have no problem keeping the Zope 3 KGS releases alive. Sooner or later we should stop the large TAR ball releases though.
Oh, yeah, in my opinion the tarball releases should be stopped today. I mean, we've released Zope 3.4, no more tall ball releases after this, please! Regards, Martijn
On Fri, Apr 10, 2009 at 06:33:51PM +0200, Martijn Faassen wrote:
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?
You are using an interesting definition of "maintaining". While I'm not interested in documentation or maintaining the installation story on any platform, that is attracting new users, I'm very interested that existing applications that use the the zope.app server remain usable with future versions of Zope Toolkit libraries, or Zope 3 KGS if you will. That's what I would call maintenance. I find it really bizarre how suddenly Zope 3 the app server has gone from new, better, up and coming, to nearly discontinued evolutionary dead end. Albertas
Hey, Albertas Agejevas wrote: [snip]
You are using an interesting definition of "maintaining".
This is why I spelled it out. But yes, if you maintain an open source project, and you want it to work well, you need to take care about issues like maintaining its community, which means documentation and an installation story and attracting new users. I hadn't realized people use a more limited form of "maintaining"; if you want your open source project to work you need to maintain the community, otherwise eventually all existing users will have left it.
While I'm not interested in documentation or maintaining the installation story on any platform, that is attracting new users, I'm very interested that existing applications that use the the zope.app server remain usable with future versions of Zope Toolkit libraries, or Zope 3 KGS if you will. That's what I would call maintenance.
That's definitely part of maintenance too.
I find it really bizarre how suddenly Zope 3 the app server has gone from new, better, up and coming, to nearly discontinued evolutionary dead end.
Well, perhaps because it wasn't maintained very well in my wider sense? It was never my intention to make Zope 3 go away though. I'm only separating that bit that many of us care about quite independently from "Zope 3 the project". There was a lot of disagreement about what it really was about. Regards, Martijn
participants (16)
-
Albertas Agejevas -
Baiju M -
Chris McDonough -
Chris Withers -
Dieter Maurer -
Hanno Schlichting -
Hermann Himmelbauer -
Jim Fulton -
Lennart Regebro -
Martijn Faassen -
Martin Aspeli -
Roger Ineichen -
Stephan Richter -
Tim Hoffman -
Tres Seaver -
Wichert Akkerman