I'd like to get feedback on two possible visions for the future of Zope 2 and Zope 3. 1) Our current vision (AFAIK) is that Zope 3 will eventually replace Zope 2 - There will be lots of overlap between the Zope 2 and Zope 3 lifetimes. (Zope 2 might be supported more or less forever.) - Eventually, the gap between Zope 2 and will become very small. requiring a small leap. In this vision, Zope 3 would have to become a lot more like Zope 2, or we would lose features. 2) In an alternate vision, Zope 2 evolves to Zope 5. - Zope 5 will be the application server generally known as Zope. It will be backward compatible (to the same degree that Zope 2 releases are currently backward compatible with previous Zope 2 releases) with Zope 2. Zope 5 will similarly be backward compatible with Zope 3 applications built on top of the current Zope 3 application server. Note that Zope 5 will leverage Zope 3 technologies to allow a variety of configurations, including a Zope 2-like configuration with implicit acquisition and through-the-web development, and a Zope 3-like configuration that looks a lot like the current Zope 3 application server. Maybe, there will be a configuration that allows Zope 2 and Zope 3 applications to be combined to a significant degree. - Zope 3 will explode. :) For many people, Zope 3 is first a collection of technologies that can be assembled into a variety of different applications. It is second a Zope 2-like application server. I think that these folks aren't really interested in the (Zope 2-like) application server. Zope 3 will continue as a project (or projects) for creating and refining these technologies. (It would probably make sense for this activity to to have some name other than "Zope". On some level, the logical name would be "Z" (pronounced "Zed" :). An argument against "Z" is that it would be hard to google for, but Google handles such queries quite well and I'd expect that we'd move to the top of Google Z search results fairly quickly. However, I'll leave naming decisions to experts. ;) Advantages of this vision: - Zope 2 users don't need to leave Zope 2. - Zope 3 doesn't have to reproduce all Zope 2 features. - There wouldn't be confusion about 2 Zopes. It is important that Zope 5 be backward compatible with both Zope 2 and Zope 3, although not necessarily in the same configuration. Many people are building Zope 3 applications today and they should not be penalized. Thoughts? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
My 2 EuroCents: Vision 1 is, I think what is happening at the moment for pragamatic and practical reasons. Drawbacks of this is that we loose the ZopeX3 (Zope3X?) vision of cutting loose from old burdens and take off to new horizons. Vision 2, on the other hand (at least to me in my not-really-started-with-z3-development-yet situation), is a lot more appealing for a variety of reasons, not the least that choosing working development model (zope2 and zope3 for starters, there may be others) becomes a "configuration"(*) issue. The potential benefits of this approach are very appealing (almost like eating the cake and still having it :), so I vote for vision 2. /dario (*) Configuration in a broad sense: mind model, conf-files, development model, etc... -- -- ------------------------------------------------------------------- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech. Lyrics applied to programming & application design: "emancipate yourself from mental slavery" - redemption song, b. marley
On Mon, 2006-02-27 at 10:37 -0500, Jim Fulton wrote:
I'd like to get feedback on two possible visions for the future of Zope 2 and Zope 3.
1) Our current vision (AFAIK) is that Zope 3 will eventually replace Zope 2
- There will be lots of overlap between the Zope 2 and Zope 3 lifetimes. (Zope 2 might be supported more or less forever.)
- Eventually, the gap between Zope 2 and will become very small. requiring a small leap.
In this vision, Zope 3 would have to become a lot more like Zope 2, or we would lose features. -1
2) In an alternate vision, Zope 2 evolves to Zope 5.
- Zope 5 will be the application server generally known as Zope. It will be backward compatible (to the same degree that Zope 2 releases are currently backward compatible with previous Zope 2 releases) with Zope 2. Zope 5 will similarly be backward compatible with Zope 3 applications built on top of the current Zope 3 application server.
Note that Zope 5 will leverage Zope 3 technologies to allow a variety of configurations, including a Zope 2-like configuration with implicit acquisition and through-the-web development, and a Zope 3-like configuration that looks a lot like the current Zope 3 application server. Maybe, there will be a configuration that allows Zope 2 and Zope 3 applications to be combined to a significant degree.
- Zope 3 will explode. :)
For many people, Zope 3 is first a collection of technologies that can be assembled into a variety of different applications. It is second a Zope 2-like application server. I think that these folks aren't really interested in the (Zope 2-like) application server.
Zope 3 will continue as a project (or projects) for creating and refining these technologies.
(It would probably make sense for this activity to to have some name other than "Zope". On some level, the logical name would be "Z" (pronounced "Zed" :). An argument against "Z" is that it would be hard to google for, but Google handles such queries quite well and I'd expect that we'd move to the top of Google Z search results fairly quickly. However, I'll leave naming decisions to experts. ;)
Advantages of this vision:
- Zope 2 users don't need to leave Zope 2.
- Zope 3 doesn't have to reproduce all Zope 2 features.
- There wouldn't be confusion about 2 Zopes.
It is important that Zope 5 be backward compatible with both Zope 2 and Zope 3, although not necessarily in the same configuration. Many people are building Zope 3 applications today and they should not be penalized.
Thoughts?
+2 I personally think that one of the great things about what has come out of Zope 3 development: other projects can use the technologies without taking Zope 3 lock stock and barrel. I'd hate to see Zope 3 get more girth and loose future traction because it had to be fully backwards compatible with Zope 2. For those who wish to slowly migrate to using Zope 3 technologies without completely rewriting their software, evolving via Five is a fair approach. To quote a blog I'd read earlier today: Doing little things well is a step towards doing big things better. Allowing others to assist in refining the little technologies which make up Zope 3 can achieve this goal. I would fear this would be impossible if the first vision was followed. Andrew Sawyers
Jim
OK, some initial, fuzzy comments: On 2/27/06, Jim Fulton <jim@zope.com> wrote:
In this vision, Zope 3 would have to become a lot more like Zope 2, or we would lose features.
You are thinking about things like TTW development and such? Because I see that as add-on products of different kinds. Like cpsskins to develop the look, and some sort of persistent schemas combined with some sort of aspect-oriented classes. ;-) If there is some sort of real "core" thingy that you lose going from Zope2 to Zope3 I must have missed it. :-p
2) In an alternate vision, Zope 2 evolves to Zope 5.
- Zope 5 will be the application server generally known as Zope. It will be backward compatible (to the same degree that Zope 2 releases are currently backward compatible with previous Zope 2 releases) with Zope 2. Zope 5 will similarly be backward compatible with Zope 3 applications built on top of the current Zope 3 application server.
Note that Zope 5 will leverage Zope 3 technologies to allow a variety of configurations, including a Zope 2-like configuration with implicit acquisition and through-the-web development, and a Zope 3-like configuration that looks a lot like the current Zope 3 application server. Maybe, there will be a configuration that allows Zope 2 and Zope 3 applications to be combined to a significant degree.
This overwhelms my complexity sensor. :-) I like the vision of Zope2 becoming a set of extra packages you install for Zope3, to get backwards compatibility. Maybe this is the same as what you call Zope 5, maybe not.
- There wouldn't be confusion about 2 Zopes.
This is definitely true... -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
On Monday 27 February 2006 11:06, Lennart Regebro wrote:
I like the vision of Zope2 becoming a set of extra packages you install for Zope3, to get backwards compatibility. Maybe this is the same as what you call Zope 5, maybe not.
That would sound good to me!!! Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Lennart Regebro wrote:
I like the vision of Zope2 becoming a set of extra packages you install for Zope3, to get backwards compatibility. Maybe this is the same as what you call Zope 5, maybe not.
+1 -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lennart Regebro a écrit : | OK, some initial, fuzzy comments: | | On 2/27/06, Jim Fulton <jim@zope.com> wrote: |>2) In an alternate vision, Zope 2 evolves to Zope 5. |> |> - Zope 5 will be the application server generally known as Zope. It |> will be backward compatible (to the same degree that Zope 2 |> releases are currently backward compatible with previous Zope 2 |> releases) with Zope 2. Zope 5 will similarly be backward |> compatible with Zope 3 applications built on top of the current |> Zope 3 application server. |> |> Note that Zope 5 will leverage Zope 3 technologies to allow a |> variety of configurations, including a Zope 2-like configuration |> with implicit acquisition and through-the-web development, and a |> Zope 3-like configuration that looks a lot like the current Zope |> 3 application server. Maybe, there will be a configuration that |> allows Zope 2 and Zope 3 applications to be combined to a |> significant degree. | | This overwhelms my complexity sensor. :-) | | I like the vision of Zope2 becoming a set of extra packages you | install for Zope3, to get backwards compatibility. Maybe this is the | same as what you call Zope 5, maybe not. I vote for this one. There's already Five product to help Zope2 products to become to be Zope3 compatible. Now, it's to Zope2 developpers to do the migration step. - -- Encolpe Degoute INGENIWEB (TM) - S.A.S 50000 Euros - RC B 438 725 632 17 rue Louise Michel - 92300 Levallois Perret - France web : www.ingeniweb.com - « les Services Web Ingénieux » -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEBBFHvFPzBBlIZMMRArvxAJ4vp3oOz4Jbs2sRdi5NiTmrgP0OYQCcDOa/ CGBI+hYJG7O+26x3Z40vuFU= =2wf7 -----END PGP SIGNATURE-----
On Mon, 2006-02-27 at 17:06 +0100, Lennart Regebro wrote:
OK, some initial, fuzzy comments:
...
You are thinking about things like TTW development and such?
Among other things. Zope 2 is more mature than Zope 3 in a lot of areas. WebDAV and process management are a couple of examples that occur to me off the top of my head. ...
- Zope 5 will be the application server generally known as Zope. It will be backward compatible (to the same degree that Zope 2 releases are currently backward compatible with previous Zope 2 releases) with Zope 2. Zope 5 will similarly be backward compatible with Zope 3 applications built on top of the current Zope 3 application server.
Note that Zope 5 will leverage Zope 3 technologies to allow a variety of configurations, including a Zope 2-like configuration with implicit acquisition and through-the-web development, and a Zope 3-like configuration that looks a lot like the current Zope 3 application server. Maybe, there will be a configuration that allows Zope 2 and Zope 3 applications to be combined to a significant degree.
This overwhelms my complexity sensor. :-)
Sorry, I'm not sure why.
I like the vision of Zope2 becoming a set of extra packages you install for Zope3, to get backwards compatibility. Maybe this is the same as what you call Zope 5, maybe not.
I see Zope 5 being a combination of Zope 2 and Zope 3, keeping the best of both.
- There wouldn't be confusion about 2 Zopes.
This is definitely true...
And given some of the discussion over the last month or two, I think this is pretty important. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote: [snip]
I see Zope 5 being a combination of Zope 2 and Zope 3, keeping the best of both.
I think we already have Zope 5, and it's called Zope 2.9. Perhaps I'm wrong. If so, how does Zope 5 differ from Zope 2.9? Regards, Martijn
Philipp von Weitershausen wrote:
Martijn Faassen wrote:
I see Zope 5 being a combination of Zope 2 and Zope 3, keeping the best of both.
I think we already have Zope 5, and it's called Zope 2.9.
I'd rather say it's called Zope 2.15 or something :).
Seriously, we are developing applications that use huge chunks of Zope 3 technology and are portable to Zope 3 in a short time right now, on Zope 2.9. Zope 2.10 and further will make it all even better of course, but let's not forget what we already have right now. It's a lot. Regards, Martijn
On Tue, 2006-02-28 at 17:29 +0100, Martijn Faassen wrote:
Jim Fulton wrote:
[snip]
I see Zope 5 being a combination of Zope 2 and Zope 3, keeping the best of both.
I think we already have Zope 5, and it's called Zope 2.9.
Perhaps I'm wrong. If so, how does Zope 5 differ from Zope 2.9?
Are you kidding? Zope 5 will be backward compatible with Zope 2 and Zope 3. It will allow configurations that look a lot like Zope 3. It will have the best of both systems, and improvements to both. It is where we put all of out app-server efforts. Among other things, it will have Zope 3's publisher and security model. It will provide support for non-developers much the way Zope 2 does now, but with better solutions that ZClasses. And, it will allow us to cleanly separate the efforts on an application server, from out work on widely usable components. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
On Tue, 2006-02-28 at 17:29 +0100, Martijn Faassen wrote:
Jim Fulton wrote:
[snip]
I see Zope 5 being a combination of Zope 2 and Zope 3, keeping the best of both.
I think we already have Zope 5, and it's called Zope 2.9.
Perhaps I'm wrong. If so, how does Zope 5 differ from Zope 2.9?
Are you kidding?
No, I'm not kidding. Zope 2.9 is the closest thing to Zope 5 that we have today, that people can work with. Zope 2.10 will hopefully be closer too, and so on.
Zope 5 will be backward compatible with Zope 2 and Zope 3. It will allow configurations that look a lot like Zope 3.
Sounds like the original vision of Zope 3 without the X. I thought we never got around to developing this stuff the last time. What changed?
It will have the best of both systems, and improvements to both.
Zope 2.9 has a lot of two systems. It doesn't have improvements to both, as we see that's clearly the mandate of the Zope 3 project, not of the Zope 2 or Five projects. We improve Zope 2 by taking bits of Zope 3. Mixing these things up into a Zope 5 puddle risks mixing it all up a lot.
It is where we put all of out app-server efforts. Among other things, it will have Zope 3's publisher and security model.
It will provide support for non-developers much the way Zope 2 does now, but with better solutions that ZClasses.
And, it will allow us to cleanly separate the efforts on an application server, from out work on widely usable components.
When do you think all this work will be finished? Who will work on it? What do we do in the mean time? What do we tell people? Do you really feel comfortable promising all that? How are we not on the course to reaching this featureset, eventually, anyway? I don't see how *saying* what Zope 5 will contain will make it *exist* any time sooner. These sound like useful evolution proposals for Zope 2 and Zope 3 to me... The current story of Zope 2, Five and Zope 3 gets us in the right direction (Zope 5, if you want to call it that, though I would definitely want to introduce yet another name in the mix), step by step. We don't promise too much to people. We don't raise the wrong expecations anymore. Everyone in the community is on board. We are already doing the work that's required to reach the ideal of "Zope 5". You could rename Zope 2.10 to Zope 5.0, but I don't see what good that would do except to confuse people. It won't contain the features you list unless someone actually does all that work. The alternative is to put Zope 5 in the nebulous future when all the work you list is done, and it'll be just like our mythical "Zope 3 without the X" then - confusing people and raising the wrong expectations. Regards, Martijn
On Tue, 28 Feb 2006 17:33:05 -0000, Martijn Faassen <faassen@infrae.com> wrote:
I don't see how *saying* what Zope 5 will contain will make it *exist* any time sooner. These sound like useful evolution proposals for Zope 2 and Zope 3 to me...
The current story of Zope 2, Five and Zope 3 gets us in the right direction (Zope 5, if you want to call it that, though I would definitely want to introduce yet another name in the mix), step by step. We don't promise too much to people. We don't raise the wrong expecations anymore. Everyone in the community is on board.
We are already doing the work that's required to reach the ideal of "Zope 5". You could rename Zope 2.10 to Zope 5.0, but I don't see what good that would do except to confuse people. It won't contain the features you list unless someone actually does all that work. The alternative is to put Zope 5 in the nebulous future when all the work you list is done, and it'll be just like our mythical "Zope 3 without the X" then - confusing people and raising the wrong expectations.
Martijn, I think you make a very sobering point. It's important to be a little careful with what you promise, and to keep a clear story for the more peripheral community and to outsiders. Zope 3 has, it seems, always been driven by a desire to make the perfect framework. In many ways, that's good, and the result to date is very beautiful. It's important to keep some ties to the real world, the applications people deploy on, systems like CPS and Plone and Silva, and not tempt them to too many false starts or with false promises that leaves them waiting forever. A vision is good. Commitment to that vision is even better. Just be careful what you promise. :) Martin -- (muted)
On Tuesday 28 February 2006 12:33, Martijn Faassen wrote:
Are you kidding?
No, I'm not kidding.
+1 on the entire post from me too. And I would really like to see the questions he raised answered. We just recovered from this BBB overpromise, now we want to make another one. We also just started to position the Zope 3 name and software correctly in the market and now we are going to confuse people again. That is just plain stupid^M^M^M^M^M^Msilly. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Stephan Richter wrote:
On Tuesday 28 February 2006 12:33, Martijn Faassen wrote:
Are you kidding?
No, I'm not kidding.
+1 on the entire post from me too. And I would really like to see the questions he raised answered.
OK, done.
We just recovered from this BBB overpromise,
What are you talking about?
now we want to make another one. We also just started to position the Zope 3 name and software correctly in the market
I'm so reassured. I had the opposite impression. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Martijn Faassen wrote:
Jim Fulton wrote:
On Tue, 2006-02-28 at 17:29 +0100, Martijn Faassen wrote:
Jim Fulton wrote:
[snip]
I see Zope 5 being a combination of Zope 2 and Zope 3, keeping the best of both.
I think we already have Zope 5, and it's called Zope 2.9.
Perhaps I'm wrong. If so, how does Zope 5 differ from Zope 2.9?
Are you kidding?
No, I'm not kidding. Zope 2.9 is the closest thing to Zope 5 that we have today, that people can work with. Zope 2.10 will hopefully be closer too, and so on.
It is not very close. It is not close enough, IMO, to call it Zope 5.
Zope 5 will be backward compatible with Zope 2 and Zope 3. It will allow configurations that look a lot like Zope 3.
Sounds like the original vision of Zope 3 without the X. I thought we never got around to developing this stuff the last time.
Actually, no. We originally said that we would provide a transition path. I said over and over that this was *not* going to be backward compatibility. I guess this was too complex a message. I think your post proves that it was. I saw Five as a key enabling technology for the transition. For some time, I said that Five would gradually narrow the gap between Zope 2 and Zope 3 until the transition would be very small.
What changed?
I assumed that Zope 3 would become more like Zope 2. That it would provide much the same features, if in somewhat different forms. This is still possible, but I don't really seeit happening. No matter how hard you and others work on Five, it's gonna be pretty hard for people to transition to Zope 3 if it doesn't provide the features they need.
It will have the best of both systems, and improvements to both.
Zope 2.9 has a lot of two systems. It doesn't have improvements to both, as we see that's clearly the mandate of the Zope 3 project, not of the Zope 2 or Five projects. We improve Zope 2 by taking bits of Zope 3. Mixing these things up into a Zope 5 puddle risks mixing it all up a lot.
Yes it does. I think the risks of continuing two application server projects for the forseeable future has greater risks.
When do you think all this work will be finished?
I don't know. I don't think it has to be that far away, I think it could happen by the end of 2007, but that depends on resources.
Who will work on it?
There are a lot of people working on Five and on leveraging Zope 3 in Zope 2 now. There are a lot more people working on these efforts than are working on Zope 3. I think that having a single application server, which is an evolution of Zope 2 will encourage a lot more people to invest time.
What do we do in the mean time? What do we tell people?
We tell people where we're going. We tell people that Zope 2 is not a dead end. That they aren't second class citizens if they stay with Zope 2. We tell the people using Zope 3 now that they won't be left high and dry. That the future single application server will run there applications too. That it can be configured to look a lot like what they're used to now.
Do you really feel comfortable promising all that?
Based on what I've seen over the last year, I feel comfortable setting it as a goal/vision/roadmap. I can't promise anything. I never suggested I was.
How are we not on the course to reaching this featureset, eventually, anyway?
I think we're moving along pretty well.
I don't see how *saying* what Zope 5 will contain will make it *exist* any time sooner.
You seem to be arguing against a roadmap, which is puzzling. Obviously, predictions of the future are imperfect.
These sound like useful evolution proposals for Zope 2 and Zope 3 to me...
Yes
The current story of Zope 2, Five and Zope 3 gets us in the right direction (Zope 5, if you want to call it that, though I would definitely want to introduce yet another name in the mix), step by step. We don't promise too much to people. We don't raise the wrong expecations anymore.
What expectations did we raise? AFAIK, the official story is that Zope 3 will eventually replace Zope 2 and that Zope 2 will be augmented with Zope 3 technology to make the transition easier. I don't think there are many people, if any, really working on making Zope 3 a credible replacement for Zope 2. There are people working on making it into something wonderful, but not a replacement for Zope 2. Do you agree that this is the current story? If not, and if *we* cannot agree on what the current story is, think how confused everyone else must be.
Everyone in the community is on board.
I think many people in the community are extreemely confused.
We are already doing the work that's required to reach the ideal of "Zope 5".
Exactly. The new vision I described attempts to capture reality. There are two parts to the reality: 1. Most of the effort in the Zope community is going toward improving Zope 2 with Zope 3 technology. 2. People working on Zope 3 don't want it to become like Zope 2. They don't want it to have the same features. Many of them don't even want it to be an application server, or think that that is its primary role. There is nothing wrong with what they want, but it isn't compatible with the vision of replacing Zope 2 with Zope 5.
You could rename Zope 2.10 to Zope 5.0,
Not and be consistent with the definition I have for Zope 5 in *my* post, Zope 2.10 is not Zope 5. Zope 5 will be ready when it will support, possibly in separate configurations, both Zope 2 and Zope 3 applications.
but I don't see what good that would do except to confuse people.
Right. I never suggested that we rename Zope 2.10 to Zope 5. You have done this and it is confusing people.
It won't contain the features you list unless someone actually does all that work.
That's right. Someone needs to do the work. Similarly, Zope 3 won't be a replacement for Zope 2 unless someone does the work. What's your point? That we shouldn't plan? That we shouldn't have a common vision for where we're going, or communicate that vision?
The alternative is to put Zope 5 in the nebulous future when all the work you list is done, and it'll be just like our mythical "Zope 3 without the X" then - confusing people and raising the wrong expectations.
The Zope 3 that provides support for transitioning from Zope 2 is "mythical" in the sense that it doesn't exist. It is something that we've been working on. Are you going to call anything that doesn't exist "mythical"? I don't see how that is useful or productive. As a community, I think we need a common vision of what we're working toward. It appears that we have that today. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On 3/1/06, Jim Fulton <jim@zope.com> wrote:
What's your point? That we shouldn't plan? That we shouldn't have a common vision for where we're going, or communicate that vision?
Well, not neccesarily. Things change, and the plan for the future has not always been the same. The important part is that we work in the same direction. I think this discusson has been fruitful, and useful, but we don't need to get consensus on a plan yet, because no matter what the plan is, the next few steps are the same: Make Zope2+Five use more and more Zope3 technologies, making the transition smaller. That plan is good at least until July, and probably until december. Commiting to a vision too soon may mean we have to change the vision, which as we have seen, is not an easy communication task to do. So I suggest we commit to the vision of making Zope2 and Zope3 more similar, for the moment, and continue discussing the future for while more, before we commit to a proper vision. The vision we have now may be fluffy and slightly different, but at least we are not pulling in different directions, and that means it's not too fluffy, yet. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
Lennart Regebro wrote:
On 3/1/06, Jim Fulton <jim@zope.com> wrote:
What's your point? That we shouldn't plan? That we shouldn't have a common vision for where we're going, or communicate that vision?
Well, not neccesarily. Things change, and the plan for the future has not always been the same. The important part is that we work in the same direction.
How is that possible if we don't communicate the vision? Are you suggesting a Zope Underground that knows the vision but keeps it secret to avoid making people nervous? ;)
I think this discusson has been fruitful, and useful, but we don't need to get consensus on a plan yet,
Then how are we going to work on the plan?
because no matter what the plan is, the next few steps are the same: Make Zope2+Five use more and more Zope3 technologies, making the transition smaller. That plan is good at least until July, and probably until december.
If the plan is to make make Zope 3 a replacement for Zope 2 or even to make them converge, then Zope 3 needs a lot of work that wouldn't be warrented otherwise.
Commiting to a vision too soon may mean we have to change the vision, which as we have seen, is not an easy communication task to do.
There's nothing wrong with changing the vision as long as it makes sense to do so. Sometimes, you change where you want to go based on what you've learned or on a changing environment.
So I suggest we commit to the vision of making Zope2 and Zope3 more similar, for the moment,
That implies more work than you realize. You seem to think that making Zope 2 and Zope 3 similar only requires changes to Zope 2. That is not true. It would require a lot of changes to Zope 3 too, changes that I don't think there's a lot of appetite for at this point.
and continue discussing the future for while more, before we commit to a proper vision. The vision we have now may be fluffy and slightly different, but at least we are not pulling in different directions, and that means it's not too fluffy, yet.
I think a lack of a realistic vision means that we are pulling in different directions. I think this is causing a lot of harm. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On 3/1/06, Jim Fulton <jim@zope.com> wrote:
Lennart Regebro wrote:
Well, not neccesarily. Things change, and the plan for the future has not always been the same. The important part is that we work in the same direction.
How is that possible if we don't communicate the vision?
In the long run it probably isn't. But in the short term it seems to work fine. :)
Then how are we going to work on the plan?
We don't have to work on a plan. All we need is to work. A plan is only needed when people start working in different directions.
If the plan is to make make Zope 3 a replacement for Zope 2 or even to make them converge, then Zope 3 needs a lot of work that wouldn't be warrented otherwise.
Maybe, but does it need it just right now?
That implies more work than you realize. You seem to think that making Zope 2 and Zope 3 similar only requires changes to Zope 2.
So far I think it requires only changes to Zope2, yes. If I'm wrong I would be interested to hear what you think must be changed in Zope 3.3 and 3.4.
I think a lack of a realistic vision means that we are pulling in different directions. I think this is causing a lot of harm.
OK. It doesn't look like that from here, but I could be wrong. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
On Wednesday 01 March 2006 10:06, Jim Fulton wrote:
I don't see how *saying* what Zope 5 will contain will make it *exist* any time sooner.
You seem to be arguing against a roadmap, which is puzzling.
I don't think Martijn is arguing against a roadmap, he just asserts (and ( agree with him) that the current roadmap using Five is a good one that we should be following for while. BTW, you also have not addressed the naming issue. I think that throwing another name out there will make the community more wary than comfortable. My suggestion would be to move along as we do now, replace the security mechanism, use Zope 3's PTs in Zope 2, even switch the publisher, etc. Then we can revisit our vision.roadmap and see how we can go from there. If you find this unacceptable, then you or someone else must do a much better job explaining the technical details of this vision. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Stephan Richter wrote:
On Wednesday 01 March 2006 10:06, Jim Fulton wrote:
I don't see how *saying* what Zope 5 will contain will make it *exist* any time sooner.
You seem to be arguing against a roadmap, which is puzzling.
I don't think Martijn is arguing against a roadmap, he just asserts (and ( agree with him) that the current roadmap using Five is a good one that we should be following for while.
What do you think the current roadmap is? I'm not sure we agree onwhat it is. That's a huge problem.
BTW, you also have not addressed the naming issue. I think that throwing another name out there will make the community more wary than comfortable.
I think that having one name for two radically different, though related, things is very confusing. There are really 2 main technologies that people care about: 1. The Zope app server. This is characterized by things like an object file system, through-the-web scripting and/or development, pluggable course-grained add-ons, etc. 2. The collection of Zope technologies that can be combined and reused in a variety of ways. These technologies support the app server, but they have a life of their own. I think that these efforts are very different and that calling them both "zope" is very confusing to people. OTOH, there are related. The first builds on the second, which is why, in many ways, "Z" is a good name for the second. I'll reiterate that the serach term "Z" is handled well by Google. IANANE (I am not a naming expert). I'm willing to defer to someone else on the names, but I think we do need to distinguish these two efforts more than we do now. I'll note that the fact that the single name "Zope 3" refers to both technologies above is very confusing to people.
My suggestion would be to move along as we do now, replace the security mechanism, use Zope 3's PTs in Zope 2, even switch the publisher, etc.
Do we also fix WebDAV in Zope 3? How about TTW scripting? How about process control? Or all of the other things in Zope 2 that we haven't gotten around to yet? If we aren't going to work on these, don't you think we are giving people false expectations for Zope 3's application server?
Then we can revisit our vision.roadmap and see how we can go from there.
If you find this unacceptable, then you or someone else must do a much better job explaining the technical details of this vision.
Perhaps, although technical details don't belong in a vision. Can you explain the current vision? Can you explain the current roadmap? Do you think we all agree on what it is? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Wednesday 01 March 2006 11:12, Jim Fulton wrote:
What do you think the current roadmap is? I'm not sure we agree onwhat it is. That's a huge problem.
The current roadmap, as far as I understand it based on your comments and feedback from the community, is as follows: Primary objective ----------------- Bring Zope 2 and 3 closer together by sharing more packages. Once they are close enough, develop a method of making them one without burdening either development team. Current Approach ---------------- 1. Integrate comparable Zope 3 packages into Zope 2 (as Andreas does right now with page templates). If this integration requires the Zope 3 packages to be extended/improved, so be it. 2. Provide a way for Zope 2 developers to use most, if not everything, that Zope 3 has to offer. This is currently achieved using Five. Results ------- Here are a couple success stories of this approach: 0. Zope 2 developers, while making their living, start learning the Zope 3 philosophy which is much more important than learning all the features. 1. Martijn is slowly porting Silva to Zope 3, piece by piece. I let him elaborate on that. 2. Several Zope 2 products emerged that rely on Zope 3 technologies, but are available for Zope 2 as well. An example is Andreas' TextIndexNG. 3. The Plone community has developed a method for building a more robust framework. That initiative is known as Cubed. It will develop pure Zope 3 component that will be directly usable in the current Plone stack. Overall I think, the Zope sub-communities just became comfortable with that approach and starting thriving on it. At least that is my impression from the Snow Sprint. We have them finally going and do something with Zope 3. It would be fatal to change the direction now, because it would put them back into "idle mode".
I think that these efforts are very different and that calling them both "zope" is very confusing to people. OTOH, there are related. The first builds on the second, which is why, in many ways, "Z" is a good name for the second. I'll reiterate that the serach term "Z" is handled well by Google.
I think we have recently communicated the differences between Zope 2 and 3 very well. I think it has become much less confusing than it used to be, when we did not communicate that much. I agree with others that a new name will harm us much more, since we are starting the communication from scratch.
Do we also fix WebDAV in Zope 3?
Yes, Michael Kerrin is doing this right now.
How about TTW scripting? How about process control? Or all of the other things in Zope 2 that we haven't gotten around to yet? If we aren't going to work on these, don't you think we are giving people false expectations for Zope 3's application server?
No, I don't think so. We clearly defined our target audience for Zope 3 to be the Python developer. We have succeeded there and have communicated this. Additionally, non-core projects/packages such as WebDev will address other audiences.
Perhaps, although technical details don't belong in a vision.
I do agree with that, but the reason I want to know technical details is that I want to know of how all this is envisioned to work. If Zope 5 means that we alienate the pure Zope 3 users or for core-developers like me to relearn Zope 2, then I have a major issue with that vision and will argue early about this direction instead of waiting for something to happen.
Can you explain the current vision? Can you explain the current roadmap? Do you think we all agree on what it is?
I thought we did. Maybe I was wrong? Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Jim Fulton wrote: [snip]
I think that having one name for two radically different, though related, things is very confusing. There are really 2 main technologies that people care about:
1. The Zope app server. This is characterized by things like an object file system, through-the-web scripting and/or development, pluggable course-grained add-ons, etc.
I must warn you that what you call 'app server' is not what I call app server; I believe that using the word appserver for this set of technologies could be very confusing to people. I believe Zope 3 is an application server. I believe, say, Django is an application server too, even though as far as I know it lacks an object file system and through the web scripting. Can we find another word for what you mean? Regards, Martijn
Martijn Faassen wrote:
Jim Fulton wrote: [snip]
I think that having one name for two radically different, though related, things is very confusing. There are really 2 main technologies that people care about:
1. The Zope app server. This is characterized by things like an object file system, through-the-web scripting and/or development, pluggable course-grained add-ons, etc.
I must warn you that what you call 'app server' is not what I call app server; I believe that using the word appserver for this set of technologies could be very confusing to people. I believe Zope 3 is an application server. I believe, say, Django is an application server too, even though as far as I know it lacks an object file system and through the web scripting. Can we find another word for what you mean?
I wasn't trying to define app server. I was describing the Zope app server. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
Martijn Faassen wrote:
Jim Fulton wrote: [snip]
I think that having one name for two radically different, though related, things is very confusing. There are really 2 main technologies that people care about:
1. The Zope app server. This is characterized by things like an object file system, through-the-web scripting and/or development, pluggable course-grained add-ons, etc.
I must warn you that what you call 'app server' is not what I call app server; I believe that using the word appserver for this set of technologies could be very confusing to people. I believe Zope 3 is an application server. I believe, say, Django is an application server too, even though as far as I know it lacks an object file system and through the web scripting. Can we find another word for what you mean?
I wasn't trying to define app server. I was describing the Zope app server.
Jim
why not say that the Zope application server is based on the Z Foundation Libraries (ZFL) ? "Z" can be interpreted as being short name for "Zope" without creating a new name for it. which can also be interpreted as the libraries used by the zope foundation software (ZF)? /JM
Jim Fulton wrote: [snip]
I wasn't trying to define app server. I was describing the Zope app server.
As long as you realize you do risk confusion even by saying 'Zope app server'. To me, Zope 3 is an app server, so when you say 'the Zope app server' will include its functionalities too. Regards, Martijn
Jim Fulton wrote:
Martijn Faassen wrote: [snip]
Sounds like the original vision of Zope 3 without the X. I thought we never got around to developing this stuff the last time.
Actually, no. We originally said that we would provide a transition path. I said over and over that this was *not* going to be backward compatibility. I guess this was too complex a message. I think your post proves that it was.
I know exactly what was said, and we, the Zope community, said it wrong, including the backwards compatibility bit. I quote the release notes for Zope X3.0: "The "X" in the name stands for "experimental", since this release does not try to provide any backward-compatibility to Zope 2." What do you think that implied? Maybe you didn't say backwards compatibility, but our release notes certainly said something about this. This message wasn't new: """ 1b. "Zope 3X" is the preliminary version of Zope 3. It is built from the ground up, paying attention to the lessons learned from Zope 2 and CMF. It is not a product but intended to let developers get familiar with the new architecture early. 1c. "Zope 3" is the mainline release intended for production use and including backwards compatibility to Zope 2. """ It was here: http://cvs.zope.org/Zope3/doc/security/background.rst?rev=1.3 I had a lot more to say in this posting which I recommend you read: http://mail.zope.org/pipermail/zope3-dev/2006-February/017939.html [snip snip]
I don't see how *saying* what Zope 5 will contain will make it *exist* any time sooner.
You seem to be arguing against a roadmap, which is puzzling.
Obviously, predictions of the future are imperfect.
I'm not arguing against a vision. I'm worried about marketing and what we will be implicitly implying. I want to be very careful about roadmaps as we can't guarantee they will happen, and broken promises in this will be worse than no promises at all. I think, for now, our vision should be sketched with what we have right now (Zope 2 and Zope 3) and where we think they are going. Talk about it names we already know, or if we really make new things, new names that are not Zope for the time being. [snip]
The current story of Zope 2, Five and Zope 3 gets us in the right direction (Zope 5, if you want to call it that, though I would definitely want to introduce yet another name in the mix), step by step. We don't promise too much to people. We don't raise the wrong expecations anymore.
What expectations did we raise?
See my referenced mail: http://mail.zope.org/pipermail/zope3-dev/2006-February/017939.html
AFAIK, the official story is that Zope 3 will eventually replace Zope 2 and that Zope 2 will be augmented with Zope 3 technology to make the transition easier. I don't think there are many people, if any, really working on making Zope 3 a credible replacement for Zope 2. There are people working on making it into something wonderful, but not a replacement for Zope 2. Do you agree that this is the current story? If not, and if *we* cannot agree on what the current story is, think how confused everyone else must be.
I think that is indeed the current story. It's not complete: Zope 3 technology is replacing Zope 2 today in that I can write a Zope 3-like application in Zope 2. In that sense, Zope 2.9 *is* the Zope 3 without X. Zope 3 technology is not only in Zope 2 for the transition, but also because it's cool stuff we can actually use profitably now, not only because we might be able to transition to Zope 3 more easily in some future. I think part of this story is that the Zope 2 people will work on Zope 3-based technology to replace bits of Zope 2 step by step, bit by bit. I believe this is happening in the context of Five, the Zope 2 core (the event system), and the CMF. I think part of this story is also that Zope 2 is safe and is going to be around for a loooong time. Emphasizing these bits of the story would be good, and I think we agree on that. We need to be careful though we also are seen to stay the course: introducing new version numbers and names of the mix is I think right now the wrong action to take. [snip]
It won't contain the
features you list unless someone actually does all that work.
That's right. Someone needs to do the work. Similarly, Zope 3 won't be a replacement for Zope 2 unless someone does the work. What's your point? That we shouldn't plan? That we shouldn't have a common vision for where we're going, or communicate that vision?
These are rhetorical questions... My point is: Have a vision, but plan step by step. Don't promote the presumed endpoint of the steps too much yet. Evolve the message step by step too. Change the message slowly, not all at once, to avoid creating confusion and unrest. Don't change the message before we're ready. Introducing a new message always carries a strong risk of being misunderstood.
The alternative is to put Zope 5 in the nebulous future when all the work you list is done, and it'll be just like our mythical "Zope 3 without the X" then - confusing people and raising the wrong expectations.
The Zope 3 that provides support for transitioning from Zope 2 is "mythical" in the sense that it doesn't exist. It is something that we've been working on. Are you going to call anything that doesn't exist "mythical"? I don't see how that is useful or productive.
I call vaporware on the promise we made for years on that, sure. I worry about Zope 5 being vaporware too. We're not close enough yet.
As a community, I think we need a common vision of what we're working toward. It appears that we have that today.
Sure. I think this thread made this explicit. Let's not stir the pot and just work on this for a few Zope 2 and Zope 3 releases more. Maybe the pot's ready for stirring after then. Regards, Martijn
Martijn Faassen wrote:
Jim Fulton wrote:
Martijn Faassen wrote:
[snip]
Sounds like the original vision of Zope 3 without the X. I thought we never got around to developing this stuff the last time.
Actually, no. We originally said that we would provide a transition path. I said over and over that this was *not* going to be backward compatibility. I guess this was too complex a message. I think your post proves that it was.
I know exactly what was said, and we, the Zope community, said it wrong, including the backwards compatibility bit. I quote the release notes for Zope X3.0:
"The "X" in the name stands for "experimental", since this release does not try to provide any backward-compatibility to Zope 2."
What do you think that implied? Maybe you didn't say backwards compatibility, but our release notes certainly said something about this.
This message wasn't new:
""" 1b. "Zope 3X" is the preliminary version of Zope 3. It is built from the ground up, paying attention to the lessons learned from Zope 2 and CMF. It is not a product but intended to let developers get familiar with the new architecture early.
1c. "Zope 3" is the mainline release intended for production use and including backwards compatibility to Zope 2. """
It was here:
http://cvs.zope.org/Zope3/doc/security/background.rst?rev=1.3
It is frustrating that there were worded this way. If was never intended that we would promise backward compatibility. I certainly tried to be clear that there would be a transition path, not backward compatibility. But perhaps we are splitting hairs...
I had a lot more to say in this posting which I recommend you read:
http://mail.zope.org/pipermail/zope3-dev/2006-February/017939.html
You seem to be calling "vaporware" on even a transition path, implying that we shouldn't promise one. (BTW, "vaporware" is software that is described as if it exists, but doesn't. I don't think that applies to anything we are talking about here.) I think that a transition plan for Zope 2 applications is critical and something we should work toward.
I don't see how *saying* what Zope 5 will contain will make it *exist* any time sooner.
You seem to be arguing against a roadmap, which is puzzling.
Obviously, predictions of the future are imperfect.
I'm not arguing against a vision.
You fooled me.
I'm worried about marketing and what we will be implicitly implying. I want to be very careful about roadmaps as we can't guarantee they will happen,
Of course we can't.
and broken promises in this will be worse than no promises at all.
I understand this. I'm more worried about roadmaps that aren't honest. That say we're working on something that we are not.
I think, for now, our vision should be sketched with what we have right now (Zope 2 and Zope 3) and where we think they are going.
Exactly.
Talk about it names we already know, or if we really make new things, new names that are not Zope for the time being.
We'll have to agree to disagree.
[snip]
The current story of Zope 2, Five and Zope 3 gets us in the right direction (Zope 5, if you want to call it that, though I would definitely want to introduce yet another name in the mix), step by step. We don't promise too much to people. We don't raise the wrong expecations anymore.
What expectations did we raise?
See my referenced mail:
http://mail.zope.org/pipermail/zope3-dev/2006-February/017939.html
I think it was right to raise expectations for a transition plan. Also, as I understand Zope 3 better, I feel that bacward compatibility *is* possible, at least to the extent that Zope 2 releases are backward compatible today.
AFAIK, the official story is that Zope 3 will eventually replace Zope 2 and that Zope 2 will be augmented with Zope 3 technology to make the transition easier. I don't think there are many people, if any, really working on making Zope 3 a credible replacement for Zope 2. There are people working on making it into something wonderful, but not a replacement for Zope 2. Do you agree that this is the current story? If not, and if *we* cannot agree on what the current story is, think how confused everyone else must be.
I think that is indeed the current story.
Cool, we agree on something ...
It's not complete:
I think it is also inaccurate, because I don't think people working on Zope 3 are really working to replace the functionality in Zope 2. In fact, most of the work on Zope 3 is not on Zope 3 itself, but on integrating it into Zope 2.
Zope 3 technology is replacing Zope 2 today in that I can write a Zope 3-like application in Zope 2. In that sense, Zope 2.9 *is* the Zope 3 without X. Zope 3 technology is not only in Zope 2 for the transition, but also because it's cool stuff we can actually use profitably now, not only because we might be able to transition to Zope 3 more easily in some future.
This is much closer to the new vision that I proposed than the current vision.
I think part of this story is that the Zope 2 people will work on Zope 3-based technology to replace bits of Zope 2 step by step, bit by bit. I believe this is happening in the context of Five, the Zope 2 core (the event system), and the CMF. I think part of this story is also that Zope 2 is safe and is going to be around for a loooong time.
Yes
Emphasizing these bits of the story would be good, and I think we agree on that. We need to be careful though we also are seen to stay the course: introducing new version numbers and names of the mix is I think right now the wrong action to take.
Again, we'll have to agree to disagree.
It won't contain the
features you list unless someone actually does all that work.
That's right. Someone needs to do the work. Similarly, Zope 3 won't be a replacement for Zope 2 unless someone does the work. What's your point? That we shouldn't plan? That we shouldn't have a common vision for where we're going, or communicate that vision?
These are rhetorical questions...
Actually, no.
My point is:
Have a vision, but plan step by step. Don't promote the presumed endpoint of the steps too much yet.
You have to agree on what the endpoint is in order to decide what the steps are.
Evolve the message step by step too. Change the message slowly, not all at once, to avoid creating confusion and unrest. Don't change the message before we're ready. Introducing a new message always carries a strong risk of being misunderstood.
I think constantly changing the message and worse, not agreeing on the message is worse.
The alternative is to put Zope 5 in the nebulous future when all the work you list is done, and it'll be just like our mythical "Zope 3 without the X" then - confusing people and raising the wrong expectations.
The Zope 3 that provides support for transitioning from Zope 2 is "mythical" in the sense that it doesn't exist. It is something that we've been working on. Are you going to call anything that doesn't exist "mythical"? I don't see how that is useful or productive.
I call vaporware on the promise we made for years on that,
I think the intent to provide a transition was and is reasonable and necessary.
sure. I worry about Zope 5 being vaporware too. We're not close enough yet.
As a community, I think we need a common vision of what we're working toward. It appears that we have that today.
Sure. I think this thread made this explicit. Let's not stir the pot and just work on this for a few Zope 2 and Zope 3 releases more. Maybe the pot's ready for stirring after then.
I don't agree, but there's no point in arguing the point further. I would just be repeating myself. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On 2/28/06, Jim Fulton <jim@zope.com> wrote:
Zope 2 is more mature than Zope 3 in a lot of areas. WebDAV and process management are a couple of examples that occur to me off the top of my head.
Ah, and here I got an answer to the question I just posted. :) Much of Zope2 maturity is there in a thorougly non-reusable way. We won't get WebDAV support for Zope3 objects by including some old crufty Zope2 code. This means that for most of these features, we will have to build something new anyway.
This overwhelms my complexity sensor. :-)
Sorry, I'm not sure why.
Not the text, the result. :) Zope2 + Zope3 + Five is a MASSIVE complexity, and I think it is important that we don't make things more complex than necessary. I think the best vision for the Zope future is to have: 1. A set of basic non-webby techniques. This is ZODB, zope.interfaces, zope.components and all that. 2. An object publisher, that publishes the ZODB objects built with the techniques in point 1, including user handling, security, traversal, yadayadaydad. This would be known as Zope3. 3. An extension to Zope3 that includes the shim to support two modules called "Products", all the old default products, and the support to make the Zope3 publisher publish these type of objects. In other words, a Zope2 backwards compatibility product. The steps to get here involves stuff like replacing Zope2s security with Zope3 security, replacing Zope2s publisher with Zope3s publisher, and so on, until Zope2 is almost nothing more than a set of products. 4. Other extension sets for Zope3, like z3ecm, for making ecm systems, and z3ttw for through-the-web development. Now, there may be something that is obviously unfeasable with all this. But it sure is much less overwhelmingly complex than some sort of Zope5.
I see Zope 5 being a combination of Zope 2 and Zope 3, keeping the best of both.
Doesn't that mean we only keep Zope3? ;-)
And given some of the discussion over the last month or two, I think this is pretty important.
Yup. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
On Tuesday 28 February 2006 11:00, Jim Fulton wrote:
Zope 2 is more mature than Zope 3 in a lot of areas. WebDAV and process management are a couple of examples that occur to me off the top of my head.
Except that Michael Kerrins recent WebDAV work will shaddow Zope 2's support. If I understand his improved implementation correctly, then it is very, very cool! Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
On Wed, Mar 01, 2006 at 09:12:08AM -0500, Stephan Richter wrote: | On Tuesday 28 February 2006 11:00, Jim Fulton wrote: | > Zope 2 is more mature than Zope 3 in a lot of areas. WebDAV | > and process management are a couple of examples that occur to me | > off the top of my head. | | Except that Michael Kerrins recent WebDAV work will shaddow Zope 2's support. | If I understand his improved implementation correctly, then it is very, very | cool! Did you run the litmus tests against it? :) BTW, I'm working on converting the full set of the litmus tests to a functional doctest, will check that in soon. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com
On Wednesday 01 March 2006 09:24, Sidnei da Silva wrote:
| Except that Michael Kerrins recent WebDAV work will shaddow Zope 2's | support. If I understand his improved implementation correctly, then it | is very, very cool!
Did you run the litmus tests against it? :)
I don't know what that is, of course. :-) I think talking to Michael is the better choice here. :-) Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
On Wed, Mar 01, 2006 at 09:29:05AM -0500, Stephan Richter wrote: | On Wednesday 01 March 2006 09:24, Sidnei da Silva wrote: | > | Except that Michael Kerrins recent WebDAV work will shaddow Zope 2's | > | support. If I understand his improved implementation correctly, then it | > | is very, very cool! | > | > Did you run the litmus tests against it? :) | | I don't know what that is, of course. :-) I think talking to Michael is the | better choice here. :-) First hit: http://www.google.com/search?q=webdav+litmus+tests What you think about turning those into functional doctests? -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com
On Wednesday 01 March 2006 09:32, Sidnei da Silva wrote:
What you think about turning those into functional doctests?
Of course a very, very big +1. :-) Though I woul split them up, so that we can only test features that we know we have implemented. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
On Wednesday 01 March 2006 14:32, Sidnei da Silva wrote:
On Wed, Mar 01, 2006 at 09:29:05AM -0500, Stephan Richter wrote: | On Wednesday 01 March 2006 09:24, Sidnei da Silva wrote: | > | Except that Michael Kerrins recent WebDAV work will shaddow Zope 2's | > | support. If I understand his improved implementation correctly, then | > | it is very, very cool! | > | > Did you run the litmus tests against it? :) | | I don't know what that is, of course. :-) I think talking to Michael is | the better choice here. :-)
First hit: http://www.google.com/search?q=webdav+litmus+tests
What you think about turning those into functional doctests? Never seen that before - found a bunch of bugs with it too :-)
Thanks for the link Michael -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894
Jim Fulton wrote:
2) In an alternate vision, Zope 2 evolves to Zope 5.
+1 as already discussed at PyCON.
- Zope 5 will be the application server generally known as Zope. It will be backward compatible (to the same degree that Zope 2 releases are currently backward compatible with previous Zope 2 releases) with Zope 2. Zope 5 will similarly be backward compatible with Zope 3 applications built on top of the current Zope 3 application server.
Note that Zope 5 will leverage Zope 3 technologies to allow a variety of configurations, including a Zope 2-like configuration with implicit acquisition and through-the-web development, and a Zope 3-like configuration that looks a lot like the current Zope 3 application server. Maybe, there will be a configuration that allows Zope 2 and Zope 3 applications to be combined to a significant degree.
- Zope 3 will explode. :)
For many people, Zope 3 is first a collection of technologies that can be assembled into a variety of different applications. It is second a Zope 2-like application server. I think that these folks aren't really interested in the (Zope 2-like) application server.
Zope 3 will continue as a project (or projects) for creating and refining these technologies.
(It would probably make sense for this activity to to have some name other than "Zope". On some level, the logical name would be "Z" (pronounced "Zed" :). An argument against "Z" is that it would be hard to google for, but Google handles such queries quite well and I'd expect that we'd move to the top of Google Z search results fairly quickly. However, I'll leave naming decisions to experts. ;)
I would vote for spelling out Zed (which would also be a little easier to google but might create trademark problems). The namespace package could either be 'z' or 'zed'. Then again, I really should take Jim's side and stay out of naming decisions.
Advantages of this vision:
- Zope 2 users don't need to leave Zope 2.
- Zope 3 doesn't have to reproduce all Zope 2 features.
- There wouldn't be confusion about 2 Zopes.
It is important that Zope 5 be backward compatible with both Zope 2 and Zope 3, although not necessarily in the same configuration. Many people are building Zope 3 applications today and they should not be penalized.
I'll note that while Zope will remain to be the application server (in its Zope 5 incarnation), you should and would still be able to create WSGI-capable object-publishing applications with the Zed pieces fairly easily, for example when you don't need the full-blown Zope experience. I will also note that just because Zope 2 won't die, it doesn't mean we shouldn't clean it up. Eventually, Zope should mostly be reusing things from Zed. A Zope distribution would include a fair number of Zed eggs and the Zope-specific things should live under the 'Zope2' namespace package. Fortunately we're already starting with cleaning up some of the top-level packages (zLOG, TAL, StructuredText) in Zope 2.10. Philipp
On Tue, Feb 28, 2006 at 12:31:33AM +0100, Philipp von Weitershausen wrote:
I will also note that just because Zope 2 won't die, it doesn't mean we shouldn't clean it up. Eventually, Zope should mostly be reusing things from Zed.
+sys.maxint I think this will be the way we get a real forward migration path for an awful lot of us who are still using Zope 2 today, and expect to continue doing so. We may or may not ever port to "zope 3", whatever that will mean in the future. More likely we will just incrementally improve and clean up our applications, just as Zope 2 itself will be getting incrementally better and cleaner. We'll have to address deprecation warnings at each upgrade, but at no point will we be forced to do a complete rewrite. And along the way, we'll be gradually getting access to more and more nifty features. -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote:
On Tue, Feb 28, 2006 at 12:31:33AM +0100, Philipp von Weitershausen wrote:
I will also note that just because Zope 2 won't die, it doesn't mean we shouldn't clean it up. Eventually, Zope should mostly be reusing things from Zed.
+sys.maxint
I think this will be the way we get a real forward migration path for an awful lot of us who are still using Zope 2 today, and expect to continue doing so.
We may or may not ever port to "zope 3", whatever that will mean in the future. More likely we will just incrementally improve and clean up our applications, just as Zope 2 itself will be getting incrementally better and cleaner. We'll have to address deprecation warnings at each upgrade, but at no point will we be forced to do a complete rewrite. And along the way, we'll be gradually getting access to more and more nifty features.
I don't see how we need a new vision. This has been the vision (evolution, not revolution) that I've been carrying out with Five for the last few years and thanks to a lot of contributions by a large range of developers, we've been making it work. Can't we just keep going on the way we've been going then? Regards, Martijn
On Tuesday 28 February 2006 07:22, Martijn Faassen wrote:
I don't see how we need a new vision. This has been the vision (evolution, not revolution) that I've been carrying out with Five for the last few years and thanks to a lot of contributions by a large range of developers, we've been making it work. Can't we just keep going on the way we've been going then?
+1, I totally agree. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Martijn Faassen wrote:
I will also note that just because Zope 2 won't die, it doesn't mean we shouldn't clean it up. Eventually, Zope should mostly be reusing things from Zed.
+sys.maxint
I think this will be the way we get a real forward migration path for an awful lot of us who are still using Zope 2 today, and expect to continue doing so. We may or may not ever port to "zope 3", whatever that will mean in the future. More likely we will just incrementally improve and clean up our applications, just as Zope 2 itself will be getting incrementally better and cleaner. We'll have to address deprecation warnings at each upgrade, but at no point will we be forced to do a complete rewrite. And along the way, we'll be gradually getting access to more and more nifty features.
I don't see how we need a new vision. This has been the vision (evolution, not revolution) that I've been carrying out with Five for the last few years and thanks to a lot of contributions by a large range of developers, we've been making it work. Can't we just keep going on the way we've been going then?
In many ways, that's precisely the idea. However, I agree with Jim when he says that we currently have a Zope 2 wanting to become like Zope 3 and a Zope 3 wanting to get all that what Zope 2 has. That'll leave us with two Zopes for a while. Zope 3 is "exploding" into several bits and pieces. That is good. The question is whether one of those (larger) pieces will also be an app server or whether one app server that evolves just the way we've been evolving it since Zope 2.8 is enough. I think focusing on one app server and a dedicated set of libraries would be a good alternative to two concurring app servers. Philipp
--On 28. Februar 2006 16:06:55 +0100 Philipp von Weitershausen <philipp@weitershausen.de> wrote:
I think focusing on one app server and a dedicated set of libraries would be a good alternative to two concurring app servers.
+1 -aj
Philipp von Weitershausen wrote:
Martijn Faassen wrote: [snip]
I don't see how we need a new vision. This has been the vision (evolution, not revolution) that I've been carrying out with Five for the last few years and thanks to a lot of contributions by a large range of developers, we've been making it work. Can't we just keep going on the way we've been going then?
In many ways, that's precisely the idea. However, I agree with Jim when he says that we currently have a Zope 2 wanting to become like Zope 3 and a Zope 3 wanting to get all that what Zope 2 has.
I don't see how that is a "however". This situation is exactly right in my opinion.
That'll leave us with two Zopes for a while.
Yes, having two Zopes is in my opinion completely unavoidable for the forseeable future.
Zope 3 is "exploding" into several bits and pieces. That is good. The question is whether one of those (larger) pieces will also be an app server or whether one app server that evolves just the way we've been evolving it since Zope 2.8 is enough.
I'm not sure what you mean here. I expect Zope 3 to keep the pieces it has right now, including the appserver bits. Nobody is proposing we throw away code, right? If someone has the time to replace Zope 2's appserver with what's in Zope 3, then that would be good and we'll see that happen some Zope 2 releases in the future. Calling that Zope 5 is not going to make it happen any faster. "explosion", whether Zope 3 is going to be managed as a number of components or as a single story doesn't matter much for this. Presumably we'll still have Zope 3 releases that I can run, say, the documentlibrary on. For the component integrators (but that's mostly the Zope core developers) things will change. From the developer's perspective, and the deployer's perspective using Zope not that much will change - you'll still install Zope 2 or Zope 3. Perhaps the way you install it is different, but a Zope developer or deployer would typically still end up installing something that's called Zope.
I think focusing on one app server and a dedicated set of libraries would be a good alternative to two concurring app servers.
I don't see how else we can get there than by the route we've been taking: continuous evolution with small steps. Saying we'll have Zope 5 in the future which will include both still means we need to get there. I don't see how introducing a new name in the mix is going to help anyone, and I think in fact it will hurt. We make a commitment we'll do something, but nobody is actually signing up to actually do it in the foreseeable future. Regards, Martijn
Philipp von Weitershausen wrote: [snip]
I would vote for spelling out Zed (which would also be a little easier to google but might create trademark problems). The namespace package could either be 'z' or 'zed'.
Then again, I really should take Jim's side and stay out of naming decisions.
Let's please not have a naming discussion again. I think renaming Zope 3 is really bad marketing myself and naming discussions mostly a waste of time... Regards, Martijn
Martijn Faassen wrote:
Philipp von Weitershausen wrote: [snip]
I would vote for spelling out Zed (which would also be a little easier to google but might create trademark problems). The namespace package could either be 'z' or 'zed'.
Then again, I really should take Jim's side and stay out of naming decisions.
Let's please not have a naming discussion again. I think renaming Zope 3 is really bad marketing myself and naming discussions mostly a waste of time...
Regards,
Martijn
please, not Z, it is an oscar-winning film from the 70's about political corruption, military coup d'état, .. http://www.bbc.co.uk/bbcfour/cinema/features/z.shtml /JM
On Tue, 2006-28-02 at 13:21 +0100, Martijn Faassen wrote:
Philipp von Weitershausen wrote: [snip]
I would vote for spelling out Zed (which would also be a little easier to google but might create trademark problems). The namespace package could either be 'z' or 'zed'.
Then again, I really should take Jim's side and stay out of naming decisions.
Let's please not have a naming discussion again. I think renaming Zope 3 is really bad marketing myself and naming discussions mostly a waste of time...
As I sit here spending sooo much time reading this thread, I've finally decided its time to throw in my own naive point of view as an ex-J2EE developer and a Zope 2 developer that generally builds applications on top of Zope2/CMF/Plone. Let me make a random comments. 1) The Zope 3 name and brand is a marketing disaster (from my perspective) -- to be honest there's really no way I could see this actually getting worse by coming up with a new name. How many times in the #plone channel do we get asked, "Does Plone run on Zope 3.1/3.2?" or, "When will Plone run on Zope 3.2" to which we say "no" to the first question and "dunno" to the second question. 2) Today when I build new applications with Plone, the best I can hope for is to use Zope 3 as a framework and Zope 2 as a deployment platform. Although the reality is I still use Zope 2 as a framework faaaar too much as well. I'm hoping (expecting) that Five will continue to make the requirement to use Zope 2 as a framework diminish more and more. As a developer, I certainly prefer working with Zope 3 "the framework" over Zope 2 "the framework". 3) New developers who are moving in to either learn how to use Zope to develop applications or support existing zope applications of course immediately download the highest number Zope (zope 3 of course). They start using it and (hopefully) enjoy working on it and discover there's a big zope community with lots of developed applications. Then this developer starts googling for a type of plugin/component he needs to make sure he's not reinventing the wheel and discovers there's a HUGE plethora of "Zope" applications that do not even run on his latest zope platform and won't run on that platform in the foreseeable future. Ok, let me say what I think regarding these things. If we started treating zope 3 as just a framework and put energies back into maintaing/refactoring/beautifying zope2 as an application server that uses that framework at its core (this is essentially what zope 2.8+ is working towards with Five IMHO) then this could help several ways: 1) we stop spending time reproducing zope2 app server functionality in zope3 2) we stop building more into zope2 as a framework (i think this is pretty much already happening) Anyway, this still keeps things very confusing from a naming perspective (mostly for new adopters). So .... having said all of that, I am actually +1 on Jim's proposal #2. What I see from that (someone correct me if I'm wrong) is the following: 1) rename zope 3 the framework as Z or zopelib or Zed or something sensical that doesn't confuse the early adopter's conquest of trying to figure out which zope to start with 2) Make zope 2 the application server acquire the name "zope" once again and be the only app server. This could only work (from a new adopter's perspective) if either the application server is given a new name or given a version number higher than 3. Who are we worried aboug confusing here? Existing Zope 3 developers? Zope 2 developers? I don't think so, those people are smart enough to figure it out. So I say lets focus on not confusing new adopters in which case SOMETHING HAS TO BE DONE ABOUT THE CURRENT NAMING SITUATION! Kind Regards, Rocky -- Rocky Burt AdaptiveWave - Consulting, Training, and Content Management as a Service http://www.adaptivewave.com Content Management Made Simple
On Thu, 02 Mar 2006 09:43:03 -0330, Rocky Burt wrote:
Anyway, this still keeps things very confusing from a naming perspective (mostly for new adopters). So .... having said all of that, I am actually +1 on Jim's proposal #2. What I see from that (someone correct me if I'm wrong) is the following:
1) rename zope 3 the framework as Z or zopelib or Zed or something sensical that doesn't confuse the early adopter's conquest of trying to figure out which zope to start with 2) Make zope 2 the application server acquire the name "zope" once again and be the only app server. This could only work (from a new adopter's perspective) if either the application server is given a new name or given a version number higher than 3.
I agree with Rocky's assessment. +1 on Jim's suggestion #2. However, if I am understanding things correctly, it doesn't really sound like door #2 entails a huge deviation from from our current course of bringing Zope 2 and Zope 3 together gradually. I don't really care what the converged product is called, Zope 2.250 or Zope 3.99 or Zope 5. My take is that Jim is not really proposing anything all that different from what Martijn wants -- a gradual convergence of Zope 2 and 3. Rather, it sounds like the biggest changes in Jim's proposal #2 entail 1) a change in how we _talk_ about what we are doing, and 2) an explicit attempt to factor out some of the Zope 3 goodness into a more generic, less-monolithic-app-server framework, Zed. (am I right here, Jim?) I think that the idea of giving Zed its own, distinct identity is great. Zope 3 is a _huge_ overhaul and it needs to be obvious to the world that it is dramatically better than crufty old Zope 2. Zope 3 then becomes the Zed application server; Zope 2 is getting Zed retrofits via Five, and the two will eventually converge into Zope 5. A distinct Zed distribution could bring in developers who are just interested in using the component architecture but not necessarily a big app server stack. It would be cool to see Zed popping up in random python products or perhaps in TurboGears / Django internals. And more than just cool -- the more people we can get using Zed, the more code we will be able to mix in easily to Zope (2/3/5) applications. Geoff
On Thu, 02 Mar 2006 09:43:03 -0330, Rocky Burt wrote:
On Tue, 2006-28-02 at 13:21 +0100, Martijn Faassen wrote:
Philipp von Weitershausen wrote: [snip]
I would vote for spelling out Zed (which would also be a little easier to google but might create trademark problems). The namespace package could either be 'z' or 'zed'.
Then again, I really should take Jim's side and stay out of naming decisions.
Let's please not have a naming discussion again. I think renaming Zope 3 is really bad marketing myself and naming discussions mostly a waste of time...
As I sit here spending sooo much time reading this thread
yes, it's a big'un alright...
1) The Zope 3 name and brand is a marketing disaster (from my perspective) -- to be honest there's really no way I could see this actually getting worse by coming up with a new name. How many times in the #plone channel do we get asked, "Does Plone run on Zope 3.1/3.2?" or, "When will Plone run on Zope 3.2" to which we say "no" to the first question and "dunno" to the second question.
+100. it's a confusing mess to anyone who isn't spending as much time as we all are reading this stuff every day. come to think of it, it's a confusing mess to us, too.
If we started treating zope 3 as just a framework and put energies back into maintaing/refactoring/beautifying zope2 as an application server that uses that framework at its core (this is essentially what zope 2.8+ is working towards with Five IMHO) then this could help several ways: 1) we stop spending time reproducing zope2 app server functionality in zope3 2) we stop building more into zope2 as a framework (i think this is pretty much already happening)
i agree with this sentiment, although i do recognize that there are folks who are currently using zope3 as an app-server, and who (understandably) don't want to have anything to do w/ anything zope2 related, ever again.
Anyway, this still keeps things very confusing from a naming perspective (mostly for new adopters). So .... having said all of that, I am actually +1 on Jim's proposal #2. What I see from that (someone correct me if I'm wrong) is the following:
1) rename zope 3 the framework as Z or zopelib or Zed or something sensical that doesn't confuse the early adopter's conquest of trying to figure out which zope to start with 2) Make zope 2 the application server acquire the name "zope" once again and be the only app server. This could only work (from a new adopter's perspective) if either the application server is given a new name or given a version number higher than 3.
i support this idea as well, but i think we have to recognize that there will be some parallel app-server-ness happening for a while, until z2 becomes so thin that we have achieved complete convergence btn the z2/five-based and the z3-based app server platforms that are already being used. -r
Strange how (most of) the Plone people seem to be so quick in willing to sacrifice the Zope brand :( S. -- Stéfane Fermigier, Tel: +33 (0)6 63 04 12 77 (mobile). Nuxeo Collaborative Portal Server: http://www.nuxeo.com/cps Gestion de contenu web / portail collaboratif / groupware / open source!
Stefane Fermigier wrote:
Strange how (most of) the Plone people seem to be so quick in willing to sacrifice the Zope brand :(
um, if you reread what i said, and what i think rocky is trying to say, i'm in favor of _keeping_ the zope brand for the app server, which is what zope has always been, and what plone runs (and will continue to run) on top of. strange how stefane seems to be so quick to write incendiary posts w/o any real content in them... -r
Stefane Fermigier wrote:
Strange how (most of) the Plone people seem to be so quick in willing to sacrifice the Zope brand :(
It's not about sacrificing the Zope-the-app-server brand. It's actually about growing it in the sense that it becomes much clearer WHAT THE HELL Zope actually is. Or can you explain what Zope is in one sentence? I surely can't. I currently need more than a page in my book. Rocky Burt is right, the naming actually confuses the heck out of people. In that sense, Zope X3 was not such a bad idea that it clearly said that Zope 3 is totally different. Just the 'X' itself standing for 'eXperimental' was bad Zope3-marketing in itself, so we dropped it. I will also note that Jim's proposal is really not a lot about naming (he wants to stay out of it) but about focusing effort in ONE application server and ONE set of reusable libraries. This focus in efforts seems to suggest to come up differnet names for the two things, but that doesn't mean they can't still be related in a brand naming sense (e.g. Zope and zopelib or somethign like that). Philipp
[ Philipp von Weitershausen ]:
It's not about sacrificing the Zope-the-app-server brand. It's actually about growing it in the sense that it becomes much clearer WHAT THE HELL Zope actually is. Or can you explain what Zope is in one sentence?
But it all comes down to the depths (or shallowness) of defining 'explain'. There is at least one definition of 'explain' where a Zope definition could take less than a page or a book. ;o) """ A middleware for building web applications from an integrated pack of servers (HTTP, FTP, XML_RPC, WebDAV), databases (OO, Relational) and engines (language and template). """
I surely can't. I currently need more than a page in my book.
Which I have and consider a good book by the way. The important thing I'd like to say is that Zope *is* a brand here in Brazil. Companies identify themselves having expertise in Zope and Plone technologies. Not just the former or just the latter. Even though there are clients looking for Plone, they know (at least most of us make sure they do) that Zope is needed.
Rocky Burt is right, the naming actually confuses the heck out of people. In that sense, Zope X3 was not such a bad idea that it clearly said that Zope 3 is totally different. Just the 'X' itself standing for 'eXperimental' was bad Zope3-marketing in itself, so we dropped it.
Yes, I could not agree more that some effort must be taken to clear up the confusion about Zope versioning for both developers and client users. But specially for newcomer-developers, those who do not follow closely the community activity get bitten by Zope version-diversity: 2.8.x, 2.9.x and 3.x
I will also note that Jim's proposal is really not a lot about naming (he wants to stay out of it) but about focusing effort in ONE application server and ONE set of reusable libraries.
That is very welcome indeed!
efforts seems to suggest to come up differnet names for the two things, but that doesn't mean they can't still be related in a brand naming sense (e.g. Zope and zopelib or somethign like that).
I acknowledge the importance of whatever name is chosen, a direct reference to Zope is desirable. cheers, Rod Senra http://rodrigo.senra.nom.br
On Thu, 02 Mar 2006 19:31:38 -0000, Stefane Fermigier <sf@nuxeo.com> wrote:
Strange how (most of) the Plone people seem to be so quick in willing to sacrifice the Zope brand :(
I don't think that's true. I'm certainly not, and I've not heard anyone directly in favour of that either. What I *am* in favour of is branding the current Zope efforts much more strongly, and I think that an *additional* name to hype a Zope 3 brand around (Zope 3 Zebra or whatever) would make such marketing easier. Building our software on a less obscure appserver would make Plone much stronger. I know a very large organisation that would jump on Plone if it were built in Java. Zope is scary. Martin -- (muted)
Stefane Fermigier wrote:
Strange how (most of) the Plone people seem to be so quick in willing to sacrifice the Zope brand :(
In out world Zope doesn't have a brand. Plone has a it. Most of our customers doesn't have a clue as to what Zope is. As far as I can tell, Zope is a developers brand. No end users (customers) starts up with Zope anymore. Rather they go straight to Plone/CPS etc. Splitting up Zope to let people use seperate pieces of Zope aka Zed is not a valid reason. Good software practise is a valid reason. But catering for those few developers that wants to use just a few pieces is probably not worth the effort. Zope didn't become really popular before Plone/CPS etc. In my case customers are calling and asking for Plone solutions. Nobody where ever asking for Zope solutions! You had to push hard to make the customer use Zope instead of .asp/Java etc. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science
On Mar 3, 2006, at 3:08 AM, Max M wrote:
Splitting up Zope to let people use seperate pieces of Zope aka Zed is not a valid reason. Good software practise is a valid reason. But catering for those few developers that wants to use just a few pieces is probably not worth the effort.
Here's one of the reasons I want good packaging: I'd like to continue using Zope-the-technology even if the Zope-the-brand loses all recognition. Whether in the future I'm working on DjangoRailsGears 3.0 or Zope3006 or Plone-NG, I'd like to be able to carry the various bits of technology that make up Zope around with me reasonably easily and run it under different Python platforms. I say this with my cynical and Zope-bigoted "consultant" hat on. There. I said it. ;-) - C
On Thu, 2006-02-03 at 19:31 +0000, Stefane Fermigier wrote:
Strange how (most of) the Plone people seem to be so quick in willing to sacrifice the Zope brand :(
Were this truly the case, most "Plone people" wouldn't bother contributing to this thread. But the reality is -- I (from a "Plone people" point of view) am very concerned about the future of Zope from both technology and marketing standpoints. I do python/zope/plone consulting for a living -- it thrills me when I can say to a fairly technology-savvy client that I will deploy my solution on top of Zope and they say, "Oh Zope? I've heard thats pretty good." And yes, it has happened. - Rocky -- Rocky Burt AdaptiveWave - Consulting, Training, and Content Management as a Service http://www.adaptivewave.com Content Management Made Simple
On Monday 27 February 2006 10:37, Jim Fulton wrote:
1) Our current vision (AFAIK) is that Zope 3 will eventually replace Zope 2
2) In an alternate vision, Zope 2 evolves to Zope 5.
As you probably know already, I am -1 on the second proposal, since it will disallow us to finally get rid of the old Zope 2 code. Anyways, since I think the vision has too littel technical detail for my taste, I would really like to see some prototyping before I give my final vote. I just want to be ensured that I do not have to deal with additional overhead (i.e. learn Zope 2 again), but can develop Zope 3 applications as I like it. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
--On 27. Februar 2006 21:57:46 -0500 Stephan Richter <srichter@cosmos.phy.tufts.edu> wrote:
On Monday 27 February 2006 10:37, Jim Fulton wrote:
1) Our current vision (AFAIK) is that Zope 3 will eventually replace Zope 2
2) In an alternate vision, Zope 2 evolves to Zope 5.
As you probably know already, I am -1 on the second proposal, since it will disallow us to finally get rid of the old Zope 2 code.
Like it or not...I agree with Jim's vision will just be the reality. As long as we do support Zope 2 we will move more and more Z3 technology into Zope 2 which will strengthen Zope 2. I still do not see that Zope 3 will provide everything we need to build large-scale applications. Having CMF 2.0 and having some future Plone version running on top I don't see that Zope 2 will fade out. Andreas
Stephan Richter wrote:
1) Our current vision (AFAIK) is that Zope 3 will eventually replace Zope 2
2) In an alternate vision, Zope 2 evolves to Zope 5.
As you probably know already, I am -1 on the second proposal, since it will disallow us to finally get rid of the old Zope 2 code.
Either way we're not getting rid of the old Zope 2 code for a while.
Anyways, since I think the vision has too littel technical detail for my taste, I would really like to see some prototyping before I give my final vote.
I'm not really sure how you think we should do that... Prototyping an entire vision is a lot of work ;)
I just want to be ensured that I do not have to deal with additional overhead (i.e. learn Zope 2 again), but can develop Zope 3 applications as I like it.
I really don't think you'd have to learn Zope 2 again. As I noted in my short response to Jim's proposal, a) you'll be able to continue to create web apps with just the Zed components. There won't be a zed.app or so, but zed.publisher would be the WSGI-capable publishing machinery that you can use to (given appropriate publication objects or whatever will be there in the future) publish objects using views and whatever we have not right now. b) Zope 5 will use zed functionality all over the place. Our current efforts with Five are providing a good deal of this already and we're going to continue with that. Having to learn "Zope 2" all over again will probably not mean the same thing in the context of Zope 5 as it does right now. Philipp
Philipp von Weitershausen wrote:
Stephan Richter wrote:
1) Our current vision (AFAIK) is that Zope 3 will eventually replace Zope 2
2) In an alternate vision, Zope 2 evolves to Zope 5.
As you probably know already, I am -1 on the second proposal, since it will disallow us to finally get rid of the old Zope 2 code.
Either way we're not getting rid of the old Zope 2 code for a while.
Yes, the Zope 2 codebase is going to stay. It isn't going to stay for everybody in all Zope related projects, and it's already quite doable to keep Zope 2 in the background while developing new software for Zope 2, but the codebase isn't going to disappear. This doesn't mean it should be there for people who are building new applications. [snip]
I really don't think you'd have to learn Zope 2 again. As I noted in my short response to Jim's proposal,
a) you'll be able to continue to create web apps with just the Zed components. There won't be a zed.app or so, but zed.publisher would be the WSGI-capable publishing machinery that you can use to (given appropriate publication objects or whatever will be there in the future) publish objects using views and whatever we have not right now.
b) Zope 5 will use zed functionality all over the place. Our current efforts with Five are providing a good deal of this already and we're going to continue with that. Having to learn "Zope 2" all over again will probably not mean the same thing in the context of Zope 5 as it does right now.
Could you please stop using a new name for Zope 3 or the zope package? You can explain this perfectly well using the existing, well established names. I'll rewrite it to demonstrate this: a) you'll be able to continue to create web apps with just the Zope 3 components. There won't be a zope.app anymore, but zope.publisher would be the WSGI-capable publishing machinery that you can use to (given appropriate publication objects or whatever will be there in the future) publish objects using views and whatever we have not right now. This is a proposal for the evolution of Zope 3. Zope 3 is already going in this direction. b) Zope 2 will use Zope 3 functionality all over the place. Our current efforts with Five are providing a good deal of this already and we're going to continue with that. Having to learn "Zope 2" all over again will probably not mean the same thing in the context of Zope 2 + Five as it does right now. This is what we are actually doing with Zope 2 right now, starting with Five on top of Zope 2.7, and continued further with Zope 2.8, Zope 2.9 and presumably Zope 2.10 and beyond. It's nothing new, and it will take more effort and time to get further. Renaming this to Zed or Zope 5 is not going to make anyone's life simpler or easier, nor will it make any development go faster than it does now. Instead we're going to confuse everybody with completely uncalled for name changes. Regards, Martijn
On Feb 27, 2006, at 10:37 AM, Jim Fulton wrote:
2) In an alternate vision, Zope 2 evolves to Zope 5.
Of the two, this seems more believable. It also may be the best we can do. However, I still don't like it. :-)
- Zope 5 will be the application server generally known as Zope. It will be backward compatible (to the same degree that Zope 2 releases are currently backward compatible with previous Zope 2 releases) with Zope 2.
This is reasonable, though I don't love it.
Zope 5 will similarly be backward compatible with Zope 3 applications built on top of the current Zope 3 application server.
This gets to the heart of my concern, I guess (see below).
Note that Zope 5 will leverage Zope 3 technologies to allow a variety of configurations, including a Zope 2-like configuration with implicit acquisition and through-the-web development, and a Zope 3-like configuration that looks a lot like the current Zope 3 application server. Maybe, there will be a configuration that allows Zope 2 and Zope 3 applications to be combined to a significant degree.
You say that one of the advantages of this vision is that "There wouldn't be confusion about 2 Zopes". I'm afraid that's wishful thinking, if you want "Zope 5" to include a Zope 3-like web configuration. If you are going to pursue a "Zope Five and the artist formerly known as Zope 3" vision, in which Zope is a single clear product, then it seems to me that Zope Five should be one or the other, and that's what books should describe. A Zope 2 derivative a la Five makes sense, given Zope's history and current users. More below.
- Zope 3 will explode. :)
For many people, Zope 3 is first a collection of technologies that can be assembled into a variety of different applications. It is second a Zope 2-like application server. I think that these folks aren't really interested in the (Zope 2-like) application server.
There are some--Steve Alexander and Canonical, maybe?--who might not care about anything beyond choosing among the bag of technologies. But I assert with the right of speaking loudly (i.e., I have no way to prove this) that there are many who appreciate the "bag of components" design who still want to buy into some of the "Zope 3 as web application server" story. For instance, if you mean by "a Zope 2-like application server" "an Object File System approach" then I certainly hope you are wrong. Even though I don't care much about the Zope 3 ZMI, Zope 3 encapsulates some web app design decisions I would be loathe to lose. I much prefer the Zope 3 approach to OFS, with __parent__ rather than acquisition wrappers, a dict interface rather than objectValues and friends, and traversal adapters rather than __bobo_traverse__ and friends. If acquisition and all the rest are on the way to being replaced within Zope 2/5, then...yay? but then how is it still "Zope 2 backward compatible"? They seem core to Zope 2 to me. And the Zope 3 versions of the decisions inform many Zope 3 component designs. Do you mean that the Zope 3 users don't need Zope 2 cataloging and indexing? Surely not, and yet again moving Zope Five to the Zope 3 catalog seems pretty questionable as "Zope 2 backward compatible". And I *much* prefer the zope.index/zope.app.keyref/zope.app.intid combo in Zope 3. Do you mean that Zope 3 users aren't looking for a better designed web app than Zope 2, that looks less "long-in-the-tooth" (as I've seen blogs call Zope 2), that has more industrial-strength flexibility and hard-won design experience than the current crop of competitors? I don't think so: I assert that developers of a certain inclination are attracted to the cleanliness of Zope 3 as a web app, and not as attracted to the cruft that accumulates in an older, very successful project like Zope 2. Some of those are new Zope developers, and some are prominent older Zope developers. Do you mean that Zope 3 users don't want a robust, battle-hardened web publisher like the Zope 2 publisher? I think many do. So, I assert that many Zope 3 users, who are in it for the "bag of components", *do* want a web application server. If I'm misunderstanding you, then, as Stephan said, maybe you could explain more. (Almost done, but still more below)
Zope 3 will continue as a project (or projects) for creating and refining these technologies.
(It would probably make sense for this activity to to have some name other than "Zope". On some level, the logical name would be "Z" (pronounced "Zed" :). An argument against "Z" is that it would be hard to google for, but Google handles such queries quite well and I'd expect that we'd move to the top of Google Z search results fairly quickly. However, I'll leave naming decisions to experts. ;)
If this is the plan, then I guess I just think that "Zed" needs to include an app server, and needs to keep on living independently. "Zope Five" needs to be Zope 2, bumped up (rather inexplicably to the outside world) to version 5. OK. I'm excited about the prospects of a Zope Five that shares "Zed"s publisher and gives it the workout and battle-hardening it needs. I'm excited about the prospects of a Zope Five that encourages Zope 2/5 developers to think of themselves more as Python developers, and ZODB component developers. But I'm not excited about losing the changes and wins that a rethought-Zope 3 web application brought. Zope 3 is not just a bag of nice technology: it is a conscious rejection of some core Zope 2 decisions. I think the rejection was a good thing. Finally, I'm also skeptical of a vision that claims "unity" when, with the "Configure Zope 5 as Zope 3" approach, all it seems we will have gained is unity of name, rather than true unity of vision. On the other hand, maybe that's enough. I offer my observations with humility, and true appreciation of what you and others, like Philipp, are trying to do. As Andreas says, maybe this is the best we can do. I wish I liked it more. Gary
Jim Fulton wrote:
I'd like to get feedback on two possible visions for the future of Zope 2 and Zope 3.
1) Our current vision (AFAIK) is that Zope 3 will eventually replace Zope 2 [snip]
2) In an alternate vision, Zope 2 evolves to Zope 5. [snip]
Thoughts?
My initial reaction is: don't change the names (or at least be extremely careful about this). Zope 3 has a brand and we'd risk throwing it all away. We also risk being seen as wavering on the course. I don't see the two proposals as mutually exclusive, and I think both are true right now. Zope 3 is replacing Zope 2 for some new applications. Zope 2 is evolving towards Zope 3 for existing applications. I wrote a piece of text about the relationship between Zope 2 and Zope 3 that might help in this discussion: [snip section about Zope being mature] Going forward ------------- We are applying our hard-earned lessons by making Zope better. The web is evolving and so is Zope, continuously striving to further increase Zope's power, flexibility and functionality. A visionary project was started in 2001 to build the next generation of Zope software, `Zope 3`_. Zope 3 uses powerful component technology to further increase the already strong extensibility and flexibility of the Zope platform. The Zope 3 project is benefiting in this from the deep experience of a large community of Zope 2 developers. Zope 2 is not being left behind however: the Zope community initiated a project called Five_ (2 + 3) to bring Zope 3 technology, where mature technology is ported back into the Zope 2 platform to obtain the best of both worlds. Zope 2 now contains Zope 3 technology and will go forward on this path with every release, while Zope 3 is forging ahead to explore new possibilities. Zope 2 and Zope 3 are evolving together this way, both benefiting from each other's strengths, until the differences between the two eventually disappear. Zope 2 and Zope 3 ----------------- Zope comes in two flavors, Zope 2 and Zope 3. Zope 2 is a mature, compatible and reliable platform that supports an enormous amounts of features. It's the workhorse of our community. Zope 3 provides a powerful component architecture and a clean, elegant architecture that is a developer's dream. It's our community's thoroughbred. It can be hard to choose between the two. Eventually you won't have to as they're evolving towards each other [Going Forward]. But how do you choose now? Here are some rough guidelines: If you are a hard-core developer, looking for power and flexibility in a clean architecture, and if you are building a new web application, you may want to consider Zope 3. If you want to make use of the rich variety of powerful Zope 2 software, need community, support and stability, consider Zope 2. And don't forget that with the Five_ (2 + 3) project, you can already start using Zope 3 technologies from within the safety of Zope 2. Whether you choose Zope 2 or Zope 3 for your project, you will reach the same future, just by a different path. Which path is better for you we leave up to you. .... I think the right way to go forward is to stay the course on this. Zope 3 is the future of Zope 2. Zope 2 will continue to evolve in the direction of Zope 3, while Zope 3 forges ahead. The difference between themselves will eventually disappear. Perhaps what I'm describing is already what you describe for Zope 5. I just don't see the reason to actually change the names, or to imply that Zope 3 does *not* have a future as a platform to build on, which could be seen as an implication of going with Zope 5. Changing names and version numbers around is not going to help anyone very much and I think could in fact be damaging. I think we're actually reaching some clarity of where we are going, people are starting to get the idea, and we just need to communicate it better to the wider world, not change our message. The pent-up demand for Zope 3 technology from Zope 2 developers that existed for a long time in the Zope 2 world while Zope 3 was under development has now been safely channeled into Five-related projects - people can actually use Zope 3 technology right now and worry less about the future. The meme "Evolution not revolution" which I have tried to spread along with Five has taken hold in the various Zope subcommunities. Here's some more of what I wrote: :Q: What's Zope? What's it good for? :A: It's a web application platform that can be used to build web applications, CMSes, etc. :Q: Where's zope coming from? is this some new thing? :A: No, it's mature. We got tons of experience and community and stuff. :Q: By 'mature' do you mean Zope is old cruft? :A: Nope, it's going forward, and has been working on this for years. (Zope 3) :Q: Well what's all this Zope 2 and zope 3 then? should I worry? :A: Nope, we are managing this, you can use either, and get the benefits of both. (Five) I think we can just carry on this message. Regards, Martijn
On Tuesday 28 February 2006 06:51, Martijn Faassen wrote: <snip great discussion>
I think we can just carry on this message.
I could not agree more. I have nothing to add at this point. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Hey, I have another comment about Zope 5, sparked by something Jeff Shell wrote. Currently we have a clear path to evolution. Zope 3 evolves at its pace, and Zope 2 evolves mostly by catching up with Zope 3, replacing more and more bits with Zope 3 bits, which often takes considerable ingenuity. We have shown that we have enough developers to sustain this both for Zope 3 and Zope 2 development. We know how to do it. Any shift to a Zope 5 vision where Zope 3 and Zope 2 are profiles of the same application would require a considerable investment of development time that we don't have, or alternatively, endless waiting. Zope 5 will in fact be very similar to one interpretation of the dreaded X in Zope X3: a version of Zope 3 that's backwards compatible with Zope 2. I'm skeptical about ever getting this done in revolution style development, and holding it up as the future will prompt remarks like "When is Zope 5 going to be done?" while nobody is actually doing anything about it. This is very very bad marketing. I really really want to avoid a repeat of history here... Meanwhile, I think the current path gets us to a future where the difference between Zope 2 and Zope 3 will become less, and it will be more and more possible to write Zope 3 applications in Zope 2, and more and more Zope 2 pieces will be replaced with pieces from Zope 3. This vision has been sold to the community already and we're on track. So, my proposal would be to tone down the vision to what we have already: a co-evolving Zope 3 and Zope 2, with Zope 2 following and Zope 3 leading (or Zope 2 driving Zope 3 forward, however you want to see it). No renaming necessary. No change of course necessary. Zope 2 can stick to Zope 2 features as long as necessary so there's no rush to replicate Zope 2 functionality in Zope 3 any time soon. At the same time, Zope 2 requirements can drive the evolution of Zope 3. I know I sound conservative here, but I'm actually happy with the way things are working now. Let's not fix what isn't broken. We can make incremental steps to making it better, and I'm glad people are starting to understand the ideas behind Five, but I don't see the need for a change of direction. Regards, Martijn
Martijn Faassen wrote:
So, my proposal would be to tone down the vision to what we have already: a co-evolving Zope 3 and Zope 2, with Zope 2 following and Zope 3 leading (or Zope 2 driving Zope 3 forward, however you want to see it). No renaming necessary. No change of course necessary. Zope 2 can stick to Zope 2 features as long as necessary so there's no rush to replicate Zope 2 functionality in Zope 3 any time soon. At the same time, Zope 2 requirements can drive the evolution of Zope 3.
An emphatic +1. -- Benji York Senior Software Engineer Zope Corporation
On Feb 28, 2006, at 9:30 AM, Benji York wrote:
Martijn Faassen wrote:
So, my proposal would be to tone down the vision to what we have already: a co-evolving Zope 3 and Zope 2, with Zope 2 following and Zope 3 leading (or Zope 2 driving Zope 3 forward, however you want to see it). No renaming necessary. No change of course necessary. Zope 2 can stick to Zope 2 features as long as necessary so there's no rush to replicate Zope 2 functionality in Zope 3 any time soon. At the same time, Zope 2 requirements can drive the evolution of Zope 3.
An emphatic +1.
Heh, in retrospect, my "I guess we should go with plan 2" post comes off a bit like Marc Antony's speech in Julius Caesar: Friends, Romans, countrymen, lend me your ears; I come to bury Caesar, not to praise him; The evil that men do lives after them, The good is oft interréd with their bones, So let it be with Caesar. ...Then Antony goes on to praise Caesar. :-) I'm also +1 on Martijn's approach: let's keep Zope 3 around, and stay the course. Also, On Feb 28, 2006, at 10:06 AM, Philipp von Weitershausen wrote:
I think focusing on one app server and a dedicated set of libraries would be a good alternative to two concurring app servers.
...if the single app server is based on acquisition, __bobo_traverse__ and friends, objectValues and friends, ZCatalog, and so on, I'd rather have two, thanks: at least I can have one I like. Gary
Gary Poster wrote: [snip]
On Feb 28, 2006, at 10:06 AM, Philipp von Weitershausen wrote:
I think focusing on one app server and a dedicated set of libraries would be a good alternative to two concurring app servers.
...if the single app server is based on acquisition, __bobo_traverse__ and friends, objectValues and friends, ZCatalog, and so on, I'd rather have two, thanks: at least I can have one I like.
I can see where Philipp is coming from: yes, it would be good to collapse the Zope 2 and Zope 3 communities into one if that frees up more development resources and lets us do less duplicate work. This cannot however be done by big steps or mandate or changing names, and this is where I think I disagree with Philipp somewhat. We're on the right track already. The communities are merging into a single community. Just compare today with the situation just one year ago - massive changes everywhere, and positive ones. Merging communities can be done by making it easier for people from the communities to work together (for instance by working on Five) and by evangelizing (you can use Zope 3 in Zope 2, today). It's fairly subtle work and it takes a long time. Philipp is doing great on all these fronts and without him Five wouldn't be where it is today. I just don't understand how the current zed/Zope 5 proposals would make everything go faster or be easier or be clearer... Regards, Martijn
Martijn Faassen wrote:
I think focusing on one app server and a dedicated set of libraries would be a good alternative to two concurring app servers.
...if the single app server is based on acquisition, __bobo_traverse__ and friends, objectValues and friends, ZCatalog, and so on, I'd rather have two, thanks: at least I can have one I like.
I can see where Philipp is coming from: yes, it would be good to collapse the Zope 2 and Zope 3 communities into one if that frees up more development resources and lets us do less duplicate work.
This cannot however be done by big steps or mandate or changing names, and this is where I think I disagree with Philipp somewhat.
I don't think we disagree here. Like you, Martijn, I believe in evolution. I find the idea of Zope 3 not having to catch up with Zope 2 very appealing. We can continue to evolve Zope 2 instead. And yes, Gary, this means we will eventually get rid of or provide alternatives to crufty Zope 2 APIs. Zope 2.9 has already deprecated one particular Zope 2 API (the event stuff), I expect upcoming versions to do more like that.
We're on the right track already. The communities are merging into a single community. Just compare today with the situation just one year ago - massive changes everywhere, and positive ones.
You're absolutely right. So focusing the effort in the app server development department seems only logical.
I just don't understand how the current zed/Zope 5 proposals would make everything go faster or be easier or be clearer...
It just articulates in papal words what has been going on so far and what might be the future for Zope 3 vs. Zope 2. Leaving aside Jim's naming suggestion, door #2 is a clear vision for the continuation of Zope 2 and Zope 3 in a common platform. It is nothing that is done today or tomorrow. There no immediate speed ups in development, only long-term ones, hopefully. I spend a fair amount of time on Five development just to reproduce Zope 3 features in Zope 2. On the other hand, a lot of people spend a fair amount of time on bringing Zope 2 features to Zope 3. Why couldn't these efforts be consolidated? Will the consolidation product ("Zope 5") be backward compatible with Zope 2.9 as we have it now? Probably not, there's an evolution path to it. Will we be able to evolve to it? I certainly think so. Perhaps it has been misunderstood, but Jim's door #2 proposal doesn't really make any technical claims nor "promises", it is just a vision to focus efforts in certain things. It's an effort roadmap. And it is actually very close to the lines of thinking that let you, Martijn, (and eventually myelf) start or embrace the Five project. I see it as the logical Zope roadmap resulting from the Five efforts. In a way we should be happy that the Five effort showed that Zope 2 is still important but is also willing to evolve. By the way, I think Terry Hancock made some very good points regarding marketing issues. However, as a "core" developer, I would tend my vision is blurred on this particular issue :). Philipp
On Tuesday 28 February 2006 07:39, Martijn Faassen wrote:
I know I sound conservative here, but I'm actually happy with the way things are working now. Let's not fix what isn't broken. We can make incremental steps to making it better, and I'm glad people are starting to understand the ideas behind Five, but I don't see the need for a change of direction.
A strong +1. Wow, I agree with Martijn for three posts in a row; that has not happened for a long time. :-) Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Stephan Richter wrote:
On Tuesday 28 February 2006 07:39, Martijn Faassen wrote:
I know I sound conservative here, but I'm actually happy with the way things are working now. Let's not fix what isn't broken. We can make incremental steps to making it better, and I'm glad people are starting to understand the ideas behind Five, but I don't see the need for a change of direction.
A strong +1.
Wow, I agree with Martijn for three posts in a row; that has not happened for a long time. :-)
+1 for me also. S. -- Stéfane Fermigier, Tel: +33 (0)6 63 04 12 77 (mobile). Nuxeo Collaborative Portal Server: http://www.nuxeo.com/cps Gestion de contenu web / portail collaboratif / groupware / open source!
participants (24)
-
Andreas Jung -
Andrew Sawyers -
Benji York -
Chris McDonough -
Dario Lopez-Kästen -
Dmitry Vasiliev -
Encolpe Degoute -
Gary Poster -
Geoff Davis -
Jean-Marc Orliaguet -
Jim Fulton -
Lennart Regebro -
Martijn Faassen -
Martin Aspeli -
Max M -
Michael Kerrin -
Paul Winkler -
Philipp von Weitershausen -
Rob Miller -
Rocky Burt -
Rodrigo Dias Arruda Senra -
Sidnei da Silva -
Stefane Fermigier -
Stephan Richter