+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, be it 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 (or Z or ZomethingElse). 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 (or Zope 2.27 or whatever). 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 even 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
Geoff Davis wrote:
I think that the idea of giving Zed its own, distinct identity is great.
I think it is stupid. We (Zope Corp + the Zope Community) have spent 8 years building the Zope brand, and you want to restart from scratch ? 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!
On Thursday 02 March 2006 10:29, Stefane Fermigier wrote:
Geoff Davis wrote:
I think that the idea of giving Zed its own, distinct identity is great.
I think it is stupid.
Me too!!!!!! Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
On Thu, 2006-02-03 at 10:32 -0500, Stephan Richter wrote:
On Thursday 02 March 2006 10:29, Stefane Fermigier wrote:
Geoff Davis wrote:
I think that the idea of giving Zed its own, distinct identity is great.
I think it is stupid.
Me too!!!!!!
Not I. Particularly not if we want further adoption "Zed" outside of the zope community. And for the record, I could care less what the name is. But I do think someone in this thread made a good point -- having a name without "zope" will allow for much easier adoption by the rest of the python community. And isn't that what we're all here for? Profile: "Zed", plays nice with others - Rocky -- Rocky Burt AdaptiveWave - Consulting, Training, and Content Management as a Service http://www.adaptivewave.com Content Management Made Simple
Stefane Fermigier wrote:
Geoff Davis wrote:
I think that the idea of giving Zed its own, distinct identity is great..
I think it is stupid.
We (Zope Corp + the Zope Community) have spent 8 years building the Zope brand, and you want to restart from scratch ?
Hehe, poor Geoff. :) In the past, the Zope community hasn't made it a *strategic* goal to play nice with other Python projects. In the past, the Zope community hasn't made it a goal to be a sea of autonomous components. Its goal has been: top-to-bottom app server. We now have (I think!) said those goals are now in scope. Those goals are currently being met using the same name as the assembly. Trying to achieve the goals of the components, using the same word as the assembly, might not be the best way to achieve those goals. The comments I got on my pro-Zope weblog post showed that, if we *do* care about these new goals, we should consider whether the name is a barrier *for the components*. Alternatively, we could say: "The components should only be used in the Zope application server." Perhaps that's the goal. I think Geoff's core point could be met by keeping the word "Zope" for the app server. I think Geoff's deeper point was to rethink the word used for the CA, which actually doesn't want to be thought of us an app server. --Paul
On Thu, 2006-02-03 at 16:49 +0100, Paul Everitt wrote:
I think Geoff's core point could be met by keeping the word "Zope" for the app server. I think Geoff's deeper point was to rethink the word used for the CA, which actually doesn't want to be thought of us an app server.
+1 -- Rocky Burt AdaptiveWave - Consulting, Training, and Content Management as a Service http://www.adaptivewave.com Content Management Made Simple
Stefane Fermigier wrote:
I think that the idea of giving Zed its own, distinct identity is great.
I think it is stupid.
We (Zope Corp + the Zope Community) have spent 8 years building the Zope brand, and you want to restart from scratch ?
Good point. There's the question: Does this "zed" thing need a different name at all? If we want other people to pick it up, then it seems like a good idea to distinguish it from Zope-the-app-server. Paul seems to suggest that in his response. How about zopelib? E.g.: * import zopelib.session * ez_install zopelib.publisher * etc. Actually, Shane suggested this once: http://dev.zope.org/Zope3/ZopeLibPackage Philipp
Philipp von Weitershausen wrote:
Good point. There's the question: Does this "zed" thing need a different name at all? If we want other people to pick it up, then it seems like a good idea to distinguish it from Zope-the-app-server. Paul seems to suggest that in his response.
How about zopelib?
If we want people outside of the zope community to use these components, they should not have the word "zope" anywhere in their name. If it says "zope" people will *always* assume it is for use only with/inside Zope (Zope 2 more often than not). I've seen this when I've told people about testing their web apps with zope.testbrowser. Their first response is invariably "oh, I can't use that; I'm not using Zope." Therefore, whatever the bag-o-components is named it should not contain "zope". "Z" or "zed" would be OK with me (especially if we could come up with some decent domain names that are still available). -- Benji York Senior Software Engineer Zope Corporation
Benji York wrote:
Good point. There's the question: Does this "zed" thing need a different name at all? If we want other people to pick it up, then it seems like a good idea to distinguish it from Zope-the-app-server. Paul seems to suggest that in his response.
How about zopelib?
If we want people outside of the zope community to use these components, they should not have the word "zope" anywhere in their name. If it says "zope" people will *always* assume it is for use only with/inside Zope (Zope 2 more often than not).
I've seen this when I've told people about testing their web apps with zope.testbrowser. Their first response is invariably "oh, I can't use that; I'm not using Zope."
Therefore, whatever the bag-o-components is named it should not contain "zope". "Z" or "zed" would be OK with me (especially if we could come up with some decent domain names that are still available).
I agree. zopelib was just a compromise for the people who like to keep the "zed" thing somewhat associated with Zope-the-project whereas we don't want this to be associated too closely with Zope-the-application-server for the reasons you state above. In the end the question is where we draw the line in all of this. Philipp
Benji York wrote:
Philipp von Weitershausen wrote:
Good point. There's the question: Does this "zed" thing need a different name at all? If we want other people to pick it up, then it seems like a good idea to distinguish it from Zope-the-app-server. Paul seems to suggest that in his response.
How about zopelib?
If we want people outside of the zope community to use these components, they should not have the word "zope" anywhere in their name. If it says "zope" people will *always* assume it is for use only with/inside Zope (Zope 2 more often than not).
Would we want people outside the community to do this? Would it ever be an audience bigger than 5-10 developers somewhere who would even have different goals than the Zope community. It is difficult enough right now to herd this flock of cats called Zope developers. Why would we want to make it even more difficult by adding other communities? Personally I could not care less if Page Templates are used in TurboGears and other frameworks. Splitting up software into chunks with few dependencies should be done because it is good software practice. Not to favour other communities. We should rather make a cool stack that will include people in Zope. Please remember It is *still* the sexiest technology out there! -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science
On Fri, 2006-03-03 at 09:30 +0100, Max M wrote:
Benji York wrote:
If we want people outside of the zope community to use these components, they should not have the word "zope" anywhere in their name. If it says "zope" people will *always* assume it is for use only with/inside Zope (Zope 2 more often than not).
Would we want people outside the community to do this?
We want as much as the python developer as possible to use pieces of zope. This means those pieces of zope will have had greater testing, more reviewing, and ultimately, more people contributing. At this point, I think the number of people that already use zope3 components and have never used zope the application server would be larger than expected. For those who don't get put off by names right away, zope3 CA is a nice piece of work. - Rocky -- Rocky Burt AdaptiveWave - Consulting, Training, and Content Management as a Service http://www.adaptivewave.com Content Management Made Simple
Geoff Davis wrote:
+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, be it 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 (or Z or ZomethingElse).
Am I right here, Jim?
Yup. Realizing that there are two distinc efforts (the app server and the collection of technologies) and making that distinction clear.
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 (or Zope 2.27 or whatever).
Ooops. OK I guess I was clear as mud. :) My idea for "Z", pronounced "zed" or whatever the naming gods decide is that it was *not* an app server. It is an un-app-server. :) A collection of technologies that are useful by themselves, to support an app server and useful to build non-app-server applications, web or otherwise. I think that Z3 is better than Z2 in a lot of ways. I also think that Z2 is more mature and complete. I really want us to combine those efforts. I think we've achieved enough and learned enough with Zope 3 that we can now bring that to bear and make Zope 2 better, refactoring the cruft away and applying the lessons we've learned with Zope 3. (Note that Zope 3 is not crust free.) I don't really care what this thing ends up being called, except that it *must* be called Zope.
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 even 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.
This paragraph makes me think I was clear. Yes, we need to follow Ian Bicking's advice and release our technology in bite-sized chunks. I'm hopeful that the packaging efforts underway will lead to more of that. 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 Thu, 02 Mar 2006 10:38:03 -0500, Jim Fulton wrote:
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 (or Zope 2.27 or whatever).
Ooops. OK I guess I was clear as mud. :) My idea for "Z", pronounced "zed" or whatever the naming gods decide is that it was *not* an app server. It is an un-app-server. :) A collection of technologies that are useful by themselves, to support an app server and useful to build non-app-server applications, web or otherwise.
No, I think I understood you. I was being sloppy in my use of language. I should have said something more like "Zope 3 then becomes an application server built around the Zed library".
I think that Z3 is better than Z2 in a lot of ways. I also think that Z2 is more mature and complete. I really want us to combine those efforts. I think we've achieved enough and learned enough with Zope 3 that we can now bring that to bear and make Zope 2 better, refactoring the cruft away and applying the lessons we've learned with Zope 3. (Note that Zope 3 is not crust free.) I don't really care what this thing ends up being called, except that it *must* be called Zope.
Yes, I agree. "Zope" is the app server. I think that is consistent with the past use of the brand.
This paragraph makes me think I was clear. Yes, we need to follow Ian Bicking's advice and release our technology in bite-sized chunks. I'm hopeful that the packaging efforts underway will lead to more of that.
Yes, and the use of the new name "Z" or "Zed" is a way to emphasize that the Zed library is NOT a big, monolithic app server; rather, it's something new and cool. Geoff
Geoff Davis wrote:
Yes, and the use of the new name "Z" or "Zed" is a way to emphasize that the Zed library is NOT a big, monolithic app server; rather, it's something new and cool.
Zope 3 is new and cool. Or at least, let's spin it this way. Screencasts, podcasts, 14'59" wikis (quicker than TurboGears!), the whole sheebang. 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!
Geoff Davis wrote:
On Thu, 02 Mar 2006 10:38:03 -0500, Jim Fulton wrote:
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 (or Zope 2.27 or whatever). Ooops. OK I guess I was clear as mud. :) My idea for "Z", pronounced "zed" or whatever the naming gods decide is that it was *not* an app server. It is an un-app-server. :) A collection of technologies that are useful by themselves, to support an app server and useful to build non-app-server applications, web or otherwise.
No, I think I understood you. I was being sloppy in my use of language. I should have said something more like "Zope 3 then becomes an application server built around the Zed library".
Good clarification.
I think that Z3 is better than Z2 in a lot of ways. I also think that Z2 is more mature and complete. I really want us to combine those efforts. I think we've achieved enough and learned enough with Zope 3 that we can now bring that to bear and make Zope 2 better, refactoring the cruft away and applying the lessons we've learned with Zope 3. (Note that Zope 3 is not crust free.) I don't really care what this thing ends up being called, except that it *must* be called Zope.
Yes, I agree. "Zope" is the app server. I think that is consistent with the past use of the brand.
Yep.
This paragraph makes me think I was clear. Yes, we need to follow Ian Bicking's advice and release our technology in bite-sized chunks. I'm hopeful that the packaging efforts underway will lead to more of that.
Yes, and the use of the new name "Z" or "Zed" is a way to emphasize that the Zed library is NOT a big, monolithic app server; rather, it's something new and cool.
I think this brings up an interesting paradox in the discussion. We want Zope to continue being the name of an app server. But we also want the CA to be perceived as usable outside of an app server. Outside of Zope, even. Thus, we are using the same name used to convey: "It *is* an app server!" "It's *not* an app server!" I think this might be a contradiction and might be worth discussing. People have it set in their brain that Zope is a monolithic web application server. Hard to dispel that meme. --Paul
Paul Everitt wrote: ...
People have it set in their brain that Zope is a monolithic web application server. Hard to dispel that meme.
Yup. I'd rather adjust the meme to: Zope is a agile flexible extensible app server with rich services. :) 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
Geoff Davis wrote:
No, I think I understood you. I was being sloppy in my use of language. I should have said something more like "Zope 3 then becomes an application server built around the Zed library".
Or "Zed is the part of Zope that can be used without Zope". -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science
participants (11)
-
Benji York -
Geoff Davis -
Jean Jordaan -
Jim Fulton -
Martin Aspeli -
Max M -
Paul Everitt -
Philipp von Weitershausen -
Rocky Burt -
Stefane Fermigier -
Stephan Richter