[Zope-dev] Fwd: Defining Zope 3.
Hi, I usually love gmail, but in these last discussions I have trouble to understand, where I should write my reply to, since I can not see a thread. So I write a reply to the first mail and reference to various mails below. Sorry for that confusion to the people who use real mail readers! I would like to comment on this stuff with a bit of an outsider view. Somewhere in 2005-2006 I got a bit disconnected from zope and its evolvement. I was stuck to, I think, 2.8, and lots of Zope2 specialities that exist in Zope2 and not in Zope3. I disliked the things that were in Zope2 but not in Zope3. I must admit, that's a bit of fan boy attitude that I must get rid of. But in the time 2005, 2006, Z3 was the new kid on the block, everybody was wondering who would need how much time to migrate to the new zope. Zope3 was the big rewrite that will be the standard soon. Now I was told that Zope3 is not being seen as a replacement of Zope2. That stuck me as odd. Philips book does not say, that Zope3 will replace Zope2. But he suggests to try to use as much Zope3 technology through five, to have an easy migration. That at least suggests that Zope3 is the future while Zope2 is not. When I go to www.zope.org and click on Zope 3 on the left, I reach a wiki page that states that Zope 3 improves the development experience. There is nowhere written that Zope3 replaces Zope2. But it also suggests it. The English entry of the wikipedia states clearly that Zope3 is not the successor, an older version even points to suggestions from Jim, where is a discussion about the possible future: http://mail.zope.org/pipermail/zope3-dev/2006-February/018415.html I did not check wikipedia, nor did I skim the last three years of mailing list traffic, I wonder, did I not do enough thoroughly research in 2008? = I came back to Zope Land in October 2008. I became responsible for a number of web apps that are based on Zope2, all programming logic in Script Python, and all data in MySQL. Actually even security was implemented on its own based on attributes in sql. I considered this an outdated development model. But I am beginning to understand that this is wrong, that's my damn fan boy attitude. Everybody said, Zope3 is better so Zope2 models that were not taken over clearly must suck. Funnily, I tend to gravitate to products that handle zope2 development this way. 2005/2006 I was also doing stuff, there all I did was considered customization and should be handled in script python. The developers went big ways to make this better and better, they even added svn support for the scripts! But I disliked it, fan boy that I am, and was thinking: Hah, when Zope3 comes along and Zope2 will be outdated, they must rethink their strategy, then they see that this has no future. I disregarded the business decisions these companies made with the way they did Zope development and considered it inferior. But these companies have based their development model on this. They allow customers who do customizations in code, and depend on Zope, to take care that their customers cant break their system. This is their competitive advantage that they cant afford to loose. That is a different culture and mind than the ones who do typical Zope3 development. For the Zope3 developer, the only ones who program are the programmers and keeping the code in file system and unrestricted is much much better because you have all the development tools at hand to have higher productivity and safety. Think versioning system and easy search and replace over multiple files. With this in mind, Zope2 and Zope3 are totally different things. People who use Zope2 and want to continue using it have different goals than the Zope3 developers. I think, both have the right to have their own communities. A different name would help separating these communities. People who do both Zope2 and Zope3 stuff would just be in two communities. = When I started big extensions in October 2008, I wanted to do it future proof, Zope3ey. I knew of grok, thought of it as something on top of Zope3 and repoze, that seemed to be something different altogether. I wanted to do a smooth migration. As much as possible should be written on top of the Zope3 part in Zope2, so that one day I would just run it on Zope3 directly. I didn't want to use grok, because I feared it would add another complication, and I wanted to do one new thing at a time. It didn't work out exactly like that. Stumbling and stumbling but finally succeeding I ended up reimplementing nearly everything. My goal still was to get it all going on Zope3 one day, but I stayed with Zope 2.10. Now after reading the threads, I start to believe that this was the wrong way. I think now grok is not so much on top of Zope3, and maybe I should have taken a deeper look into that. But how shall somebody, who does not wade through the
Re: [Zope-dev] Fwd: Defining Zope 3.
Hey Patrick, Patrick Gerken wrote: [snip] I did not check wikipedia, nor did I skim the last three years of mailing list traffic, I wonder, did I not do enough thoroughly research in 2008? I think the strong impression was given that Zope 3 was going to be the new bright future and that Zope 2 was going to be replaced by Zope 3, one way or the other. It doesn't matter what exactly was said, the impression was given. The path that this took has evolved over time. The original ideas about Zope 3 being able to run Zope 2 code, perhaps with a migration script, never went anywhere. But along another path in some ways we are already in that future, as Zope 2 apps use a large amount of Zope 3 approaches and code. One thing that happened recently is that we extracted the concept of the Zope Toolkit from Zope 3. We'd now say that Zope 2 uses the Zope Toolkit. It could use more of the toolkit, it could use the toolkit better, and the toolkit itself is imperfect, but it's going forward, and that's good. [snip] I disregarded the business decisions these companies made with the way they did Zope development and considered it inferior. But these companies have based their development model on this. They allow customers who do customizations in code, and depend on Zope, to take care that their customers cant break their system. This is their competitive advantage that they cant afford to loose. That is a different culture and mind than the ones who do typical Zope3 development. Yes, I think that this is an important realization; that development using the ZMI, while flawed in many ways, is also *superior* in other ways to the development model that Zope 3 (and the Zope Toolkit) use. I talked a bit about that here: http://faassen.n--tree.net/blog/view/weblog/2008/09/19/0 One response to this is to try to make the development model of the Zope Toolkit less challenging for developers. That's Grok. Another response is to make there simply less code to worry about when developing; that's BFG. Hopefully we'll manage to continue to evolve the Toolkit in the direction of increased simplicity too. But there are other responses. One is to reconsider through the web development patterns and see how they might be supported in the context of the Zope Toolkit. I have some ideas... For the Zope3 developer, the only ones who program are the programmers and keeping the code in file system and unrestricted is much much better because you have all the development tools at hand to have higher productivity and safety. Think versioning system and easy search and replace over multiple files. With this in mind, Zope2 and Zope3 are totally different things. People who use Zope2 and want to continue using it have different goals than the Zope3 developers. I think, both have the right to have their own communities. A different name would help separating these communities. People who do both Zope2 and Zope3 stuff would just be in two communities. I think it's valuable for those communities to share code and approaches, but yes, I think a different name (for either Zope 2 or Zope 3, where Zope 3 would be the road of least resistance) would help make clear the vast differences between Zope 2 and Zope 3. There are a large number of overlaps too, but fundamentally the Zope 2 TTW web development model is quite different. [snip] I think now grok is not so much on top of Zope3, and maybe I should have taken a deeper look into that. In the past, when Zope 3 meant both Zope Toolkit and Zope 3 the thing you install and start developing with, Grok was on top of Zope 3 in part. Now we simply state that Grok is built on top of the Zope Toolkit. It mostly adds an alternative configuration mechanism to the Zope Toolkit (through Martian), and tries to make it easier to hook up applications this way. But how shall somebody, who does not wade through the mailing lists, make an informed decision? No. This is why I think good information on the web and a consistent message are both important. We're not there yet for both. I think we need a home page that says: want to get started with Zope? Here are the options. That is being worked on. If the Zope3 App Server with its zmi is becoming more of an implementation to show whats possible with the ZTK, why should it be called Zope3? I don't think it's to show what's possible. I think it is a development platform that pre-integrates the Zope Toolkit and adds a bit (documentation, installation methods, a user community). People start to get annoyed of this discussion, since some started to say bad words. I for one am happy about this discussion, because I hope that It might result in a better common understanding and after that a better public statement, whats happening, what frameworks are around and which have what advantages and disadvantages. Me too! Also, I want be be in the Zope foundation, so that Lennart makes me drunk
