Hi there, There was some discussion recently on how to name Zope in the future. Here are my thoughts and suggestions. First of all some principles I tend to follow surrounding names. * I prefer not introducing too many new names at the same time. A renaming takes a while to percolate through the community and people to gain full understanding of it. * I prefer naming something that already exists (or renaming something) as opposed to naming something that doesn't really exist yet. A name is a handle on something that we can then use to talk about it and reason about it. * Naming discussions tend to lead to endless bikeshed discussion. Naming stuff is easy so everybody has an opinion, including myself. It's not very productive. We don't have clear community mechanisms to make decisions either (the Zope Framework Steering Group isn't it; it only cares about the Zope Framework. Perhaps the Foundation can be it, but it can only approve initiatives from the community in this area, I think. In this context I'll mention the new name "Zope Framework" that was recently introduced and is probably not yet fully understood by everybody. The Zope Framework is a collection of libraries. It's shared by at least the following web frameworks/app servers: Zope 2 app server, Zope 3 app server, Grok. Other systems such as bfg use a much smaller subset of these libraries. I see this as following the principles above: * it's only introducing a single new name. That's why it at least gets some acceptance now. * it's naming something that we were really already talking about. Unfortunately we conflated it with "Zope 3", the thing you start that has a UI and so on, which retarded the development of both Zope 3 and the Zope Framework itself. It's good we have a handle on it now as a separate entity. This "Zope Framework" name and concept is just now percolating through the community. Zope Framework is *not* the renamed Zope 3, even though it's entirely based on what we used to call Zope 3. Zope 3 continues to exist, as long as there are people who are interested in creating an installation tool for it and care about its UI. Zope Framework is a *separate* entity. Zope 2 and Zope 3 do have confusing names. I prefer to tweak the meaning of "Zope" to be a project identifier instead of identifying software directly: Zope is all of the stuff developed by the Zope project. We therefore have the Zope Object Database, we have the zope component architecture, the zope interface package. This doesn't work for Zope 2 and Zope 3. It works for Grok by the way: I've been saying "Zope Grok" sometimes. With Zope 2 and Zope 3, we have version numbers that are at the same time identifiers of a piece of software itself; they're not really version numbers at all. That's why I have been using terms like Zope 2 App Server and Zope 3 App Server, but that isn't very satisfactory either. The 2 and the 3 still imply some kind of evolutionary progression that isn't quite what we are doing. In order to make Zope 2 and Zope 3 fit the pattern, it'd be nice if they had names that fit the "Zope is a project, not software" pattern. We could rename Zope 2 to Zope Classic, as was suggested. I think we should also rename Zope 3 to something else (that doesn't imply it's the modern future, as there are other alternatives at least as modern around that are more recently developed - we want to get out of that bind). I think renaming Zope 2 to Zope Classic will be easy. If the Zope 2 developers are okay with this, let's go right ahead. Not much discussion needed. Zope 2.11 becomes Zope Classic 11. It's a huge version number, but Zope Classic is over a decade old anyway. Nobody's going to mind. It looks impressive and it should be impressive; Zope Classic has been maintained for a long time by the community. I think it's going to be harder for Zope 3, as the "Zope 3" community: those people who care about Zope 3 as a piece of software that can be installed, hasn't fully formed yet. There's a tool called "zopeproject" which is quite misnamed in the light of the above discussion. While I sometimes do use that piece of software, I'm far more interested in the Zope Framework, myself. Anyway, I'm rather reluctant to post this as I fear this will be a pile-on bikeshed discussion. I'd suggest that anyone interested in naming Zope 3 something else should keep quiet for the time being. Go and form a Zope 3 interest group first, don't talk about naming too much yet in that either, and come back to this topic later. Let's talk about Zope Classic and see whether renaming Zope 2 to that is a step we can realistically take in the near future. Who is in favor of that? Regards, Martijn
Previously Martijn Faassen wrote:
I think renaming Zope 2 to Zope Classic will be easy. If the Zope 2 developers are okay with this, let's go right ahead. Not much discussion needed. Zope 2.11 becomes Zope Classic 11. It's a huge version number, but Zope Classic is over a decade old anyway. Nobody's going to mind. It looks impressive and it should be impressive; Zope Classic has been maintained for a long time by the community.
-1 The term `classic' is associated with things like old, ancient and obsolete to me and immediately makes me want to figure out what the new thing is. I do not think that is desired here: Zope 2 is just as hip and modern as Zope 3 and deserves just as much attention. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Wichert Akkerman wrote:
Previously Martijn Faassen wrote:
I think renaming Zope 2 to Zope Classic will be easy. If the Zope 2 developers are okay with this, let's go right ahead. Not much discussion needed. Zope 2.11 becomes Zope Classic 11. It's a huge version number, but Zope Classic is over a decade old anyway. Nobody's going to mind. It looks impressive and it should be impressive; Zope Classic has been maintained for a long time by the community.
-1
The term `classic' is associated with things like old, ancient and obsolete to me and immediately makes me want to figure out what the new thing is.
+1 to renaming Zope2 to classic for exactly these reasons ;) Hanno
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08.04.2009 15:31 Uhr, Martijn Faassen wrote:
Let's talk about Zope Classic and see whether renaming Zope 2 to that is a step we can realistically take in the near future. Who is in favor of that?
- -100 Renaming Zope 2 to Zope anything does not solve any particular problem and will only lead to confusion. Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknctlAACgkQCJIWIbr9KYwiqACfTfd2XIhYBgQkEqKbQQOYuzgu cisAoNZR/WWJ+qW1wq/Q51QcJaqFvTpl =Whdm -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08.04.2009 16:47 Uhr, Martijn Faassen wrote:
Hi there,
Andreas Jung wrote:
Renaming Zope 2 to Zope anything does not solve any particular problem and will only lead to confusion.
What particular problem is not solved? We may not be talking about the same problem?
There is not much to be added to the posting of Martin Aspelli. If you want to rename Zope 2 then name it "Zope 2 application server" or "Zope Application Server" in order to make its functionality more clear. A name like "Zope Classic" is pretty pointless and information-free. Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkncukMACgkQCJIWIbr9KYxE/ACfWkDPrsFtIRc/rHC7KQg1qPwT YaMAn1PD3os6h9hPoYudybuj3UAu73Es =Xpei -----END PGP SIGNATURE-----
Andreas Jung wrote:
There is not much to be added to the posting of Martin Aspelli. If you want to rename Zope 2 then name it "Zope 2 application server" or "Zope Application Server" in order to make its functionality more clear. A name like "Zope Classic" is pretty pointless and information-free.
ZAS 4.0 works for me. "Zope x y" where x is a number and y is a name is a total fail afaic. Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Andreas Jung wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08.04.2009 15:31 Uhr, Martijn Faassen wrote:
Let's talk about Zope Classic and see whether renaming Zope 2 to that is a step we can realistically take in the near future. Who is in favor of that?
- -100
Renaming Zope 2 to Zope anything does not solve any particular problem and will only lead to confusion.
Sure it does, Zope Classic 4.0 and Zope Toolkit 4.0 are pretty clear differentiators. Zope 2.0 and Zope 3.0 are not. Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Martijn Faassen wrote:
Let's talk about Zope Classic and see whether renaming Zope 2 to that is a step we can realistically take in the near future. Who is in favor of that?
-100 "Zope 2" is an incredibly established name. It's been around forever. Renaming something that has been out there for years and years and is mentioned in thousands of pages of documentation (including books) is a recipe for confusion. To the outside world, this will sound like renaming for renaming's sake. If you look at the companies that have done this with their brand names, it's normally a disaster and costs a fortune in marketing to set the record straight in people's minds. Don't believe for a moment that the common usage in the chatter in cyberspace and real life is going to change over night (or even over a few weeks or months) just because it is suddenly decreed. It'll be a point of confusion we'll have to deal with for years. Also, if "Zope Framework" is the set of re-usable libraries and "Zope 3" is what remains after factoring out this, then the terms "Zope 2" and "Zope 3" are probably closer in representation to their original goal. Whether "Zope 3" is *successful* in succeeding Zope 2 is another matter. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
- 1 for Zope Classic for the same reasons as Martin brought up. juh
Hey, Okay, in the interests of making this discussion go quickly, there has been enough negative feedback about renaming Zope 2 to think we have no realistic chance of renaming it. We are still stuck with the following perceived sequence: Zope 2, Zope 3 which implies that people should want to upgrade. How to get out of that bind? We could consider renaming Zope 3. Is there any potential for this? I'll note that I don't think there's as much at risk here: Zope 2, Zope 3, Zope Framework. This isn't a progression that people want to upgrade to either, but it may give the wrong impression. If we don't call Zope Framework "4.0", we'll be fine. We should call its first release 1.0 and there's no implication of a progression. Regards, Martijn
I see no reason at all to rename anything. remeber the days when there was dBase3. and then dBase4 came allong. technically better but never took off ? To the day things are either dBase or dBase3 compatible. A simmilar situation we have with Zope. Like dBase, Zope is a base technology. How its named is not (very) important. Nobody but techies will be interested. And they quickly will learn what the different bits in the tool-chest are used for. What ever they are named. robert Martijn Faassen schrieb:
Hey,
Okay, in the interests of making this discussion go quickly, there has been enough negative feedback about renaming Zope 2 to think we have no realistic chance of renaming it.
We are still stuck with the following perceived sequence:
Zope 2, Zope 3
which implies that people should want to upgrade.
How to get out of that bind? We could consider renaming Zope 3. Is there any potential for this?
I'll note that I don't think there's as much at risk here:
Zope 2, Zope 3, Zope Framework.
This isn't a progression that people want to upgrade to either, but it may give the wrong impression.
If we don't call Zope Framework "4.0", we'll be fine. We should call its first release 1.0 and there's no implication of a progression.
Regards,
Martijn
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Martijn Faassen wrote:
If we don't call Zope Framework "4.0", we'll be fine. We should call its first release 1.0 and there's no implication of a progression.
+1 on calling it Zope Framework 1.0. We need the people who have been burned by past Zope releases to take another look, because we believe Zope is finally getting simpler. Those people would assume Zope-anything 4.0 is just piling on more complexity, while a version 1.0 release would invalidate that assumption and suggest they take another look. Shane
On Wed, Apr 8, 2009 at 10:54 AM, Shane Hathaway <shane@hathawaymix.org> wrote:
Martijn Faassen wrote:
If we don't call Zope Framework "4.0", we'll be fine. We should call its first release 1.0 and there's no implication of a progression.
+1 on calling it Zope Framework 1.0. We need the people who have been burned by past Zope releases to take another look, because we believe Zope is finally getting simpler. Those people would assume Zope-anything 4.0 is just piling on more complexity, while a version 1.0 release would invalidate that assumption and suggest they take another look.
+1 for Zope Framework "1.0" Regards, Baiju M
Baiju M wrote:
On Wed, Apr 8, 2009 at 10:54 AM, Shane Hathaway <shane@hathawaymix.org> wrote:
Martijn Faassen wrote:
If we don't call Zope Framework "4.0", we'll be fine. We should call its first release 1.0 and there's no implication of a progression. +1 on calling it Zope Framework 1.0. We need the people who have been burned by past Zope releases to take another look, because we believe Zope is finally getting simpler. Those people would assume Zope-anything 4.0 is just piling on more complexity, while a version 1.0 release would invalidate that assumption and suggest they take another look.
+1 for Zope Framework "1.0"
Could we just call it Zope Libraries? Whenever I see a description of what the Zope Framework is, it says "a collection of libraries", so why not just call it that? "Framework" to many Python web people implies a runnable application server (the terms got conflated when Pylons and Django started calling themselves "web frameworks"). I'll step out of the discussion about whether these libraries should be versioned and treated as a unit, everybody knows my opinion about that. - C - C
On Wed, Apr 8, 2009 at 18:47, Chris McDonough <chrism@plope.com> wrote:
Could we just call it Zope Libraries? Whenever I see a description of what the Zope Framework is, it says "a collection of libraries", so why not just call it that?
Well, that's a bad description, it's more than just libraries, they fit together, and it's also a development style with the component architecture et al.
"Framework" to many Python web people implies a runnable application server (the terms got conflated when Pylons and Django started calling themselves "web frameworks").
Oh, that's bad. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64
On Wed, Apr 8, 2009 at 11:54 AM, Shane Hathaway <shane@hathawaymix.org> wrote:
Martijn Faassen wrote:
If we don't call Zope Framework "4.0", we'll be fine. We should call its first release 1.0 and there's no implication of a progression.
+1 on calling it Zope Framework 1.0. We need the people who have been burned by past Zope releases to take another look, because we believe Zope is finally getting simpler. Those people would assume Zope-anything 4.0 is just piling on more complexity, while a version 1.0 release would invalidate that assumption and suggest they take another look.
Maybe I'm dense, but from the description of the Zope Framework (from http://docs.zope.org/zopeframework/about/index.html) as "a collection of libraries managed by the Zope developers," I can't imagine a non-Zope person being interested at all. As far as I can tell, the Zope Framework is a project management structure, not something outsiders would be interested in. -- Benji York Senior Software Engineer Zope Corporation
Benji York wrote:
On Wed, Apr 8, 2009 at 11:54 AM, Shane Hathaway <shane@hathawaymix.org> wrote:
Martijn Faassen wrote:
If we don't call Zope Framework "4.0", we'll be fine. We should call its first release 1.0 and there's no implication of a progression. +1 on calling it Zope Framework 1.0. We need the people who have been burned by past Zope releases to take another look, because we believe Zope is finally getting simpler. Those people would assume Zope-anything 4.0 is just piling on more complexity, while a version 1.0 release would invalidate that assumption and suggest they take another look.
Maybe I'm dense, but from the description of the Zope Framework (from http://docs.zope.org/zopeframework/about/index.html) as "a collection of libraries managed by the Zope developers," I can't imagine a non-Zope person being interested at all.
As far as I can tell, the Zope Framework is a project management structure, not something outsiders would be interested in.
That's good point. I think we've been mixing up the two concepts in the discussions. My position: * right now the Zope Framework is indeed a concept used primarily for project management purposes. The documentation is not geared towards outsiders. * I think we could extend the documentation with some information useful for outsiders. It would take a better introduction in that document and some pointers to where to find out more documentation about the individual libraries. I think we should do this. There are good reasons to present the Zope Framework to the outside world (certainly where we want to attract new developers to Zope 2, Zope 3 or Grok): * non-zope developers would be most interested in the individual libraries. If they want to contribute they'd need to find out how that is done, and this is documented there. * it's the common foundation to these projects. We can therefore show where our community has some measure of unity. * much of our community's development efforts are invested into this stuff! We should talk about what we actually spend a lot of our time doing and talking about. Regards, Martijn
On 8 Apr 2009, at 16:40, Martijn Faassen wrote:
How to get out of that bind? We could consider renaming Zope 3. Is there any potential for this?
A thought that occurs to me is we could not rename Zope 2 or Zope 3 but abbreviate Zope 3 to z3 as much as possible. I'm not sure if that's even a good idea, but I think it's a fairly universally understood term for Zope users, and new people wouldn't realise until they asked, at which point they get the explanantion. Matt
Previously Martijn Faassen wrote:
How to get out of that bind? We could consider renaming Zope 3. Is there any potential for this?
I doubt many see Zope 3 as a finished product - I get the impression everyone is using it as a grab bag if tools to build their own applications. It certainly has not seen any marketing push in that direction, unlike Zope 2. This suggests that renaming Zope 3 is not problematic.
If we don't call Zope Framework "4.0", we'll be fine. We should call its first release 1.0 and there's no implication of a progression.
+1 To stir things up: I would like to suggest renumbering the next Zope 2 release to Zope 4. That reflects the large refactoring that is being done to clean up the codebase and fully eggify Zope. There are enough changes to warrant a new major version bump. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08.04.2009 18:09 Uhr, Wichert Akkerman wrote:
To stir things up: I would like to suggest renumbering the next Zope 2 release to Zope 4. That reflects the large refactoring that is being done to clean up the codebase and fully eggify Zope. There are enough changes to warrant a new major version bump.
This proposal makes no sense to me. People thought Zope 3 would be the successor of Zope 2. Now we have to tell that Zope 4 isn't the successor of Zope 3 but basically the old Zope 2 stuff...juggling with numbers at this point will be highly confusing. Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknczdAACgkQCJIWIbr9KYxHkwCg5ojz0WLJpelohd3D0H5NKWLM fyYAnA+skxhstuLNoAMQLvJgXGFVKNP/ =sIHb -----END PGP SIGNATURE-----
Andreas Jung wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08.04.2009 18:09 Uhr, Wichert Akkerman wrote:
To stir things up: I would like to suggest renumbering the next Zope 2 release to Zope 4. That reflects the large refactoring that is being done to clean up the codebase and fully eggify Zope. There are enough changes to warrant a new major version bump.
This proposal makes no sense to me. People thought Zope 3 would be the successor of Zope 2. Now we have to tell that Zope 4 isn't the successor of Zope 3 but basically the old Zope 2 stuff...juggling with numbers at this point will be highly confusing.
I agree that would be too confusion, for the reasons Andreas gives. I think we should keep "Zope 4" in the realm of april fools joke territory for the time being. Regards, Martijn
Wichert Akkerman wrote:
To stir things up: I would like to suggest renumbering the next Zope 2 release to Zope 4. That reflects the large refactoring that is being done to clean up the codebase and fully eggify Zope. There are enough changes to warrant a new major version bump.
-100 again. We need to stop confusing people! The only way we could do this would be if we definitely, 100%, with-an-axe killed off any notion of Zope 3 as an app server or application development framework and told everyone "the thing you need to be using if you like Zope, is this Zope thing that's basically Zope 2.14). We won't do that. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Aspeli wrote:
Wichert Akkerman wrote:
To stir things up: I would like to suggest renumbering the next Zope 2 release to Zope 4. That reflects the large refactoring that is being done to clean up the codebase and fully eggify Zope. There are enough changes to warrant a new major version bump.
-100 again. We need to stop confusing people!
The only way we could do this would be if we definitely, 100%, with-an-axe killed off any notion of Zope 3 as an app server or application development framework and told everyone "the thing you need to be using if you like Zope, is this Zope thing that's basically Zope 2.14).
We won't do that.
We already have: "Le roi est mort, vive le roi!" and all that. Jim has pronounced Zope3^H^H^H^HDecoy DOA. Nobody is every going to care about Zope3-the-appserver, as opposed to "the-libraries-harvested-from-Zope3" (at least, the folks who might care are a tiny minority for branding purposes). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ3Wui+gerLs4ltQ4RAtD3AJ9FZBB7ZzAc0xTIM1DjWyhFmVg1PgCfUdP7 j/7TFDt6sC00+tq/8opLbZU= =+sRi -----END PGP SIGNATURE-----
On Apr 8, 2009, at 11:29 PM, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Martin Aspeli wrote:
Wichert Akkerman wrote:
To stir things up: I would like to suggest renumbering the next Zope 2 release to Zope 4. That reflects the large refactoring that is being done to clean up the codebase and fully eggify Zope. There are enough changes to warrant a new major version bump.
-100 again. We need to stop confusing people!
The only way we could do this would be if we definitely, 100%, with-an-axe killed off any notion of Zope 3 as an app server or application development framework and told everyone "the thing you need to be using if you like Zope, is this Zope thing that's basically Zope 2.14).
No. It would only mean that there was one Zope application thing (pluggabel application platform ...) ...
We already have: "Le roi est mort, vive le roi!" and all that. Jim has pronounced Zope3^H^H^H^HDecoy DOA.
No. I was only referring to the Zope 2 wanna-be application implemented with Zope 3. I certainly think the components that such an application is made of, including application-server components have a long and happy life ahead of them.
Nobody is every going to care about Zope3-the-appserver, as opposed to "the-libraries-harvested-from- Zope3" (at least, the folks who might care are a tiny minority for branding purposes).
I don't think the term "app server" is crisp. To me "app server" != pluggable application. Jim -- Jim Fulton Zope Corporation
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Fulton wrote:
On Apr 8, 2009, at 11:29 PM, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Martin Aspeli wrote:
Wichert Akkerman wrote:
To stir things up: I would like to suggest renumbering the next Zope 2 release to Zope 4. That reflects the large refactoring that is being done to clean up the codebase and fully eggify Zope. There are enough changes to warrant a new major version bump. -100 again. We need to stop confusing people!
The only way we could do this would be if we definitely, 100%, with-an-axe killed off any notion of Zope 3 as an app server or application development framework and told everyone "the thing you need to be using if you like Zope, is this Zope thing that's basically Zope 2.14).
No. It would only mean that there was one Zope application thing (pluggabel application platform ...)
Agreed.
We already have: "Le roi est mort, vive le roi!" and all that. Jim has pronounced Zope3^H^H^H^HDecoy DOA.
No. I was only referring to the Zope 2 wanna-be application implemented with Zope 3.
That is what I meant. For branding purposes (what this discussion si about) we would like to avoid using "Zope3" as a name for what is left, beecause it implies "successor to Zope2".
I certainly think the components that such an application is made of, including application-server components have a long and happy life ahead of them.
Nobody is every going to care about Zope3-the-appserver, as opposed to "the-libraries-harvested-from- Zope3" (at least, the folks who might care are a tiny minority for branding purposes).
I don't think the term "app server" is crisp. To me "app server" != pluggable application.
Right. There exist hoops we make typical Z2 applications jump through, mostly unrelated to the real requirements for the app: those hoops are to make the app "play nice" inside the "bean^W^W^Wapplication container" which is the ZMI. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ3hPd+gerLs4ltQ4RAhKKAKCkwmS7tm8VLsjMVLkzpx+HK01pHQCfbapU Km5+H0AD3glgxKXq/DuAOB0= =wrNL -----END PGP SIGNATURE-----
Previously Martin Aspeli wrote:
Wichert Akkerman wrote:
To stir things up: I would like to suggest renumbering the next Zope 2 release to Zope 4. That reflects the large refactoring that is being done to clean up the codebase and fully eggify Zope. There are enough changes to warrant a new major version bump.
-100 again. We need to stop confusing people!
The only way we could do this would be if we definitely, 100%, with-an-axe killed off any notion of Zope 3 as an app server or application development framework and told everyone "the thing you need to be using if you like Zope, is this Zope thing that's basically Zope 2.14).
We won't do that.
Actually, we have already done that. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Wichert Akkerman wrote:
Previously Martin Aspeli wrote:
Wichert Akkerman wrote:
To stir things up: I would like to suggest renumbering the next Zope 2 release to Zope 4. That reflects the large refactoring that is being done to clean up the codebase and fully eggify Zope. There are enough changes to warrant a new major version bump. -100 again. We need to stop confusing people!
The only way we could do this would be if we definitely, 100%, with-an-axe killed off any notion of Zope 3 as an app server or application development framework and told everyone "the thing you need to be using if you like Zope, is this Zope thing that's basically Zope 2.14).
We won't do that.
Actually, we have already done that.
Well, except that Grok runs on "Zope 3 the app server" or at least "Zope 3 the platform". I just think we need to stop playing with names and numbers. I have absolutely no problem with Zope 2 version numbers reaching 2.20 or whatever. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Zope Toolkit is a good name. But so is Zope Framework. And honestly, it's more a framework than a toolkit. A toolkit is a collection of reasonably independent tools. OK, so Zope Framework is actually loads of frameworks, one for components, one for security one for web forms, and this and that. But they are also designed to work together, and therefore makes a sort of megaframework. OK, fair enough, Django calls itself a framework too. It is more specifically "a high level web framework". Zope Framework is NOT a web framework and certainly not high level. It's an application framework. Grok and BFG are web frameworks in the sense of Django. Is it really a big enough problem to distinguish between an application framework like Zope, and a Web Framework like Django, so that we need to rename everything again? I don't think so. Zope Framework is clear name and already in use. Changing that name just because it's not the same type of Framework as Django seems weird. So I'm +0 on Zope Toolkit. But +1 on Zope Framework. It just makes more sense to me. //Lennart
When i speak about zope with my friends or tell about zope to my boss i allways use "Zope Framework" name. Zope Framework was from beginning the "natural" name for zope3 for me. When i thing about Zope3, i think about Zope Framework When i thing about Zope2, i think about Zope2 Just my 0.02 cents :) Regards Roman Lacko
-----Original Message----- From: zope-dev-bounces@zope.org [mailto:zope-dev-bounces@zope.org] On Behalf Of Lennart Regebro Sent: Thursday, April 09, 2009 11:18 AM To: Martin Aspeli Cc: zope-dev@zope.org Subject: Re: [Zope-dev] naming Zope
Zope Toolkit is a good name. But so is Zope Framework. And honestly, it's more a framework than a toolkit. A toolkit is a collection of reasonably independent tools. OK, so Zope Framework is actually loads of frameworks, one for components, one for security one for web forms, and this and that. But they are also designed to work together, and therefore makes a sort of megaframework.
OK, fair enough, Django calls itself a framework too. It is more specifically "a high level web framework". Zope Framework is NOT a web framework and certainly not high level. It's an application framework. Grok and BFG are web frameworks in the sense of Django.
Is it really a big enough problem to distinguish between an application framework like Zope, and a Web Framework like Django, so that we need to rename everything again? I don't think so. Zope Framework is clear name and already in use. Changing that name just because it's not the same type of Framework as Django seems weird.
So I'm +0 on Zope Toolkit. But +1 on Zope Framework. It just makes more sense to me.
//Lennart _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Wichert Akkerman wrote:
To stir things up: I would like to suggest renumbering the next Zope 2 release to Zope 4. That reflects the large refactoring that is being done to clean up the codebase and fully eggify Zope. There are enough changes to warrant a new major version bump.
I could certainly live with: "Zope 4 is built using Zope Toolkit 1.0, as is Grok, repoze.cfg, and something else" Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On 4/11/09 9:40 AM, Chris Withers wrote:
Wichert Akkerman wrote:
To stir things up: I would like to suggest renumbering the next Zope 2 release to Zope 4. That reflects the large refactoring that is being done to clean up the codebase and fully eggify Zope. There are enough changes to warrant a new major version bump.
I could certainly live with:
"Zope 4 is built using Zope Toolkit 1.0, as is Grok, repoze.cfg, and something else"
repoze.bfg is actually *not* build with the Zope Toolkit at least as "Zope Toolkit" is defined by the Steering Group. It uses only zope.component, zope.interface, and zope.configuration, plus the dependencies thereof plus zope.testing. This works out to maybe 12 zope-related packages, while the Zope Toolkit is, AFAICT, defined as "the set of packages that Zope 3 used to be, versioned as a unit through time". - C
Chris McDonough wrote:
On 4/11/09 9:40 AM, Chris Withers wrote:
"Zope 4 is built using Zope Toolkit 1.0, as is Grok, repoze.cfg, and something else"
repoze.bfg is actually *not* build with the Zope Toolkit at least as "Zope Toolkit" is defined by the Steering Group. It uses only zope.component, zope.interface, and zope.configuration, plus the dependencies thereof plus zope.testing. This works out to maybe 12 zope-related packages, while the Zope Toolkit is, AFAICT, defined as "the set of packages that Zope 3 used to be, versioned as a unit through time".
The closest technical definition of packages in the Zope Toolkit is currently "what Zope2 (or Grok) needs of Zope 3, minus the stuff it shouldn't need, plus the general useful stuff". This comes down to a list of about 70 packages right now, where ideally it should be closer to 50 after some more dependency cleanup. The "general useful stuff" are things like zope.intid, zope.keyreference and zope.catalog if I remember Theuni's mail correctly. ZDecoy, eh Zope 3 consisted of over 140 packages, so I do see a very clear difference between the two. That is not to say, repoze is based on the Zope Toolkit :) Hanno
On 4/11/09 4:39 PM, Hanno Schlichting wrote:
Chris McDonough wrote:
On 4/11/09 9:40 AM, Chris Withers wrote:
"Zope 4 is built using Zope Toolkit 1.0, as is Grok, repoze.cfg, and something else" repoze.bfg is actually *not* build with the Zope Toolkit at least as "Zope Toolkit" is defined by the Steering Group. It uses only zope.component, zope.interface, and zope.configuration, plus the dependencies thereof plus zope.testing. This works out to maybe 12 zope-related packages, while the Zope Toolkit is, AFAICT, defined as "the set of packages that Zope 3 used to be, versioned as a unit through time".
The closest technical definition of packages in the Zope Toolkit is currently "what Zope2 (or Grok) needs of Zope 3, minus the stuff it shouldn't need, plus the general useful stuff".
Right. That's what I meant to say. ;-)
This comes down to a list of about 70 packages right now, where ideally it should be closer to 50 after some more dependency cleanup. The "general useful stuff" are things like zope.intid, zope.keyreference and zope.catalog if I remember Theuni's mail correctly.
That much dependency cleanup would be fantastic.
ZDecoy, eh Zope 3 consisted of over 140 packages, so I do see a very clear difference between the two. That is not to say, repoze is based on the Zope Toolkit :)
Heh. "Repoze" (unqualified with a suffix) is a whole separate thing; BFG obviously has its own naming issues. - C
Hi
Betreff: Re: [Zope-dev] naming Zope
On 4/11/09 4:39 PM, Hanno Schlichting wrote:
Chris McDonough wrote:
On 4/11/09 9:40 AM, Chris Withers wrote:
"Zope 4 is built using Zope Toolkit 1.0, as is Grok, repoze.cfg, and something else" repoze.bfg is actually *not* build with the Zope Toolkit at least as "Zope Toolkit" is defined by the Steering Group. It uses only zope.component, zope.interface, and zope.configuration, plus the dependencies thereof plus zope.testing. This works out to maybe 12 zope-related packages, while the Zope Toolkit is, AFAICT, defined as "the set of packages that Zope 3 used to be, versioned as a unit through time".
The closest technical definition of packages in the Zope Toolkit is currently "what Zope2 (or Grok) needs of Zope 3, minus the stuff it shouldn't need, plus the general useful stuff".
Right. That's what I meant to say. ;-)
Ah, cool Zope Toolkit! Seems to be another nice thing which nobody exactly knows what it is or should be. Sounds good to me. I'm used to such things since I develope Zope 3 and every new user makes decisions ;-)
This comes down to a list of about 70 packages right now, where ideally it should be closer to 50 after some more dependency cleanup. The "general useful stuff" are things like zope.intid, zope.keyreference and zope.catalog if I remember Theuni's mail correctly.
That much dependency cleanup would be fantastic.
Yes, cool, but what exactly whould you like to cleanup?
ZDecoy, eh Zope 3 consisted of over 140 packages, so I do see a very clear difference between the two. That is not to say, repoze is based on the Zope Toolkit :)
Ah, ZDecoy, sounds nice, do I need that?
Heh. "Repoze" (unqualified with a suffix) is a whole separate thing; BFG obviously has its own naming issues.
I know that the spring turns many people crazy sometimes but hey, we are developer and there a no girls arround ;-) Let me know if the renaming excess is over and please let me know with what I'm working and on what my applications are running at that time. Regards Roger Ineichen
On 4/11/09 7:32 PM, Roger Ineichen wrote:
That much dependency cleanup would be fantastic.
Yes, cool, but what exactly whould you like to cleanup?
The bits that I use are already pretty nicely cleaned up. But in theory, if we did a more reasonable job of dependency management, I'd be able to use, say, zope.catalog without getting zope.publisher and ~30 other seemingly unrelated dependent packages sucked down too. That said, I've already created a forked catalog implementation (repoze.catalog) that requires only ZODB and zope.index, so that particular example is not very useful to me personally. Maybe there are other pieces that could have a life outside of Zope-the-application-server. Or maybe not. Maybe they'll just die inside the appserver. It's actually a heck of a lot easier to clean nothing up and just continue to do what I've been doing, which is to fork every package that I find useful so it can be used sanely outside an appserver context. That's been working out ok so far, and it feels better than needing to communicate on this maillist in emails like this one. ;-)
Heh. "Repoze" (unqualified with a suffix) is a whole separate thing; BFG obviously has its own naming issues.
I know that the spring turns many people crazy sometimes but hey, we are developer and there a no girls arround ;-)
Let me know if the renaming excess is over and please let me know with what I'm working and on what my applications are running at that time.
Hey, don't blame me, I didn't create the "Zope Framework/Toolkit" idea (personally I am not a fan of the concept). But it probably doesn't matter anyway. You needn't pay attention to any of this: nothing has changed at all except for a bunch of names, and even those, not too much. - C
On Sat, Apr 11, 2009 at 9:05 PM, Chris McDonough <chrism@plope.com> wrote:
On 4/11/09 7:32 PM, Roger Ineichen wrote:
That much dependency cleanup would be fantastic.
Yes, cool, but what exactly whould you like to cleanup?
The bits that I use are already pretty nicely cleaned up. But in theory, if we did a more reasonable job of dependency management, I'd be able to use, say, zope.catalog without getting zope.publisher and ~30 other seemingly unrelated dependent packages sucked down too. That said, I've already created a forked catalog implementation (repoze.catalog) that requires only ZODB and zope.index, so that particular example is not very useful to me personally.
Maybe there are other pieces that could have a life outside of Zope-the-application-server. Or maybe not. Maybe they'll just die inside the appserver. It's actually a heck of a lot easier to clean nothing up and just continue to do what I've been doing, which is to fork every package that I find useful so it can be used sanely outside an appserver context. That's been working out ok so far, and it feels better than needing to communicate on this maillist in emails like this one. ;-)
Heh. "Repoze" (unqualified with a suffix) is a whole separate thing; BFG obviously has its own naming issues.
I know that the spring turns many people crazy sometimes but hey, we are developer and there a no girls arround ;-)
Let me know if the renaming excess is over and please let me know with what I'm working and on what my applications are running at that time.
Hey, don't blame me, I didn't create the "Zope Framework/Toolkit" idea (personally I am not a fan of the concept). But it probably doesn't matter anyway. You needn't pay attention to any of this: nothing has changed at all except for a bunch of names, and even those, not too much.
Rightly or wrongly, before the naming discussion came up, I was basically already considering Repoze to be the Zope toolkit. Or Zope 4. The *stated* goals for Zope Mega(tm) seem to align fairly closely with what Repoze already is: extraction of the good, useful ideas from Zope into reusable modules, refactored so as to avoid dependency hell. Some packages in the zope.* namespace are already nice and reusable as is--I don't really care if the tool of the moment starts with zope.* or repoze.*. If the trend were merely to continue these sorts of refactors, call it Zope, or Repoze, or whatever, you would find no complaint from me. Chris
On Wed, Apr 8, 2009 at 17:40, Martijn Faassen <faassen@startifact.com> wrote:
How to get out of that bind? We could consider renaming Zope 3.
Assuming Zope 3 The Application Server is still going to exist, I think it should be renamed (I suggested Blue Bream). But I have so far seen no indication that anybody wants it, neither during both PyCon nor during the Zope 4 discussion.
If we don't call Zope Framework "4.0", we'll be fine. We should call its first release 1.0 and there's no implication of a progression.
This is a good point. Unfortunately it's hard to call the framework anything else than the Zope Framework, as it's made up mainly of modules called zope.*. :-) That would give us, based on my earlier suggestion, Zope Framework 1.0 -> A Framework for building application servers. Zope 2, Grok and BFG -> Application servers using the Zope Framework This is only mildly confusing. It can also only get better with time, as Plone seems to continue away from Zope 2 and onto the framework, which means we in the future may end up with Plone, Grok and BFG being app servers on the Zope Framework. I also think all applications should move over to using repoze by default. BFG already does so, of course, and Plone 4 is set to do so. Hopefully by Zope 2.13, the old publisher can be a horrid memory, and repoze.Zope2 be default. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64
Lennart Regebro wrote:
This is only mildly confusing. It can also only get better with time, as Plone seems to continue away from Zope 2 and onto the framework, which means we in the future may end up with Plone, Grok and BFG being app servers on the Zope Framework.
The current line of thinking for Plone is about this: Plone 4 will still run on Zope2. Plone 5 will run on Python 3.x and not depend on Zope2 anymore at all. We can all guesstimate on what kind of timeline that will mean. So it's highly likely that Zope 2.12 is the last release of Zope2 that Plone is going to use. Maybe a Zope 2.13 once Python 2.7 is released might be of interest to Plone. But otherwise I don't see any reason for a new Zope 2 feature release anymore from the Plone perspective. Plone is going to continue to use selected Zope libraries as everyone else, but use Repoze or just general Python packages from all over. Personally I want to move Plone from zope.i18n to Babel for example. We are not bound by names or frameworks in our package choices.
I also think all applications should move over to using repoze by default. BFG already does so, of course, and Plone 4 is set to do so. Hopefully by Zope 2.13, the old publisher can be a horrid memory, and repoze.Zope2 be default.
I don't know if there's going to be anyone, who is going to drive Zope2 itself forward into WSGI land. Plone is just switching to repoze.zope2 and bits of zope.pipeline by itself. The kind of radical and backwards incompatible changes an application like Plone can do, give us much more flexibility here, compared to the more conservative approach a framework needs to have. Hanno
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote:
Lennart Regebro wrote:
This is only mildly confusing. It can also only get better with time, as Plone seems to continue away from Zope 2 and onto the framework, which means we in the future may end up with Plone, Grok and BFG being app servers on the Zope Framework.
The current line of thinking for Plone is about this: Plone 4 will still run on Zope2. Plone 5 will run on Python 3.x and not depend on Zope2 anymore at all. We can all guesstimate on what kind of timeline that will mean.
There isn't going to *be* a Zope3 to run on.
So it's highly likely that Zope 2.12 is the last release of Zope2 that Plone is going to use. Maybe a Zope 2.13 once Python 2.7 is released might be of interest to Plone. But otherwise I don't see any reason for a new Zope 2 feature release anymore from the Plone perspective.
Zope2 is the only game in town, as far as appservers go.
Plone is going to continue to use selected Zope libraries as everyone else, but use Repoze or just general Python packages from all over. Personally I want to move Plone from zope.i18n to Babel for example. We are not bound by names or frameworks in our package choices.
Note that unless you scrap the entire model of a Plone site as an application object hosted inside an appserver, you won't have a choice except to run atop Zope2: the Z3 appserver is going to be even more moribund a year from now than it is today.
I also think all applications should move over to using repoze by default. BFG already does so, of course, and Plone 4 is set to do so. Hopefully by Zope 2.13, the old publisher can be a horrid memory, and repoze.Zope2 be default.
I don't know if there's going to be anyone, who is going to drive Zope2 itself forward into WSGI land.
Z2 is at least *interesting* to work with at this point; making the Z3 appserver WSGI'fied will be hard and pointless by comparison. ? Plone is just switching to repoze.zope2
and bits of zope.pipeline by itself. The kind of radical and backwards incompatible changes an application like Plone can do, give us much more flexibility here, compared to the more conservative approach a framework needs to have.
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ3WzV+gerLs4ltQ4RAs2PAJ4iQKiuFQm6nfBqEPoybe9rAkiprwCfWSPe rm+xkGTzEk2vRyUeI6KYWlo= =IIDR -----END PGP SIGNATURE-----
On Thu, Apr 9, 2009 at 05:34, Tres Seaver <tseaver@palladion.com> wrote:
Hanno Schlichting wrote:
The current line of thinking for Plone is about this: Plone 4 will still run on Zope2. Plone 5 will run on Python 3.x and not depend on Zope2 anymore at all. We can all guesstimate on what kind of timeline that will mean.
There isn't going to *be* a Zope3 to run on.
Right. He didn't say that it would though. In this scenario, Plone would be one of the platforms using the Zope Framework, like Grok and BFG.
Zope2 is the only game in town, as far as appservers go.
So neither Grok nor BFG exist? :-) I don't know how you are thinking here. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64
Lennart Regebro wrote:
On Thu, Apr 9, 2009 at 05:34, Tres Seaver <tseaver@palladion.com> wrote:
Hanno Schlichting wrote:
The current line of thinking for Plone is about this: Plone 4 will still run on Zope2. Plone 5 will run on Python 3.x and not depend on Zope2 anymore at all. We can all guesstimate on what kind of timeline that will mean. There isn't going to *be* a Zope3 to run on.
Right. He didn't say that it would though. In this scenario, Plone would be one of the platforms using the Zope Framework, like Grok and BFG.
Zope2 is the only game in town, as far as appservers go.
So neither Grok nor BFG exist? :-) I don't know how you are thinking here.
I think Tres is trying to draw a disinction between "application server" and "web framework". I don't think that distinction is useful as far as your garden-variety web programmer goes, though, to be honest. - C
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lennart Regebro wrote:
On Thu, Apr 9, 2009 at 05:34, Tres Seaver <tseaver@palladion.com> wrote:
Hanno Schlichting wrote:
The current line of thinking for Plone is about this: Plone 4 will still run on Zope2. Plone 5 will run on Python 3.x and not depend on Zope2 anymore at all. We can all guesstimate on what kind of timeline that will mean. There isn't going to *be* a Zope3 to run on.
Right. He didn't say that it would though. In this scenario, Plone would be one of the platforms using the Zope Framework, like Grok and BFG.
Zope2 is the only game in town, as far as appservers go.
So neither Grok nor BFG exist? :-) I don't know how you are thinking here.
They aren't "appservers": they are "web frameworks." Grok muddies the lines a tiny bit, but BFG is *only* about giving you tools for building a web app to be run under an arbitrary WSGI server: it doesn't buy into the "container for apps obeying some interface" thing at all. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ3hLL+gerLs4ltQ4RAlLMAKCqjT5V+6cYhB4xPxbfksBBIqim4ACgpe6w +TjBfaokQQAIGVX6VJFUwm8= =MkC8 -----END PGP SIGNATURE-----
Tres Seaver wrote:
Hanno Schlichting wrote:
Lennart Regebro wrote:
So it's highly likely that Zope 2.12 is the last release of Zope2 that Plone is going to use. Maybe a Zope 2.13 once Python 2.7 is released might be of interest to Plone. But otherwise I don't see any reason for a new Zope 2 feature release anymore from the Plone perspective.
Zope2 is the only game in town, as far as appservers go.
I don't see that Plone needs an appserver anymore. A "framework" plus the application code on top is more than enough.
Plone is going to continue to use selected Zope libraries as everyone else, but use Repoze or just general Python packages from all over. Personally I want to move Plone from zope.i18n to Babel for example. We are not bound by names or frameworks in our package choices.
Note that unless you scrap the entire model of a Plone site as an application object hosted inside an appserver, you won't have a choice except to run atop Zope2: the Z3 appserver is going to be even more moribund a year from now than it is today.
I don't want to switch to another application server and certainly not "Zope 3". The notion of a Plone site being a local instance inside the application server is already blurry. From what I see today, we will slowly move away from it. WSGI configuration is going to be application global, more configuration and behavior will be based on things simply being available on sys.path. What Plone will get is a notion of a "website" or "subsite" inside the application with a much smaller configuration aspect to it. Maybe I'm wrong on this, but I assume the "Plone Site" object is going to be optional in Plone 5 (two or three years from now). Hanno
On Apr 8, 2009, at 11:34 PM, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hanno Schlichting wrote:
Lennart Regebro wrote:
This is only mildly confusing. It can also only get better with time, as Plone seems to continue away from Zope 2 and onto the framework, which means we in the future may end up with Plone, Grok and BFG being app servers on the Zope Framework.
The current line of thinking for Plone is about this: Plone 4 will still run on Zope2. Plone 5 will run on Python 3.x and not depend on Zope2 anymore at all. We can all guesstimate on what kind of timeline that will mean.
There isn't going to *be* a Zope3 to run on.
So it's highly likely that Zope 2.12 is the last release of Zope2 that Plone is going to use. Maybe a Zope 2.13 once Python 2.7 is released might be of interest to Plone. But otherwise I don't see any reason for a new Zope 2 feature release anymore from the Plone perspective.
Zope2 is the only game in town, as far as appservers go.
Plone could run on something like the "Zope Framework" without running on Zope 2. Alternatively, Zope (2 or whatever) could use more and more Zope framework components so that it would become what they mean by Zope 3.
Plone is going to continue to use selected Zope libraries as everyone else, but use Repoze or just general Python packages from all over. Personally I want to move Plone from zope.i18n to Babel for example. We are not bound by names or frameworks in our package choices.
Note that unless you scrap the entire model of a Plone site as an application object hosted inside an appserver, you won't have a choice except to run atop Zope2: the Z3 appserver is going to be even more moribund a year from now than it is today.
I don't agree at all with your definition of app server. ...
Z2 is at least *interesting* to work with at this point; making the Z3 appserver WSGI'fied will be hard and pointless by comparison.
Zope 3 has been wsgi-based for years now. Jim -- Jim Fulton Zope Corporation
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Fulton wrote:
On Apr 8, 2009, at 11:34 PM, Tres Seaver wrote:
Plone could run on something like the "Zope Framework" without running on Zope 2.
That would be feasible, except that a ton of Plone's features depend on Zope2-specific machinery. Hanno may be ambitious enough to pull that off (he is certainly capable), but I'm not sure it would be worth the effort.
Alternatively, Zope (2 or whatever) could use more and more Zope framework components so that it would become what they mean by Zope 3.
Zope2 has been doing just that for the past four years. We need to recognize and bless this fact, and quit using a brand name which creates an expectation that "Zope2" is an evolutionary dead end.
Plone is going to continue to use selected Zope libraries as everyone else, but use Repoze or just general Python packages from all over. Personally I want to move Plone from zope.i18n to Babel for example. We are not bound by names or frameworks in our package choices. Note that unless you scrap the entire model of a Plone site as an application object hosted inside an appserver, you won't have a choice except to run atop Zope2: the Z3 appserver is going to be even more moribund a year from now than it is today.
I don't agree at all with your definition of app server.
I'm using the term pretty much as a cognate for your "pluggable application," or for "bean container" in the Java world; an application server is a standalone thing which has separately-developed "applications" installed into it. The other Python "web frameworks" now current don't match this pattern at all: they give you a way to build and run a custom web application under a WSGI server, but there is no notion of "installing an application" into the server. The server also provides almost *no* functionality to the application, by comparison with what Zope2 does.
Z2 is at least *interesting* to work with at this point; making the Z3 appserver WSGI'fied will be hard and pointless by comparison.
Zope 3 has been wsgi-based for years now.
In a sense, yes, although the stock publisher is too policy filled to take advantage of a lot of the benefits of a WSGI-fied environment. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ3haQ+gerLs4ltQ4RAu7iAJ9cVi3qe4p7tOZuN6+b7DpKu+64/wCgyGhr lT1hpyXcgU86WLGD5OsRJow= =nDBR -----END PGP SIGNATURE-----
On Apr 8, 2009, at 11:40 AM, Martijn Faassen wrote:
Hey,
Okay, in the interests of making this discussion go quickly, there has been enough negative feedback about renaming Zope 2 to think we have no realistic chance of renaming it.
We are still stuck with the following perceived sequence:
Zope 2, Zope 3
which implies that people should want to upgrade.
That is a problem we ought to fix, IMO.
How to get out of that bind? We could consider renaming Zope 3. Is there any potential for this?
I think we should call the Zope 3 application "ZDecoy". The rest of Zope 3, the parts everyone uses, is covered by "Zope Framework". Jim -- Jim Fulton Zope Corporation
Jim Fulton wrote:
On Apr 8, 2009, at 11:40 AM, Martijn Faassen wrote: [snip]
How to get out of that bind? We could consider renaming Zope 3. Is there any potential for this?
I think we should call the Zope 3 application "ZDecoy". The rest of Zope 3, the parts everyone uses, is covered by "Zope Framework".
Okay, so we have zdecoy which contains the ZMI. Should we also rename zopeproject to zdecoyproject or could we move in the direction of a more generally useful tool that can be shared between Zope 2 and Grok and roll-it-yourself users? Regards, Martijn
On Apr 8, 2009, at 1:12 PM, Martijn Faassen wrote:
Jim Fulton wrote:
On Apr 8, 2009, at 11:40 AM, Martijn Faassen wrote: [snip]
How to get out of that bind? We could consider renaming Zope 3. Is there any potential for this?
I think we should call the Zope 3 application "ZDecoy". The rest of Zope 3, the parts everyone uses, is covered by "Zope Framework".
Okay, so we have zdecoy which contains the ZMI.
Should we also rename zopeproject to zdecoyproject or could we move in the direction of a more generally useful tool that can be shared between Zope 2 and Grok and roll-it-yourself users?
I don't think the application that gets installed when people install from the old Z3 tarball is useful to anyone. I propose deprecating it and calling it anything you want as long as you don't call it "Zope 3", which implies a progression from Zope 2. The parts that make it up, even the ZMI, are useful to people and should live on in the Zope Framework. Jim -- Jim Fulton Zope Corporation
Hey, Jim Fulton wrote:
The parts that make it up, even the ZMI, are useful to people and should live on in the Zope Framework.
The ZMI is definitely not going to live in the Zope Framework. An important point of the Zope Framework is to have to worry about less code. If people want to maintain the ZMI they should create their own project to do so - perhaps by gathering code now lying around in more and more empty zope.app.* packages into one or more zmi.* packages. Regards, Martijn
Martijn Faassen wrote:
Hey,
Okay, in the interests of making this discussion go quickly, there has been enough negative feedback about renaming Zope 2 to think we have no realistic chance of renaming it.
We are still stuck with the following perceived sequence:
Zope 2, Zope 3
which implies that people should want to upgrade.
Does it? There's precedence for systems where n and n+1 does not represent a linear upgrade path. The '3' says more "if you're starting afresh, this is where you want to start". I think that's still a correct statement.
If we don't call Zope Framework "4.0", we'll be fine. We should call its first release 1.0 and there's no implication of a progression.
Yes. For the love of God, please don't call "the Zope Framework" 4.0! Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Aspeli wrote:
Martijn Faassen wrote:
Hey,
Okay, in the interests of making this discussion go quickly, there has been enough negative feedback about renaming Zope 2 to think we have no realistic chance of renaming it.
We are still stuck with the following perceived sequence:
Zope 2, Zope 3
which implies that people should want to upgrade.
Does it? There's precedence for systems where n and n+1 does not represent a linear upgrade path.
The '3' says more "if you're starting afresh, this is where you want to start". I think that's still a correct statement.
Nope. There is no point in treating the two as equivalent choices at this point. Nobody cares about the Z3 equivalent to Z2, only the libraries.
If we don't call Zope Framework "4.0", we'll be fine. We should call its first release 1.0 and there's no implication of a progression.
Yes. For the love of God, please don't call "the Zope Framework" 4.0!
Heh, don't call the "*the* Zope framework" at all! There are a bunch of frameworks lurking in the codebase, and none of them is a "web framework" in the sense the rest of the Python web development community users: Grok and BFG do match what they mean, more or less. Tres - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ3W2J+gerLs4ltQ4RAhEBAKDLxTlpZDz07ZuTkoby350osK5SoACgoYAC doxYlJBDwzzK8N7CLDWnzVE= =/djo -----END PGP SIGNATURE-----
Thanks for posting this. (Thank you too Chris for starting the Zope 4 thread.) Despite the inevitable bike shedding, I think this is a discussion worth having. Here are my opinions, which build on the arguments you gave, even though I disagree with some of your conclusions. 1. I hate "Zope Classic". It was a mistake for Coke and I think it would be a mistake for us too. :) 2. I think Zope 3 the application should die. It should go the way of New Coke. 3. I think the word "Zope" should refer to both the application currently called Zope 2 and the Zope ecosystem, depending on context, although I'm also fine with coming up with another name as long as it doesn't imply obsolescence. :) Jim On Apr 8, 2009, at 9:31 AM, Martijn Faassen wrote:
Hi there,
There was some discussion recently on how to name Zope in the future. Here are my thoughts and suggestions.
First of all some principles I tend to follow surrounding names.
* I prefer not introducing too many new names at the same time. A renaming takes a while to percolate through the community and people to gain full understanding of it.
* I prefer naming something that already exists (or renaming something) as opposed to naming something that doesn't really exist yet. A name is a handle on something that we can then use to talk about it and reason about it.
* Naming discussions tend to lead to endless bikeshed discussion. Naming stuff is easy so everybody has an opinion, including myself. It's not very productive. We don't have clear community mechanisms to make decisions either (the Zope Framework Steering Group isn't it; it only cares about the Zope Framework. Perhaps the Foundation can be it, but it can only approve initiatives from the community in this area, I think.
In this context I'll mention the new name "Zope Framework" that was recently introduced and is probably not yet fully understood by everybody.
The Zope Framework is a collection of libraries. It's shared by at least the following web frameworks/app servers: Zope 2 app server, Zope 3 app server, Grok. Other systems such as bfg use a much smaller subset of these libraries.
I see this as following the principles above:
* it's only introducing a single new name. That's why it at least gets some acceptance now.
* it's naming something that we were really already talking about. Unfortunately we conflated it with "Zope 3", the thing you start that has a UI and so on, which retarded the development of both Zope 3 and the Zope Framework itself. It's good we have a handle on it now as a separate entity.
This "Zope Framework" name and concept is just now percolating through the community. Zope Framework is *not* the renamed Zope 3, even though it's entirely based on what we used to call Zope 3. Zope 3 continues to exist, as long as there are people who are interested in creating an installation tool for it and care about its UI. Zope Framework is a *separate* entity.
Zope 2 and Zope 3 do have confusing names. I prefer to tweak the meaning of "Zope" to be a project identifier instead of identifying software directly: Zope is all of the stuff developed by the Zope project. We therefore have the Zope Object Database, we have the zope component architecture, the zope interface package. This doesn't work for Zope 2 and Zope 3. It works for Grok by the way: I've been saying "Zope Grok" sometimes.
With Zope 2 and Zope 3, we have version numbers that are at the same time identifiers of a piece of software itself; they're not really version numbers at all. That's why I have been using terms like Zope 2 App Server and Zope 3 App Server, but that isn't very satisfactory either. The 2 and the 3 still imply some kind of evolutionary progression that isn't quite what we are doing.
In order to make Zope 2 and Zope 3 fit the pattern, it'd be nice if they had names that fit the "Zope is a project, not software" pattern. We could rename Zope 2 to Zope Classic, as was suggested. I think we should also rename Zope 3 to something else (that doesn't imply it's the modern future, as there are other alternatives at least as modern around that are more recently developed - we want to get out of that bind).
I think renaming Zope 2 to Zope Classic will be easy. If the Zope 2 developers are okay with this, let's go right ahead. Not much discussion needed. Zope 2.11 becomes Zope Classic 11. It's a huge version number, but Zope Classic is over a decade old anyway. Nobody's going to mind. It looks impressive and it should be impressive; Zope Classic has been maintained for a long time by the community.
I think it's going to be harder for Zope 3, as the "Zope 3" community: those people who care about Zope 3 as a piece of software that can be installed, hasn't fully formed yet. There's a tool called "zopeproject" which is quite misnamed in the light of the above discussion. While I sometimes do use that piece of software, I'm far more interested in the Zope Framework, myself.
Anyway, I'm rather reluctant to post this as I fear this will be a pile-on bikeshed discussion. I'd suggest that anyone interested in naming Zope 3 something else should keep quiet for the time being. Go and form a Zope 3 interest group first, don't talk about naming too much yet in that either, and come back to this topic later.
Let's talk about Zope Classic and see whether renaming Zope 2 to that is a step we can realistically take in the near future. Who is in favor of that?
Regards,
Martijn
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
-- Jim Fulton Zope Corporation
Previously Jim Fulton wrote:
3. I think the word "Zope" should refer to both the application currently called Zope 2 and the Zope ecosystem, depending on context, although I'm also fine with coming up with another name as long as it doesn't imply obsolescence. :)
I am somehow reminder of X, which goes under many names. From its manpage: The X Consortium requests that the following names be used when refer- ring to this software: X X Window System X Version 11 X Window System, Version 11 X11 Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Fulton wrote:
Thanks for posting this. (Thank you too Chris for starting the Zope 4 thread.) Despite the inevitable bike shedding, I think this is a discussion worth having.
Here are my opinions, which build on the arguments you gave, even though I disagree with some of your conclusions.
1. I hate "Zope Classic". It was a mistake for Coke and I think it would be a mistake for us too. :)
2. I think Zope 3 the application should die. It should go the way of New Coke.
3. I think the word "Zope" should refer to both the application currently called Zope 2 and the Zope ecosystem, depending on context, although I'm also fine with coming up with another name as long as it doesn't imply obsolescence. :)
Amen to all of that. WRT the "Framework" name: "framework" is a misleading name for the collection of packages salvaged from the "new Coke" effort: it is actually a *bunch* of frameworks, in the classic software engineering sense, along with some "pure" libraries. The notional "Zope Framwork" is alos *not* what other Python web developers mean when they say "web framework": Grok and BFG fit that meaning. Zope2 is really an "app server" / "pluggable application", rather than a "web framework". Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ3QAR+gerLs4ltQ4RAjzaAJ43T+lwhHt9KCiVHsw1V+/tN2aZFACfc5HA bWiGfqU8wk4/dGpDd5pD0ZQ= =qAY1 -----END PGP SIGNATURE-----
<discussion type="bikeshed"> Tres Seaver wrote:
WRT the "Framework" name: "framework" is a misleading name for the collection of packages salvaged from the "new Coke" effort: it is actually a *bunch* of frameworks, in the classic software engineering sense, along with some "pure" libraries.
Zope Toolkit, perhaps? (No relationship to Portal Toolkit. :-] ) </discussion> Shane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Shane Hathaway wrote:
<discussion type="bikeshed">
Tres Seaver wrote:
WRT the "Framework" name: "framework" is a misleading name for the collection of packages salvaged from the "new Coke" effort: it is actually a *bunch* of frameworks, in the classic software engineering sense, along with some "pure" libraries.
Zope Toolkit, perhaps? (No relationship to Portal Toolkit. :-] )
+0.5 (better than any other name I've seen yet ;) Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ3SJQ+gerLs4ltQ4RAtZ7AJ0RzNsLZ0AQBZnBmXJi8UsID2ZVuACgyfGM /JoSyiJ6Gg1wk4vIb9Q4K+k= =rqcA -----END PGP SIGNATURE-----
Hey, Joy, another naming discussion. Oh well, I started it. :) Zope Toolkit is better name than Zope Framework. I'm fine with renaming Zope Framework to Zope Toolkit if: * someone goes and changes the name in: * the Zope Framework sphinx documentation in SVN * renames the SVN directory * renames the Zope Framework Steering Group to the Zope Toolkit Steering Group * bothers Jens to change the /zopeframework URL to zope toolkit. * updates the "story" website to talk about the Zope Toolkit, not the the framework. I.e. a great renaming action. If nobody volunteers to do this (feel free to organize more volunteers), we'll stick with Zope Framework. Let me know if you're going to do this and when you're done. Regards, Martijn
Martijn Faassen wrote:
If nobody volunteers to do this (feel free to organize more volunteers), we'll stick with Zope Framework.
Let me know if you're going to do this and when you're done.
FWIW, I think this particular pile of libraries is in fact best described by the name "framework", because the code we're discussing often calls user code rather than the other way around. For example, looking up and using an adapter is deep in framework territory. The name framework has earned a bad name just because there are so many bad frameworks out there, but there are plenty of good ones too. Good frameworks use library-like patterns where possible, falling back to carefully designed framework-like patterns. Zope Framework will be one of the best frameworks. Shane
I can't believe no one's suggested Zope Mega, yet. Chris On Thu, Apr 9, 2009 at 4:25 PM, Martijn Faassen <faassen@startifact.com>wrote:
Hey,
Joy, another naming discussion. Oh well, I started it. :)
Zope Toolkit is better name than Zope Framework. I'm fine with renaming Zope Framework to Zope Toolkit if:
* someone goes and changes the name in:
* the Zope Framework sphinx documentation in SVN
* renames the SVN directory
* renames the Zope Framework Steering Group to the Zope Toolkit Steering Group
* bothers Jens to change the /zopeframework URL to zope toolkit.
* updates the "story" website to talk about the Zope Toolkit, not the the framework.
I.e. a great renaming action.
If nobody volunteers to do this (feel free to organize more volunteers), we'll stick with Zope Framework.
Let me know if you're going to do this and when you're done.
Regards,
Martijn
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
On Thu, Apr 9, 2009 at 23:07, Chris Rossi <chris@archimedeanco.com> wrote:
I can't believe no one's suggested Zope Mega, yet.
It sounds stupid. The Zope Ultra Component Framework Toolkit, though, THAT's a name with panache! -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On 4/9/09 4:25 PM, Martijn Faassen wrote:
Hey,
Joy, another naming discussion. Oh well, I started it. :)
Zope Toolkit is better name than Zope Framework. I'm fine with renaming Zope Framework to Zope Toolkit if:
* someone goes and changes the name in:
* the Zope Framework sphinx documentation in SVN
* renames the SVN directory
* renames the Zope Framework Steering Group to the Zope Toolkit Steering Group
* bothers Jens to change the /zopeframework URL to zope toolkit.
* updates the "story" website to talk about the Zope Toolkit, not the the framework.
I.e. a great renaming action.
If nobody volunteers to do this (feel free to organize more volunteers), we'll stick with Zope Framework.
Let me know if you're going to do this and when you're done.
All done except for the renaming of the steering group. I'm not sure where to rename that. - C
Chris McDonough wrote:
On 4/9/09 4:25 PM, Martijn Faassen wrote:
If nobody volunteers to do this (feel free to organize more volunteers), we'll stick with Zope Framework.
Let me know if you're going to do this and when you're done.
All done except for the renaming of the steering group. I'm not sure where to rename that.
Grr. Way to end a bikeshed discussion. Now what are we going to drone on about? :-) Shane
On Fri, Apr 10, 2009 at 01:36, Shane Hathaway <shane@hathawaymix.org> wrote:
Grr. Way to end a bikeshed discussion. Now what are we going to drone on about?
Wait, wait, it should be called Zope Platform! -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Previously Shane Hathaway wrote:
<discussion type="bikeshed">
Tres Seaver wrote:
WRT the "Framework" name: "framework" is a misleading name for the collection of packages salvaged from the "new Coke" effort: it is actually a *bunch* of frameworks, in the classic software engineering sense, along with some "pure" libraries.
Zope Toolkit, perhaps? (No relationship to Portal Toolkit. :-] )
+1 Cute. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Wichert Akkerman wrote:
Previously Shane Hathaway wrote:
<discussion type="bikeshed">
Tres Seaver wrote:
WRT the "Framework" name: "framework" is a misleading name for the collection of packages salvaged from the "new Coke" effort: it is actually a *bunch* of frameworks, in the classic software engineering sense, along with some "pure" libraries. Zope Toolkit, perhaps? (No relationship to Portal Toolkit. :-] )
+1
Cute.
It can even be shortened to ZTool. Then we need a package ztool.sample. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Wichert Akkerman wrote at 2009-4-9 10:40 +0200:
Previously Shane Hathaway wrote:
<discussion type="bikeshed">
Tres Seaver wrote:
WRT the "Framework" name: "framework" is a misleading name for the collection of packages salvaged from the "new Coke" effort: it is actually a *bunch* of frameworks, in the classic software engineering sense, along with some "pure" libraries.
Zope Toolkit, perhaps? (No relationship to Portal Toolkit. :-] )
+1
If you want to attract non-Zope people, then "Zope Toolkit" may not be optimal. The term suggests: the toolkit for Zope users. -- Dieter
Martijn Faassen wrote at 2009-4-8 15:31 +0200:
... In order to make Zope 2 and Zope 3 fit the pattern, it'd be nice if they had names that fit the "Zope is a project, not software" pattern. We could rename Zope 2 to Zope Classic, as was suggested. I think we should also rename Zope 3 to something else (that doesn't imply it's the modern future, as there are other alternatives at least as modern around that are more recently developed - we want to get out of that bind).
"Zope 2" and "Zope 3" is not ideal but by now familiar. I do not think a renaming effort would be worth at the current time. Avoid misleading names in the future....
think renaming Zope 2 to Zope Classic will be easy. If the Zope 2 developers are okay with this, let's go right ahead.
I will continue to speak of Zope 2 (not Zope Classic). -- Dieter
On Fri, Apr 10, 2009 at 09:23, Dieter Maurer <dieter@handshake.de> wrote:
I will continue to speak of Zope 2 (not Zope Classic).
Right. The classic/legacy renaming is only necessary if we were to move to Zope 4, which we aren't, or continue to talk about Zope 3, which we aren't. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Friday 10 April 2009, Dieter Maurer wrote:
think renaming Zope 2 to Zope Classic will be easy. If the Zope 2 developers are okay with this, let's go right ahead.
I will continue to speak of Zope 2 (not Zope Classic).
+1. I think we gain nothing by renaming Zope 2 to anything else. I agree with all arguments made in favor of keeping the Zope 2 name. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Stephan Richter wrote:
On Friday 10 April 2009, Dieter Maurer wrote:
think renaming Zope 2 to Zope Classic will be easy. If the Zope 2 developers are okay with this, let's go right ahead. I will continue to speak of Zope 2 (not Zope Classic).
+1. I think we gain nothing by renaming Zope 2 to anything else. I agree with all arguments made in favor of keeping the Zope 2 name.
It's not necessary anymore to pile this on; before Dieter even spoke up today this branch of the discussion was dead anyway. :) I'd rather have your opinions about the future of Zope 3 elsewhere in this thread... Regards, Martijn
participants (21)
-
Andreas Jung -
Baiju M -
Benji York -
Chris McDonough -
Chris Rossi -
Chris Withers -
Dieter Maurer -
Hanno Schlichting -
Jan Ulrich Hasecke -
Jim Fulton -
Lacko Roman -
Lennart Regebro -
Martijn Faassen -
Martin Aspeli -
Matthew Wilkes -
robert rottermann -
Roger Ineichen -
Shane Hathaway -
Stephan Richter -
Tres Seaver -
Wichert Akkerman