Re: [Zope-dev] Plone/Metadata/FUD
Hi! I could comment for hours on the postings in this thread (after rereading what I've just written below I actually did ;-)). But let me just take this to say what is most important to me: > In the world of Zope 3, this distinction will be even more clear. Zope > 2 unfortunately tried too much to be an enduser product, causing > confusion. Zope 3 will clearly say: "This is for developers." Paul, you are talking about a point that is very critical to Zope's future. Many of us started using Zope in the first place because it was a cool, out-of-the box product. Zope 1.x, as well as the early versions of Zope 2.x, could be described as a feature-complete, easy-to-customize content mangement system for a small number of users, with support for integration of data from SQL and other external sources and for writing nice little dynamic apps. You just needed some DTML, not really do any real programming, be it in Python or DTML. And the separation of programming vs. just customizing was rather obvious. With the limited possibilities of DTML it was impossible to do real coding, which was a good thing. The Zope Management Interface (ZMI) worked fine if you had just a few templates, like a customized index_html, standard_html_header, etc. The Add-list was short, and even security worked fine with just a few Products installed and just a few users to map roles to, which you would have to map Permissions to. Then a lot of stuff was added, most of it very cool, but not always fitting into the original concept. ZClasses where the best and the worst idea of all at the same time. And they also are a good example of a Zope component that was over-hyped at first and then dropped like a hot potatoe (others are XML support, Mozilla support, and to some extent even the CMF). Before ZC started the documentation efforts, a Zope newbie would have no clue whether it was better to work with ZClasses or file-based products. Now things are, to an extent, even worse. To work with Zope and really get the most out of it, you need to know Python (even in the ZMI, as Python scripts are the preferred way of coding little helper methods), DTML (because ZPT can't do everything), and ZPT. This is really confusing for a lot of people. The thing I hate most is that there are really useful helper methods and classes in lib/python/App (and also in some other obscure places) that are frequently used by the ZMI itself. But this stuff is mostly undocumented and obviously written by ZMI-designers for ZMI-designers. E.g.: Zope copy&paste support is cool. But there is no easy way of using it in customized user interfaces, as all the methods return you "back" to some ZMI page. So while obviously Paul is right that Zope 3 should be focussed at the developer and mainly provide well-tested, well-documented, low-level tools for doing great things, Zope (3) will only survive if we get a lot of a lot people using it. And as most people are NOT developers, they will need end-user products that are based on Zope. Otherwise Zope will get lost. If Zope 3 is meant to be a developer's tool then it will play in the league of BEA WebLogic, IBM WebSphere. Those products are powerful and expensive. And they are so complicated to use that you need experts to work with them. So the market segment is very interesting, but limited to large corporate clients. Most of the users Zope currently has are probably using it as an alternative not to an application server but to either Apache+PHP/Perl or to a CMS. Virtually all the hosting customers we have at iuveno run no custom products. Some of them use existing ones like Squishdot or the CMF, some use ZClasses. So for them Zope IS the product, not the platform. Most of the consulting jobs Zope services companies can get will not be in the 100.000-1.000.000 EUR or $ range, but smaller in size. So the budget is large enough to customize an existing product, but not to write one from scratch, regardless how cool the platform is. I am quite sure that you can write a lot of stuff much quicker in Zope/Python than you'd get it done in Java, let alone C. But still that's not good enough to survive. My opinion is that what we as Zope-using services companies will need to survive is ready-to-use products we can easily customize. Plone is one of those, though I personally don't like all of it that much, Silva is another. And now comes the part where the Zope community can fit in: Most CMS I know, Zope-based or not, just try to do the same thing in slightly different ways. I am positive that as an open source community we could do MUCH better if we shared more of the development, not only on the Zope-level, but also and maybe even mainly on the application level. For me, Zope 2 is not perfect, but good enough to base applications on. So I would not necessarily need Zope 3 from that point of view. It is also hard for me to contribute to Zope 3 if it stays so abstract. An example: Contributing to the object hub is hard if yo
Re: [Zope-dev] Plone/Metadata/FUD
> My only response is why wasn't " Many of the components and frameworks > currently supplied by the CMF" included in the core Zope in the first > place? Everybody has the right to work on their own thing sure. We > would already have a highly extensible Zope3 by now if the time wasn't > spent trying to create something else that should have been in the core > of Zope in the first place. If only people could write the ideal software first time! From my point of view as a Zope 3 contributor, I'm extremely glad that the patterns, use-cases and learning experiences were developed in the CMF, outside of the core of Zope. If what is going into Zope 3 had been worked into the core of Zope 2 instead of being tried out in the CMF, the speed of development would have been an order of magnitude slower, and there would have been a much greater risk of increasing the number of deprecated APIs in the Zope 2 core. So, bravo to the CMF developers and contributors. Not only do we have a useful and innovative framework today, we have the blueprints for a better Zope tomorrow. -- Steve Alexander ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Plone/Metadata/FUD
>From: Max M <[EMAIL PROTECTED]> >Paul Everitt wrote: >> >>...this. How can we listen to you if you're not participating? But to >>your point: the Zope community does not want, IMO, Zope and CMF merged. >>Content management is a piece of the Zope pie, not the whole pie. > > >And sooo right you are. If Zope became the CMF or Plone I would drop it in >an instance. > I'm way too tired and need to hit the sack now, but here is a quote from the URL given to me by Paul " Zope 3 will include many of the components and frameworks currently supplied by the CMF. " Now I never claimed or stated that the CMF needed to be merged with the Core Zope. Nor did I claim that Plone needed to be merged into Zope. After school tommorrow I will work to clarify my position. What I'm sensing though is double speak, because now it sounds like you want to beef up that shovel, and imho the content to be managed is the dirt. My only response is why wasn't " Many of the components and frameworks currently supplied by the CMF" included in the core Zope in the first place? Everybody has the right to work on their own thing sure. We would already have a highly extensible Zope3 by now if the time wasn't spent trying to create something else that should have been in the core of Zope in the first place. Let me ask you this, what does an app server serve? I say it servers content, you can call it data, information, results, or whatever. I'd say we would have had alot more products out for Zope had that framework been placed in Zope instead or "Forking" the content concept with a seperate tool. There are parts of the CMF that we can agree on that don't belong in the core of Zope. And that is where products such as Plone, CMFZen, and Swishdot come into play. What is the problem with my point of view? Peace, -- James I am a Washington State Citizen. Spamming this Email Address may be against Washington State Law Chapter 19.86, and 19.190 RCW. http://www.wa.gov/ago/junkemail/protect.html _ Send and receive Hotmail on your mobile device: http://mobile.msn.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Plone/Metadata/FUD
Paul Everitt wrote: > > ...this. How can we listen to you if you're not participating? But to > your point: the Zope community does not want, IMO, Zope and CMF merged. > Content management is a piece of the Zope pie, not the whole pie. And sooo right you are. If Zope became the CMF or Plone I would drop it in an instance. There are so many wonderfull things that can be done in Zope, when it is as it is now. And many of the things does not fit into the cmf frame of mind. Ie. I have a completely different idea as to how things should be done in Zope than how the CMF do it. When you start making a concrete implementation of something you make some decissions in the beginning, and those decissions influence how you make the rest of your decissions. So you get this complex web of layers of decissions that depends on each other. You sort of paint yourself into a corner. An evolutionary dead-end so to speak. If Zope gets forced to go in one different direction, like CMF, it will quickly hit an evolutionary dead end. regards Max M -- The reason I don't reach any higher is that I stand on the shoulders of midgets. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Plone/Metadata/FUD
On Thursday, Oct 3, 2002, at 03:54 Europe/Paris, James Johnson wrote: > I've been around the Zope/Python scene for many years. One thing I > see this group suffer I believe if from the groupthink mentality. > Imho Alexander Limi "2 cents worth" demonstrated Erik's point > perfectly. applaud the effort made with plone. I believe it to be a > spoon in which we can spoon feed newbies into the CMS side of the Zope > way. > Seem my post regarding Zopezen.org. Plone is slow. Zope with CMF is > slow... Not as slow as plone, but the issue is with ZPT. There is no > way around it Erik is right. Developer time being spent on speeding > up plone in order to backport the improvements to Zope/CMF sounds... > Well arse backwards. Plone has its place, but I suspect some > doublespeak here, lets be realistic about it. The Plone people are a layer above CMF, which is a layer above Zope, which is a layer above Python, which is a layer above the C library, which is... Do the Plone people have responsibility for all the layers below them? Nope. If there was a bug in the Python compiler (and in the last six months, there was one), should Plone have to fix it? Should they also fix problems in the Linux virtual memory model if they find that too? Nope. > I debated a long time ago about CMS being the core of Zope anyway, > but lo and behold they pushed on with a "CMF" product. I see plone as > being the same, a Two errors here: a. The Zope community, on the whole, doesn't want Zope narrowed exclusively to content management. b. The CMF isn't a product. It is a framework. It specifically intends to not be a product. > product. Now my understanding is that with Zope3, they will roll a > lot of the CMF functionality into Zope3 Hmm go figure? All that > time wasted on maintaining 2 This isn't precise. The CMF machinery, the part not unique to content management, is going into Zope 3. The effort for content management in Zope 3 is being managed as a companion project: http://lists.zope.org/pipermail/zope3-dev/2002-September/002819.html I'll note that you are neither subscribed to the Zope 3 mailing list, nor have you commented on the email above. If you're not even participating, then you should be more circumspect when making assertions such as: > products Zope/CMF has proven cumbersome at the least imho. Now just > imagine if the community would have listened to the lone voice > James-then/Erik-now where we ...this. How can we listen to you if you're not participating? But to your point: the Zope community does not want, IMO, Zope and CMF merged. Content management is a piece of the Zope pie, not the whole pie. > would be today. We all know that the decision back then was based on > commercial interest for ZC and others trying to market some industry > catch phrase. I have no idea what you are claiming. In fact, the reverse is true: ZC is focused on content management, but ZC realized others want to do different things with Zope. Thus ZC didn't turn Zope into a CMS-exclusive thing. Doing the CMF outside of Zope allowed the CMF to make rapid progress in a focused area without making promises that Zope itself would have to live with permanently. This has worked perfectly. We all now know a lot more about the patterns of content management. We can now refine them, and refine Zope, with the work on Zope 3. Tell me, do you think KDE should be merged into X11? It is exactly the same analogy. You're also claiming that Erik is voicing your opinion. I don't believe Erik wants a one-size-fits-all CMS product that everyone must support, nor do I believe Erik wants Zope to be focused exclusively on content management. However, I don't pretend to speak for Erik, so he can correct me if I'm wrong. > So I hear you Erik, you have these wonderful, bright people working > on special interest projects, but not on the core issues that allow > Zope to have that strong core that it needs to move it forward. People work on what they want to work on. Alex Limi knows CSS and doesn't want to learn how the ZPT compiler should be optimized in C. It is unfair that you demand that he learn how to program in C. It is also wrong. Zope has more people that know C than know CSS well. We are lucky that Alex is filling an unmet need in the world of Zope. > With it being evident in how the "Release early/Release often" mantra > has been Explain how this is thrown by the wayside. You can, every single day, make a checkout of any part of Zope. Sure there was a gap between 2.6 alpha and 2.6 beta. But that's a single datapoint. Name another datapoint to support your conclusion. > thrown to the wayside, I'm left wondering what do I do next with my > 2.5.1 site? Do I go the plone, 2.6, 2.7 or 3.0 route? Going the Plone route is orthogonal to choosing a Zope version. Not a single person in the world of Zope claims that 3.0 could even
