Re: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists
On 10/8/07, David Pratt [EMAIL PROTECTED] wrote: Hi Dieter. Zope 2 is one application among many dependent upon zope 3. Zope 3 is different software than zope 2. It has a community of pure zope 3 developers (that I don't believe the suggestion of folding the lists together adequately considers). Again, these lists are about the development of, not development with. There are indeed some people developing only Zope3 but not involved in Zope2. I don't think they are very many. There are none involved in Zope 2 that are not involved in Zope 3. More so, I get the impression that the unstated goal here is to assimilate zope 3 into a different notion of 'zope' It's not unstated, although admittedly, it is in my opinion off topic for the discussion. that would further obfuscate it as a framework Nope. (under the influence of zope2). Nope. Zope 3 stands on its own as a framework and I sure hope I am wrong about how I have been interpreting the dialog. You are indeed, yes. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] I'd lobe to merge the zope3-dev andzope-dev lists
Hi Lennart -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Lennart Regebro [...] Again, these lists are about the development of, not development with. Can you explain why do you think this makes a difference? Regards Roger Ineichen -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 ) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] I'd lobe to merge the zope3-dev andzope-dev lists
On 10/8/07, Roger Ineichen [EMAIL PROTECTED] wrote: Hi Lennart -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Lennart Regebro [...] Again, these lists are about the development of, not development with. Can you explain why do you think this makes a difference? Because developing WITH Zope2 and Zope 3 are very different. The development OF Zope 2 and Zope 3 are not, sincem as mentioned, the development OF Zope 2 is almost exclusively about getting more Zope 3 into Zope 2. The differences in community that is taken as a reason for keeping the lists separate simply do not exist anymore. There are no separate Zope 2 developers anymore. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: ZCML-Directive for DirectoryResource factories?
On 2007-10-05 14:30:14 +0200, Fred Drake [EMAIL PROTECTED] said: Meant to send this to the list... On 9/18/07, Christian Zagrodnick [EMAIL PROTECTED] wrote: The only thing is, no I'm not going to register every file in ZCML. I want to use the zc.resourcelibrary. The follwoing makes it possible, but it's not too nice to have that somewhere in the code: (zope.app.publisher.browser.directoryresource. DirectoryResource.resource_factories['.js']) = ( z3c.zrtresource.zrtresource.ZRTFileResourceFactory) I'd rather have a ZCML-directive to do that. Would that fit into zope.app.publisher? I think the right approach would be to make the new directive a sub-directive of the resourcelibrary and/or the resourcedirectory directive. Then there could be a separate extension - type map for each directory of resources. An alternative would be to allow the library or directory directive to refer to a map defined elsewhere (say, in Python), making it easier to re-use maps. This makes a lot of sense to me, since the provider of each pile of resources knows what they put in it and what the processing requirements are. A global map seems like a bad idea here. You are right, a local map would be much better. I basically came up with the global one, because its already there. But local sounds good. -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] I'd lobe to merge the zope3-dev andzope-dev lists
Hi Lennart Betreff: Re: [Zope3-dev] I'd lobe to merge the zope3-dev andzope-dev lists [...] Can you explain why do you think this makes a difference? Because developing WITH Zope2 and Zope 3 are very different. The development OF Zope 2 and Zope 3 are not, sincem as mentioned, the development OF Zope 2 is almost exclusively about getting more Zope 3 into Zope 2. The differences in community that is taken as a reason for keeping the lists separate simply do not exist anymore. There are no separate Zope 2 developers anymore. Ah, now I see your point. My motivation not to merge the dev lists is another one. I think many developer (500 subscribers) which develops with Zope 3 watches the Zope3-dev list and if they have questions, they will ask them on the zope3-users list. Hm, I think your mail also means, we can't avoid to have Zope 2 topics on the zope3-dev list because Zope 2 is going to move to Zope 3 and we have to exchange information. Doesn't matter how the list is called. Regards Roger Ineichen -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: The elevator speech for Zope 3
Oliver Marx wrote: Here is what I told my mother: Zope 3 is a web development technology that focuses on code reuse, automated testing and security. - Code reuse: we can do more in less time. - Automated testing: Code reuse makes it a much have. - And with automated testing we can actually prove that we implemented the security model we have agreed with our customers to use. Yup. Now let's drop the 3 in that sentence, because all of this applies to Zope software as a whole. This is, in fact, one way to sum up the way the Zope project as a whole works. What I told my mother is much much less important than what I didn't tell her. I did not use words like library, server, python, zodb, sql etc. Who are the people in the audience? Business people - yes Non-programmers (but still IT) - maybe Programmers (non-python) - more often that not Programmers (python) - yes Zope 3 core developers - never - already customers Zope 2 programmers - yes The audience consist of people who will never (or at least very seldom) become contributers to the Zope 3 stack!? Maybe we can learn from the javascript libraries? The first time you pick the whole package. Later when you have become more familiar with the library you only include the parts that you really need. But that is not how you start! Absolutely. Zope 3 should IMO have a click clack install version that makes the first little app a piece of cake. Add to that a story about flexibility and automated testing; then even I would buy it ;) http://cheeseshop.python.org/pypi/zopeproject is probably the fastest and easiest way to get started nowadays. One command and you're set up with a sandbox. If you haven't got Zope 3 downloaded yet, it will do so as well. It selects a set of libraries that are common in most applications and installs them by default. You can, of course, get rid of them later on. Then of course there's Grok (http://grok.zope.org) which builds on the Zope Libraries and aims at making it all much easier. It too has a click clack install along the lines of zopeproject; it's called grokproject. And a while ago, I demonstrated how you could create a TodoList application in 15 minutes with it: http://www.archive.org/details/grok_todo_part1. Note that Grok has evolved a bit since then and adding any kind of ZCML or working with the ZMI is unnecessary nowadays. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 releases?
Stephan Richter wrote: On Sunday 07 October 2007 17:13, Martijn Faassen wrote: I'm not saying an ecosystem approach is bad, if that's what Zope 3 wants to be. I do think that such an approach needs to be supplemented by a framework approach (and I've been putting work into one way to do that). Why? I have no need for anything on top of Zope 3. I just need to have stable sets of packages.= Because we have endless confusion between Zope 3 the ecosystem and Zope 3 the web application framework. If you go and make a separate Zope 3 the web application framework and you can get away with just writing a buildout.cfg, then be happy. Just call it something else, as otherwise people will confuse it a lot with the exploded Zope 3 libraries. They don't *have* to use this particular web framework in order to use Zope 3. They can also use Zope 2, or Grok. If Zope 3 is an ecosystem, a release of Zope 3 the ecosystem doesn't really make much sense. To follow the comparison with Linux distribution, it's more like a distribution of an ecosystem. I don't understand that sentence. If Zope 3 is like a linux distribution, we'll have to manage it like a linux distribution does. A linux distribution has releases, but it doesn't have releases of something individual you install and run. It just has semi-frozen ecosystems being released once every while. You can't do this and at the same time manage Zope 3 as an application, I think. It's an either-or. I'd therefore suggest that the release of Zope 3.4, if it ever actually happens, will be the last release of Zope 3 the application server framework. That would be really bad. Who defines stable sets then? Again, I think there is absolutely no need for another framework on top of Zope 3. The stable sets for the web application server are defined by those people who develop the Zope 3 web application server. The people who develop the web application server make choices that other users of Zope 3 technology might not make: perhaps to use Twisted for a web server. Perhaps to use paste for configuration, or *not* use paste for configuration. They might at some point decide that z3c.form is the default form framework that is documented in Zope 3 tutorials, instead of zc.formlib. Hopefully the users of the Zope 3 technology can work together on defining stable sets, but probably not for the entire range: Grok has some extra dependencies that Zope 2 may not have, and vice versa, for instance. The Zope 3 web application server is not primarily what the Zope 3 project appears to be developing. I strongly suspect there are more users of Zope 3 technology within the Plone community than outside it, for instance. If the Zope 3 project cared about developing a web server, you'd think it would do a somewhat better job presenting it to the outside world on a web page, and that there'd be more people to actually make releases? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 releases?
I'm not sure that library or collection of libraries is the right term for what we want to be. I think we've been using it because it stands in sharp contrast to application, which, BTW, isn't exactly what Zope 2 is. I think these terms were useful to make some points, but neither is accurate. FWIW, I have a fairly open mind on this topic. Lots of good points are being made. :) Jim On Oct 7, 2007, at 5:13 PM, Martijn Faassen wrote: Jim Fulton wrote: On Oct 7, 2007, at 6:25 AM, Lennart Regebro wrote: [snip] - We need a *realistic* (especially wrt available resources) process for managing releases. There are 2 aspects of this. We shouldn't make plans for which there aren't enough resources. We also shouldn't plan significant tasks that people won't care enough to work on. I think the classic Zope 3.4 release is a good example of a large effort that really wouldn't benefit many people, if any. Do you have a sort explanation on what is the missing resource? Is it, as it was for 3.3, lack of people-hours with knowledge in fixing the last bugs? I'm not entirely sure. I just observe that this doesn't seem to be making much progress. I think it's one of the drawbacks of taking an ecosystem/libraries approach instead of a application/framework style approach. An application or framework typically is an integrated whole that has a single version number. An ecosystem or set of libraries can be integrated (which Zope 3 is) but everything evolves at different rates and there's no single thing to install or talk about. I'm not saying an ecosystem approach is bad, if that's what Zope 3 wants to be. I do think that such an approach needs to be supplemented by a framework approach (and I've been putting work into one way to do that). If Zope 3 is an ecosystem, a release of Zope 3 the ecosystem doesn't really make much sense. To follow the comparison with Linux distribution, it's more like a distribution of an ecosystem. I'd therefore suggest that the release of Zope 3.4, if it ever actually happens, will be the last release of Zope 3 the application server framework. I hope that besides Grok, some community will stand up that takes a less radical approach to building an application server on top of the Zope 3 ecosystem. People having existing applications in Zope 3 to maintain (like myself with the Document Library) will have a need for it, and Grok doesn't suit everyone's tastes anyway, especially people comfortable with existing Zope 3 practices. As I said elsewhere, I suggest we call this project not Zope 3 but something else, to avoid confusion with the Zope ecosystem (and also to avoid implying it's the clear successor to Zope 2. I think we can safely say by now that's not how history went). Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: The elevator speech for Zope 3
Yup. Now let's drop the 3 in that sentence, because all of this applies to Zope software as a whole. This is, in fact, one way to sum up the way the Zope project as a whole works. I have no problem with that. The simpler the better. As long as the new comers learn Zope 3 and not Zope 2. Maybe we can learn from the javascript libraries? The first time you pick the whole package. Later when you have become more familiar with the library you only include the parts that you really need. But that is not how you start! Absolutely. Zope 3 should IMO have a click clack install version that makes the first little app a piece of cake. Add to that a story about flexibility and automated testing; then even I would buy it ;) http://cheeseshop.python.org/pypi/zopeproject is probably the fastest and easiest way to get started nowadays. One command and you're set up with a sandbox. If you haven't got Zope 3 downloaded yet, it will do so as well. It selects a set of libraries that are common in most applications and installs them by default. You can, of course, get rid of them later on. I will have to look at zopeproject. Without having looked at it - My guess is that I would like a little more flesh on the bones - like z3c.form(demo). Remember it is for people who are *new* to Zope. I would love to see a set of extjs widgets as well. Then of course there's Grok (http://grok.zope.org) which builds on the Zope Libraries and aims at making it all much easier. It too has a click clack install along the lines of zopeproject; it's called grokproject. And a while ago, I demonstrated how you could create a TodoList application in 15 minutes with it: http://www.archive.org/details/grok_todo_part1. Note that Grok has evolved a bit since then and adding any kind of ZCML or working with the ZMI is unnecessary nowadays. I have looked at Grok. I love the ideas. But it feels like its a little too much convention over configuration. I do not hate zcml. I hate to write zcml. If there was a way to auto generate zcml and way to overwrite that zcml when needed - then I would be a happy man. /Oliver ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.error is a 3.5 egg, but is needed by 3.4.x releases
Martijn Faassen skrev: We've worked with eggs for a few months now, with Grok. I can report that I believe the egg situation is currently massively unusable for almost all Zope 3 users except, from now on, Grok users, as two people spent half the week in resolving this problem and figuring out which eggs to use for what. I think the traffic on this mailing list the last weeks is plenty of evidence that non-Grok users have had very similar problems. I don't understand why this wasn't imlediately obvious from the beginning of egg'ifying zope 3? It was the first thing I thought about when I heard of things moving in that direction. Making software by releasing loosely coupled versions of seperate projects sounds like the perfect recipe for disaster. But I assumed I had just misunderstood how it was supposed to work. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: The elevator speech for Zope 3
On 8 Oct 2007, at 13:30 , Oliver Marx wrote: Yup. Now let's drop the 3 in that sentence, because all of this applies to Zope software as a whole. This is, in fact, one way to sum up the way the Zope project as a whole works. I have no problem with that. The simpler the better. As long as the new comers learn Zope 3 and not Zope 2. That's the idea. http://cheeseshop.python.org/pypi/zopeproject is probably the fastest and easiest way to get started nowadays. One command and you're set up with a sandbox. If you haven't got Zope 3 downloaded yet, it will do so as well. It selects a set of libraries that are common in most applications and installs them by default. You can, of course, get rid of them later on. I will have to look at zopeproject. Without having looked at it - My guess is that I would like a little more flesh on the bones - like z3c.form(demo). Remember it is for people who are *new* to Zope. I would love to see a set of extjs widgets as well. It's always an act of balance figuring out how much boilerplate we give to the users and how much we don't. zopeproject is a tool for getting started with *your* application, not a demo app. If somebody wants to go and build demo sites with Zope 3, then I'd welcome such an effort. It's just not what zopeproject is about. By the way, there are a number of demo Grok apps in the repository: http://svn.zope.org/grokapps/. Another one is here: http:// codespeak.net/svn/z3/NudgeNudge/trunk/ Then of course there's Grok (http://grok.zope.org) which builds on the Zope Libraries and aims at making it all much easier. It too has a click clack install along the lines of zopeproject; it's called grokproject. And a while ago, I demonstrated how you could create a TodoList application in 15 minutes with it: http:// www.archive.org/details/grok_todo_part1. Note that Grok has evolved a bit since then and adding any kind of ZCML or working with the ZMI is unnecessary nowadays. I have looked at Grok. I love the ideas. But it feels like its a little too much convention over configuration. I do not hate zcml. I hate to write zcml. If there was a way to auto generate zcml and way to overwrite that zcml when needed - then I would be a happy man. I realize that Grok's message is currently a bit misunderstanding. With Grok, you can spell out everything that you spell out in ZCML. Every little detail. But: if you adhere to some conventions, you can save yourself some typing. You don't have to adhere to those conventions at all. But in that case you'll have to do the typing again. The typing is, of course, much nicer than ZCML, because it's in Python and frankly, it's much more coherent than ZCML, easier to remember and it prevents context-switching. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: The elevator speech for Zope 3
Oliver Marx [EMAIL PROTECTED] writes: I have looked at Grok. I love the ideas. But it feels like its a little too much convention over configuration. I do not hate zcml. I hate to write zcml. If there was a way to auto generate zcml and way to overwrite that zcml when needed - then I would be a happy man. Have a look at bebop.protocol in PyPI. It's still a preminary version but it does exactly what you want. Regards, Uwe Dr. Uwe Oestermeier Institut für Wissensmedien Knowledge Media Research Center Konrad-Adenauer-Str. 40 D-72072 Tuebingen Germany [EMAIL PROTECTED] Tel. +49 7071 979-208 Fax +49 7071 979-100 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: The elevator speech for Zope 3
Hi Uwe. I have been thinking of something similar and posted on the list a couple of weeks back: http://mail.zope.org/pipermail/zope3-dev/2007-September/023653.html I want the zcml to be generated with a switch on zc.buildout so all configuration is auto generated. Currently site.zcml is done this way and I want to extend this to the class level. Recipe's would be produced to handle different types of configuration by providing the decorator methods. I'm hoping to use decorators exclusively on the classes to do this so there would be no need to modify the code in the classes themselves to accomplish the configuration. Further, classes without this decoration would be skipped by the process allowing this approach to be incorporated into your code gradually. I want to be able to see and verify the zcml produced and have the same control over it that I have now. The advantage of having it in buildout is that it becomes integrated into the development of the application, which is by nature just the configuration glue for your packages. Uwe, is there a chance your package can be zpl'd since I believe bebop is gpl and this is fairly low level code that could be a great plus for general z3 development. At the very least I'd like a zpl'd package to handle configuration this way or to borrow from your efforts to move forward with this idea. Regards, David Uwe Oestermeier wrote: Oliver Marx [EMAIL PROTECTED] writes: I have looked at Grok. I love the ideas. But it feels like its a little too much convention over configuration. I do not hate zcml. I hate to write zcml. If there was a way to auto generate zcml and way to overwrite that zcml when needed - then I would be a happy man. Have a look at bebop.protocol in PyPI. It's still a preminary version but it does exactly what you want. Regards, Uwe Dr. Uwe Oestermeier Institut für Wissensmedien Knowledge Media Research Center Konrad-Adenauer-Str. 40 D-72072 Tuebingen Germany [EMAIL PROTECTED] Tel. +49 7071 979-208 Fax +49 7071 979-100 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/fairwinds%40eastlink.ca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: The elevator speech for Zope 3
On 8 Oct 2007, at 15:14 , David Pratt wrote: Hi Uwe. I have been thinking of something similar and posted on the list a couple of weeks back: http://mail.zope.org/pipermail/zope3-dev/2007-September/023653.html I want the zcml to be generated with a switch on zc.buildout so all configuration is auto generated. Currently site.zcml is done this way and I want to extend this to the class level. Recipe's would be produced to handle different types of configuration by providing the decorator methods. I'm hoping to use decorators exclusively on the classes to do this so there would be no need to modify the code in the classes themselves to accomplish the configuration. Further, classes without this decoration would be skipped by the process allowing this approach to be incorporated into your code gradually. I want to be able to see and verify the zcml produced and have the same control over it that I have now. We were considering the generation of ZCML briefly when developing Grok, but discarded it quickly. The ZCML machinery (zope.configuration) itself is nice, but many of the directive handlers that are out there are flawed. In particular, the browser:page handler is so awful, I'm very very happy not having to use it in Grok. Death to magic class creation! Other handlers have side-effects during parsing time (as opposed to action execution time). Of course, we could've always written our own directives, but that wasn't the exercise. Soon, we will change Grok so that it emits configuration actions, rather than doing the registrations right away. That way, you will still be able to inspect what exactly Grok is doing (for example by dumping all configuration actions before or instead of executing them), but you won't have to deal with ZCML anymore. You will also be able to use the overrides mechanism with them. The advantage of having it in buildout is that it becomes integrated into the development of the application, which is by nature just the configuration glue for your packages. I think buildout is entirely the wrong place to do this, but feel free to pursue your own ideas :). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 releases?
On Monday 08 October 2007 06:56, Martijn Faassen wrote: Because we have endless confusion between Zope 3 the ecosystem and Zope 3 the web application framework. For me it is exactly the same. Zope 3 is a Web application server. Zope 2 uses many components of the Zope 3 Web application server. If you go and make a separate Zope 3 the web application framework and you can get away with just writing a buildout.cfg, then be happy. Just call it something else, as otherwise people will confuse it a lot with the exploded Zope 3 libraries. They don't *have* to use this particular web framework in order to use Zope 3. They can also use Zope 2, or Grok. But I consider the crafted set of libraries the Zope 3 application server. Whether you use just some of its components, choose a different WSGI server, or exchange functionality is totally irrelevant; it just proves how good the Zope 3 application server is. If Zope 3 is like a linux distribution, we'll have to manage it like a linux distribution does. A linux distribution has releases, but it doesn't have releases of something individual you install and run. It just has semi-frozen ecosystems being released once every while. Right, and I think this is what we need to do for Zope 3. This is what download.zope.org/zope3.4 and the KGS idea is all about. You can't do this and at the same time manage Zope 3 as an application, I think. It's an either-or. I have never defended the idea of a Zope 3 application. In fact, a lot of my efforts in Zope 3 right now are to get rid of the ZMI in my projects. application server != application The stable sets for the web application server are defined by those people who develop the Zope 3 web application server. The people who develop the web application server make choices that other users of Zope 3 technology might not make: perhaps to use Twisted for a web server. Perhaps to use paste for configuration, or *not* use paste for configuration. They might at some point decide that z3c.form is the default form framework that is documented in Zope 3 tutorials, instead of zc.formlib. Thus, the KGS should include all packages the sub-communities care about. For example download.zope.org/zope3.4 has both z3c.form and zope.formlib. Again, we should look at Linux distributions. They have a very healthy process for including and excluding packages. The community makes requests of packages to be included, then they are tested and if all is well, they are added to the next version of the distribution. If a package looses support and becomes so outdated that it does not work with the latest set of packages anymore, it is removed. Hopefully the users of the Zope 3 technology can work together on defining stable sets, but probably not for the entire range: Grok has some extra dependencies that Zope 2 may not have, and vice versa, for instance. Well, I would like to have a KGS that can be used by all user projects, including Zope 2 and Grok. If any of the user projects want to nail additional versions, they can do so and I would be glad helping to develop technology to make this happen. The Zope 3 web application server is not primarily what the Zope 3 project appears to be developing. I strongly suspect there are more users of Zope 3 technology within the Plone community than outside it, for instance. If the Zope 3 project cared about developing a web server, you'd think it would do a somewhat better job presenting it to the outside world on a web page, and that there'd be more people to actually make releases? I think we have very different definitions of application server. For me web server != application server. In Zope 3's case I could care less what the Web server is. For me, the publisher is really the server component. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: The elevator speech for Zope 3
Hi Philipp Betreff: Re: [Zope3-dev] Re: The elevator speech for Zope 3 [...] Soon, we will change Grok so that it emits configuration actions, rather than doing the registrations right away. That way, you will still be able to inspect what exactly Grok is doing (for example by dumping all configuration actions before or instead of executing them), but you won't have to deal with ZCML anymore. You will also be able to use the overrides mechanism with them. I don't know much about grok. But this sounds interesting. Does grok support a component architecture where I can use some components from or is grok a use it all or nothing concept? Regards Roger Ineichen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: AW: Re: The elevator speech for Zope 3
Roger Ineichen wrote: Hi Philipp Betreff: Re: [Zope3-dev] Re: The elevator speech for Zope 3 [...] Soon, we will change Grok so that it emits configuration actions, rather than doing the registrations right away. That way, you will still be able to inspect what exactly Grok is doing (for example by dumping all configuration actions before or instead of executing them), but you won't have to deal with ZCML anymore. You will also be able to use the overrides mechanism with them. I don't know much about grok. But this sounds interesting. Does grok support a component architecture where I can use some components from or is grok a use it all or nothing concept? Grok *aims* to support reusing bits of it. It hasn't reached this goal yet as we focused on making it work first, but has been an explicit seocndary goal from the beginning last year. We need to do some things to make this possible: * Done: Grok's mechanism of scanning for classes and instances in modules and issuing some form of configuration has been factored out into the martian library. * as Philipp mentioned, emit configuration actions instead of component registrations directly. This is underway, started at the sprint last week by Godefroid Chapelle. * split up Grok into separate components that are independently reusable, without having to pull in the whole of Grok to use this. Philipp wanted to start this work but I'm not sure about its status. * related to this, Grok turns off some of Zope 3's security infrastructure (for content objects, not for views). The Grok core should continue doing this for the forseeable future, but of course if you want to reuse other bits of Grok standalone this shouldn't come along. So, this is slowly but surely coming nearer. We want Grok to be a unified story for most users, so this is not our *primary* goal, but we do want Grok's work to be reusable in other Zope 3 projects as well. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: AW: Re: The elevator speech for Zope 3
Hi Martijn Betreff: [Zope3-dev] Re: AW: Re: The elevator speech for Zope 3 [...] Grok *aims* to support reusing bits of it. It hasn't reached this goal yet as we focused on making it work first, but has been an explicit seocndary goal from the beginning last year. We need to do some things to make this possible: * Done: Grok's mechanism of scanning for classes and instances in modules and issuing some form of configuration has been factored out into the martian library. * as Philipp mentioned, emit configuration actions instead of component registrations directly. This is underway, started at the sprint last week by Godefroid Chapelle. * split up Grok into separate components that are independently reusable, without having to pull in the whole of Grok to use this. Philipp wanted to start this work but I'm not sure about its status. * related to this, Grok turns off some of Zope 3's security infrastructure (for content objects, not for views). The Grok core should continue doing this for the forseeable future, but of course if you want to reuse other bits of Grok standalone this shouldn't come along. So, this is slowly but surely coming nearer. We want Grok to be a unified story for most users, so this is not our *primary* goal, but we do want Grok's work to be reusable in other Zope 3 projects as well. Cool, sounds promising Regards Roger Ineichen Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 releases?
Hey, Stephan, I tried to reply to your points but I realized I was getting lost in a sea of semantics and that it wasn't useful. The Zope 3 web application server is not primarily what the Zope 3 project appears to be developing. I strongly suspect there are more users of Zope 3 technology within the Plone community than outside it, for instance. If the Zope 3 project cared about developing a web server, you'd think it would do a somewhat better job presenting it to the outside world on a web page, and that there'd be more people to actually make releases? I think we have very different definitions of application server. For me web server != application server. In Zope 3's case I could care less what the Web server is. For me, the publisher is really the server component. I meant to write web application server, but I didn't write the word application, sorry. I'd like to see a separation between what you consider to be not only closely allied but *identical*: the pool of Zope 3 components, managed together by *all* the communities that make use of Zope 3 technologies, and the Zope 3 application server, where you go to some web site explaining what it's all about, and then download and install and get some script for to start some webserver so you can access it, read tutorials on and try to see Hello world on your screen with. Of course since to you there is no difference between the two, it gets hard to communicate. The communities that use Zope 3 technologies all have an interest in improving the common components, and also in distributing such common components for reuse. Our collective community could be called the Zope community, where Zope is like a Linux distribution that different systems make use of, with the major difference that we actually develop most of those packages within the community instead of mostly reusing what's developed outside. The Zope community has always been in the business of building software that can be used to build (web) applications. For years now we haven't had a single unified piece as we did when Zope 2 was (almost) the only game in town in the Zope world. These days, we have a whole host of related pieces that people can download and install and build software on top of. We have Zope 2, Zope 2 + Five, Zope 2 + CMF, Zope 2 + CMF + Five, original Zope 3, and Zope Grok. What's more we've had things build on top of this that also have aspects of frameworks or platforms, such as Plone or Silva. We've also always had components and systems that we use in our application servers, but could also be used separately: bobo, the ZODB, zope.interface, buildout, zope.pagetemplate. We don't have a linear evolution of a single platform at all, even though for a while we first intended and then pretended it was so with the naming of Zope 2 and Zope 3. We've stopped pretending for a while, I think. Instead, we have different communities that share underlying philosophies and technologies, and interact with each other within the Zope community. The one thing all these systems have had in common for the last years is that they all share Zope 3 technologies. If anything is the Zope platform it's this pool of Zope 3 technologies. The Zope development community is about the Zope platform. How to improve the platform? We've done this by improving them, adding to them, making them easier to evolve independently, supplementing them with technology like eggs and buildout, testing them, and making them easier to manage. The Zope community is also about the things we build on top of the Zope platform: Zope 2, Zope 3, CMF, Grok, etc. The nice thing about these is that they make choices for you. If you use Zope 2.10 today, you know what you have to deal with and you can rely on what you deal with. With Zope 3.3 it was the same story, and so it is for Grok. These we can market and offer for download and install. These things is what we can write tutorials for. So, the Zope community is a community of communities that are tied together by their common interest in the Zope platform, on top of which they build applications, web application frameworks and web application servers. The Zope platform allows you to roll your own software directly on top of it if you'd like, but typically you'd make use of one of the pre-packaged varieties such as Zope 2, Zope 3 or Grok. All of them are Zope. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] I'd lobe to merge the zope3-dev andzope-dev lists
On 10/8/07, Roger Ineichen [EMAIL PROTECTED] wrote: I think your mail also means, we can't avoid to have Zope 2 topics on the zope3-dev list because Zope 2 is going to move to Zope 3 and we have to exchange information. Doesn't matter how the list is called. Exactly. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: I'd lobe to merge the zope3-dev and zope-dev lists
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Any objections? This would basically involve retiring the zope3-dev list and moving zope3 developers to the zope-dev list. +1. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] 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 iD8DBQFHCkzF+gerLs4ltQ4RAjD5AKC+7vl0DlWSJYqHTlrNADqRFRyRLwCgz+qU u5liXF5Lu25oOk5OPY+TZjY= =SXR9 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: AW: [Zope3-dev] Re: The elevator speech for Zope 3
On 8 Oct 2007, at 15:52 , Roger Ineichen wrote: Betreff: Re: [Zope3-dev] Re: The elevator speech for Zope 3 [...] Soon, we will change Grok so that it emits configuration actions, rather than doing the registrations right away. That way, you will still be able to inspect what exactly Grok is doing (for example by dumping all configuration actions before or instead of executing them), but you won't have to deal with ZCML anymore. You will also be able to use the overrides mechanism with them. I don't know much about grok. But this sounds interesting. Does grok support a component architecture where I can use some components from or is grok a use it all or nothing concept? Currently Grok has tendencies of an all-or-nothing approach, but we're working on separating it to different packages. In the future, if you just want to register adapters and utilities using the Grok way, but don't want Grok's security policy or publication, you won't have to load all of Grok. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: AW: Re: The elevator speech for Zope 3
Hey, On 10/8/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Martijn Faassen wrote: [snip] ... emit configuration actions instead of component registrations directly. This is underway, started at the sprint last week by Godefroid Chapelle. Great! Where can this work be seen? Good question. I thought there was a branch but I can't find any. This definitely needs some followup from Godefroid, to at least check his work into a branch of Grok: Godefroid? * split up Grok into separate components that are independently reusable, without having to pull in the whole of Grok to use this. Philipp wanted to start this work but I'm not sure about its status. There's a branch that works and has tests [1], but I need to speak to you about some quirks that the current Grokker story has. Some refactoring in Martian would make this much easier. I will bring this up on grok-dev. Okay, thanks, see you there. Hopefully we can get martian fixed for this quickly. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Splitting files or packages
Since it has come up a few times on the checkins list recently, I'd like to reiterate an important point: When you split files or packages, you should always use 'svn cp' and not simply copy the bare files. Because if you simply copy the files from a checkout to another one, version history is broken. Using 'svn cp' preserves version history. You can either start out by copying from one repo URL to another, e.g.: svn cp $z/foo.bar/trunk/src/foo/bar/snob $z/foo.snob/trunk/src/foo or you can copy a remote set of files into a local sandbox (e.g. if you want to modify them right away): cd checkout-of-foo.snob/trunk/src/foo svn cp $z/foo.bar/trunk/src/foo/bar/snob . ... edit files svn ci Note that this also applies to single files. E.g. when you split a long module into two, use 'svn cp' to create the second file and then start removing duplicate things from the original and the copy. Why are we so anal about this? Because version history is important for understanding why something was done and who did it. If we didn't need to know this once in a while, we wouldn't have to use version control. And if we didn't care for version history when copying, moving and splitting files, we wouldn't have switched from CVS to subversion. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Known-good-sets problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hey, Another point of feedback: I saw Stephan's mail on a (partially new) toolchain and somewhat extensive workflow on using it. I'm a bit surprised a toolchain is necessary and that the workflow is so involved. With Grok's approach using extends in buildout, we can just publish such a list on a dumb website without any tools whatsoever. I'll agree that I don't see a need for much of a toolchain. Effectively, the index pages are just a set of N+1 static HTML pages (where N is the number of distutils projects managed by the index) with mirrored copies of all the distributions in some well-known (and guarded ;) location. Since you're effectively mirroring the cheeseshop anyway, why not rely on the cheeseshop entirely and just publish the version lists? If you don't mirror the actual distributions, then you are at the mercy of the project owner on the cheeseshop, who is free to remove or (worse) update-in-place an egg you rely on. This is why Debian mirrors the pristine tarballs of packges, and why RPM bundles them inside the SRPMs: *other* people and their software distribution mechanisms can't be relied on when repeatability is your goal. - -Tres.- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] 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 iD8DBQFHCnZA+gerLs4ltQ4RApxHAKCbXq2QkS3l4kD7Q0/qrssPn2zTYACfRjvb vVYlNIbZ6JwKVGY2jkxcXoA= =B++h -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists
David Pratt wrote at 2007-10-8 00:21 -0300: Zope 2 is one application among many dependent upon zope 3. Zope 3 is different software than zope 2. I do not argue with you that Zope3 is different software than Zope 2. What I argue about is Zope 2 is an application. I have seen hundreds of applications built on top of Zope 2, long before someone thought about Zope 3. I interpret this as: Zope 2 is not an application but a web application framework. Recently some applications make not only use of Zope 2 but also of Zope 3 (prominent example is Plone 3). But Zope 2 itself is still only slightly dependent on Zope 3. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 releases?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: On Oct 7, 2007, at 6:25 AM, Lennart Regebro wrote: On 10/6/07, Jim Fulton [EMAIL PROTECTED] wrote: - We need to decide what a Zope 3 release is (or maybe multiple flavors). I favor copying the linux experiences, but have an open mind. I'm not sure what you mean with that, I mean we need to decide what a release is. Presuming agreement on the known good set (KGS) term, I would think that we have two candidates for what makes up platform releases Frozen Releases - A frozen release would consist of: - A single, frozen KGS (index pages cannot change after release). - Scripts / tools which target that KGS, and create from it a standalone environment whcih includes the selected diestributiongs for each project in the KGS. E.g.: o An easy_install'able meta-egg with pinned versions, referencing the KGS index as 'index_url'. The egg would also include scripts and other entry points used to configure the platform environment (e.g., install zope.conf and site.zcml from skeletons, etc.) o A bootstrappable zc.buildout with pinned versions for all packages, or which relies on the frozen meta-egg for pinning. o A 'virtualenv' derivative, again probably leveraging the frozen egg. It would probably be fairly straightforward to generate the meta egg given the manifest. In fact, the meta egg should probably load the pinned versions from a config file which was also used to generate the frozen index page. These releases would be useful for: - Testing third-party packages which extend the platform. - Reproducing bugs reported against the platform - Giving to newbies as a safe starting point. The public versions of them would probably *not* be good for use in production deployments, because they cannot be updated with bugfixes. Some users might maintain their own versioned frozen releases for such uses, and handle updates by re-installing and migrating their data). Such a release would be analogous to a bootable ISO for a Linux distribution: if you run from the CD, you *know* what software is present, without any question. I would note that the script I posted a week or so ago for building package index pages from a directory full of source distributions would be a perfectly adequate tool for constructing such a KGS: simple copy or link all the frozen distributions into a directory and run the script. Once you've verified that the installation regime works from the generated files, you *never touch them again*. Updatable Platform Releases - --- An updatable platform release would consist of: - A KGS whose index pages were manually updated from time to time with carefully-selected new distributions of existing packges. - An installation regime, as above, which uses the KGS as its 'index_url', but *pins no packages* (whether in the meta egg, buildout.cfg, or whatever). o This regime should also contain / bootstrap scripts which couls be used to do automated updates from the KGS, like 'yum update' / 'apt-get upgrade'. In this case, generating the meta egg (or equivalent) should be unneeded: that egg could just be managed within the KGS itself. In a typical environment, the meta egg would likely never be updated all all (because it contains no software beyond the parts used to generate the environment). Such a relase would be analogous to an installed Linux distribution, with update repositories pre-configured. Maintaining the KGS in this case is harder, and could probably use a little more tooling. Once we have the tools, then tweaking them to allow generating a frozen release will be simple. In that mode, the two flavors of release here could be thought of as like tags and branches in the CVS sense (not SVN, which doesn't really have tags). Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] 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 iD8DBQFHCoBx+gerLs4ltQ4RAnz3AJ0fBLZfO/oSbBr37L1LGp/bpAAtZQCgs0gg zShIqAl+sFbdCRKMHOhAH4A= =vl1V -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 releases?
On Monday 08 October 2007 11:06, Martijn Faassen wrote: Stephan, I tried to reply to your points but I realized I was getting lost in a sea of semantics and that it wasn't useful. I agree I'd like to see a separation between what you consider to be not only closely allied but *identical*: the pool of Zope 3 components, managed together by *all* the communities that make use of Zope 3 technologies, and the Zope 3 application server, where you go to some web site explaining what it's all about, and then download and install and get some script for to start some webserver so you can access it, read tutorials on and try to see Hello world on your screen with. Of course since to you there is no difference between the two, it gets hard to communicate. Exactely. Because it might not be so easy to just click and go. Let's take an example, because I think it makes it more clear. For me z3c.formdemo is a good example of a small Zope 3 application. It is built on top of the Zope 3 Web application server. But in order to get it working, I did not have to install anything special. I just use the libraries. *I do not want to add technology just to match desired terminology.* Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 releases?
On Monday 08 October 2007 15:09, Tres Seaver wrote: Presuming agreement on the known good set (KGS) term, I would think that we have two candidates for what makes up platform releases Frozen Releases I started commenting this section until I saw the one below. I personally do not see much benefit from the frozen release. That said, it would be trivial to create one from the updateable version below. I have already scripts for this, which are checked in as part of Jim's PyPI mirror tool. Updatable Platform Releases --- An updatable platform release would consist of: - A KGS whose index pages were manually updated from time to time with carefully-selected new distributions of existing packges. - An installation regime, as above, which uses the KGS as its 'index_url', but *pins no packages* (whether in the meta egg, buildout.cfg, or whatever). o This regime should also contain / bootstrap scripts which couls be used to do automated updates from the KGS, like 'yum update' / 'apt-get upgrade'. This is pretty much done. See http://download.zope.org/zope3.4. I have checked in the tools in zc.mirrorcheeseshopslashsimple. Buildout itself serves as an equivalent to ``yum update`` or ``apt-get upgrade``. You can simply say ``./bin/buildout``. Without the -N option it will fetch the latest version, but the KGS guarantees that this will at most be a bug fix. In this case, generating the meta egg (or equivalent) should be unneeded: that egg could just be managed within the KGS itself. In a typical environment, the meta egg would likely never be updated all all (because it contains no software beyond the parts used to generate the environment). Yep. Such a relase would be analogous to an installed Linux distribution, with update repositories pre-configured. Exactely! Maintaining the KGS in this case is harder, and could probably use a little more tooling. Once we have the tools, then tweaking them to allow generating a frozen release will be simple. In that mode, the two flavors of release here could be thought of as like tags and branches in the CVS sense (not SVN, which doesn't really have tags). Yep, I agree. The usefulness of tags other than for generating a full release is questionable in my opinion, but I still agree with your ananlisys. :-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: Zope 3 releases?
Hi Tres Cc: zope3-dev Development Betreff: [Zope3-dev] Re: Zope 3 releases? [...] A frozen release would consist of: - A single, frozen KGS (index pages cannot change after release). Can we use a flag on the server side e.g. in the index page, so nobody is able to upload files if we use automated tools for the upload? Or can we use a different url which we can't upload after the freeze has be done. Like we do in subversion at least in some svn clients there will be a not if you try to commit to a url which contains the /tag/ part. [...] I would note that the script I posted a week or so ago for building package index pages from a directory full of source distributions would be a perfectly adequate tool for constructing such a KGS: simple copy or link all the frozen distributions into a directory and run the script. Once you've verified that the installation regime works from the generated files, you *never touch them again*. Do you think the directory should be a subversion tag which makes it reproducable? [...] Roger Ineichen Tres. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope-dev] AW: I'd lobe to merge the zope3-dev and zope-dev lists
Dieter Maurer wrote: David Pratt wrote at 2007-10-8 00:21 -0300: Zope 2 is one application among many dependent upon zope 3. Zope 3 is different software than zope 2. I do not argue with you that Zope3 is different software than Zope 2. What I argue about is Zope 2 is an application. I have seen hundreds of applications built on top of Zope 2, long before someone thought about Zope 3. I interpret this as: Zope 2 is not an application but a web application framework. Recently some applications make not only use of Zope 2 but also of Zope 3 (prominent example is Plone 3). But Zope 2 itself is still only slightly dependent on Zope 3. This statement is very confusing, given that nearly all of Zope 3 ships with Zope 2 since 2.8. So in fact a Zope 2 release depends very much on a Zope 3. It may be true that not much of the Zope 2 machinery uses Zope 3 (but if you look at Zope 2.10+, you'll see that core components such as the ZPublisher have been changed to look up views), but certainly a lot of applications that are built with Zope 2 use the Zope 3 libraries that ship with it, as well as the integration layer Five. This makes the Zope 3 libraries as much an integral part of Zope 2 as the old packages. Waiting-for-this-discussion-to-die-down-ly Philipp -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope-dev] AW: I'd lobe to merge the zope3-dev and zope-dev lists
Philipp von Weitershausen wrote: Waiting-for-this-discussion-to-die-down-ly I just counted votes here, there was 11 positive votes and 2 negative votes. +1 (Baiju M) +100 (Philipp von Weitershausen) +1 (Michael R. Bernstein) +1 Lennart Regebro +1 Andreas Jung +1 Jens Vagelpohl +1 Chris Withers +1 Martijn Faassen +1 Wichert Akkerman +1 Jodok Batlogg +1 Tres Seaver -1 Stephan Richter -1 Roger Ineichen Jim, I think you can proceed with merge now. Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
