The bleak Future of Zope?!
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
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
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. Meyer http://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/
-----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: hertzler.eckart@guj.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAhlKLxvP4sHhhP/gRAne0AKCXehtMYeMzx1s0N0o+1ph11As/4gCg2Y62 MigAPYapLhAii0HGbEdz84A= =E63J -----END PGP SIGNATURE-----
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
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
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
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
Chris Withers wrote:
Andre Meyer wrote:
With respect to CMS, Plone archetypes are too simplistic for complex data/document types and customisation takes too much effort.
totally agree...
I have the same experience. They keep refactoring how a single small (and relatively uninterresting) subset of problems can be solved. In the meantime all the products depending on the framework are in a perpetual state of broke. Furthermore they keep forking the codebase and giving it new names. I have a few Plone Products, and while it takes a bit to get the skeleton set up correctly, it is never that part of the product development that takes the most time. After the setup I can then enjoy that I don't have to fight the constraints of a framework. regards Max M
Martin Kretschmar wrote:
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!
It looks like the classical strategic mistake: http://www.joelonsoftware.com/articles/fog0000000069.html Funny thing though is that Joel uses Netscape/Mozilla as an example on how not to do it. I think that the jury is still out as to who won the browser war. So it ain't ower until the fat lady sings.
I can't believe the fairy tales with the possible migration from Zope2 to Zope3.
Me neither. The best we can hope is that it will be like copying a Z2 product to a folder, and then move stuff out into configuration files instead. Perhaps it can be somewhat automated, but I see a lot of subtleties that can only be handled manually. On the possitive side, a lot of the Z3 technologies are allready back-ported to to Z2. So Z3 will not be completely alien. But if Z3 succeds in picking up more developers, as Z3 development gets a lot easier and more Pythonic, it can very well be better in the long run.
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 ...
It is the single biggest concern about Zopes future. That is correct. And not one to be taken lightly. But the biggest problem with Z2 has allways been the steep learning curve. Relatively few developers has been able to work on it. The time lost for Z2 developers transfering to Z3 could quickly be offset by new developers due to an easier development model. Also, Python is flexible. We will probably see a transition phase, where products are developed for Z2/Z3 compatibility. That way we *can* get a smooth transition.
Further I see the problem that Zope probably has no real target group as an application server.
Zope has allways had that problem. But actually it fits very nicely into the cms market. Especially with Plone as the base. Many companies has their own home rolled cms system. They will be replaced by open solutions due to scale of economics. It is simply to costly to compete against something like Plone. Zope/Plone has a sweet spot that actually fits most customers out there. You can make solutions for a fraction of the cost of what a typical Java bases system costs. Many Java based cms solutions are too costly timewise to implement solutions in for many customers.
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.
Scripting was never the reason for Zope. The absolutely brilliant object publishing model was. Well that and Python. It might be Groovy, but Python it ain't! The things you can do in Zope you simply cannot do as well in other systems. The solution fits the problem space *very* well.
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.
The world of small/medium applications will dissapear! The bigger systems like Plone can do anything out of the box that the small hand-built systems needs to have hand coded. Why on earth should somebody set up a PHP server and do a lot of hand coding, when they can set up a Plone server that does it all for them? PHP based systems tends to be monolithic blocks. Something like PHPBoard is a good example. Setting it up is rather complicated. And using several on the same site is also difficult. I Zope you can have a discussion board in each end every folder, just by adding it through a web based interface. Furthermore smaller systems will grow larger. Then they will get growing problems too. Developers allready using bigger systems will find the future simpler.
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. ...
That is hard for any CMS system. What system does it better? It isn't a simple task to create a skinning system that flexible. Actually I find Plone to be very well factored for a system of that complexity. There isn't much in Plone that you cannot change to your liking. But it's a complex beast for flexible solutions. (That is why it is good for us consultants ;-) )
Maybe I'm simply sick of moving along within web browsers and the file system without a sensible IDE and documentation.
That might be it ;-) regards Max M
Max M wrote:
Martin Kretschmar wrote:
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!
It looks like the classical strategic mistake:
Well, I don't agree with this assessment for Zope 3. We needed the freedom to work oput new ideas and patterns. Trying to use existing code would have been a huge distraction. I think that the result proves that we were right. The beauty of our approach is that, having built what we've built, we'll be able to take advantage of that code in the current platform. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
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:
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 - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Martin, Maik, Andreas, and others, I see two issues being raised in this thread: 1. Maik disagrees with the design philosophy behind Zope3 (the Component Architecture) and the place Zope3 wants to position itself at in the future. As a Zope developer who has spent the last two years both developing *with* Zope2 and developing Zope3 itself, I obviously have a different point of view about the technical part. Whether Zope3 will be success in its market niche is yet to be determined. If you fight, you can win the war; if you give up now, you've already lost the war. Since this is more a philosophical issue, or even a matter of taste, I am not going to argue too much about it. I find the component architecture superior to anything we have seen before and we will soon have proofs that it is capable of industrial strength applications. Most other developers who are involved into development with or of CMF (such as the leading Plone developers) seem to share that point of view; in fact, we all can't hardly wait for Zope3 to hit stable. 2. Especially Andreas expressed his worries about the current release policy in Zope 2 and its future regarding maintainance and support. I have to say that I share some of his skepticism regarding Zope 2. I personally have never fully understood ZC's reasons for the release roadmap as it is. I might not see the big picture, but I know I would have done it differently. I've always tried to make that clear in the past. Coming up with harsh criticism now is not very fair, I think, especially when you're as in involved as Maik or Andreas. Zope 2 development has opened for the community a lot in the past. While people were to extend Zope2 with more or less useful features (seemed to me that it was more than fixing bugs), all the administrative stuff got stuck with ZC. Did anyone from the community ever volunteer helping with the releases or the CVS administration? In this matter, btw, the future painted in Zope3 is brighter: more community involvement, more innovations coming from the community and more administrative tasks taken up by volunteers. Not that I'm not suggesting that more help is needed... Philipp
Philipp von Weitershausen wrote:
Martin, Maik, Andreas, and others,
I see two issues being raised in this thread:
2. Especially Andreas expressed his worries about the current release policy in Zope 2 and its future regarding maintainance and support. I have to say that I share some of his skepticism regarding Zope 2. I personally have never fully understood ZC's reasons for the release roadmap as it is. I might not see the big picture, but I know I would have done it differently. I've always tried to make that clear in the past.
I'm surprised to read this. Could you be more specific about your concerns? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
I'm surprised to read this. Could you be more specific about your concerns?
Did you read Andreas Jung's mail? He was pretty specific, but I had to hunt around as in my mailreader his reply had broken the thread. Regards, Martijn
Martijn Faassen wrote:
Jim Fulton wrote:
I'm surprised to read this. Could you be more specific about your concerns?
Did you read Andreas Jung's mail? He was pretty specific, but I had to hunt around as in my mailreader his reply had broken the thread.
I was responding to Philipp, not Andreas. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
Martijn Faassen wrote:
Jim Fulton wrote:
I'm surprised to read this. Could you be more specific about your concerns?
Did you read Andreas Jung's mail? He was pretty specific, but I had to hunt around as in my mailreader his reply had broken the thread.
I was responding to Philipp, not Andreas.
Yeah, but I figured you might not have seen Andreas's mail as I had some trouble finding it myself, so I was trying to be helpful. :) Regards, Martijn
Jim Fulton wrote:
2. Especially Andreas expressed his worries about the current release policy in Zope 2 and its future regarding maintainance and support. I have to say that I share some of his skepticism regarding Zope 2. I personally have never fully understood ZC's reasons for the release roadmap as it is. I might not see the big picture, but I know I would have done it differently. I've always tried to make that clear in the past.
I'm surprised to read this. Could you be more specific about your concerns?
I should have said "the release roadmap as it WAS". I was very skeptical about the original plans to make Zope3 backward compatible. I am still very skeptical about the ability to add conversion scripts. They would be incredibly tedious painful to write and I personally would rather migrate code manually than trust a script. After all, the paradigms have changed a lot. I see it as realistic as Stephan. There is no sane migration to Zope3 than the one of refactoring code. Now, in order for that to happen, we need the CA in Zope2, so people can start asap. My only criticism has been and still is that the CA hasn't been introduced to Zope2 earlier. Now, I know that a) the CA has been refactored a lot since its invention (and IMO only for the good) and b) there was a lack of resources to do that actual integration. That's why I've never declared anyone guilty for it (which is why you may be surprised by this). It sure would have been nice if Gary had shared his experience with FrankenZope a little earlier. I remember Martijn being quite eager to experiment with it, too. But that's the only constructive criticism I have. Philipp
Philipp von Weitershausen wrote:
Jim Fulton wrote:
2. Especially Andreas expressed his worries about the current release policy in Zope 2 and its future regarding maintainance and support. I have to say that I share some of his skepticism regarding Zope 2. I personally have never fully understood ZC's reasons for the release roadmap as it is. I might not see the big picture, but I know I would have done it differently. I've always tried to make that clear in the past.
I'm surprised to read this. Could you be more specific about your concerns?
I should have said "the release roadmap as it WAS". I was very skeptical about the original plans to make Zope3 backward compatible. I am still very skeptical about the ability to add conversion scripts. They would be incredibly tedious painful to write and I personally would rather migrate code manually than trust a script. After all, the paradigms have changed a lot.
I see it as realistic as Stephan. There is no sane migration to Zope3 than the one of refactoring code. Now, in order for that to happen, we need the CA in Zope2, so people can start asap. My only criticism has been and still is that the CA hasn't been introduced to Zope2 earlier. Now, I know that a) the CA has been refactored a lot since its invention (and IMO only for the good) and b) there was a lack of resources to do that actual integration. That's why I've never declared anyone guilty for it (which is why you may be surprised by this).
It sure would have been nice if Gary had shared his experience with FrankenZope a little earlier. I remember Martijn being quite eager to experiment with it, too. But that's the only constructive criticism I have.
So your concerns are really about the Z2 to Z3 transition plan, not about the Zope release process. Before I get into the main topic of my response, I'll note that I'm a good bit more optimistic about backward compatability than you are. I just have an intuition that we'll be able to do much more than you or Stephan expect. It's an intuition, not a promise. I can't prove it. Only time will tell. :) I know that lots of people are concerned by the uncertainlty about the future transition. This is a tough situation. I made a number of tradeoffs that put us in this situtaion. I think they were the right tradeoffs and I'd make them again. But, as with any tradeoff, we've had to balence positives and negatives. Let me explain: Zope 3 has always been a relatively small project. Within Zope Corporation, I'm the only one that has worked on Zope 3 full time for any length of time. As CTO, even my time on Zope 3 is not truly full time, but it's closer than for anyone else at ZC. Customer work (Zope 2), important community issues (like this thread, or like the security issues we uncovered last fall) take precedent. Other people working on Zope 3 have "day" jobs. They have to go to school or or do customer work (usually in Zope 2) to make a living. (Of course, you know this Philipp. :) I'm not complaining. This is reality and a reality we planned for. I made two choices that were controversial: 1. I decided not to be encumbered by backward compatability. This was refactoring mercelessly" applied in the extreme. This had the result that, except in a few areas, we did start from scratch. Pros: We had freedom to think abstracty about how Zope should work, and how we could make the experience for the developer as good as possible. The premise of not being backward compatible with Zope 2, also made us realize that we didn't have to be backward compatible with our own Zope 3 work. We were free to try things out, see how they worked and often, totally change them to make them better. Many core parts of Zope 3 have been redone, some more than once. This wouldn't have been possible if we had been trying to be backward compatible. Cons: We're not backward compatible. Will we ever be? I'm confident that we will have a decent transition. I don't know what shape that will take but I am still confident. Will there be bumps along the way? Definately. The recent issue with the conflicts between the "Zope" and "zope" package is a good example. While many might not agree with me, I am glad I made this decision. I would make it again. It was the right decision for Zope. If we had a lot more resources, we might have been able to pay more attention to Zope 2 compatability, although I'm not sure that that would have been the right thing to do. 2. I decided not to think much about the transition until Zope 3 has gotten farther along. The transition is a road from where we are to where we're going. It's awfully hard to build a road when the destination is changing. This means that, as the Zope Pope and CTO of Zope Corporation, I can promise that the road will be built, but I can't tell you what precise route the road will take or what it will be like. I can only give a general direction. Frankly, the destination has been well enough defined for a while now that we could begin defining the transition, but we just don't have enough resources to do so. Pros: We didn't waste time planning transition to a moving target. We ere able to focus scarce resources on getting a Zope 3 baseline. Cons: Fear, uncertainty and doubt Do I regret the decision not to define the transition better sooner? No. Not given available resources. I know that this puts the community in a tough spot, but I don't know what else I can do. Fortunately, I think we're pretty close to a time where we can provide a lot more attention to the transition and I think that much more clarity will emerge over coming months. My main regret is so badly underestimating how long it would take to reach where we are. There are a lot of reasons for being so far off. One important reason is that we created a different culture, one that is far more quality driven. We are being very picky about what we put in the Zope 3 baseline. We're willing to take the time to get it right, or at least as right as we can make it. We couldn't do this if it wasn't for Zope 2. Ultimately, I think that this cultural shift will provide us with great benefits. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
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 people migrate to Zope 3 and this is a good thing.
Further I see the problem that Zope probably has no real target group as an application server.
Really, I see a lot of opportunity; maybe not with Zope 2, but I think we innovated a lot in Zope 3, which will give it a great competitive advantage.
The enterprise world is dominated by .Net and J2EE.
I think these technologies are all much stronger in the US than they are in Europe or other contintents. Of course they are bigger, since they have huge company backing, but most of their solutions are also very expensive.
Zope in its current form without a sensible documentation in conjunction with the drama about the english zope book doesn't help changing this.
Well, stop complaining and do something. It is always so easy to complain, isn't it? (I do not mean you directly here, it's a general comment.) And now my favorite subject, documentation. As for Zope 3, I have done everything I could to create a lot of valuable, quality documentation. We have: - A tutorial with slides (with comments) and working code for a trivial example Zope 3 content component. - A Zope 3 Developers book (currently about 430 pages that needs some updating -- coming soon) that explains solutions to some of the most common day-to-day tasks for an application developer. - An API reference comes with Zope itself. Since Zope 3 is so configurable, it is not worth making a static API reference. The tool, accessable via http://localhost:8080/++apidoc++, provides an extremly interlinked documentation as I have seen it for no other technology yet. - The online Zope 3 Wiki is also pretty rich of information, but you have to work a little harder. - Philipp also works on a Zope 3 book.
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.
This changes with Zope 3. PHP is for script-kiddies, not for experienced developers. Zope was always more than just scripting. It was an application framework that supported scripting. That made it so attractive.
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. ...
Aehm, I think Plone's success speaks for itself. It found a niche. It does not have to perform outside of it.
Maybe I'm simply sick of moving along within web browsers and the file system without a sensible IDE and documentation.
Well, join the Zope 3 community. Good documentation and Emacs is the answer. So far to my direct response. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
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
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.
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
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
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
On Wed, 21 Apr 2004 13:10:51 -0400 Chris McDonough <chrism@plope.com> 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.
Joel Burton recently updated the ZCatalog chapter, which should be all set for 2.7. So that one's already done. -Casey
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.
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
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
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.
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
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 - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
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
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
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
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 - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
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>.
BTW, once Shane is safely settled out west we plan to engage him to fix a number of the ills of zope.org, so I expect we'll see a marked improvement in the near future. As to zope.org/About, it is confusing right now because the actual docs aren't yet posted. Michael is working as we speak to get the click-wrap alluded to in /About up and running and a place to organize these docs, have a "place" for working groups, expand the FAQ, etc. Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
On Fri, 2004-04-23 at 13:21, Brian Lloyd wrote:
BTW, once Shane is safely settled out west we plan to engage him to fix a number of the ills of zope.org, so I expect we'll see a marked improvement in the near future.
OK, in the meantime if we wanted to organize a (one-day) "Zope.org sprint" I would attend.
As to zope.org/About, it is confusing right now because the actual docs aren't yet posted. Michael is working as we speak to get the click-wrap alluded to in /About up and running and a place to organize these docs, have a "place" for working groups, expand the FAQ, etc.
I'm not sure whether helping is blocked on any of this stuff, but if it's not, I'm willing to do whatever is necessary as time allows. - C
Stephan Richter wrote:
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.
My only problem is that it is difficult to be an "occasional" developer in Z3 on Windows. I normally don't develop in c. So I don't have Visual Studion installed. I have downloaded the milestones and tried them out. But then I read about this and that *geddon, and think "well guess I should wait for another version" before I try it again. I quickly feel out of sync in Z3. If there was some way to have a Binary core that didn't change very often, and a Python only part that I could upload from cvs/subversion to be up to date, it would be much easier to use a few hours here and there to try out stuff in Z3. Or perhaps an automated nightly Windows build. I believe that Chris Withers is testing Z3 nightly on Windows. Right? Would it be difficult to have that available as a download somewhere? It seems that zipping and uploading the test directory is enough. Being able to grab the builds seems more important than the releases.
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.
Great. regards Max M
On Wednesday 21 April 2004 10:40, Max M wrote:
I normally don't develop in c. So I don't have Visual Studion installed.
You can also use cygwin.
I have downloaded the milestones and tried them out. But then I read about this and that *geddon, and think "well guess I should wait for another version" before I try it again.
right.
I quickly feel out of sync in Z3.
yes.
If there was some way to have a Binary core that didn't change very often, and a Python only part that I could upload from cvs/subversion to be up to date, it would be much easier to use a few hours here and there to try out stuff in Z3.
There is little change in the C files. It is very rare.
Or perhaps an automated nightly Windows build.
We have talked about it many times before, but simply lack the bandwidth. Maybe you could provide this for Cygwin? Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Stephan Richter wrote:
On Wednesday 21 April 2004 10:40, Max M wrote:
Or perhaps an automated nightly Windows build.
We have talked about it many times before, but simply lack the bandwidth. Maybe you could provide this for Cygwin?
Argh ... that wasn't fair. Ok I will try and find some time to look into it. regards Max M
[Max M]
Or perhaps an automated nightly Windows build.
[Stephan Richter]
We have talked about it many times before, but simply lack the bandwidth. Maybe you could provide this for Cygwin?
[Max M]
Argh ... that wasn't fair.
Ok I will try and find some time to look into it.
A problem is that every platform has its own unique bag of miserable quirks. Case in point: before we released ZODB 3.3a3 last Friday (which is also the ZODB in the current Zope2 and Zope3 CVS HEADs), I tried to run the ZODB/ZEO test suite under Cygwin on WinXP Pro. "Disaster" is a fair assessment -- every time the test framework tried to spawn a ZEO process, it died instantly, with a Cygwin-specific message I didn't understand. So you need to be a real platform fan to get a "minority" platform to work; while I like Cygwin well enough, I rarely use it, and don't have time or interest to pursue it as a hobby. Maybe this is (still) relevant to building Zope under Cygwin, maybe not: http://www.zope.org/Members/dgeorgieff/howto_zope_cvs_on_cygwin/index_html What exactly is needed? I routinely compile Zope2 and Zope3 HEAD on Windows, using MSVC 6. I can't make time to set up a fancy snapshot procedure, but if all people want is (e.g.) a zip file containing the .pyd files, uploading those once a week wouldn't be a significant time sink.
Maybe this is (still) relevant to building Zope under Cygwin, maybe not:
http://www.zope.org/Members/dgeorgieff/howto_zope_cvs_on_cygwin/index_ht ml Python release23-maint and Zope 2.7 just builds fine on cygwin with the usual ./configure, make, make install sequence. Regards, Sandor
Tim Peters wrote:
[Max M]
Or perhaps an automated nightly Windows build.
[Stephan Richter]
We have talked about it many times before, but simply lack the bandwidth. Maybe you could provide this for Cygwin?
[Max M]
Argh ... that wasn't fair.
Ok I will try and find some time to look into it.
A problem is that every platform has its own unique bag of miserable quirks.
Well, yeah. I installed cygwin and all the devolpment tools. About 800 Megs. I could have sorted it, but I wouldn't risk missing libraries, tools etc. and harddisk is cheap. Python compiled fine, both with and without "./configure --with-threads" Z3 also compiled without a hickup. But when I tried to go to "http://localhost:8080" or "http://localhost:8080/manage" I just got a "A system error occurred." message, and a the following log entry: 2004-04-22T08:47:13 ERROR root PageTemplateFile: Error in template: Compilation failed exceptions.SyntaxError: invalid syntax (<string>, line 1) Which is sort of non-helpfull.
Maybe this is (still) relevant to building Zope under Cygwin, maybe not: http://www.zope.org/Members/dgeorgieff/howto_zope_cvs_on_cygwin/index_html
I didn't need to do all of that to get it build.
What exactly is needed? I routinely compile Zope2 and Zope3 HEAD on Windows, using MSVC 6. I can't make time to set up a fancy snapshot procedure, but if all people want is (e.g.) a zip file containing the .pyd files, uploading those once a week wouldn't be a significant time sink.
AS far as I can see that should be enough. If the compiled files, in their directory structure, could just be dropped on top of the python structure from cvs/subversion I expect that would be enough? As far as I can see from a quick manual scan of the directory structure that's how the code is structured now? The compiled files are not under version control, and so would not be overwritten by updating from cvs/subversion. regards Max M
[Max M]
Well, yeah. I installed cygwin and all the devolpment tools. About 800 Megs. I could have sorted it, but I wouldn't risk missing libraries, tools etc. and harddisk is cheap.
Same here (although my old laptop doesn't have enough disk space remaining to download the whole thing).
Python compiled fine, both with and without "./configure --with-threads" Z3 also compiled without a hickup.
Python 2.3.3 comes with current Cygwin, so there shouldn't be a need to build Python (or maybe there is? I don't know; the one that comes with Cygwin has threads enabled already: $ python Python 2.3.3 (#1, Dec 30 2003, 08:29:25) [GCC 3.3.1 (cygming special)] on cygwin Type "help", "copyright", "credits" or "license" for more information.
import thread def f(): ... print 'hi!' ... thread.start_new_thread(f, ()) 10852896 hi!
). I didn't have any problems compiling anything, I hit instant disasters whenever code tried to spawn a new process ("mystery errors" under WinXP Pro, segfault and system freeze under Win98SE).
But when I tried to go to "http://localhost:8080" or "http://localhost:8080/manage" I just got a "A system error occurred." message, and a the following log entry:
2004-04-22T08:47:13 ERROR root PageTemplateFile: Error in template: Compilation failed exceptions.SyntaxError: invalid syntax (<string>, line 1)
Which is sort of non-helpfull.
Sorry, no clues here. Perhaps someone else knows how to get Cygwin to work. ...
What exactly is needed? I routinely compile Zope2 and Zope3 HEAD on Windows, using MSVC 6. I can't make time to set up a fancy snapshot procedure, but if all people want is (e.g.) a zip file containing the .pyd files, uploading those once a week wouldn't be a significant time sink.
AS far as I can see that should be enough. If the compiled files, in their directory structure, could just be dropped on top of the python structure from cvs/subversion I expect that would be enough?
No way to tell without trying. I don't know whether you're building Zope2 or Zope3, but since this is the zope-dev list I assume the former. Try http://zope.org/Members/tim_one/Zope2-20040422.zip/file_view and let us know what happens! As the comment there says, it's just ".pyd files from Zope2 HEAD, compiled with MSVC 6". This is from an inplace ("setup.py build_ext -i") build on Windows, from a current Zope HEAD checkout.
As far as I can see from a quick manual scan of the directory structure that's how the code is structured now?
The compiled files are not under version control, and so would not be overwritten by updating from cvs/subversion.
That's correct.
[Tim Peters]
... No way to tell without trying. I don't know whether you're building Zope2 or Zope3, but since this is the zope-dev list I assume the former. Try
http://zope.org/Members/tim_one/Zope2-20040422.zip/file_view
and let us know what happens! As the comment there says, it's just ".pyd files from Zope2 HEAD, compiled with MSVC 6". This is from an inplace ("setup.py build_ext -i") build on Windows, from a current Zope HEAD checkout.
FYI, there's a similar zip file now containing the same kind of thing for a current Zope3 checkout (s/Zope2/Zope3/ in the URL). If this is good enough for people trying to work from CVS on Windows, let me know and I'll update them from time to time, and maybe move them to a saner location. If it's not good enough, sorry, but I don't anticipate having enough time to do more than this (which is just a trivial zip+upload step beyond the builds I have to do anyway).
Tim Peters wrote:
[Tim Peters]
... No way to tell without trying. I don't know whether you're building Zope2 or Zope3, but since this is the zope-dev list I assume the former. Try
http://zope.org/Members/tim_one/Zope2-20040422.zip/file_view
and let us know what happens! As the comment there says, it's just ".pyd files from Zope2 HEAD, compiled with MSVC 6". This is from an inplace ("setup.py build_ext -i") build on Windows, from a current Zope HEAD checkout.
FYI, there's a similar zip file now containing the same kind of thing for a current Zope3 checkout (s/Zope2/Zope3/ in the URL).
If this is good enough for people trying to work from CVS on Windows, let me know and I'll update them from time to time, and maybe move them to a saner location. If it's not good enough, sorry, but I don't anticipate having enough time to do more than this (which is just a trivial zip+upload step beyond the builds I have to do anyway).
Thanks Tim. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
FYI, there's a similar zip file now containing the same kind of thing for a current Zope3 checkout (s/Zope2/Zope3/ in the URL).
If this is good enough for people trying to work from CVS on Windows, let me know and I'll update them from time to time, and maybe move them to a saner location. If it's not good enough, sorry, but I don't anticipate having enough time to do more than this (which is just a trivial zip+upload step beyond the builds I have to do anyway).
Thanks Tim.
Hi Guys, Saw my name mentioned earlier but not sure whether Tim has solved the problem... I'd be happy to set up a nightly (or weekly, let me know which would be better) scheduled task (see, it's Widnows, there is no Cron, although Schedules Tasks do have a much nicer UI ;-) ) that checked out he latest HEAD of Zope 3, compiled it and PUT it up to my Zope.org member area (I suspect the slowest part of this process will actually be uploading it to Zope.org - what's the plan to fix zope.org speed suckage? how about workflow suckage?) Would it be helpful to get the nightly Windows tests running again? I stopped as a corollory of setting up my own company, but also because of lack of perceived support from people who could fix Windows problems and the lack of caring of developers who only developed for Linux and broke stuff on Windows... ahs any of that changed? Anyway, look forward to hearing about it... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Jim Fulton wrote:
FYI, there's a similar zip file now containing the same kind of thing for a current Zope3 checkout (s/Zope2/Zope3/ in the URL). If this is good enough for people trying to work from CVS on Windows, let me know and I'll update them from time to time, and maybe move them to a saner location.
I'd be happy to set up a nightly (or weekly, let me know which would be better) scheduled task (see, it's Widnows, there is no Cron, although Schedules Tasks do have a much nicer UI ;-) ) that checked out he latest HEAD of Zope 3, compiled it and PUT it up to my Zope.org member area
I think that a nightly windows build would have a strong psychological effect. I *did* manage to get Z3 compiled under Cygwin. I had downloaded it to my Cygwin home directory with my TortoisCVS (win client). TortoiseCVS converts newlines to Windows newlines. This, together with an apparent bug in PageTemplates or somesuch, gave me an error when I tried to go to a page in Plone. Are we missing a testcase here ;-) It compiled fine, and all, but just couldn't show any pages. When I downoaded it from CVS with the Cygwin command line client, it ran just as it should. I didn't need to do anything special. I am writing an extensive How-To on this in any case. It's nice infor to have out there. But I would rather run it from my normal Python under Windows. It would be easier in the long run I think. I wouldn't mind writing a how-to for how to get that up and running either. I actually like writing technical documentation. Go figure. regards Max M
On Sat, 24 Apr 2004 18:59:36 +0200, Max M <maxm@mxm.dk> wrote:
I *did* manage to get Z3 compiled under Cygwin.
I just had to type "python setup.py build -i" and was able to run it after adding the principals.zcml file. I used WinCVS (crlf eol) to check it out, for compiling I used MSVC6 and for running Python 2.3.3. I had no problems. Regards, Florian Schulze
[Chris Withers]
Saw my name mentioned earlier but not sure whether Tim has solved the problem...
Can't say -- I put up .pyds for current Zope 2 and Zope 3 HEAD, but haven't heard whether anyone tried them.
I'd be happy to set up a nightly (or weekly, let me know which would be better) scheduled task [...] that checked out he latest HEAD of Zope 3, compiled it and PUT it up to my Zope.org member area
I expect that would be helpful, and also helpful for the Zope 2 HEAD, but it's not clear what you would upload. For example, just the .pyds, or the entire codebase, or...?
(I suspect the slowest part of this process will actually be uploading it to Zope.org
If it's just the .pyds, the upload is small and goes fast, and only *needs* to be done when Zope's C code changes (infrequent). If it's the entire codebase, then, ya, it will go slower, and needs doing more often.
... Would it be helpful to get the nightly Windows tests running again?
Yes! For both HEADs.
I stopped as a corollory of setting up my own company, but also because of lack of perceived support from people who could fix Windows problems and the lack of caring of developers who only developed for Linux and broke stuff on Windows... ahs any of that changed?
I can't know whether your perceptions have changed, but guess that they haven't <wink>. Of course most developers are still on Linux, and break the tests on Windows routinely; that's not going to change (the things that go wrong on Windows don't make sense to Linux programmers -- e.g., the idea that you can't rename or delete an open file just isn't in their view of the world). So progress on Windows occurs in spurts, usually only when one of the few active contributors on Windows can make spare time for it. There are currently 7 failures on native Windows in Zope 2 HEAD. I opened a Collector report about them because I don't know how to fix them. The Zope3 tests are in better Windows shape today, and it's likely that all Zope3 tests (unit and functional, including the --all tests) will pass on native Windows today. Exceptions I know about: + One test will never pass on Win98SE (it opens more sockets simultaneously than Win98SE can handle). + One of the --all ZEO tests often fails on my hyper-threaded Pentium box, but never fails anywhere else, and never fails if I disable hyper-threading in the BIOS.
Tim Peters wrote:
[Chris Withers]
Saw my name mentioned earlier but not sure whether Tim has solved the problem...
Can't say -- I put up .pyds for current Zope 2 and Zope 3 HEAD, but haven't heard whether anyone tried them.
I will. Early next week. Something came up friday.
I expect that would be helpful, and also helpful for the Zope 2 HEAD, but it's not clear what you would upload. For example, just the .pyds, or the entire codebase, or...?
CVS clients are easy enough to get a hold on on Windows. The best solution would be if it was possible to get the Python sources from CVS and the compiled binaries from somewhere else. The problem is the compilation part, for somebody like me that don't normally develop in c. I guess that many Zope developers are like me, but I don't know offcourse. But it would also make it possible for most Zope users, to download and try out this Zope 3 thing, and get a feel for how it develops. regards Max M
Chris Withers wrote:
Jim Fulton wrote:
FYI, there's a similar zip file now containing the same kind of thing for a current Zope3 checkout (s/Zope2/Zope3/ in the URL).
If this is good enough for people trying to work from CVS on Windows, let me know and I'll update them from time to time, and maybe move them to a saner location. If it's not good enough, sorry, but I don't anticipate having enough time to do more than this (which is just a trivial zip+upload step beyond the builds I have to do anyway).
Thanks Tim.
Hi Guys,
Saw my name mentioned earlier but not sure whether Tim has solved the problem...
I'd be happy to set up a nightly (or weekly, let me know which would be better) scheduled task (see, it's Widnows, there is no Cron, although Schedules Tasks do have a much nicer UI ;-) ) that checked out he latest HEAD of Zope 3, compiled it and PUT it up to my Zope.org member area
I think that would be super. Nightly would be best.
(I suspect the slowest part of this process will actually be uploading it to Zope.org - what's the plan to fix zope.org speed suckage? how about workflow suckage?)
Do you have to go through all of that? Couldn't you put it up as a zip file, using ZMI, rather than CMF API's?
Would it be helpful to get the nightly Windows tests running again? I stopped as a corollory of setting up my own company, but also because of lack of perceived support from people who could fix Windows problems
I think making the binaries available will widen the pool of people who could fix windows problems.
and the lack of caring of developers who only developed for Linux and broke stuff on Windows... has any of that changed?
Don't confuse "caring" with "time" and "priorities". I care about having Zope 3 run on Windows, and Mac OS X, and other platforms. I don't have time to do that though. I think it would be appropriate for others to help by working on windows and Mac OS X (etc.) issues. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
I'd be happy to set up a nightly (or weekly, let me know which would be better) scheduled task (see, it's Widnows, there is no Cron, although Schedules Tasks do have a much nicer UI ;-) ) that checked out he latest HEAD of Zope 3, compiled it and PUT it up to my Zope.org member area
I think that would be super. Nightly would be best.
Okay, added to the bottom of a sadly very long list :-S
Do you have to go through all of that? Couldn't you put it up as a zip file, using ZMI, rather than CMF API's?
As a mere mortal member and not-yet-signer of litigious paperwork, am I allowed ZMI access?
I think making the binaries available will widen the pool of people who could fix windows problems.
Really? I would have thought they'd need ot be able to compile :-S
Don't confuse "caring" with "time" and "priorities". I care about having Zope 3 run on Windows, and Mac OS X, and other platforms. I don't have time to do that though. I think it would be appropriate for others to help by working on windows and Mac OS X (etc.) issues.
Indeed. Although the stuff which stopped me was shear carelessness (things like just using unix path seperators rather that os.path.join, etc)... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Do you have to go through all of that? Couldn't you put it up as a zip file, using ZMI, rather than CMF API's?
As a mere mortal member and not-yet-signer of litigious paperwork, am I allowed ZMI access?
Sure. After you log in, you can still get to Members/youruserid/manage_main.
I think making the binaries available will widen the pool of people who could fix windows problems.
Really? I would have thought they'd need ot be able to compile :-S
If they have the .pyd files, they can run Zope and fix problems they find in the .py files.
Don't confuse "caring" with "time" and "priorities". I care about having Zope 3 run on Windows, and Mac OS X, and other platforms. I don't have time to do that though. I think it would be appropriate for others to help by working on windows and Mac OS X (etc.) issues.
Indeed. Although the stuff which stopped me was shear carelessness (things like just using unix path seperators rather that os.path.join, etc)...
<shrug> Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
[Jim] ...
If they have the .pyd files, they can run Zope and fix problems they find in the .py files.
They have the .pyd files now. I'm keeping them up to date, and Max M wrote a clear howto (which references the .pyd Zip files on zope.org): http://www.mxm.dk/papers/run-z3-cvs-wthout-compiler/ easier-to-do-it-than-argue-about-it<0.7-wink>-ly y'rs - tim
Tim Peters wrote:
If they have the .pyd files, they can run Zope and fix problems they find in the .py files.
They have the .pyd files now. I'm keeping them up to date, and Max M wrote a clear howto (which references the .pyd Zip files on zope.org):
http://www.mxm.dk/papers/run-z3-cvs-wthout-compiler/
easier-to-do-it-than-argue-about-it<0.7-wink>-ly y'rs - tim
Oh cool :-) Thanks Tim! cheers, Chris - 1 item removed off very long to-do list... -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Wednesday 21 April 2004 09:40 am, Max M wrote:
Stephan Richter wrote:
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.
Well, I couldn't find the antecedent for that quote, but it's really good news! I'm deeply embroiled in organizing for an upcoming space conference on Memorial Day Weekend (May 27-31, http://www.isdc2004.org ), so I'm not able to do *any* programming for about a month, but I will definitely be checking X3.0 out in June. That's probably when I'll be available to look at the Schema package and see if I can contribute usefully to it, as well. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Stephan Richter wrote:
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.
Note that you were one of those people, in 2002. I remembering you rushing schema/forms as you were going to use it on a customer project. It still ain't done.
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.
On and off I've tried to make the component architecture work in Zope 2, and from a Python level it *should* be easy. I just want to be able to do adapter lookup on Zope 2 objects, in product code; no other Zope 2 integration is necessary. Unfortunately right now this is *difficult*. The only way to make it work is with a really unwieldy FrankenZope setup . I spent hours trying to get it to work but in the end I gave up; I saw some recipes more recently I still have to try, but unwieldy it is. Another alternative, one I've been proposing for what, half a year now, and which actually installs easily, is patching the interfaces package so that it doesn't try to use __implements__ but something else (as this conflicts with Zope 2's usage of it). Keep them separate but allow people to use Zope 3 interfaces in Zope 2.7. But while I've proposed this over and over again, I'm just blocked over and over again. In my mind this strategy of blocking people who are willing and able from starting integrating Zope 3 technology into Zope 2 is pretty stupid. Not technically stupid, but it doesn't make strategic sense at all. Of course, in theory Zope 2.8 with integrated Zope 3 interfaces is already there. :) To quote Jim:
I expect Zope 2.8 to be released no later than February.
I displayed some skepticism about this at the time. So, while I have not much in the way of technical comments on Zope 2 or Zope 3, I do think some strategic mistakes have been made in the past. No wonder people are skeptical about any Zope 3 release plans now; they've been burned too often in the past. I know if I want to speed things up I should volunteer, but I have my hands full already. But if you let me follow my strategy for Zope 2 integration, I *will* make time. It's clear that the official strategy is failing; not from technical grounds but from a strategic point of view. Regards, Martijn
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: joachim.werner@iuveno.de WWW: http://www.iuveno.de
Joachim Werner wrote:
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.
It would be great to start something like a Zope3 CMS interest group up, to pool all our CMS experience - start collecting requirements, etc. Seems like a mighty large task, though :-) I'd like to at least have a session on this topic at Europython.
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)...
I know it's said to be slow, but Eclipse has some pretty major momentum behind it... has anyone round here looked at it in detail? I guess it requires you to write loads of Java to produce new plugins :-(
Finally we need industry-strength performance. We are just lacking the performance (mostly thanks to Python being a beautiful, but not really fast language).
I disagree that performance is a problem in Zope 2. With a combination of profiling to eliminate bottlenecks, ZEO, and Squid, Zope hums along beautifully. We are consulting for a company that is in the process of replacing their Java front-end with Zope. They have huge amounts of traffic, and are impressed with Zope's performance compared with their comparable Java system. Seb P.S. I don't agree with your pessimistic assessment of CMF, or Plone. They're both good at what they do.
On Thu, 22 Apr 2004 11:15:58 +0100, Seb Bacon <seb@jamkit.com> wrote:
Joachim Werner wrote:
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.
It would be great to start something like a Zope3 CMS interest group up, to pool all our CMS experience - start collecting requirements, etc. Seems like a mighty large task, though :-)
I'd like to at least have a session on this topic at Europython.
Heimo and I have proposed a panel with the CMS's for Zope, to discuss the future of content management in Zope. My goal is to have a session that is structured enough to actually make a constructive step forward, if only in understanding and agreement. Particularly regarding Zope3. The panelists would be the implementors of current CMSs for Zope. How bout you, Silva, CPS, and Plone? Any others? --Paul
Paul Everitt wrote
On Thu, 22 Apr 2004 11:15:58 +0100, Seb Bacon <seb@jamkit.com> wrote:
Joachim Werner wrote:
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.
It would be great to start something like a Zope3 CMS interest group up, to pool all our CMS experience - start collecting requirements, etc. Seems like a mighty large task, though :-)
I'd like to at least have a session on this topic at Europython.
Heimo and I have proposed a panel with the CMS's for Zope, to discuss the future of content management in Zope. My goal is to have a session that is structured enough to actually make a constructive step forward, if only in understanding and agreement. Particularly regarding Zope3.
The panelists would be the implementors of current CMSs for Zope. How bout you, Silva, CPS, and Plone? Any others?
Yes, we work on a open source framework based on Zope3 called tiks. I'm interested in this, can you point me to the proposal?
--Paul
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Hi!
It would be great to start something like a Zope3 CMS interest group up, to pool all our CMS experience - start collecting requirements, etc. Seems like a mighty large task, though :-)
I've proposed that a couple of times already. There are two problems in real life: 1) "Somebody" has to take care of managing the project. We need at least a web page and a first draft of what we want to accomplish. My idea always was to start with a feature matrix of the current Zope-based and competing systems and then add a wish list of things that we need for Zope 3, based on the existing products' implementations. 2) If politics take over, things will quickly fall apart. I for my part would be happy to work together with people who are currently using Plone, but I'd not want to work on a Plone 3. So the effort should aim at the common grounds all the CMS have, not on the individual philosophies that drive the different projects ...
I'd like to at least have a session on this topic at Europython. Unfortunately I probably won't be there this year.
I know it's said to be slow, but Eclipse has some pretty major momentum behind it... has anyone round here looked at it in detail? I guess it requires you to write loads of Java to produce new plugins :-(
Well, it is becoming some kind of standard. But my personal feeling is that we'd need something fresh that is focussed on Zope. That would make things easier. Whenever I use an IDE that "also talks Python" I am distracted by all the stuff that I'll never really need ... Eclipse can be used as a platform though (and I'm sure one can use Jython a lot to make things easier for Pythonists). I personally prefer Qt, but that's not free on Windows, so the target group is a bit more limited than with using a Java-based solution.
I disagree that performance is a problem in Zope 2. With a combination of profiling to eliminate bottlenecks, ZEO, and Squid, Zope hums along beautifully. We are consulting for a company that is in the process of replacing their Java front-end with Zope. They have huge amounts of traffic, and are impressed with Zope's performance compared with their comparable Java system.
I've heard that a couple of times. But let's face it: Of course you can get Zope to deliver partly dynamic pages at high speed and if you use caching you can deliver pages at wire speed, but it will not be nearly as fast as a solution using Java or .NET/C# if we are talking about a lot of two-way traffic and CPU-intensive tasks in the back end, e.g. an online shopping mall, a booking system, or a groupware.
P.S. I don't agree with your pessimistic assessment of CMF, or Plone. They're both good at what they do.
I agree with you that Plone is quite impressive as it is now, but nobody will ever convince me that the CMF => Plone way was the right way to go ... Well, different people, different tastes ;-) Cheers Joachim iuveno AG Joachim Werner _________________ Wittelsbacherstr. 23b 90475 Nürnberg joachim.werner@iuveno-net.de www.iuveno-net.de Tel.: +49 (0) 911/ 9 88 39 84
Joachim Werner wrote:
[Seb Bacon wrote:]
I disagree that performance is a problem in Zope 2. With a combination of profiling to eliminate bottlenecks, ZEO, and Squid, Zope hums along beautifully. We are consulting for a company that is in the process of replacing their Java front-end with Zope. They have huge amounts of traffic, and are impressed with Zope's performance compared with their comparable Java system.
I've heard that a couple of times. But let's face it: Of course you can get Zope to deliver partly dynamic pages at high speed and if you use caching you can deliver pages at wire speed, but it will not be nearly as fast as a solution using Java or .NET/C# if we are talking about a lot of two-way traffic and CPU-intensive tasks in the back end, e.g. an online shopping mall, a booking system, or a groupware.
I have yet to see a comprehensive list of "official" (as in approved) things to consider when designing and building your application and then deploying it. I am not trying to coerce anyone into doing this for me, I am just pointing out the situation. There are several docs that go thru different aspects, but they are scattered around the net, and there is no real, AFAIK, description of do's and don'ts related to Zope application desing. I think these things should go into the manual perhaps. I will try to contribute to such an end - eventually a chapter on that might even become written ;-)
P.S. I don't agree with your pessimistic assessment of CMF, or Plone. They're both good at what they do.
I agree with you that Plone is quite impressive as it is now, but nobody will ever convince me that the CMF => Plone way was the right way to go ... Well, different people, different tastes ;-)
This is also something I have never been able to find any comprehensive document describing in som depth what the shortcomings of CMF and Plone. Is there one? /dario -- -- ------------------------------------------------------------------- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech.
Joachim Werner wrote:
I've proposed that a couple of times already. There are two problems in real life:
1) "Somebody" has to take care of managing the project.
2) If politics take over, things will quickly fall apart.
I agree. I hope that Heimo & Paul's session at EP will help work through some solutions to these points.
I disagree that performance is a problem in Zope 2.
I've heard that a couple of times. But let's face it: Of course you can get Zope to deliver partly dynamic pages at high speed and if you use caching you can deliver pages at wire speed, but it will not be nearly as fast as a solution using Java or .NET/C# if we are talking about a lot of two-way traffic and CPU-intensive tasks in the back end, e.g. an online shopping mall, a booking system, or a groupware.
Well, the site I am talking about is a real-world, huge-traffic, highly dynamic, personalised shopping site and multiple bookings system which gets millions of visits a day. It performs very well under extreme load in test conditions, *even when you take squid out*: better than the previous Java solution. I would take this as a pretty good indication that performance need not be an issue when evaluating Zope. Let's face it: there are plenty of badly-performing Java sites out there ;-) I do agree that it is hard to find best practice information about this subject, though. I am planning to do a talk about it at Europython. If Chris M doesn't mind, I'll be using some of his material, and elaborating on it: http://www.plope.org/misc/szweb The reason the Zope site I'm talking about performs better, IMO, is nothing to do with the language, but to do with (a) the better application design and (b) the ease of scaling horizontally with ZEO. seb
Seb Bacon wrote:
P.S. I don't agree with your pessimistic assessment of CMF, or Plone. They're both good at what they do.
Funny, I do, and Joachim's the first person to put that into words that made sense for me... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
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
From: "Dieter Maurer" <dieter@handshake.de>
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
Lennart Regebro wrote:
From: "Dieter Maurer" <dieter@handshake.de>
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/
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 <sidnei@awkly.org> http://awkly.org - dreamcatching :: making your dreams come true http://plone.org/about/team#dreamcatcher FORTRAN is for pipe stress freaks and crystallography weenies.
Lennart Regebro wrote at 2004-4-23 10:57 +0200:
From: "Dieter Maurer" <dieter@handshake.de>
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
Dieter Maurer wrote:
Lennart Regebro wrote at 2004-4-23 10:57 +0200:
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 :-)
I also disliked the cmf concept, until I actually started using it seriously. regards Max M
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
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
Dieter Maurer wrote:
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.
Okay, point taken. :) How much do the tools listed interdepend on each other? Regards, Martijn
Martijn Faassen wrote:
Dieter Maurer wrote:
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.
Okay, point taken. :)
How much do the tools listed interdepend on each other?
See the attached file. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com [/home/tseaver/projects/CMF/CMF-1.4-head/CMFCore] $ grep getToolByName Action*.py ActionInformation.py:from utils import getToolByName ActionInformation.py: membership = getToolByName(tool, 'portal_membership') # uses 'portal_membership' to compute whether the user is anonymous, and # to look up the user's ID. # uses 'Expression' class heavily; Expression also depends on # 'portal_membership'. [/home/tseaver/projects/CMF/CMF-1.4-head/CMFCore] $ grep getToolByName Skins*.py SkinsTool.py:from utils import UniqueObject, getToolByName, _dtmldir SkinsTool.py: pm = getToolByName(self, 'portal_membership') SkinsTool.py: pu = getToolByName(self, 'portal_url') # Uses 'portal_membership' to look up member skin prefs # Uses 'portal_url' to compute the path of the site object, in order to set # the path on the skin cookie. [/home/tseaver/projects/CMF/CMF-1.4-head/CMFCore] $ grep getToolByName FS*.py FSObject.py:from utils import expandpath, getToolByName FSObject.py: portal_skins = getToolByName(self,'portal_skins') # Uses 'portal_skins' to do customization. [/home/tseaver/projects/CMF/CMF-1.4-head/CMFCore] $ grep getToolByName Member*.py RegistrationTool.py MemberDataTool.py:from utils import UniqueObject, getToolByName, _dtmldir MemberDataTool.py: membertool = getToolByName(self, 'portal_membership') MemberDataTool.py: mtool = getToolByName(self, 'portal_membership') MemberDataTool.py: membertool= getToolByName(self, 'portal_membership') MemberDataTool.py: membership = getToolByName(self, 'portal_membership') MemberDataTool.py: registration = getToolByName(self, 'portal_registration', None) MembershipTool.py:from utils import getToolByName, _dtmldir MembershipTool.py: registration = getToolByName(self, 'portal_registration', None) MembershipTool.py: md = getToolByName(parent, 'portal_memberdata') MembershipTool.py: md = getToolByName( self, 'portal_memberdata' ) from utils import getToolByName membership = getToolByName(self, 'portal_membership') membership = getToolByName(self, 'portal_membership') # Membership, memberdata, and registration are self-contained. [/home/tseaver/projects/CMF/CMF-1.4-head/CMFCore] $ grep getToolByName Workflow*.py WorkflowCore.py:from utils import getToolByName WorkflowCore.py: wf = getToolByName(instance, 'portal_workflow', None) WorkflowTool.py:from utils import getToolByName WorkflowTool.py: types_tool = getToolByName( self, 'portal_types', None )WorkflowTool.py: pt = getToolByName(self, 'portal_types', None) # Uses 'portal_types', *if present*, to compute list of type names, and to # verify type-specific bindings. [/home/tseaver/projects/CMF/CMF-1.4-head/CMFCore] $ cd ../DCWorkflow [/home/tseaver/projects/CMF/CMF-1.4-head/DCWorkflow] $ grep getToolByName *.py DCWorkflow.py:from Products.CMFCore.utils import getToolByName DCWorkflow.py: catalog = getToolByName(self, 'portal_catalog') # Uses 'portal_catalog' to build work lists.
Tres Seaver wrote at 2004-4-26 11:46 -0400:
Martijn Faassen wrote:
Dieter Maurer wrote: ...
We use "SkinsTool", "ActionsTool" and "DCWorkflow" a lot, "MembershipTool" sometimes and most other tools not at all.
Okay, point taken. :)
How much do the tools listed interdepend on each other?
See the attached file. ... ... longer list than written above ...
This happens when I write from memory, sorry! We also use "portal_types" regularly. When you do not use the full functionality from the MembershipTool, you may not need the MemberDataTool nor the RegistrationTool. Our minimal tool usage is probably: "Actions", "Membership", "Skins", "Types", "Workflow". -- Dieter
On Mon, Apr 26, 2004 at 07:47:39PM +0200, Dieter Maurer wrote:
Our minimal tool usage is probably: "Actions", "Membership", "Skins", "Types", "Workflow".
I'm curious... do you use these with sites that are not in any other way based on CMFCore/CMFDefault ? -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's ! (random hero from isometric.spaceninja.com)
Paul Winkler wrote at 2004-4-26 17:45 -0400:
On Mon, Apr 26, 2004 at 07:47:39PM +0200, Dieter Maurer wrote:
Our minimal tool usage is probably: "Actions", "Membership", "Skins", "Types", "Workflow".
I'm curious... do you use these with sites that are not in any other way based on CMFCore/CMFDefault ?
Yes. -- Dieter
Joachim Werner wrote:
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.
You are somewhat right. It's an absolute bitch to write Products for Plone. But it does shows what is actually needed for Zope to work as intended. In plain Z2 You could write a lot of products, and they would all work fine on your site. But others could not easily download and use/try out the products. What Plone really is a good example of, is the necessity of a practical reference implementation that all content types and tools can be tested up against. It the light house that everything is steering towards. I believe that's the reason for it's succes. It's hard to put a finger on exactly why it has become one. But obviously it has reached critical mass of being "good enough" for a lot of things. It is also flexible enough to be changed beyond recognition. So both novice users and developers can use it with a lot of succes. A short list of things that I think makes it an end user succes (even advanced developers are end users of others products): The skin -------- Notably main_template.pt & plone.css. It is absolute paramount to have a flexible template/styleguide to write up against. It has to be pretty enough to be used in production site out of the box, and easy to change. The CMS' skin apparently wasn't good enough. A site can be layed ot in umpteen ways, but the Plone guys has said "this is how we think it should look and function", and put a working example out there. Apparently that has been a very succesfull strategy. There is also several layers at which it can be changed. From stylesheets to programming. So it can look completely different. But ther reference is allways there as a guide. Installation ------------ It is easy to install and try out new products, and they all work together, and all use the same skin. So if you install a new product it automatically has the look and feel of your site. Even though the site is heavily skinned. Development process ------------------- Quick and non-bureaucratic. The Plone developers are pretty open for suggestions, and hang out on irc and maillists. There is a shared repository (the collective) for 3'rd party products. Which gives a good sense of comunity There is a lot of stuff that could be different in Plone, but on a basic level they got the right solution for making it possible to do distributed development of products that can still work together. regards Max M
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.
Well, thanks for the kind words. Makes me want to work really hard to satisfy your concerns.
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.
I'm sorry you feel that way. We've tried to be very honest about the road map. Zope 3 has taken much longer than I expected. I made a conscious decision a few months ago to actually slow it down, Why? Two reasons: - We have Zope 2. While not perfect, Zope 2 is a great system. We make out living with Zope 2. The vast majority of ZC people work in Zope 2, not Zope 3. - We want Zope 3 to be as solid and clean as it can be. We have an opportunity, before a stable release, to change things readily. That will be much harder once it's in production.
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,
This enormous learning curve is one of the main reasons we created Zope 3.
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.
That's both insulting and incorrect. Many of the leaders of the Zope 2 community are involved in Zope 3 and using it. These people are application developers.
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 ...
Any new project distracts development from other projects. That's natural and healthy? Has development on Zope 2 stopped? No. ZC still puts more work into Zope 2 than into Zope 3. I expect that to continue for some time. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
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.
That's both insulting and incorrect. Many of the leaders of the Zope 2 community are involved in Zope 3 and using it. These people are application developers.
Jim, we native german speakers tend to be much more direct and phrase dings more bluntly the you americans do. In german I read Maik's statement as a strong opinion but never as an insult. Since I am the one who asked Mike to speak up I would feel bad if it created any bad feelings. Robert
robert rottermann wrote:
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.
That's both insulting and incorrect. Many of the leaders of the Zope 2 community are involved in Zope 3 and using it. These people are application developers.
we native german speakers tend to be much more direct and phrase dings more bluntly the you americans do. In german I read Maik's statement as a strong opinion but never as an insult.
Since I am the one who asked Mike to speak up I would feel bad if it created any bad feelings.
I would also like to point out that Maik did not post it here himself. It's an opinion directed to a group of people that most likely knows him and his context better than we do on this list. There is a big difference in how you can talk about, and talk to, other people. Sometimes you use harder language to emphasize a point. A language that you wouldn't normally use when talking to somebody. Generally there is nothing wrong with this, but seen out of context it can seem inapropriate. regards Max M
robert rottermann wrote:
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.
That's both insulting and incorrect. Many of the leaders of the Zope 2 community are involved in Zope 3 and using it. These people are application developers.
Jim, we native german speakers tend to be much more direct and phrase dings more bluntly the you americans do. In german I read Maik's statement as a strong opinion but never as an insult.
Since I am the one who asked Mike to speak up I would feel bad if it created any bad feelings.
Bad feeling don't last long with me. I couldn't be an open-source developer if they did. :/ Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
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?
Hi to all, I'm not able to respond to all mails in this thread due to a "trashed" shoulder (very unlucky cyclocross-crash last week), but I'm feeling the need to make some simple remarks. 1) Chris is right: Yes, I've had a bad day...;) 2) My initial mail wasn't intended for zope-dev. So I'm a little bit suprised that it made it to this list. If anyone feels offended (esp. Jim), I'm very sorry, but if I want to complain about Zope2/3 on this list, I would use other words. The initial mail (written in german) was written in a state of fear (not anger). The translation (and maybe my mail itself) didn't transport my fear about the future of Zope very well I guess. 3) To say it clearly: I would have never started the "German Zope User Group" two years ago if I were not totally convinced of Zope (the technology & the community). Bringing up a community in Germany (with several big conferences, etc.) was a lot of work (believe me), so I don't feel as a usual "freerider who only complains but does not give something back to the community". But my resources are limited as well, so I can't take additional tasks as documentation, release-management, etc.pp... If this means I'm not allowed to say anything critical about these points then I'm very, very sorry making any remarks... 4) Stephan, you're right, I did not study Zope3 (and the zope3-dev-list) very well. My initial approach to Zope3 ended with the impression: "huh, complicated stuff, but I don't have time to work it out in the moment!" Then I've talked to many people who said similar things about their first experience with Zope3 (maybe I've talked to the wrong people, than this is my fault, sorry again). So I came up with the impression: "yeah, Zope3 is cool, but complicated (stated as 'academic' in my mail)!" (at least if you don't have the time to work things out by diving into the source). And if you run several mission critial applications you don't have time to look into this kind of new stuff. But you're right, Stephan: If you want to stay in technology business, you have to invent (read: improve by a complete redesign) the wheel many times. So I don't think that Zope3 is useless for the future of Zope. 5) But there's some kind of a bad impression in my mind (maybe it is without any foundation, than all things are in best state): Zope2 isn't maintained very well anymore due to limited ressources (bug fixes, documentation, see mail from Andreas), but Zope3 isn't production ready at all. So if you talk to people making the decisions in the IT-business they say: "Zope2 seems to be a dead horse, Zope3 is just a child which learns to run... Let's settle our business on more approved technologies like Java / Net (or even PHP...;)). We can't wait anymore..." This kind of "frustrating" impression made me writing the mail about the future of Zope, because I'm in love with Zope and not Java, Net or PHP... [[[6) Just a personal note to Stephan: You're right again about the "quick&dirty" design of some of my products (esp. Epoz, I have simply no knowledge about JavaScript at all (and I don't like it), but Epoz seems to do a good job for many people until Kupu is finished). My job (read: strength) is custom-application-development (talking to customers and reading their minds, developing prototypes to track down the issues the customer meant and didn't told me and didn't dream of etc.pp., developing & securing & maintaing web-applications which need to work in an environment with 20.000 students & 2000 office-workers etc.), not "application-framework-design-nor-development", so my products are just some "wired" by-products of my daily work. About MailBoxer: If you think MailBoxer is just another "mailinglistmanager" (like mailman) you didn't get the idea of it... MailBoxer is a lightweight mailinglist-framework (!, yes I've done some kind of framework, it can be done better, but it solves my problems this way) which is built on the power of Zope to achieve some things you can hardly achieve with Mailman (at least I wasn't able to to). So I've "reinvented" the wheel once more to solve some of my application-needs...]]] Hope this made things a little bit clearer... I didn't want to attack ZC / Zope3-devs / the community or anyone else. I'm just fearing that we miss the train for Zope2 AND Zope3 in the moment... if you don't think so, I'm fine...:) Keep zoped, Maik
Hi, On Wed, 21 Apr 2004 19:04:34 +0200, Maik Jablonski <maik.jablonski@uni-bielefeld.de> wrote:
Zope2 isn't maintained very well anymore due to limited ressources(bug fixes, documentation, see mail from Andreas), but Zope3 isn'tproduction ready at all. So if you talk to people making the decisionsin the IT-business they say: "Zope2 seems to be a dead horse, Zope3is just a child which learns to run...
Agree. Here is my point of view, as 'site manager'. We are creating small sites for end-users, and we try to use Zope in many cases, recommending this platform to end users. Many customers refuse to use Zope because of one simple reason: they look at http://www.zope.org web site, and then get back to us asking us how we could recommend this product. In my opinion the most important fixes to web site are: - Web site (zope.org) is very slow, and contains outdated documentation, links. Not well organized. Does not look professional way.I have no idea why zope.org site is slow and dying, but if it is because hardware or any kind of misconfiguration problem it must be fixed a.s.a.p. Just tried to open home page of http://www.zope.org - my Opera shows 1 min 11 sec to load. (compare, www.php.org loads in 5 seconds). This makes our customers to make false decision that Zope is a way too slow. Most of customers refused to work with Zope because they tell: "all sites we looked at seems to be really slow". - Look at "Zope powered sites":http://www.zope.org/Resources/ZopePowered/. At first 4 sites are not enought to convience any commercial customer. Even total of 11 links found on the page is not enought. I suggest to have "submit a site" form on this page so end users will submit their sites URLs and the list will be growing. Inactive sites should be removed after some time. - I do not understand the link to "Zope CMF" which leads me to http://cmf.zope.org/ and where I read "ATTENTION! ... Please don't add new content here...". What this site is about, if it should not be used. Is Zope CMF dead? I see it is not, but this link makes me confused. - "Zope HowTos" contain all documents made in 1999. Most of people (including me) will never read such old documents because most probably many things described there are outdated. - "Zope Development Guide" full of comments since 2002. This should be refactored once a month, at least once a 3 months (I've seen the effort to rewrite ZDG has been started). - Bug tracking system (issue tracker) is not very comfortable to use. Better to use bugzilla, foxbugs, even 'trac' project will be a way much better and easier to use. And intruducing a better bug tracking could lead to better and faster bug resolution. So, I think zope.org needs good refactoring, but it seems there are no single person working on the site constantly, only from time to time (like plone integration event). Does anyone have any suggestions how this could be fixed? I can try to help, but as you have probably noticed I am not native English speaker, so my help with editing texts will not be very useful. But we can try to find out the problem with hardware/software setup of zope.org to find out why its slow. Possible we can install bugzilla or some other thing. I just need to know if anybody else interested into better look of zope.org site? And how this could be done... -- Alex V. Koval
--On Freitag, 7. Mai 2004 19:26 Uhr +0300 "Alex V. Koval" <alex@halogen-dg.com> wrote:
I just need to know if anybody else interested into better look of zope.org site? And how this could be done...
Basically by volunteering to help out with the one or the task. See <http://www.zope.org/About/> how to participate. -aj
What a great discussion. I'm not sure I can catch up and make a single coherent reply, so I'll just drop this into the stew right here: I think Zope 3 is firmly on the right track. At the same time let us not forget the ideas around http://www.dreamsongs.com/WorseIsBetter.html .
participants (34)
-
Alex V. Koval -
Andre Meyer -
Andreas Jung -
Brian Lloyd -
Casey Duncan -
Chris McDonough -
Chris Withers -
Dario Lopez-Kästen -
Dieter Maurer -
Eckart Hertzler -
Florian Schulze -
Jamie Heilman -
Jim Fulton -
Joachim Werner -
kretschmar＠infoman.de -
Lennart Regebro -
Maik Jablonski -
Martijn Faassen -
Matt -
Max M -
Paul Everitt -
Paul Winkler -
Peter Sabaini -
Philipp von Weitershausen -
robert rottermann -
Roger ineichen -
Sandor Palfy -
Seb Bacon -
Sidnei da Silva -
Simon Michael -
Stephan Richter -
Terry Hancock -
Tim Peters -
Tres Seaver