Re: [Zope-dev] The bleak Future of Zope?
Martijn Faassen wrote at 2004-4-24 22:49 +0200: ... In practice right now the picture is 'Use all of the CMF or none of it'. No, not really... We use SkinsTool, ActionsTool and DCWorkflow a lot, MembershipTool sometimes and most other tools not at all. -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] The bleak Future of Zope?
Lennart Regebro wrote: A lot of the things that are CMF should have been put into Zope core. Agreed, that'd been a lot better. The CMF is a framework. It'd be nicer if it'd been a set of independent components. Then Silva (for instance) could've used more of what's in the CMF than is possible now. In practice right now the picture is 'Use all of the CMF or none of it'. DCWorkflow should have been there. acl_user folder should have been extended with property management and other member management instead of shimming tools and wrapping user objects as is done now. And even if portal_skins would have been included, they should have been empty of skins, instead of sending with a bunch of skins that makes CMF look like it almost is a finished product, when in fact, it just a bunch of handy tools. Actually there's a version available of at least the filesystem to Zope part of the skins system, called FileSystemSite. This is the only part of the CMF that Silva actually uses, and a separate version had to be extracted and maintained. This is a good case in point that it should've been a separate system anyway. Note that I actually also agree with Lennart that the whole concept of FileSystemSite (code on the filesystem, but actually in the ZODB) is rather odd. Silva on the medium term is switching over to a more advanced system that's purely filesystem code, more similar to Zope 3's view classes. Customization through the ZMI of skins is not possible anymore with such a system (unless some extra work is performed), but Silva never took that approach anyway so that's no loss to us. But ah well, what is done is done. Too late to change the past now. :-0 Actually Silva is using this component approach more and more, though of course its core components besides Formulator are not used in many other projects. But in fact most of its foundation should be usable outside of Silva, though underdocumented. We're in the process of factoring out more functionality though, and I expect this will slowly start to change. a few things that are going to happen in the few next months: * A cache manager. Not very advanced, but mostly useful from a python persective for simple RAM caching but in a ZEO context. This is only for application level caches and doesn't integrate with Zope's built-in caching mechanism, but that's not the intent anyway. * an extension manager; a Zope installation and configuration system that is inspired by Silva's system but is suitable for any Zope Product that needs to be extended through other Products. Silva is going to migrate to this soon. * the new view system I spoke of. It'll be based on Zope 3 adapters. I've been talking about this for a while now, and it's still vaporware besides some protoypes, but a lot of preparation has been done and we're actually going to take the big transition to such a system over the coming months. Everybody else is also invited to us it. :) Regards, Martijn ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] The bleak Future of Zope?
From: Dieter Maurer [EMAIL PROTECTED] I do not believe you. But I believe him. :-) If Zope has a steep lurning curve, that's nothing compared with CMF. There are many good things with CMF, the actions are a good idea, DCWorkflow of course, and some more. But portal_skins are a fundamentally flawed idea and has the tendency to move logic out from the products into the skins, instead of facilitating a separation between logic and design. Other evidence that the thinking is wrong is that skins are stored on disk, but through some clever predenting on Zopes part they look like they are in the ZODB. This shows that somebody has been thinking backwards. :-) The skins that come with CMF are incomprehensible, and stopped me from using CMF before I was forced to (something which is solved by using Plone or CPS, but that's not obvious first of all, and secondly, none of them were available when I started looking at CMF). And the member management is a complete mess with gazillion tools involved. :-) A lot of the things that are CMF should have been put into Zope core. DCWorkflow should have been there. acl_user folder should have been extended with property management and other member management instead of shimming tools and wrapping user objects as is done now. And even if portal_skins would have been included, they should have been empty of skins, instead of sending with a bunch of skins that makes CMF look like it almost is a finished product, when in fact, it just a bunch of handy tools. But ah well, what is done is done. Too late to change the past now. :-0 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] The bleak Future of Zope?
Lennart Regebro wrote: From: Dieter Maurer [EMAIL PROTECTED] I do not believe you. But I believe him. :-) Adding more framework code to a project as large as Zope already is, is adding complexity. It might help you get your project done faster, because the new tools are better suited to the job, but it doesn't simplify what a developer needs to know in the long run. There's nothing quite as telling as looking at the full set of methods available on a 3rd or 4th generation object. By the time you've crawled your way down the paths of all the inherited classes, you can usually uncover some fairly severe inconsistencies. The permissions associated with those methods are usually laughable by that point. Mashing 3 different permissions onto the same object meta data via 7 differen't APIs is complete HELL for people who want to program with any degree of security/privacy, and thats exactly what happens in a lot of these large add-on frameworks. -- Jamie Heilman http://audible.transient.net/~jamie/ ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] The bleak Future of Zope?
On Fri, Apr 23, 2004 at 10:57:18AM +0200, Lennart Regebro wrote: | A lot of the things that are CMF should have been put into Zope core. | DCWorkflow should have been there. acl_user folder should have been extended | with property management and other member management instead of shimming | tools and wrapping user objects as is done now. And even if portal_skins | would have been included, they should have been empty of skins, instead of | sending with a bunch of skins that makes CMF look like it almost is a | finished product, when in fact, it just a bunch of handy tools. Add to that some fancy xml-based configuration named zcml and a nice architecture and bingo, you have zope3 ;) -- Sidnei da Silva [EMAIL PROTECTED] http://awkly.org - dreamcatching :: making your dreams come true http://plone.org/about/team#dreamcatcher FORTRAN is for pipe stress freaks and crystallography weenies. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] The bleak Future of Zope?
Lennart Regebro wrote at 2004-4-23 10:57 +0200: From: Dieter Maurer [EMAIL PROTECTED] I do not believe you. But I believe him. :-) If Zope has a steep lurning curve, that's nothing compared with CMF. Usually, I am able to explain CMF to my colleagues in something like a few hours (I do this occasionally for different teams). ... portal_skins are a fundamentally flawed idea and has the tendency to move logic out from the products into the skins, instead of facilitating a separation between logic and design. It is one of our favorite tools... It provides a flexible way to contruct a namespace (badly termed skin) from components (layers). This is very useful, whenever you need several namespaces which large common parts but various small differences. We use it to describe hierarchies similar to an inheritance hierarchy: Infrastructure/ ShopPortals/ # overrides (or adds) things special for ShopPortals ShopPortal1 # overrides (or adds) things special for ShopPortal1 ... ProductPortal/ ... It makes it very easy to add new portal grous or new individual portals. We will soon use it as a main component for a production environment to produce many related products (they are described by a similar hierarchical structure). Logic, too, can make use of the flexibility provided by the SkinsTool The production system mentioned above will use the SkinsTool for logic only. Other evidence that the thinking is wrong is that skins are stored on disk, but through some clever predenting on Zopes part they look like they are in the ZODB. This shows that somebody has been thinking backwards. :-) You look at this in a funny way -- in the sense that I see it totally different. That Zope can use the objects in the file system, they must be mapped to Python objects. As the mapping is non-trivial, it is very helpful that you can check the result via the ZMI. What the DirectoryView does here, is similar to what LocalFS does -- and it is very senseful... The skins that come with CMF are incomprehensible, and stopped me from using CMF before I was forced to (something which is solved by using Plone or CPS, but that's not obvious first of all, and secondly, none of them were available when I started looking at CMF). Here, you blur the distinction between CMFCore and CMFDefault. CMFDefault is nothing more than an example for CMFCore (in my view). While we use CMFCore very successfully and very profitably, we do not use CMFDefault at all (other than as some example code). And the member management is a complete mess with gazillion tools involved. :-) This provides for a great deal of modularity... A lot of the things that are CMF should have been put into Zope core. We consider CMFCore (and DCWorkflow) as part of the Zope core. Nothing prevents you to do the same... ... acl_user folder should have been extended with property management and other member management instead of shimming tools and wrapping user objects as is done now. When CMF was designed there were already several dozens of UserFolders around. It is not too bad an idea to use existing components and wrap them with new functionality... And even if portal_skins would have been included, they should have been empty of skins, instead of sending with a bunch of skins that makes CMF look like it almost is a finished product, when in fact, it just a bunch of handy tools. Disregard CMFDefault (when you like) and just use CMFCore as a bunch of handy tools. In fact, this was the main purpose. Again: CMFDefault was considered as an example how to use the framework CMFCore. But ah well, what is done is done. Too late to change the past now. :-0 There is no need to change the past. You can start using CMFCore profitable in the future :-) -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] The bleak Future of Zope?!
Andre Meyer wrote: I have been developing for Zope for about half a year now and it took considerable effort to get anything going. I would suggest that's because you chose to use what are, imho, overly complex products ;-) With respect to CMS, Plone archetypes are too simplistic for complex data/document types and customisation takes too much effort. totally agree... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] The bleak Future of Zope?!
Terry Hancock wrote at 2004-4-21 09:39 -0500: ... I've been developing an application, which has taken about two years, largely because developing in the Zope 2 Framework model is like beating your head against the wall constantly. That's probably because I'm writing a fundamentally complex web application which I need to have a lot of large-scale control over. ... I also have to do this in my copious free time, as I'm not commercially employed to do this work (maybe someday, but not now). So in those two years, I've probably had the equivalent of 2 months of full-time work. Writing a fundamentally complex web application within 2 months work is quite impressive, isn't it? Apparently, the framework is not too bad... -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] The bleak Future of Zope?
Joachim Werner wrote at 2004-4-21 21:24 +0200: ... Believe me or not, almost everything gets more complicated with CMF/Plone than with plain Zope. I do not believe you. We have used CMF (mostly the SkinsTool, the ActionsTool and DCWorkflow) very successfully to build * an editorial system for news and newletters * an E-Commerce solution * partner portals * a content management system for fragmented SGML/XML documents We plan to use it for * the configuration of a production process * customizable intranet solutions. * ... Building a framework on top of a broken framework on top of an ageing framework that is hardly documented isn't a very good idea after all. Would be interested why you think the CMF were broken. The source documentation of Zope is not optimal but not too bad at all. Tools like my DocFinder and Zpydoc allow you to access this source documentation quite easily. -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Zope Book development moved (was Re: Call for Zope Book volunteers (was Re: Zope Book, was Re: [Zope-dev] The bleak Future of Zope?))
I've come to the unfortunate conclusion that Zope.org is just not going to cut it to do Zope Book development work due to its speed (or lack thereof). I'd like to help fix the Zope.org slowness problem, but I'm a little unclear about what's required for me to get the level of access required to do so. I read the stuff at Zope.org/About and Zope.com/Legal but it's a little hard to divine out of the combination what I need to do before I can be allowed to help. So of the Zope.org Application Server Working Group/Zope Application Working Group/Whoever wants help trying to fix it, you know where to find me! Just don't make me attend a 7am committee meeting or sign a noncompete instrument wink. In the meantime, in the spirit of expedience, I'm moving the development version of the book to plope.com. Once 2.7 edition development work is done, I will move a copy of the book back to Zope.org so it can be found easily by newbies. Interested parties can now refer to http://www.plope.com/Books/zb_signup for project information. - C On Wed, 2004-04-21 at 14:13, Chris McDonough wrote: I've set up a development BackTalk sandbox for the 2.7 edition of the Zope book at http://zope.org/Documentation/Books/ZopeBook/2_7Edition. Currently it's just an exact copy of the 2.6 Edition book (comments and all). I think the plan should be for people to: 1. take ownership of a chapter or two 2. address all the comments in the chapter and get rid of comments in places you've addressed. 3. update any material that is wrong wrt to differences between 2.6 and 2.7. The prize for taking ownership and updating two complete chapters is your name as a coauthor on the front page (as before ;-). Another thing to do is to incorporate some of John Whitener's changes the lost chapter referenced all over the place within book comments. I wonder if he's still around. At some point in the future, we can backport some of the changes to the 2.6 book if someone wants to take on that responsibility. It's advisable to use external editor to make the changes or to maybe use FTP to get sandboxed local copies of the book and make changes reuploading them as necessary. I've lost track of whether FTP access is possible or not on Zope.org at this point, however. Does anyone know? I've tried a few ports but nothing. Also, Zope.org is so slow for each request when you're logged in that we may need to move development to another system. As a data point, I've been waiting 4 minutes for Z.org to save a Wiki page... still waiting. Hilarious. Admittedly, it takes a unique brand of apathy to ignore this, but I've got an excuse. I'm waiting for the Zope.org steering committee to solve it! Chuckle. In the meantime, what slowness.. I don't know what you're talking about.. I have given Manager role in the entirety of the 2.7 edition book to both Peter and Paul. Anyone else who wants to contribute, please let me know which chapter(s) you'd like to sign up to revise and I will provide you access as necessary. I've set up a project wiki for the project at http://zope.org/Members/mcdonc/ZB_project where people can get a sense of which chapters are still available. It may not be available yet... still waiting for it to save. I will take ownership of the Installation chapter for now (I will probably take ownership of some other chapters, but I'll start small...) - C ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 ) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] The bleak Future of Zope?!
On Thursday 22 April 2004 05:22 pm, Dieter Maurer wrote: Writing a fundamentally complex web application within 2 months work is quite impressive, isn't it? Apparently, the framework is not too bad... Ya' think? I thought it just meant I kicked ass. :-D No, seriously Zope is great. But it's a bit rigid. Zope 3 will (I think) be a lot better. There's also the tiny detail that I haven't actually written it to the point where it can be used yet. So maybe it isn't that impressive. :-( Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] The bleak Future of Zope?!
Martin Kretschmar wrote: Maik Jablonski of the german speaking Zope Users Group DZUG issued a pretty bleak outlook for the future of Zope. What are your oppinions? Maik's having a bad day, he'll get over it ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] The bleak Future of Zope?!
Well, Maik has more than a bad day. In fact, he is rather right about the points he raises! I have been developing for Zope for about half a year now and it took considerable effort to get anything going. I have experience with filesystem-based Zope 2 products, Plone and Archteypes and a bit of Zope 3. While Z3 looks promising it is not likely to just take over Z2. It is too much different. The biggest problem, however is the lack of (any useful) documentation and sample code. Without the help of the mailing lists you cannot get far with Zope. With respect to CMS, Plone archetypes are too simplistic for complex data/document types and customisation takes too much effort. Do not get me wrong! I decided to use Zope because it fits my bill and I am willing to invest more time in Python/Zope/Plone, because I like it a lot (*). But be aware of J2EE/.Net, especially after the Sun/M$ agreement. I have been a Java developer for years and I know that there are a lot of (commercial) parties to develop whatever anyone needs, if you pay them. The same must be true of .Net. A good IDE for Python/Zope with support for application patterns, UML, etc. would be a good thing. Real application development is a serious business and good tools are essential, just like deadlines and milestones for new releases and up-to-date documentation. I am currently using Eclipse with PyDev, but it has a long way to go until it offers the wealth of support that Eclipse offers for Java. Boa Constructor is a good try, too. This is meant to encourage everybody, I am an optimist ;-) Beware of the pragmatic commercial developers. (*) fyi http://zope.org/Members/drapmeyer/spyse Chris Withers wrote: Martin Kretschmar wrote: Maik Jablonski of the german speaking Zope Users Group DZUG issued a pretty bleak outlook for the future of Zope. What are your oppinions? Maik's having a bad day, he'll get over it ;-) Chris -- Dr. Andre P. Meyerhttp://home.hccnet.nl/a.meyer/ TNO FEL Command Control and Simulation, http://www.fel.tno.nl/div2/ Delft Cooperation on Intelligent Systems, http://www.decis.nl/ ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] The bleak Future of Zope?!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 21 April 2004 11:53, Andre Meyer is believed to have said: Well, Maik has more than a bad day. In fact, he is rather right about the points he raises! I have been developing for Zope for about half a year now and it took considerable effort to get anything going. I have experience with filesystem-based Zope 2 products, Plone and Archteypes and a bit of Zope 3. While Z3 looks promising it is not likely to just take over Z2. It is too much different. The biggest problem, however is the lack of (any useful) documentation and sample code. Without the help of the mailing lists you cannot get far with Zope. I don't agree. I am new to zope. So I tried zope2 first, because plone had a lot of appeal. I got discouraged very quickly, because zope2 is so very grown over a time it's hard to join later. Zope3 seemed quite well documented and I had no problems going on on my own. ( There is a tutorial, a cookbook, and an online apidoc ) I can say nothing however to migrating apps from zope2 to zope3. With respect to CMS, Plone archetypes are too simplistic for complex data/document types and customisation takes too much effort. Do not get me wrong! I decided to use Zope because it fits my bill and I am willing to invest more time in Python/Zope/Plone, because I like it a lot (*). But be aware of J2EE/.Net, especially after the Sun/M$ agreement. I have been a Java developer for years and I know that there are a lot of (commercial) parties to develop whatever anyone needs, if you pay them. The same must be true of .Net. Right, I am developing Java applications for a living as well. I have been focused on consultancy work recently ( writing tech-specifications and projectmanaging for a really big publishing company ) and I think Zope / python has a good potential for use in commercial apps/systems. I have had to work with some premium CMSes and some of them really suck. I'd swap it gladly. A good IDE for Python/Zope with support for application patterns, UML, etc. would be a good thing. Real application development is a serious business and good tools are essential, just like deadlines and milestones for new releases and up-to-date documentation. I am currently using Eclipse with PyDev, but it has a long way to go until it offers the wealth of support that Eclipse offers for Java. Boa Constructor is a good try, too. I tried Eclipse, but its so slow. This is meant to encourage everybody, I am an optimist ;-) Beware of the pragmatic commercial developers. As to be pragmatic: It is easier and faster to write a functionality in python than in java and thus cheaper. I say : beware of the Marketing. We had to migrate a banking system from a corba/c++ system to J2EE during the last phase of the project, because the customer had heard of 'this J thing everyone is using'. (*) fyi http://zope.org/Members/drapmeyer/spyse Chris Withers wrote: Martin Kretschmar wrote: Maik Jablonski of the german speaking Zope Users Group DZUG issued a pretty bleak outlook for the future of Zope. What are your oppinions? Maik's having a bad day, he'll get over it ;-) Chris - -- Eckart Hertzler Senior Consultant G+J Electronic Media Services GmbH 20457 Hamburg Tel. : +49 40 3703 7591 Fax : +49 40 3703 - 5792 email: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAhlKLxvP4sHhhP/gRAne0AKCXehtMYeMzx1s0N0o+1ph11As/4gCg2Y62 MigAPYapLhAii0HGbEdz84A= =E63J -END PGP SIGNATURE- ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] The bleak Future of Zope?!
is there an URL for the original? Martin Kretschmar wrote: Hello, Maik Jablonski of the german speaking Zope Users Group DZUG issued a pretty bleak outlook for the future of Zope. What are your oppinions? Here comes the translation of his oppoion: smime.p7s Description: S/MIME Cryptographic Signature ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] The bleak Future of Zope?!
my nz$ 0.02 worth - is the future bleak? nothing seems to awry to me, this copy you pasted has no basis for argument - why even bother pasting it - for some upgrades of zope 2.* I need to rethink some rather understandable aspects of my zope products - each one appears to be a migration to z3. - if my next upgrade == z3 and I need to spend more than a few days fixing my products, then perhaps something went wrong. But I don't see that happening yet, but then, by being limited to production quality releases, I just read the news items and browse zope-dev. On 21/04/2004, at 7:58 PM, Martin Kretschmar wrote: Hello, Maik Jablonski of the german speaking Zope Users Group DZUG issued a pretty bleak outlook for the future of Zope. What are your oppinions? Here comes the translation of his oppoion: Maik, what makes you look full of scepticism for the future of Zope? Shortly said, the whole set of stupidities in connection with Zope3. It is a pretty bad state for a project, if it looms for years as the followup project on the horizon but in reality isn't one! I can't believe the fairy tales with the possible migration from Zope2 to Zope3. All the people which have dwelled more or less deeply into the Zope2 world, thereby having had an enormous learning curve and now running applications, will not be able to participate easily on the academic Zope3 train. The technic freaks who modell Zope3 are usually not application developers, which have to build and run working applications for real human users. The artifical not-yet-product Zope3 will sooner or later be distracting development efforts from Zope2 because Zope3 is almost finished. That doesn't look not nice ... Further I see the problem that Zope probably has no real target group as an application server. The enterprise world is dominated by .Net and J2EE. Zope in its current form without a sensible documentation in conjunction with the drama about the english zope book doesn't help changing this. Scripting has arrived in the Java world by Groovy, so this isn't a reason for using Zope anymore. In the world of small and medium applications PHP is likely to stay, because it leads much faster to results. Zope is to complicated for this. For the CMS stuff we have Plone, but this is rather suited for handling some simplistic documents for the intranet rather then a nice internet representation. This is because customizing Plone isn't trivial at all and nobody want's to run web pages with standard underwear blue. OK, the colours can be changed easily, other features via CSS, etc. ... Maybe I'm simply sick of moving along within web browsers and the file system without a sensible IDE and documentation. Regards, Maik ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 ) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] The bleak Future of Zope?
On Wednesday 21 April 2004 03:58, Martin Kretschmar wrote: Maik Jablonski of the german speaking Zope Users Group DZUG issued a pretty bleak outlook for the future of Zope. What are your oppinions? I think Chris is right to say that Maik had a bad day. If not, and if he is serious about his uninformed opinions as stated in this E-mail, then I feel the necessity to reply to his points. Here comes the translation of his oppoion: Maik, what makes you look full of scepticism for the future of Zope? Shortly said, the whole set of stupidities in connection with Zope3. It is a pretty bad state for a project, if it looms for years as the followup project on the horizon but in reality isn't one! The reason it took so long is that there are a lot of people that take, but do not give back. While the Zope community has thousand's of developers, the Zope 3 community never exceeded a core team of 10 people at any given time. That is very sad!!! People use Zope 2 and rest on it. Many do not realize that if you want to stay in the technology business, you have to innovate and Zope 3 is just that, Zope 2 would eventually fall apart due to bloating and inflexibility. Zope 3 anticipates this and tries to fix the deficiencies. BTW, the TODO list for Zope X3.0 is less than 80 lines long at this point. I can't believe the fairy tales with the possible migration from Zope2 to Zope3. Well, if you have not studied the proposed solutions, what can you expect? I personally never believed in a compatibility layer for Zope 2 in Zope 3, which was thought possible early on and I made no secret out of it. However, the current approach is very simple and therefore realistic. Starting with Zope 2.8 or 2.9, you will be able to start developing applications that will run in Zope 2 and 3. This will provide a migration path to many. BTW, if you think that we do not address your needs correctly, don't waste time complaining, but use it to create **constructive** criticism on Zope3-Dev and participate. All the people which have dwelled more or less deeply into the Zope2 world, thereby having had an enormous learning curve and now running applications, will not be able to participate easily on the academic Zope3 train. academic, huh? To talk about myself, just because I am a Ph.D. student does not mean I am academic (in the sense you mean it here). I often consider myself as an engineer in science. Furthermore, I have developed many apps for end-users before starting to work on Zope 3. Many of the large contributions I made were motivated by my application development experiences. The current I18n and L10n support, for example, would not be what it is without my real-world doings. The technic freaks who modell Zope3 are usually not application developers, which have to build and run working applications for real human users. First off, freak has an extremely negative connotation in English, other than in German. The German freak is translated as geek to English. Now to some of the other developers: Jim (Fulton) -- Over the last years I have been several times in F12g and had the chance to get to know him better. Jim has wealth of experience that is hard to match. If he cannot think about a good solution or thinks about his approach as too abstract, he always talks to other ZC developers (who do work on applications all the time) for advise and values it highly. He is a true engineer! Steve -- He has built the first commercial application for Zope 3. In fact, a lot of his contributions came from a time were he readied Zope 3 for this application. Marius, Albertas, Bjorn, Victorija -- They develop for Zope 3 because they do projects with it. Enough said! Gary (Poster) -- He uses Zope 3 already in Zope 2 (FrankenZope) for a customer project. Python Labs (Fred, Barry, Guido, Tim and Jeremy) -- Clearly they have all had a lot of application development experience. Shane, Tres and other ZC developers -- Most of the ZC developers these days work on customer projects, so they have plenty of real-world, end-user experience. Martijn Faassen -- All I say is Silva. Phillipp (von Weitershausen) -- He also builds applications and his contributions were often very practical ones. Sidnei -- Well, he built the second Zope 3 app that actually makes use of the strengths of Zope 3 in a way that is not possible in Zope 2. So I see no reason to believe that we are a too abstract- or academic-thinking set of developers. **However**, we all need to be academic, because otherwise we would not be able to build a stable and well-performing framework for other people to work with and build on! Abstract thinking and development is a pre-requisite for a good, solid foundation. The artifical not-yet-product Zope3 will sooner or later be distracting development efforts from Zope2 because Zope3 is almost finished. That doesn't look not nice ... That will happen, of course, as
Re: [Zope-dev] The bleak Future of Zope?
On Wednesday 21 April 2004 03:58, Martin Kretschmar wrote: Maik Jablonski of the german speaking Zope Users Group DZUG issued a pretty bleak outlook for the future of Zope. What are your oppinions? To not make the previous mail too long, here my general opinion. 1. Maik likes to do things the quick and dirty way. See Epoz and Mailboxer. That works well for small and personal projects, but is not the answer for large projects. If Zope 2 or 3 would have been built this way, they would have already fallen apart. Abstract thinking is a required for framework development. Epoz has been totally redesigned (Kupu) in a more abstract way and works very well for end users in Silva...and it is easily adjustable and extensible. For Mailboxer I can only say that he should have leveraged the development power behind Mailman and develop a nice UI on top of it as I had demonstrated with some code a year earlier. This suggests to me he is either (1) not a team player or (2) technically not good enough to integrate. It is much, much harder to play nice with other projects than starting your own. I have done this mistake myself often enough (back then I was not technically good enough ;-). 2. Maik is is frustrated with the releases of both Zope 2 and Zope 3, including their merging. First off, I do not develop Zope 2 and I am not involved there, so I have no qualified opinion. However, it is always easy to complain about ZC and push all the responsibility to them. I bet you that ZC would allow a 3rd party to do releases, if they show interest, knowledge and wisdom. However, people just keep complaining and do nothing. The situation is even more obvious with the Zope book. All the community has to do is to give a particular part/chapter/section to a couple of people for maintenance. But oh wait, that would need someone to manage this effort and *that* would be just too much work. For Zope 3 however, I can give a very well-informed opinion. Philipp privately pointed out to me that people exected Zope 3 technologies to arrive earlier in Zope 2, such as the CA and principals maybe. This was not desirable in several ways. First, the API was not stable and Zope 2 as a mature software would have suffered from the ever changing API. Next, there was still a lot of restructuring going on that would have caused interruptions in Zope 2. Third, none of the code was optimized and dog slow, nothing someone wanted to use for a large site. Finally, we just had no bandwidth for it! Who was to support the Zope 3 in Zope 2? At the end it would have been Jim and it distract him from finishing Zope 3. Concerning the release schedule, ZC has little to do with that for Zope 3. In fact, I have been release manager since this summer and I am responsible for the release schedule and packages. However, I decided not to release often, since again we do not have bandwidth to support the milestones. Since the CVS is as stable as any milestone release (we have tests for everything), releases are less important and it is much easier and less time consuming to support the current HEAD, which you can just download via the Web. However, we are getting the first alpha out by the end of the month. Hopefully, by end of May we will have finished the X3.0 to-do list and will release the beta. At this point the API will freeze and application developers are encouraged to have look at it. I have more to say, but I the E-mail would become too long. Overall, I think Maik's predictions and scepticism is fairly uninformed from a Zope 3 perspective. He has never seriously participated in writing code/documentation and/or contributing to discussions. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Zope Book, was Re: [Zope-dev] The bleak Future of Zope?
Stephan Richter wrote: On Wednesday 21 April 2004 03:58, Martin Kretschmar wrote: -- snip -- 2. Maik is is frustrated with the releases of both Zope 2 and Zope 3, including their merging. -- snip -- The situation is even more obvious with the Zope book. All the community has to do is to give a particular part/chapter/section to a couple of people for maintenance. But oh wait, that would need someone to manage this effort and *that* would be just too much work. -- snip -- Hmph, as one of the people that works on the Zope Book I feel a little stung by a comment like this one. While its true that a 2.7 Edition of the Zope book is overdue, I still think that the 2.6 Edition was both quite a step forward and still largely applicable for 2.7 Zopes That being said, I wonder if there are people interested to make an effort for a 2.7 Edition of the Zope book? cheers, peter. smime.p7s Description: S/MIME Cryptographic Signature ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] The bleak Future of Zope?!
On Wednesday 21 April 2004 05:52 am, Eckart Hertzler wrote: I don't agree. I am new to zope. So I tried zope2 first, because plone had a lot of appeal. I got discouraged very quickly, because zope2 is so very grown over a time it's hard to join later. Zope3 seemed quite well documented and I had no problems going on on my own. ( There is a tutorial, a cookbook, and an online apidoc ) I can say nothing however to migrating apps from zope2 to zope3. I'm really looking forward to Zope 3, and I'm thinking about migrating to it this Summer. I've been developing an application, which has taken about two years, largely because developing in the Zope 2 Framework model is like beating your head against the wall constantly. That's probably because I'm writing a fundamentally complex web application which I need to have a lot of large-scale control over. I'm not writing in an environment where a slightly-customized ZMI or even a collection of new Zope objects will quite do the job. I'm writing a system which gives end-users (NOT CS experts) a lot of control over their environment. And there are fundamental user-interface changes involved. I also have to do this in my copious free time, as I'm not commercially employed to do this work (maybe someday, but not now). So in those two years, I've probably had the equivalent of 2 months of full-time work. For somebody dealing with that, the constant pressure to adapt to a changing platform and the myriad interfaces that break when you do, and the unwillingness to document these problems because that's too old get really frustrating. The lack of formally defined interfaces makes it very hard to deal with this situation -- it's not easy to mix-and-match the new parts you need with the old parts you haven't been able to upgrade yet. In short -- Zope 2 is TOO LABOR INTENSIVE. Mostly because it's TOO COMPLEX and TOO MONOLITHIC. During the development phase of my project, I've had to upgrade Zope THREE times, and EACH one REQUIRED A MAJOR RE-WRITE on my part. That makes it very difficult to concentrate on forward momentum. I've missed my own deadlines, and had to admit that I simply can't deliver the product on anything like the schedule I originally was trying for. And this 3 steps forward, 2 steps back problem of dealing with a changing, poorly documented, and often buggy platform is part of the reason. The promise of Zope 3 is that it is following Python's TOOLBOX model, and making it easier to separate out the parts you need into separate interfaceable components. This will make life vastly easier for large-scale projects which don't follow the typical quick and dirty Zope site model. Or so I hope. ;-) I don't understand everything else they're doing with it, and I've had frustrations with Zope 3, but in the long run (which I care about -- I expect my application, or a later version of it, to be in use in 15-20 years, so I'm not just concerned with first to market), I think it will be easier to keep up with. I understand that my situation is probably unusual, but I do want to speak out to say that there is interest in Zope 3, and I personally expect to be using it before 2005. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 Book, was Re: [Zope-dev] The bleak Future of Zope?
On Wednesday 21 April 2004 10:18, Peter Sabaini wrote: The situation is even more obvious with the Zope book. All the community has to do is to give a particular part/chapter/section to a couple of people for maintenance. But oh wait, that would need someone to manage this effort and *that* would be just too much work. Hmph, as one of the people that works on the Zope Book I feel a little stung by a comment like this one. While its true that a 2.7 Edition of the Zope book is overdue, I still think that the 2.6 Edition was both quite a step forward and still largely applicable for 2.7 Zopes I was really addressing the people who just sit idle. I know from experience that the few who do something always get their beating... I did not mean to do that at all. But since people are complaining about the quality of the book, it must not have enough volunteers. That being said, I wonder if there are people interested to make an effort for a 2.7 Edition of the Zope book? Probably: A lot of people want it, few people want to help. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 Book, was Re: [Zope-dev] The bleak Future of Zope?
On Wed, Apr 21, 2004 at 04:18:17PM +0200, Peter Sabaini wrote: Stephan Richter wrote: On Wednesday 21 April 2004 03:58, Martin Kretschmar wrote: -- snip -- 2. Maik is is frustrated with the releases of both Zope 2 and Zope 3, including their merging. -- snip -- The situation is even more obvious with the Zope book. All the community has to do is to give a particular part/chapter/section to a couple of people for maintenance. But oh wait, that would need someone to manage this effort and *that* would be just too much work. -- snip -- Hmph, as one of the people that works on the Zope Book I feel a little stung by a comment like this one. Same here. Put up or shut up, whiners. Chris McDonough put a lot of time into editing and coordinating the 2.6 edition. If he hadn't put out a formal call for contributors, and organized the whole thing, it wouldn't have happened at all. I don't hear anybody volunteering to take over that job. -- Paul Winkler http://www.slinkp.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 Book, was Re: [Zope-dev] The bleak Future of Zope?
On Wed, 2004-04-21 at 10:18, Peter Sabaini wrote: That being said, I wonder if there are people interested to make an effort for a 2.7 Edition of the Zope book? I am. I think Paul is too. It won't be nearly as much work as 2.5 - 2.6. Let's just do it. Wanna pick chapters? I'll get the new book set up on Zope.org (another BT book) and send the link to whomever is interested. - C ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 Book, was Re: [Zope-dev] The bleak Future of Zope?
Chris McDonough wrote: On Wed, 2004-04-21 at 10:18, Peter Sabaini wrote: That being said, I wonder if there are people interested to make an effort for a 2.7 Edition of the Zope book? I am. I think Paul is too. It won't be nearly as much work as 2.5 - 2.6. Let's just do it. Wanna pick chapters? I'll get the new book set up on Zope.org (another BT book) and send the link to whomever is interested. Ok then... I think the following issues would deserve attention: * Installing chapter: I'm working on it and hope to finish soon (no really this time!) * Maintaining chapter update * Creating Basic Zope Applications: I've been wanting to extend and incorporate Jon Whiteners version but never got around to it * Using Zope Page Templates: judging by the comments there seem to be some trouble spots there * Reference: IMHO one of the trickier things, especially for the API Ref. because one would first have to decide what constitutes the API and what is simply Zope core... * A chapter TOC: it would be great if we could have an inter-chapter table of contents; would greatly help navigation esp. in longer chapters -- I seem to recall that someone once mentioned working on such a feature -- Paul maybe? * Lots of weeding out comments resp. incorporating answers * Generating PDFs Anything else? - peter. smime.p7s Description: S/MIME Cryptographic Signature ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Call for Zope Book volunteers (was Re: Zope Book, was Re: [Zope-dev] The bleak Future of Zope?)
I've set up a development BackTalk sandbox for the 2.7 edition of the Zope book at http://zope.org/Documentation/Books/ZopeBook/2_7Edition. Currently it's just an exact copy of the 2.6 Edition book (comments and all). I think the plan should be for people to: 1. take ownership of a chapter or two 2. address all the comments in the chapter and get rid of comments in places you've addressed. 3. update any material that is wrong wrt to differences between 2.6 and 2.7. The prize for taking ownership and updating two complete chapters is your name as a coauthor on the front page (as before ;-). Another thing to do is to incorporate some of John Whitener's changes the lost chapter referenced all over the place within book comments. I wonder if he's still around. At some point in the future, we can backport some of the changes to the 2.6 book if someone wants to take on that responsibility. It's advisable to use external editor to make the changes or to maybe use FTP to get sandboxed local copies of the book and make changes reuploading them as necessary. I've lost track of whether FTP access is possible or not on Zope.org at this point, however. Does anyone know? I've tried a few ports but nothing. Also, Zope.org is so slow for each request when you're logged in that we may need to move development to another system. As a data point, I've been waiting 4 minutes for Z.org to save a Wiki page... still waiting. Hilarious. Admittedly, it takes a unique brand of apathy to ignore this, but I've got an excuse. I'm waiting for the Zope.org steering committee to solve it! Chuckle. In the meantime, what slowness.. I don't know what you're talking about.. I have given Manager role in the entirety of the 2.7 edition book to both Peter and Paul. Anyone else who wants to contribute, please let me know which chapter(s) you'd like to sign up to revise and I will provide you access as necessary. I've set up a project wiki for the project at http://zope.org/Members/mcdonc/ZB_project where people can get a sense of which chapters are still available. It may not be available yet... still waiting for it to save. I will take ownership of the Installation chapter for now (I will probably take ownership of some other chapters, but I'll start small...) - C ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 Book, was Re: [Zope-dev] The bleak Future of Zope?
On Wed, 2004-04-21 at 14:10, Peter Sabaini wrote: Chris McDonough wrote: On Wed, 2004-04-21 at 10:18, Peter Sabaini wrote: Ok then... I think the following issues would deserve attention: * Installing chapter: I'm working on it and hope to finish soon (no really this time!) Cool, I'll pick another chapter then! * Maintaining chapter update I'll pick that one. ;-) * Creating Basic Zope Applications: I've been wanting to extend and incorporate Jon Whiteners version but never got around to it This is important. * Using Zope Page Templates: judging by the comments there seem to be some trouble spots there Yup. It's ripe for attention like the attention you gave to Maintaining. ;-) * Reference: IMHO one of the trickier things, especially for the API Ref. because one would first have to decide what constitutes the API and what is simply Zope core... I think we should continue to ignore the API ref except for addressing specific corrective comments made against it. The API ref is terrible, but unless someone has a spare few weeks on their hands to go through Zope and define APIs, that's the best we're going to do. * A chapter TOC: it would be great if we could have an inter-chapter table of contents; would greatly help navigation esp. in longer chapters -- I seem to recall that someone once mentioned working on such a feature -- Paul maybe? Yes, it's in BackTalk CVS. I just need to convince ZC to install the newest BackTalk. * Lots of weeding out comments resp. incorporating answers Yeah.. * Generating PDFs Anything else? Backporting changes to the 2.6 edition, although I think this should be low priority! - C ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Call for Zope Book volunteers (was Re: Zope Book, was Re: [Zope-dev] The bleak Future of Zope?)
Sigh. I think I stressed Zope.org to its breaking point by creating a Wiki page. It's down. - C On Wed, 2004-04-21 at 14:13, Chris McDonough wrote: I've set up a development BackTalk sandbox for the 2.7 edition of the Zope book at http://zope.org/Documentation/Books/ZopeBook/2_7Edition. Currently it's just an exact copy of the 2.6 Edition book (comments and all). I think the plan should be for people to: 1. take ownership of a chapter or two 2. address all the comments in the chapter and get rid of comments in places you've addressed. 3. update any material that is wrong wrt to differences between 2.6 and 2.7. The prize for taking ownership and updating two complete chapters is your name as a coauthor on the front page (as before ;-). Another thing to do is to incorporate some of John Whitener's changes the lost chapter referenced all over the place within book comments. I wonder if he's still around. At some point in the future, we can backport some of the changes to the 2.6 book if someone wants to take on that responsibility. It's advisable to use external editor to make the changes or to maybe use FTP to get sandboxed local copies of the book and make changes reuploading them as necessary. I've lost track of whether FTP access is possible or not on Zope.org at this point, however. Does anyone know? I've tried a few ports but nothing. Also, Zope.org is so slow for each request when you're logged in that we may need to move development to another system. As a data point, I've been waiting 4 minutes for Z.org to save a Wiki page... still waiting. Hilarious. Admittedly, it takes a unique brand of apathy to ignore this, but I've got an excuse. I'm waiting for the Zope.org steering committee to solve it! Chuckle. In the meantime, what slowness.. I don't know what you're talking about.. I have given Manager role in the entirety of the 2.7 edition book to both Peter and Paul. Anyone else who wants to contribute, please let me know which chapter(s) you'd like to sign up to revise and I will provide you access as necessary. I've set up a project wiki for the project at http://zope.org/Members/mcdonc/ZB_project where people can get a sense of which chapters are still available. It may not be available yet... still waiting for it to save. I will take ownership of the Installation chapter for now (I will probably take ownership of some other chapters, but I'll start small...) - C ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 ) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Call for Zope Book volunteers (was Re: Zope Book, was Re: [Zope-dev] The bleak Future of Zope?)
Chris McDonough wrote: I've set up a development BackTalk sandbox for the 2.7 edition of the Zope book at http://zope.org/Documentation/Books/ZopeBook/2_7Edition. Currently it's just an exact copy of the 2.6 Edition book (comments and all). I think the plan should be for people to: 1. take ownership of a chapter or two 2. address all the comments in the chapter and get rid of comments in places you've addressed. 3. update any material that is wrong wrt to differences between 2.6 and 2.7. The prize for taking ownership and updating two complete chapters is your name as a coauthor on the front page (as before ;-). Erm, there is no front page... you need to realise the truth: its you who is the front page /lame-matrix-quoting Another thing to do is to incorporate some of John Whitener's changes the lost chapter referenced all over the place within book comments. I wonder if he's still around. Yes he is, I talked about this to him some time ago. In light of this its maybe best if I do the incorporating At some point in the future, we can backport some of the changes to the 2.6 book if someone wants to take on that responsibility. It's advisable to use external editor to make the changes or to maybe use FTP to get sandboxed local copies of the book and make changes reuploading them as necessary. I've lost track of whether FTP access is possible or not on Zope.org at this point, however. Does anyone know? I've tried a few ports but nothing. Hm, we should make the sources available somewhere. Once Zope.org starts working again. Also, Zope.org is so slow for each request when you're logged in that we may need to move development to another system. As a data point, I've been waiting 4 minutes for Z.org to save a Wiki page... still waiting. Hilarious. Admittedly, it takes a unique brand of apathy to ignore this, but I've got an excuse. I'm waiting for the Zope.org steering committee to solve it! Chuckle. In the meantime, what slowness.. I don't know what you're talking about.. Nono not slow at all merely... andante. Or broken down. Or something. I have given Manager role in the entirety of the 2.7 edition book to both Peter and Paul. Anyone else who wants to contribute, please let me know which chapter(s) you'd like to sign up to revise and I will provide you access as necessary. I've set up a project wiki for the project at http://zope.org/Members/mcdonc/ZB_project where people can get a sense of which chapters are still available. It may not be available yet... still waiting for it to save. I will take ownership of the Installation chapter for now (I will probably take ownership of some other chapters, but I'll start small...) Erm, I'd like the Installation chapter. Already started on it. Really, I promise :-) opening-a-bottle-of-favourite-austrian-beer-and-hacking-away'ly peter. - C smime.p7s Description: S/MIME Cryptographic Signature ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Call for Zope Book volunteers (was Re: Zope Book, was Re: [Zope-dev] The bleak Future of Zope?)
On Wed, Apr 21, 2004 at 02:13:30PM -0400, Chris McDonough wrote: I've set up a development BackTalk sandbox for the 2.7 edition of the Zope book at http://zope.org/Documentation/Books/ZopeBook/2_7Edition. Currently it's just an exact copy of the 2.6 Edition book (comments and all). Also, Zope.org is so slow for each request when you're logged in that we may need to move development to another system. Why don't we use the project CVS at sourceforge? http://sourceforge.net/cvs/?group_id=21038 I see you're an admin there. It doesn't look like it has the 2.6 edition, though. Everything's 2 years old. As a data point, I've been waiting 4 minutes for Z.org to save a Wiki page... still waiting. Hilarious. Admittedly, it takes a unique brand of apathy to ignore this, but I've got an excuse. I'm waiting for the Zope.org steering committee to solve it! Chuckle. In the meantime, what slowness.. I don't know what you're talking about.. They're really crawling now :-( -- Paul Winkler http://www.slinkp.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: Call for Zope Book volunteers (was Re: Zope Book, was Re: [Zope-dev] The bleak Future of Zope?)
On Wed, 2004-04-21 at 14:52, Paul Winkler wrote: Why don't we use the project CVS at sourceforge? http://sourceforge.net/cvs/?group_id=21038 I see you're an admin there. I'm +0 on the idea.. if you and Peter are more comfortable with it than using BackTalk, I'll set it up. It's just difficult to keep the BackTalk stuff in sync with CVS; we'd probably need to write a script to do it. It doesn't look like it has the 2.6 edition, though. Everything's 2 years old. Yeah, it's dead dead dead. - C ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] The bleak Future of Zope?
Hi! I am not too active on the Zope mailing lists any more because there is not too much time left for it. But this thread asks for a comment. So here it is: First of all, I am not sure if the release policy of Zope 3, and the whole concept of doing a complete rewrite was right or wrong, but at least I don't see a much better alternative. Zope 2 really is getting ugly with its age, so just fixing it wouldn't really be too much fun. What I've been missing in Zope 3 fro years now is a clear focus on a single target. Maybe that is the target of Zope 3: not solve a specific problem like web content management but be a general toolkit for building applications. But I think it would have been a bit easier and much more efficient to start with a rather focussed project, let's say a web groupware system or a CMS, then make sure that things don't get too specific. That way there would have been a list of deliverables to test all the neat new features and concepts against, not just conceptual ideas. As things are now, me and lots of other commercial Zope users never had the resources to really actively participate in Zope 3 because we have to earn our living, and that means applications for the end user if we don't want to charge for the toolkit (which is obviously no option). Well, it's not too late for this. The world still doesn't have the perfect groupware or CMS application, and maybe Zope 3 can be a starting point for it. The problem of Zope 2 is - don't kill me for saying that - Plone. Plone and its foundations in CMF have created a large momentum around a terribly horrible code base. Believe me or not, almost everything gets more complicated with CMF/Plone than with plain Zope. Building a framework on top of a broken framework on top of an ageing framework that is hardly documented isn't a very good idea after all. The shortcomings in Zope 2 itself should have been addressed and fixed, rather than reinventing most of its good parts poorly and keeping the bad parts. Send me a private mail for an extensive list of issues I see ;-) There are quite a few Zope-based CMS solutions out there, and most of them are better than their commercial counterparts in many respects. But if we had managed to start a joint CMS effort (other than CMF, which is a failure by design) two or three years ago things would look even better now. I am currently working on a prototype for a project management solution that is going to be used at SUSE LINUX AG. For that I am using plain Zope. No Archetypes, no Plone, no nothing. Why? Because while Zope 2 is ugly in many respects it still is the most beautiful solution in the Zope (2) community. The original Zope concept is great (having a filesystem-like structure of objects and a web-based frontend to work with it). What I expect from Zope 3 (at least as one part of the project) is a better replacement for Zope 2. The few problems I have always had with Zope 2 haven't been addressed in Plone. They probably have been addressed in Zope 3. I'll have to find out. What I am looking for is a real rapid development tool for web-based (or at least distributed) applications. If Zope 3 doesn't deliver that then other solutions will win the war.** Rapid development can only work if there is an easy-to-understand concept or basic paradigm in a system. Zope 2 is such a system. A lot of things just got ugly because too much bloat was added later. One of the best ideas with the worst implementation was ZClasses. ZClasses would be extremely useful if they really worked as expected. In the web frontend all we'd have needed is a separation between configuration stuff and data (e.g. using two or three tabs instead of one mixing everything). Zope 3 has addressed this issue quite well I guess. What we should work on in the future is development tools for Zope. If I get the stuff I know about Zope 3 right it should be relatively easy to write IDEs (or plugins for existing IDEs) that add wizards, code-completion and lots of introspection, so that I don't have to learn all the API but can explore it while developing. Add an UML-based or UML-inspired graphical frontend to do the application architecture. Finally we need industry-strength performance. The last point is one of the most important ones. Zope 2 has lots of very nice features (like the ZODB, WebDAV access, etc.). Basically everything is there to replace a lot of the most recent Microsoft products (including their planned WinFS DB-like filesystem). We are just lacking the performance (mostly thanks to Python being a beautiful, but not really fast language). That's from my part. Cheers Joachim ** A final question that is mainly aimed at the ZC people: What is the competition you are positioning Zope 3 against? I've never seen an answer to that quite important question ... -- iuveno AG Joachim Werner Wittelsbacherstr. 23b 90475 Nürnberg Tel.: +49 (0) 911 9883 984 E-Mail:
Re: Zope Book, was Re: [Zope-dev] The bleak Future of Zope?
On Wed, Apr 21, 2004 at 08:10:26PM +0200, Peter Sabaini wrote: * Reference: IMHO one of the trickier things, especially for the API Ref. because one would first have to decide what constitutes the API and what is simply Zope core... The long-term solution, I think, is to fix the API mess itself. Eek. I have a proposal about this here: http://dev.zope.org/Wikis/DevSite/Proposals/SanitizeHelpSysAndAPIReference ... but I think this will take a while, and I'd rather get the book updated first. I think it's worth hand-massaging the API reference chapter for the 2.7 book and fixing the embedded docs later. Yes, I volunteer to do this :-) * A chapter TOC: it would be great if we could have an inter-chapter table of contents; would greatly help navigation esp. in longer chapters -- I seem to recall that someone once mentioned working on such a feature -- Paul maybe? The book already has an inter-chapter TOC at the beginning ;-) Chris and I worked on an intra-chapter TOC at Pycon. My stuff is in backtalk CVS on sourceforge. http://cvs.sourceforge.net/viewcvs.py/backtalk/BackTalk/ Just needs a bit of cleanup and it'll be ready to go. -- Paul Winkler http://www.slinkp.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 Book, was Re: [Zope-dev] The bleak Future of Zope?
Paul Winkler wrote: On Wed, Apr 21, 2004 at 08:10:26PM +0200, Peter Sabaini wrote: * Reference: IMHO one of the trickier things, especially for the API Ref. because one would first have to decide what constitutes the API and what is simply Zope core... The long-term solution, I think, is to fix the API mess itself. Eek. I have a proposal about this here: http://dev.zope.org/Wikis/DevSite/Proposals/SanitizeHelpSysAndAPIReference ... but I think this will take a while, and I'd rather get the book updated first. I think it's worth hand-massaging the API reference chapter for the 2.7 book and fixing the embedded docs later. Yes, I volunteer to do this :-) Brave... and while I'd really like to have a clean API Reference, you are probably right that its more important to get the main book updated first. * A chapter TOC: it would be great if we could have an inter-chapter table of contents; would greatly help navigation esp. in longer chapters -- I seem to recall that someone once mentioned working on such a feature -- Paul maybe? The book already has an inter-chapter TOC at the beginning ;-) Chris and I worked on an intra-chapter TOC at Pycon. My stuff is in backtalk CVS on sourceforge. http://cvs.sourceforge.net/viewcvs.py/backtalk/BackTalk/ Just needs a bit of cleanup and it'll be ready to go. Yay! And, judging by the CVS, done pretty straightforward (I was afraid of having to do several parsing passes and such). Cool. smime.p7s Description: S/MIME Cryptographic Signature ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
