Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
Hi 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 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
On Tue, Apr 14, 2009 at 16:46, Jim Fulton j...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
-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 tsea...@palladion.com Palladion Software Excellence by Designhttp://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- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
Hi Martijn
-Ursprüngliche Nachricht-
Von: zope-dev-boun...@zope.org
[mailto:zope-dev-boun...@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 )
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
Hi Martijn Betreff: 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 ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 faas...@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-...@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
On Mon, Apr 13, 2009 at 08:14, Dieter Maurer die...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
Hi Martin -Ursprüngliche Nachricht- Von: zope-dev-bounces+dev=projekt01...@zope.org [mailto:zope-dev-bounces+dev=projekt01...@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 ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
On Mon, Apr 13, 2009 at 12:49, Hermann Himmelbauer du...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
On Fri, Apr 10, 2009 at 11:33 AM, Martijn Faassen faas...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Baiju M wrote: On Fri, Apr 10, 2009 at 11:33 AM, Martijn Faassen faas...@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 tsea...@palladion.com Palladion Software Excellence by Designhttp://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- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
On Sun, Apr 12, 2009 at 02:10, Tim Hoffman t...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
On Sun, Apr 12, 2009 at 08:51, Dieter Maurer die...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
-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 tsea...@palladion.com Palladion Software Excellence by Designhttp://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- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
-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 tsea...@palladion.com
Palladion Software Excellence by Designhttp://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-
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
Hi 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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
Hi 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 chr...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 )
Re: [Zope-dev] who wants to maintain Zope 3?
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 chr...@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-...@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
Hi Chris On Sun, Apr 12, 2009 at 11:55 AM, Chris McDonough chr...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
On 4/12/09 12:02 AM, Tim Hoffman wrote: Hi Chris On Sun, Apr 12, 2009 at 11:55 AM, Chris McDonoughchr...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
Hi Martijn Betreff: [Zope-dev] who wants to maintain Zope 3? Hi there, Is anyone interested in maintaining Zope 3? With Zope 3 I mean: * the thing with the ZMI - do you care about the ZMI? Of corse do we all need the UI part for manage the components we install. But the old style ZMI views are obsolate this days. Right now we have to write this part for each project by ourself if they need to depend on z3c.form and z3c.pagelet. * the thing that can be installed as a particular development platform - do you care about the installation story for Zope 3? (as opposed to Grok or your own application's?) Yes, I don't use it but I think we should have something available as a starting point for newcomers. This could be something like zopeproject or a minimalistic setup with as less as possible zope.*, z3c.* and repoze packages. * the thing that has some kind of documentation website - do you care about providing documentation for Zope 3 as opposed to documentation for Grok or individual libraries? People who are interested in these aspects please speak up, so we can figure out what this all means for the future of Zope 3. I think we should take a look if we can build a minimal setup which Plone, Grok and other projects can use. Do you think there could be such a based configuration? Or is there to much difference in each of Plone, Grok, repoze etc? If nobody is interested, we should perhaps stop talking about it entirely. If people are just interested in the ZMI, perhaps we should form a ZMI project. The question is, can we find browser page pattern which Grok, Plone, repoze and others can use? Everybody needs to have at least management views for manage the components they install in some ways. So the question is not if we skip the ZMI or not. I think the question is can we improve and share such views in the different projects or do we have to develop views for each of them? Regards Roger Ineichen ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
