Re: [Zope3-Users] Visionaire! (All your problems, solved)
Jeff Shell wrote: Yes it does. And I hate it. At Bottlerocket, we're a very small company. We look at Plone and go alright, how do we make it do less? how do we turn this thing off, and this thing off, and this thing off, and this thing off? why is it so slow? and it still doesn't do the page we need to do. Let's just write our own CMS. * Apparently many people disagree with you. Google hits: **27,700,000* for **Plone ***23,600,000* for **Zope** *14,800,000* for **Zope -Plone** For small companies that needs a small subset of what Plone can do, Plone might be a bit big. But for consultants/developers like me it is *far* easier to use Plone, remove some features and add those that are missing. A fully finished system, that end users can install and try out, is the biggest succes story of Zope. There *must* be a lesson in that somewhere. That Plone is difficult does not reflect that a big integrated system is the wrong way to go! It only indicates that the Zope/CMF/Plone stack is too big. Which is exactly why Zope 3 was developed, and I can hardly wait until something like Plone is running directly on Zope 3. Then we will both have a big hunking end user system and a clean development model. I know that something like Plone isn't the best solution for everything. Eg creating a task based intranet is impractical. But its still the most succesfull approach so far. Plone has become a very precise communication tool between programmers. If your product works in a straight Plone installation, it can be modified with known patterns by other developers. If everything is fragmented we will loose this unification by example and setting up big systems will be a lot more difficult. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Visionaire! (All your problems, solved)
Jeff Shell wrote: I think this keeps Zope 3 as we know it alive, keeps the Zope brand intact, and offers a future for Zope 2 and similar caliber desires for a Big App Server while not interfering with the more pure and simple concepts that makes Zope 3 appealing for developers like me. I think its an absolutely terrible idea! The most succesfull Zope 2 product out there is most likely Plone. And it has everything and the kitchen sink in it. Python also has a lot of libraries included, which means that you seldomly need 3. party libraries to extend Plone. I fear that loosely coupled libraries does not make an app server. I can just imagine the upgrade hell when one package requires two different packages, and another package requires the same two different packages, but in different versions. Canonical releases of compatible package collections is a *must*. Splitting it all up in small chunks that are out of sync would be a disaster. Releases that contains a *huge* compatible collection of packages is the most effective way to move forward in an unified way. Plone products works together because Plone is so well defined. Sometimes this feels like a straightjacket. On the othe hand, in plain Zope 2 it is practically impossible to reuse other peoples products on your own site because the playing field was too loosely defined. But just like you don't have to learn every Python library to use Python, you should not have to know every package in the app server. That is not a question of making seperate releases though, it's the age old programming problem of structuring code with few interdependencies. So throw everything into the release. heck even throw Zope 2 in there if you have to. But dont force the programmers to use it before they need the functionality. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Visionaire! (All your problems, solved)
I'm with Max on this one. What's the point? To save a few megabytes of harddisk space? If you don't want the zope.bobo part of your zope3, ignore it. You don't have to use it if you don't want to. It's been a while but the last time I installed Plone it came with stuff like CookieCrumbler and Formulator. What a bliss and time-saver! It's not unix-right but I don't care, I have other stuff to spend my precious time on such as coding. Making things simple will (and always has) be superior to making things clinically correct in the computer industry. You point, Jeff, was that the Zope2 ZMI is plaguing the true Zope3 as you know it. I'm not worried about this personally. On most of my zope2 products the ZMI is just used as a debug tool rather than something clients get to work in. Sure, people have misstaken Zope for Plone when they use the windows installer and we've all seen newbies complaining about bugs in zope on the zope mailing list which just happens to be a 100% plone related only. Tough. I'd rather have a few of these lost beginners who are wrong than no new beginners at all. Let's keep it simple, bundle it all in one fat package and ignore the excessive zmi files that gets thrown in. On 3/2/06, Max M [EMAIL PROTECTED] wrote: Jeff Shell wrote: I think this keeps Zope 3 as we know it alive, keeps the Zope brand intact, and offers a future for Zope 2 and similar caliber desires for a Big App Server while not interfering with the more pure and simple concepts that makes Zope 3 appealing for developers like me. I think its an absolutely terrible idea! The most succesfull Zope 2 product out there is most likely Plone. And it has everything and the kitchen sink in it. Python also has a lot of libraries included, which means that you seldomly need 3. party libraries to extend Plone. I fear that loosely coupled libraries does not make an app server. I can just imagine the upgrade hell when one package requires two different packages, and another package requires the same two different packages, but in different versions. Canonical releases of compatible package collections is a *must*. Splitting it all up in small chunks that are out of sync would be a disaster. Releases that contains a *huge* compatible collection of packages is the most effective way to move forward in an unified way. Plone products works together because Plone is so well defined. Sometimes this feels like a straightjacket. On the othe hand, in plain Zope 2 it is practically impossible to reuse other peoples products on your own site because the playing field was too loosely defined. But just like you don't have to learn every Python library to use Python, you should not have to know every package in the app server. That is not a question of making seperate releases though, it's the age old programming problem of structuring code with few interdependencies. So throw everything into the release. heck even throw Zope 2 in there if you have to. But dont force the programmers to use it before they need the functionality. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Visionaire! (All your problems, solved)
On 02.03.2006., at 12:41, Peter Bengtsson wrote: I'm with Max on this one. What's the point? To save a few megabytes of harddisk space? If you don't want the zope.bobo part of your zope3, ignore it. You don't have to use it if you don't want to. not sure of what to think about this vision but the idea may be seen from a naming and documentation stand point. I don't think there is a particulary need to phisically split the distribution, various zope subpackages are already quite independent from each other, but a simple naming of layers of the entiere framework could be helpful to describe to a beginner how to approach to a given problem, and a set of instance installation scripts that will create the base for it. -- marko ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Visionaire! (All your problems, solved)
On Thu, Mar 02, 2006 at 10:23:17AM +0100, Max M wrote: Canonical releases of compatible package collections is a *must*. Splitting it all up in small chunks that are out of sync would be a disaster. but we already have that situation with current Products. How many sites are still running Zope 2.7 and Plone 2.0 because there's one product they depend on that doesn't work in 2.8 or 2.9? Releases that contains a *huge* compatible collection of packages is the most effective way to move forward in an unified way. That requires a huge coordination effort. It's not sustainable. This is why there's so much attention being paid to eggs lately. Eggs are one packaging solution that allows version dependencies to be explicitly stated in each package, and allows multiple installed versions at the same time. -- Paul Winkler http://www.slinkp.com ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Visionaire! (All your problems, solved)
Jeff Shell wrote: - Zope 3 CA: The Zope Component Architecture. Core services. Would include zope.publisher and most other current top level zope.* things. Usable as a library, as a publisher for other environments, perhaps as a simple standalone server. Easy to deploy against WSGI, Paste.deploy, whatever. - Zope 3 AS: The Zope 3 Application Server. A Zope 3 CA stack using the ZODB, ILocation, and most of the zope.app services but without any content objects. Perhaps only an application server configuration skin (process management) but no ZMI. Maybe have the current configuration installable as an option. - Zope Suite (or Zope Web or Zope DE): This is the full application server perhaps Jim is envisioning. A comprehensive web based user interface, based on features (and implementations) of both Zope 2 and Zope 3 application servers and offerings. Zope 3 CA, Zope 3 AS: good. Zope Suite: moderately bad. Zope 3 ECM (currently known as Z3ECM): good ;) Zed/The Component Architecture Formerlyknown as Zope/GoldEgg/whatever that's not called Zope something: YUCK! (Who's Zed? Zed's dead, baby!) S. -- Stéfane Fermigier, Tel: +33 (0)6 63 04 12 77 (mobile). Nuxeo Collaborative Portal Server: http://www.nuxeo.com/cps Gestion de contenu web / portail collaboratif / groupware / open source! ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Visionaire! (All your problems, solved)
Paul Winkler wrote: On Thu, Mar 02, 2006 at 10:23:17AM +0100, Max M wrote: Canonical releases of compatible package collections is a *must*. Splitting it all up in small chunks that are out of sync would be a disaster. but we already have that situation with current Products. How many sites are still running Zope 2.7 and Plone 2.0 because there's one product they depend on that doesn't work in 2.8 or 2.9? That's Plone's problem, not Zope's. S. -- Stéfane Fermigier, Tel: +33 (0)6 63 04 12 77 (mobile). Nuxeo Collaborative Portal Server: http://www.nuxeo.com/cps Gestion de contenu web / portail collaboratif / groupware / open source! ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Visionaire! (All your problems, solved)
Stefane Fermigier a écrit : Paul Winkler wrote: On Thu, Mar 02, 2006 at 10:23:17AM +0100, Max M wrote: Canonical releases of compatible package collections is a *must*. Splitting it all up in small chunks that are out of sync would be a disaster. but we already have that situation with current Products. How many sites are still running Zope 2.7 and Plone 2.0 because there's one product they depend on that doesn't work in 2.8 or 2.9? That's Plone's problem, not Zope's. +1 -- Encolpe Degoute INGENIWEB (TM) - S.A.S 5 Euros - RC B 438 725 632 17 rue Louise Michel - 92300 Levallois Perret - France web : www.ingeniweb.com - « les Services Web Ingénieux » ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Visionaire! (All your problems, solved)
Marko Mikulicic wrote: On 02.03.2006., at 12:41, Peter Bengtsson wrote: I'm with Max on this one. What's the point? To save a few megabytes of harddisk space? If you don't want the zope.bobo part of your zope3, ignore it. You don't have to use it if you don't want to. not sure of what to think about this vision but the idea may be seen from a naming and documentation stand point. I don't think there is a particulary need to phisically split the distribution, various zope subpackages are already quite independent from each other, but a simple naming of layers of the entiere framework could be helpful to describe to a beginner how to approach to a given problem, and a set of instance installation scripts that will create the base for it. Exactly. I hope to see three kinds of tutorials and books: one set about using the component architecture, one set about using the application server, and one set about the CMS. I believe all three layers are already complex enough to write a whole book about each one, and the methods of using each layer already seem quite different. Thus choosing names for the layers, and choosing what software goes in what layer, would be quite beneficial for documentation authors. Shane ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Visionaire! (All your problems, solved)
On Mar 2, 2006, at 6:41 AM, Peter Bengtsson wrote: I'm with Max on this one. What's the point? To save a few megabytes of harddisk space? If you don't want the zope.bobo part of your zope3, ignore it. You don't have to use it if you don't want to. ... Let's keep it simple, bundle it all in one fat package and ignore the excessive zmi files that gets thrown in. That's a reasonable position; Zope 2 has really done well under this model. But one of Zope's historical problems been that no two people have the same vision of what that one fat package should actually do. Is it a content management system? An app server? A collection of Python packages? It's all of those things to some level or another, but it's hard to keep it tidy when the huge package is being pulled in all of those directions. It's be easier to compose the big package out of smaller, independently-maintained bits. It's not just excessive ZMI files that clutter things up, cross-package dependencies creep in because nobody can tell what the boundaries are, and then it's impossible to not distribute the whole huge honking tarball. It's also important to let the good parts of Zope thrive naturally on their own and let the bad parts die, and in order for this to happen they need to be packaged independently. Zope 2 was *meant* to be a collection of smaller packages that could work outside of Zope-the- framework, but because of packaging issues, only a few things actually do work well outside (ZPT and ZODB). - C ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Visionaire! (All your problems, solved)
We've been through a lot lately. You know it, I know it. Zope has a reputation. Sometimes it's good, sometimes it's bad. This has affected Zope 3, since Zope 3 is very much not Zope 2. But it's affecting Zope 2 as well, as Jim has brought to our attention. Zope 3 is Mature. Zope 3 sounds like Zope 2+1. Zope 2 and Zope 3 have very different concepts. Zope 3 has restricted its audience, for now, to developers; while Zope 2 is appealing to many different kinds of end users and programmer types. Five offers a bridge so that Zope 3 as a library may be used in Zope 2, and the Zope 2 core has started making use of some Zope 3 concepts. But it's obvious we have a name problem. Even within Zope 3, there's a name problem, between Zope 3 as Application Server and Zope 3 as cool collection of packages. Today, I wrote a much longer message in response to the Two Visions thread. But I was in a bit of a bad mood, having spent many hours trying to set up a test harness to test one little thing in my own code that was causing problems - a one little thing that depended on quite a few components being set up, and it was painful. And I'm still not done. And I realized, as I stewed away, that I like Zope 3 as an Application Server... But I'd like it with less. And this option hasn't been proffered, so far as I can tell. It seems like Jim's Vision might be two options - zope as library and big zope application server with all of the object file system and probably through the web stuff and so on and so on and would be largely compatible with both Zope 2 and Zope 3 as they stand today. Personally, I'd love to have the first option. I also, personally, don't care if I have the second option, but I recognize the need or desire for it, and the desire to get out the message that Zope 2 and the applications on it actually do have a future even though they may not have a future with Zope 3 as Zope 3 is currently known. I'd like a third option: the Zope 3 Application Server as it is right now, but with less. No Rotterdam skin, perhaps no ZMI. No content objects at all, except maybe for some example file and image objects to show how to do BLOBs. It would still be ZODB based. It would still be ILocation based. zope.app.container would be prominent, and zope.app.folder would not be a distraction. It's the basis for building applications like Schoolbell/Schooltool, custom content management, itinerary managers, knowledge bases, whatever. Catalog, local sites/utilities, all still there. But without the distraction of should I support the ZMI? use it as my user interface? should I use the TTW page templates?. IFolder and IContainer... What is the difference and which should I use? Which should be my base class (because at Bottlerocket, we chose Folder when we shouldn't have, we found out much later). Maybe that stuff would still be in the library. Maybe it would still be available as a 'mkzopeinstance' option. But the Zope 3 Application Server would probably work best if it promoted custom development via persistent objects, views, and custom skins, as the default way of working with it. It's easier to write documentation for, it could be easy to write mkzopeinstance commands for (to generate a basic starting point with skeleton code and a site.zcml setup that loads the custom skin). There's not this other User Interface and other objects providing a distraction. I'm making a wiki. How does SQL Script apply? I18N File?. And then I thought about Taligent, for some reason. I'm not going into the history of the company/project, whose products never really made it out into the light of day. But at some point, they broke their product (which was to be a new object oriented operating system) out into a small set of distinct offerings: TalOS (Taligent Object Services), TalAE (Taligent Application Environment), and so on. And I thought about doing this for Zope, and came up with the following: - Zope 3 CA: The Zope Component Architecture. Core services. Would include zope.publisher and most other current top level zope.* things. Usable as a library, as a publisher for other environments, perhaps as a simple standalone server. Easy to deploy against WSGI, Paste.deploy, whatever. - Zope 3 AS: The Zope 3 Application Server. A Zope 3 CA stack using the ZODB, ILocation, and most of the zope.app services but without any content objects. Perhaps only an application server configuration skin (process management) but no ZMI. Maybe have the current configuration installable as an option. - Zope Suite (or Zope Web or Zope DE): This is the full application server perhaps Jim is envisioning. A comprehensive web based user interface, based on features (and implementations) of both Zope 2 and Zope 3 application servers and offerings. We don't need a hundred different editions like Microsoft. Nor do we need a hundred different acronyms like Java development seems to have. I think we could boil things down to these three offerings,
Re: [Zope3-Users] Visionaire! (All your problems, solved)
On Mar 1, 2006, at 7:42 PM, Jeff Shell wrote: [...] - Zope 3 CA: The Zope Component Architecture. Core services. Would include zope.publisher and most other current top level zope.* things. Usable as a library, as a publisher for other environments, perhaps as a simple standalone server. Easy to deploy against WSGI, Paste.deploy, whatever. - Zope 3 AS: The Zope 3 Application Server. A Zope 3 CA stack using the ZODB, ILocation, and most of the zope.app services but without any content objects. Perhaps only an application server configuration skin (process management) but no ZMI. Maybe have the current configuration installable as an option. - Zope Suite (or Zope Web or Zope DE): This is the full application server perhaps Jim is envisioning. A comprehensive web based user interface, based on features (and implementations) of both Zope 2 and Zope 3 application servers and offerings. This would meet what I'm looking for...but I don't think I'll be one of the hard ones to convince. ;-) Gary ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Visionaire! (All your problems, solved)
I think packaging efforts are really the key to being able to tell a story like this. The efforts happen to be couched in a process of converting z3 packages into eggs, but really the process of identifying dependencies and eliminating the silly ones is the valuable work here, and it seems to be getting done by embracing egg packaging, which is really wonderful. One we have well-factored modules that are packaged and maintained independently, all sorts of things like the AS vs. CA you mention or a Zope 3 core that is more like zope.bobo, or a Zope that combines both z3 and z2 in various ways becomes a lot more possible. On Mar 1, 2006, at 7:42 PM, Jeff Shell wrote: We've been through a lot lately. You know it, I know it. Zope has a reputation. Sometimes it's good, sometimes it's bad. This has affected Zope 3, since Zope 3 is very much not Zope 2. But it's affecting Zope 2 as well, as Jim has brought to our attention. Zope 3 is Mature. Zope 3 sounds like Zope 2+1. Zope 2 and Zope 3 have very different concepts. Zope 3 has restricted its audience, for now, to developers; while Zope 2 is appealing to many different kinds of end users and programmer types. Five offers a bridge so that Zope 3 as a library may be used in Zope 2, and the Zope 2 core has started making use of some Zope 3 concepts. But it's obvious we have a name problem. Even within Zope 3, there's a name problem, between Zope 3 as Application Server and Zope 3 as cool collection of packages. Today, I wrote a much longer message in response to the Two Visions thread. But I was in a bit of a bad mood, having spent many hours trying to set up a test harness to test one little thing in my own code that was causing problems - a one little thing that depended on quite a few components being set up, and it was painful. And I'm still not done. And I realized, as I stewed away, that I like Zope 3 as an Application Server... But I'd like it with less. And this option hasn't been proffered, so far as I can tell. It seems like Jim's Vision might be two options - zope as library and big zope application server with all of the object file system and probably through the web stuff and so on and so on and would be largely compatible with both Zope 2 and Zope 3 as they stand today. Personally, I'd love to have the first option. I also, personally, don't care if I have the second option, but I recognize the need or desire for it, and the desire to get out the message that Zope 2 and the applications on it actually do have a future even though they may not have a future with Zope 3 as Zope 3 is currently known. I'd like a third option: the Zope 3 Application Server as it is right now, but with less. No Rotterdam skin, perhaps no ZMI. No content objects at all, except maybe for some example file and image objects to show how to do BLOBs. It would still be ZODB based. It would still be ILocation based. zope.app.container would be prominent, and zope.app.folder would not be a distraction. It's the basis for building applications like Schoolbell/Schooltool, custom content management, itinerary managers, knowledge bases, whatever. Catalog, local sites/utilities, all still there. But without the distraction of should I support the ZMI? use it as my user interface? should I use the TTW page templates?. IFolder and IContainer... What is the difference and which should I use? Which should be my base class (because at Bottlerocket, we chose Folder when we shouldn't have, we found out much later). Maybe that stuff would still be in the library. Maybe it would still be available as a 'mkzopeinstance' option. But the Zope 3 Application Server would probably work best if it promoted custom development via persistent objects, views, and custom skins, as the default way of working with it. It's easier to write documentation for, it could be easy to write mkzopeinstance commands for (to generate a basic starting point with skeleton code and a site.zcml setup that loads the custom skin). There's not this other User Interface and other objects providing a distraction. I'm making a wiki. How does SQL Script apply? I18N File?. And then I thought about Taligent, for some reason. I'm not going into the history of the company/project, whose products never really made it out into the light of day. But at some point, they broke their product (which was to be a new object oriented operating system) out into a small set of distinct offerings: TalOS (Taligent Object Services), TalAE (Taligent Application Environment), and so on. And I thought about doing this for Zope, and came up with the following: - Zope 3 CA: The Zope Component Architecture. Core services. Would include zope.publisher and most other current top level zope.* things. Usable as a library, as a publisher for other environments, perhaps as a simple standalone server. Easy to deploy against WSGI, Paste.deploy, whatever. - Zope 3 AS: The Zope 3 Application Server. A Zope 3 CA stack
