[Zope-dev] Plone vs. Zope2 was: Re: naming Zope
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 ___ 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 )
Re: [Zope-dev] Plone vs. Zope2 was: Re: naming Zope
-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 tsea...@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- ___ 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 )
Re: [Zope-dev] Plone vs. Zope2 was: Re: naming Zope
On Thu, Apr 9, 2009 at 05:34, Tres Seaver 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 ___ 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 )
Re: [Zope-dev] Plone vs. Zope2 was: Re: naming Zope
Lennart Regebro wrote: > On Thu, Apr 9, 2009 at 05:34, Tres Seaver 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 ___ 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 )
Re: [Zope-dev] Plone vs. Zope2 was: Re: naming Zope
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 ___ 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 )
Re: [Zope-dev] Plone vs. Zope2 was: Re: naming Zope
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 ___ 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 )
Re: [Zope-dev] Plone vs. Zope2 was: Re: naming Zope
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: > On Thu, Apr 9, 2009 at 05:34, Tres Seaver 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 tsea...@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- ___ 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 )
Re: [Zope-dev] Plone vs. Zope2 was: Re: naming Zope
-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 tsea...@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- ___ 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 )
