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 run a prototype system, much less
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
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? snip 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
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
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 copypaste 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 you don't
[Zope-dev] Plone/Metadata/FUD
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. 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 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 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 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. 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. With it being evident in how the Release early/Release often mantra has been 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? Like I said before, as a qoute from Mr limi you should not mix in the Plone name if you do not intend to follow our guidelines. TM. Plone is a major benefit to the community. Please keep up the good work and effort. I believe that the master minds behind it all should be working to make Zope3 a reality for the plone product and not the other way around, hence you'll screw up mixed-up people like me even more. I hope I'm making some sense with this. I understand that this is free software, but as I community we should work toward making sure that we all can have a voice and benefit from plone/zope 2.5-2.6-2.7-3.0/CMF/Thingy. I'm sure I'll have to take a loan out on this, because it's more than 2 cents worth ;-). 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 At 05:08 PM 10/2/02, Alexander Limi wrote: quote who=Erik Lange In the install-script for MMM Skins, we call it a plone rip-off... I've suggested that we change the product name to Plone skin to Alan, to recognize the fine work of Plone, and to make it clear what it is: A skin that gives your CMF-site a Plone-look, and nothing more... As one of the two designers of the Plone skin, I thought I would send you my 2 cents on this. Most welcome ! :-) Not to be harsh, but calling your skin anything with Plone would just cause confusion, as it has none of the distinguishing marks of the original look, apart from the blue color. Nevertheless people constantly assumes that we use Plone on our sites... so it must have something in common with the Plone 'thingy' ... Check: http://www.mmmanager.org/Members/erla/1018802975267402990/talkback/1018829961 You break almost every consistency rule and design decision in your skin, Yep - the rules set up by Plone - not the rules of CMF ;-) That was what leed us to make the product in the first place... and it is nowhere near being Plone, neither from a usability nor a design perspective. Nope - and we're proud of that ;-) I will not comment further on this, I find this discussion a bit far-fetched. Plone is a separate entity, and you should not mix in the Plone name if you do not intend to follow our guidelines. I agree :-) And we don't intend to follow your guidelines.. sorry.. but why should we ? How about CMF Zlone skin for a name ? ;-) Or CMF BTTF Skin ? BBTF = back to the future ;-) Is it okay that we thanks Plone.org for the inspiration and basic layout in the next release ? Or should we simply just blame it all on Canada ? *ROTFL* Regards, Erik _ Chat with friends online, try MSN Messenger: http://messenger.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 )
