[Zope-dev] Re: [Zope3-dev] Re: Proposal: Rename zope package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please pardon my slowness to respond. Zope is (still) not (yet) my full-time occupation. Jim Fulton wrote: | Troy Farrell wrote: | | Philipp, not everyone follows well-planned, ideal upgrade practices. | | There's only so much we can do for people who don't. Agreed. I'm mainly playing devil's advocate because we're moving into the realm where changes have consequences (unlike the legacy-free nature of Z3.) | I think your main point is people who skip updates. Perhaps, | I should have suggested keeping the legacy Zope package longer? I think you are right. | Deprecation errors are nice, but usually admins take one of two | | Warning, not errors Yep, my mistake. | approaches to | them, neither of which is ideal: | 1) Ignore them since everything seems to work alright | 2) See the apocalypse horsemen headed their direction - this results in | URGENT!!! HELP ME PLAESE RIGHT NOW email on the [EMAIL PROTECTED] list. | | This will cause many a shock when the occasion for upgrade to 2.9 | comes around. | ~ At 2 A.M. | | Would you feel better if we kept the legacy support available longer? I see this in your email to Tres: - - We would not enable this by default in 2.9, Assuming that the note on enabling this in 2.9 is fairly easy to spot (README or ChangeLog or whatever is appropriate) that should be enough. I'm not trying to rain on anyone's parade or slow the adoption of Zope 3. I, along with everyone here want to see this transition go smoothly. When the customer only notices the change due to new functionality, ease of use, or improved performance, then we will know that we have succeeded. Troy -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAh2lPAykmMtO9ylMRAiWcAJ9dDp9QOwfSDcK/Ko+EYbfioSSyTwCdE0ZV CswY0tSqsUTKdKx1NT6prbo= =lbVr -END PGP SIGNATURE- ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: The bleak Future of Zope?
Stephan Richter wrote: Nobody is willing to contribute. ZC agreed to change zope.org to Plone so more community members can contribute. But noone has stepped up; that's very sad. Sorry, but I think you'll find several people stepped up, and ZC slapped them in the face with a big fat legal document. That's never a good way to encourage people to help... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Book at ZopeWiki.org
Andreas Jung wrote: Yeah...just had a look a zopewiki.org it seems to be a great place. I wonder why we were not able to built a such place there were it would belong to: zope.org? Indeed. I shall see if I can put some input there... Any chance ZopeWiki.org could become the master location for the book? It's got a much nicer UI than Zope.org... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope.org: legal problems?
Jim Fulton wrote: - The zope.org community site is a mess. Lots of outstanding problems are not fixed, the performance of the site is more than poor (it takes ages to login, it takes ages to load pages), usability (e.g. when you perform a software release) is bad. Yes, that's a bad situation. We (meaning the Zope community) need to do something about this. Sigh. Then maybe you (being Zope Corp) could remove the big barriers that some people perceive in the legal document you want them to sign? That appears to be what's killing help on Zope.org. Me? I don't care, since i know it's neither in ZC's interest or my interest for anything to go to court, and even if it did, either side can find a lawyer who will tear that piece of paper to shreds to suite whichever side is paying him more... I just don't have any time ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: The bleak Future of Zope?!
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Bug days?
Lennart Regebro wrote: This means that we need more bugdays. A typical bugday squishes a whole bunch of bugs. They bugs will be harder to squish the more bugdays we have, since the easy one will be squished first, but no matter. Whatever happened to the plan to have a monthly bug day on the last monday of each month or somesuch? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: The bleak Future of Zope?
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] The bleak Future of Zope?!
Andre Meyer wrote: I have been developing for Zope for about half a year now and it took considerable effort to get anything going. I would suggest that's because you chose to use what are, imho, overly complex products ;-) With respect to CMS, Plone archetypes are too simplistic for complex data/document types and customisation takes too much effort. totally agree... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Book at ZopeWiki.org
On Thu, 2004-04-22 at 02:56, Chris Withers wrote: Any chance ZopeWiki.org could become the master location for the book? It's got a much nicer UI than Zope.org... Every few weeks or so I go and clean out (sometimes hundreds of) test and fglrldjksjds and you suck! comments in the BackTalk version of the book and I'm tremendously thankful at that point that I don't need to actually read the text to distinguish a comment from a canonical part of the book, but I still have the comment in-situ to see its context. Before the Zope.org transition, I had configured the books to be commentable only by authenticated users to make inane and content-free comments harder for people to make, but it still happened. When the transition was done, it turned out that authentication was no longer required, I didn't bother to turn it back on; I figured it's more important to lower the bar for commenters in order to get the best feedback possible anyway, so I just go clean it manually every so often and keep the good parts. It works pretty well, and I'm pretty happy with BackTalk for this purpose. Wikis are great for ad-hoc sorts of things but not so great when it's useful to maintain a distinct level of separation between reader and writer. I can also generate a PDF of the book at will from the BackTalk version, which I couldn't do (or at least I don't think I could do easily) with ZWiki. That said, I think zopewiki.org is a good thing and I encourage folks to contribute. If the Zope.org problems persist and I'm unable to find the time to fix them, I will host the development of the book somewhere else, but it will almost certainly be hosted with BackTalk. - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Book at ZopeWiki.org
From: Chris Withers [EMAIL PROTECTED] Any chance ZopeWiki.org could become the master location for the book? It's gonna be hard to get a printable book out of a Wiki... ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Bug days?
From: Chris Withers [EMAIL PROTECTED] Whatever happened to the plan to have a monthly bug day on the last monday of each month or somesuch? Nothing, as usual, I guess. Even since bugdays where first thought of, more of then and more regular bugdays have been promised, but it doesn't happen. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] [Q] Pickle support for C wrapper and ZEO
Hi all, I'm reposting here because I had no luck on [EMAIL PROTECTED] I'm in the course of low-level wrapping the ODBC api. Just in case you wonder: I know of mxODBC and pyodbc, they don't fit my needs as well license-wise as technically (I want better metadata access, thread-safety etc.). I'll use my wrapper from within Zope. There will be some python wrapper around the low-level stuff and I wonder if it makes sense to add pickle-support to that python wrapper. The ODBC api is object-based and exhibits four object types: environment, connection, statement and descriptor objects each of which has a set of methods and properties. Pickle-wise I'm not so concerned about persistence across shutdown/restart cycles (I think it's reasonable to re-create your ODBC environments, connections etc. after restart) but rather about consistency across ZEO-instances. My lack of experience makes me ask here for expert advise. 1) Does the ZEO scenario demand some pickle support, e. g. to use consitent environments/connections etc. across ZEO instances or do I just misunderstand ZEO? 2) If pickle support is a good idea: What scope would you find reasonable? I. e. I can imagine that persistence of environments/descriptors could be useful while persistent connections/statements could cause more trouble than they are worth. As you can see the whole thing isn't very clear to me and so I'd appreciate your comments. TIA, andreas ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] performance tuning of ZODB
I've used the cache_size paramter to the constructor of the DB to good effect. Are there any further gotchas for ensuring that the ZODB stays in memory as much as possible? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] List of bugs which can be closed
Maik Jablonski writes: Hi, there are some bugs in the Zope-Collector which IMHO can be closed. [...] Not up2date anymore: http://zope.org/Collectors/Zope/591 http://zope.org/Collectors/Zope/943 and: http://zope.org/Collectors/Zope/599 (if someone minds...) Cheers, Clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] performance tuning of ZODB
On Thursday 22 April 2004 10:42, Syver Enstad wrote: I've used the cache_size paramter to the constructor of the DB to good effect. Are there any further gotchas for ensuring that the ZODB stays in memory as much as possible? Memory usage scales proportional to the number of threads. Reducing the number of worker threads lets you increase the per-thread cache size. -- Toby Dickenson ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: On a constructive note: Zope 2.8
Jim Fulton wrote: Martijn Faassen wrote: Hey there, I understand from: http://dev.zope.org/Wikis/DevSite/Projects/Zope2.8/MilestonePlan Zope 2.8 is now planned for june. This is, of course, a function of people's availability to help. I still need to fix ZClasses, and I need to get through the Zope X3.0 to-do list first. If Zope 2.8 is indeed released by june this could fit fairly well with my own (also delayed :) plans for using this facility in Silva. The obvious area I could try to contribute is in integrating Zope 3 interfaces in Zope 2. Great! I meant to mention that Kapil has offered to work on this. I suggest you get with him to see if he nees any help or if it makes sense to collaborate in some way. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Re: Proposal: Rename zope package
Troy Farrell wrote: ... I'm not trying to rain on anyone's parade or slow the adoption of Zope 3. I, along with everyone here want to see this transition go smoothly. When the customer only notices the change due to new functionality, ease of use, or improved performance, then we will know that we have succeeded. This exactly the sort of feedback we need. Thanks. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Book at ZopeWiki.org
On Thursday 22 April 2004 03:31, Lennart Regebro wrote: Today 03:31:57 From: Chris Withers [EMAIL PROTECTED] Any chance ZopeWiki.org could become the master location for the book? It's gonna be hard to get a printable book out of a Wiki... I tried this and I can tell you that a Wiki is not the right format for a book. While it lowers the entrance points, it is far too simplistic. I eventually changed my master to LaTeX, where I can add as much meta-data and other markup (especially for an index, which is crucial) easily and then I try to create Wiki-friendly STX files from that. When people change things in the Wiki, I use the diffs to update the masters. This turned out to be a very good move, since sometimes the corrections change the meaning of what I intended to say. Additionally, I can now always create a beautiful PDF in less than a minute. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: The bleak Future of Zope?!
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Zope3, CMS, IDEs (was: [Zope-dev] The bleak Future of Zope?)
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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] performance tuning of ZODB
Toby Dickenson [EMAIL PROTECTED] writes: On Thursday 22 April 2004 10:42, Syver Enstad wrote: I've used the cache_size paramter to the constructor of the DB to good effect. Are there any further gotchas for ensuring that the ZODB stays in memory as much as possible? Memory usage scales proportional to the number of threads. Reducing the number of worker threads lets you increase the per-thread cache size. I don't use connection per thread semantics but I think I understand what you mean. I should pass a lower number than the default to the pool_size keyword argument for the DB constructor? What about the other arguments to the DB constructor? cache_deactivate_after sounds interesting. Since I am running ZODB in a web server I don't want the data to timeout and disappear from memory since every object I have should be loaded at all times. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] performance tuning of ZODB
On Thursday 22 April 2004 11:43, Syver Enstad wrote: cache_deactivate_after sounds interesting. Since I am running ZODB in a web server I don't want the data to timeout and disappear from memory since every object I have should be loaded at all times. Thats why ZODB ignores that parameter now ;-) -- Toby Dickenson ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: The bleak Future of Zope?!
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Proposal: Rename zope package
Jim Fulton wrote: Philipp von Weitershausen wrote: Why would they switch to Zope 2.8 if not for the component architecture? To stay current? To get MVCC? To get new-style extension classes, and thus access to many modern Python features. Later releases will provide benefits beyond just the Z3 features. But, if they are willing to investigate into new features, new-style extensions classes and all that, a small package rename from Zope to Zope2 should be just as manageable. Philipp ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Zope Book at ZopeWiki.org
On Thu, Apr 22, 2004 at 06:07:10AM -0400, Stephan Richter wrote: I tried this and I can tell you that a Wiki is not the right format for a book. While it lowers the entrance points, it is far too simplistic. I eventually changed my master to LaTeX, where I can add as much meta-data and other markup (especially for an index, which is crucial) easily and then I try to create Wiki-friendly STX files from that. Would this help... LatexWiki is a patch to the ZWiki package that allows rendering of in-line LaTeX. http://mcelrath.org/Notes/LatexWiki -- Fred Yankowski [EMAIL PROTECTED] tel: +1.630.879.1312 OntoSys, IncPGP keyID: 7B449345fax: +1.630.879.1370 www.ontosys.com 38W242 Deerpath Rd, Batavia, IL 60510-9461, USA ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: On a constructive note: Zope 2.8
Jim Fulton wrote: Have interfaces stabilized enough to start this work, or should I wait until next month (may is indicated on the planning). I think so. You think I can start now or you think I should wait? :) What steps need to be taken concretely before such integration is considered completed? I know the package rename discussion rename (zope to z) in Zope 3 is related to this. That's the big one. I think I'd do this after we do the svn conversion. I *hope* to do that next week. Okay, I'll wait for this then. :) Regards, Martijn ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Zope3, CMS, IDEs (was: The bleak Future of Zope?)
On Thu, 22 Apr 2004 11:15:58 +0100, Seb Bacon [EMAIL PROTECTED] 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Q] Pickle support for C wrapper and ZEO
Hello Martin, [EMAIL PROTECTED] (Martin Kretschmar) writes: putting this back on list, hope it's ok with you. Hello, I was once debugging an application which usually crashed after 2-3 days during load tests. It was doing a lot of database operations. The access was to a Microsoft SQL Server. There has been once a warning, that constantly creating and deleting CDatabase-Objects leeds to memory leaks. So the application had been written to reuse a given CDatabase object. The occasional crashes, shown to be somewhere in the ODBC code, were gone, when each Thread got back exactly his last CDatabase object in use. In this sense my definition of threadsafe is not always the way Microsoft sees it. Regards, Martin Thanks for the hint, but I won't use MFC in my code (portability). I'm currently using unixODBC to get started and hope to be able to preserve source code compatibility with MS's ODBC Driver Manager (and eventually iODBC if needed). If there are bugs in the platform code then these will bother me not before some time from now because I'm still wrapping all (or rather a subset of) those SQL... functions which live in sql[ext].h. Currently my own refcount leaks are much worse than any driver manager's memory leaks could ever be ;-). cheers, andreas ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: On a constructive note: Zope 2.8
Jim Fulton wrote: Jim Fulton wrote: this could fit fairly well with my own (also delayed :) plans for using this facility in Silva. The obvious area I could try to contribute is in integrating Zope 3 interfaces in Zope 2. I meant to mention that Kapil has offered to work on this. I suggest you get with him to see if he nees any help or if it makes sense to collaborate in some way. Okay, I'll try to hook up with Kapil on the interface package work. Getting the interface package to work in Zope 2.x in my mind basically opens up a lot of possibilities straight away. Regards, Martijn ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
AW: [Zope-dev] Re: Zope3, CMS, IDEs (was: The bleak Future of Zope?)
Paul Everitt wrote On Thu, 22 Apr 2004 11:15:58 +0100, Seb Bacon [EMAIL PROTECTED] 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 - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Bug Day Next Thursday (April 29)
I proposed this yesterday, but I wanted to make sure that everyone say it. I think we should have a bug day, we're long overdue. I'm proposing we hold it on Thursday, April 29. We'll convene on the #zope-dev irc channel. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Proposal: Rename zope package
Philipp von Weitershausen wrote: Jim Fulton wrote: Philipp von Weitershausen wrote: Why would they switch to Zope 2.8 if not for the component architecture? To stay current? To get MVCC? To get new-style extension classes, and thus access to many modern Python features. Later releases will provide benefits beyond just the Z3 features. But, if they are willing to investigate into new features, new-style extensions classes and all that, a small package rename from Zope to Zope2 should be just as manageable. My point was that Zope 2 will make advances independent of Zope 3. Zope 3 technology isn't the only reason for people to upgrade. Also, sometimes, people *need* to upgrade to retain support. That may be the only reason to upgrade for some folks. (Perhaps we, the community, need to provide better management of old releases, but that's a different topic.) We need better ways to manage change. Up to now, Zope 3 has established a culture of embracing change and damning backward compatibility. That was exactly the right culture for Zope 3. When Zope X3.0 enters beta, however, we'll need to shift to embrace change *and* backward compatibility through an orderly change process. We will need to figure out what that process is. Up to now, Zope 2 hasn't managed change very well. Historically, Zope 2 has put expediency and backward compatibility before cleanliness and elegance. I'm a major offender here. We will often pile hacks on top of hacks to retain backward compatibility. This was driven to an extensive degree by practical realities, but it was also a result of a lack of appreciation of the benefits of architectural restructuring and the lack of a change process. We didn't so much evolve as accumulate. We must learn to evolve. I'm optimistic that, as Zope 3 stabilizes and begins to merge with Zope 2, we will establish a new healthier culture of change and compatibility. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Reflections on the Zope 2 to Zope 3 transition
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
RE: [Zope-dev] Reflections on the Zope 2 to Zope 3 transition
I know I'm new here, but I think this may work to my benefit in this case ... +1 on everything Jim just said! Unlike some others it seems, I look at Zope almost uniquely as framework for building web applications. An API or SDK if you will. As such, I think it's internal software desing and architecture has to be priority number one. Otherwise anything you layer on top of it is doomed from the start. To those people that just want an application server that works, such as CPS or Plone, this should still be a very good thing. Having a much higher quality base will mean better end-user usable products in the long run ... Personally, I'm fully expecting to do a full re-design of my code for Zope 3. And that's fine, I like the idea. Given the radical changes in design, I would want to make sure my applications/products take full advantage of the new features. I'm actually counting on several of them to do things like proper multi-lingual support, workflow and publishing control. I might actually NOT bother with migrating slowly through 2.8 and 2.9, that seems dangerous to me ... the potential for kludges and nasty work arounds seems great. We'll have to see. Can't wait for ExtensionClass to go though!! In the mean time, I'll be trying to give back to the Zope community by working on my Subversion storage idea :) Thanks, J.F. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jim Fulton Sent: April 22, 2004 10:47 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [Zope-dev] Reflections on the Zope 2 to Zope 3 transition 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
Re: [Zope-dev] performance tuning of ZODB
Toby Dickenson [EMAIL PROTECTED] writes:
On Thursday 22 April 2004 11:43, Syver Enstad wrote:
cache_deactivate_after sounds interesting. Since I am running ZODB in
a web server I don't want the data to timeout and disappear from
memory since every object I have should be loaded at all times.
Thats why ZODB ignores that parameter now ;-)
Good :-)
I have a strange case here with ReadConflictErrors. I don't know if
this is covered already but anyway. I am using ZODB 3.2 so this might
be fixed in 3.3 for all I know.
Just replace the twisted stuff with the standard lib unittest module to
have it work on a computer without twisted installed.
import pdb
import sys
import time
import threading
import os
from ZODB import DB
from ZODB.PersistentList import PersistentList
from ZODB.FileStorage import FileStorage
from ZODB.POSException import ReadConflictError
from Persistence import Persistent
from twisted.trial import unittest
class Computer(Persistent):
def __init__(self, oidInteger):
self._oid = oidInteger
self._articleStatus = None
self._endUserPrice = None
self._location = None
def setArticleStatus(self, anObject):
self._articleStatus = anObject
def setEndUserPrice(self, anObject):
self._endUserPrice = anObject
def setLocation(self, anObject):
self._location = anObject
class MockArticleDb(Persistent):
def __init__(self):
self._articles = PersistentList()
def addArticle(self, anArticle):
self._articles.append(anArticle)
def articles(self):
return self._articles
class TestReadConflictError(unittest.TestCase):
def setUp(self):
try:
os.unlink('test.fs')
except OSError, err:
pass
storage = FileStorage(
'test.fs',
create=True)
db = DB(storage, cache_size=10)
connection = db.open()
connection.setLocalTransaction()
connection.root()['articledb'] = MockArticleDb()
computer = Computer(1)
computer.setArticleStatus('For sale')
computer.setEndUserPrice(10050)
computer.setLocation('H0101')
connection.root()['articledb'].addArticle(computer)
connection.getTransaction().commit()
connection.close()
db.close()
storage.close()
storage = FileStorage(
'test.fs',
create=False)
self._db = DB(storage, cache_size=10)
def writeStuff(self, connection):
begin = time.time()
connection.sync()
articleDb = connection.root()['articledb']
eachBegin = time.time()
computer = Computer(1)
computer.setArticleStatus('For sale')
computer.setEndUserPrice(10050)
computer.setLocation('H0101')
articleDb.addArticle(computer)
connection.getTransaction().commit()
print 'write list length', len(articleDb.articles())
def doRead(self, oddRead, connection):
tryCount = 1
articleDb = connection.root()['articledb']
try:
for article in articleDb.articles():
pass
except ReadConflictError, err:
if True:
connection.sync()
else: # this also works
connection.close()
connection = self._db.open()
connection.setLocalTransaction()
for article in articleDb.articles():
pass
tryCount += 1
print 'read list length', len(articleDb.articles())
if oddRead:
# on first, third, fifth read we get a ReadConflictError
self.assertEquals(
2,
tryCount)
else:
# but on second, fourth and so forth we don't
self.assertEquals(
1,
tryCount)
def testProvokeReadConflictError(self):
conn2 = self._db.open()
conn2.setLocalTransaction()
for each in range(1, 11): # 1000 works also but takes a bit of time
begin = time.time()
connection = self._db.open()
connection.setLocalTransaction()
self.writeStuff(conn2)
oddRead = each % 2 != 0
self.doRead(oddRead, connection)
connection.close()
if __name__ == '__main__':
from twisted.scripts.trial import run
import sys
sys.argv.append(sys.argv[0])
run()
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Re: The bleak Future of Zope?
[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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Re: The bleak Future of Zope?
[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). ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: The bleak Future of Zope?!
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 . ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: The bleak Future of Zope?
Casey Duncan wrote: On a bright note, I think zopewiki.org could change that. It *greatly* lowers the bar on contributing That is exactly the intent. We have needed this since the days of the ZDP. I see no reason why it being or not being on Zope.org is relevant. Its a social thing: Simon decided to do something and had the software, Not *just* social. I would say there seem to be social/structural/technical/perceptual reasons why such a thing simply cannot exist at ZC-managed zope.org right now. So, while zope.org would be the ideal url (and I tried to nudge zope.org in this direction for years without coming across as a zealot) I think there are actually some advantages to having a slightly separate docs site. More modular, scales better. Of course the more integration and interlinking the better. Constructively-intended zope.org criticism: zope.org is the zope community's biggest documentation asset. And yet at this point it is indeed also a big fat piano sitting on the windpipe of zope documentation, and hence the zope community itself. This is despite the best of intentions on all sides. To say (as Stephan has) that it's due to lack of volunteers is wrong. Many of us have tried. Perhaps ZC expects more from a volunteer than is realistic. Compare with other successful successful open source projects. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: Zope3, CMS, IDEs (was: [Zope-dev] The bleak Future of 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 [EMAIL PROTECTED] www.iuveno-net.de Tel.: +49 (0) 911/ 9 88 39 84 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Zope3, CMS, IDEs
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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zLOG changes
I wrote: - In debug mode, add a new handler that dumps to standard output. This is fairly easy to code, but is inflexible. Andreas responded: But flexible enough for most usecase. The point is that you want to see the tracebacks on the console during the development phase. Watching the event.log with tail -f is somewhat annoying. Understood! I've committed changes that that I think should do the trick for you. - In debug mode, a log handler is added to the root logger that writes events to standard error. This is no longer conflated with the startup logging. - When running Zope using zopectl fg (the best way to run things for debugging), zopectl will force debug mode to be enabled. - In debug mode, use an alternate or auxillary logging configuration to replace or augment the eventlog configuration section. This is more work up front, but keeps everything flexible. Maybe too much overkill...not sure if one needs an academic solution here... I don't know that I'd describe this as academic (most academics I've worked with considered the ability to change the code configuration enough), but if you're happy not to need it, I'm happy not to implement it. ;-) -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zLOG changes
On Wednesday 21 April 2004 04:48 am, Chris Withers wrote: I'm guessing there is some kind of log-to-console logger already? If so, why not just add that in zope.conf and comment it out when you move to production? That would work for me, but not everyone at ZC agreed, so I've made some changes that should be good for most people; see my message to Andreas and (and Zope-Dev) for a description of how things work on the trunk now. BTW, is there a logger in Python 2.3/Zope 2.7 that sends log entries via email? If not, I'll port MailingLogger to Zope 2.7 and see if I can make it play nice :-) Yes, there is. You should be able to use it by adding a section like this inside your eventlog section in zope.conf: email-notifier fromChris Withers [EMAIL PROTECTED] to [EMAIL PROTECTED] to [EMAIL PROTECTED] subject Something blew up! smtp-server [EMAIL PROTECTED] level error format Timestamp: %(asctime)s\nComponent: %(name)s\nLevel: %(levelname)s (%(levelno)s)\n\n%(message)s /email-notifier My mailer might have wrapped that long line; sorry. ;-( Let me know if there are any problems with this. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: The bleak Future of Zope?
Jim Fulton wrote at 2004-4-21 11:39 -0400: Andreas Jung wrote: ... I am sure that more are willing to contribute more than at the moment. Great! Where are they? I, for example, would but I am scared away by the required promise to defend ZC against any potential patent claim related to my checkins. As in the US almost any triviality seems to be patentable, I consider this too big a risk... -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] The bleak Future of Zope?!
Terry Hancock wrote at 2004-4-21 09:39 -0500: ... I've been developing an application, which has taken about two years, largely because developing in the Zope 2 Framework model is like beating your head against the wall constantly. That's probably because I'm writing a fundamentally complex web application which I need to have a lot of large-scale control over. ... I also have to do this in my copious free time, as I'm not commercially employed to do this work (maybe someday, but not now). So in those two years, I've probably had the equivalent of 2 months of full-time work. Writing a fundamentally complex web application within 2 months work is quite impressive, isn't it? Apparently, the framework is not too bad... -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] The bleak Future of Zope?
Joachim Werner wrote at 2004-4-21 21:24 +0200: ... Believe me or not, almost everything gets more complicated with CMF/Plone than with plain Zope. I do not believe you. We have used CMF (mostly the SkinsTool, the ActionsTool and DCWorkflow) very successfully to build * an editorial system for news and newletters * an E-Commerce solution * partner portals * a content management system for fragmented SGML/XML documents We plan to use it for * the configuration of a production process * customizable intranet solutions. * ... Building a framework on top of a broken framework on top of an ageing framework that is hardly documented isn't a very good idea after all. Would be interested why you think the CMF were broken. The source documentation of Zope is not optimal but not too bad at all. Tools like my DocFinder and Zpydoc allow you to access this source documentation quite easily. -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Q] Pickle support for C wrapper and ZEO
Ames Andreas (MPA/DF) wrote at 2004-4-22 11:07 +0200: ... The ODBC api is object-based and exhibits four object types: environment, connection, statement and descriptor objects each of which has a set of methods and properties. Pickle-wise I'm not so concerned about persistence across shutdown/restart cycles (I think it's reasonable to re-create your ODBC environments, connections etc. after restart) but rather about consistency across ZEO-instances. You mean ZEO client instances not ZEO (server) instances, don't you? Why do you think your ODBC objects should be consistent across ZEO clients? I do not think that it is necessary as all your requests your be independent which means all transactions inside a single request which implied that connections need not to be shared. My lack of experience makes me ask here for expert advise. 1) Does the ZEO scenario demand some pickle support, e. g. to use consitent environments/connections etc. across ZEO instances or do I just misunderstand ZEO? You probably misunderstand ZEO. ZEO is a storage server that stores persistent objects (as pickles). Persistent means persistence across shutdown/restart. Any object stored by ZEO must be picklable. But, as you are not interested in persistence across shutdown/restart for your ODBC objects, there is probably no need to store them in ZEO. 2) If pickle support is a good idea: What scope would you find reasonable? I. e. I can imagine that persistence of environments/descriptors could be useful Maybe... while persistent connections/statements could cause more trouble than they are worth. This is definitely true. As you can see the whole thing isn't very clear to me and so I'd appreciate your comments. See how (other) database adapters handle these issues... -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: The bleak Future of Zope?
Martijn Faassen wrote at 2004-4-21 19:42 +0200: Stephan Richter wrote: Nobody is willing to contribute. ZC agreed to change zope.org to Plone so more community members can contribute. But noone has stepped up; that's very sad. I believe part of the blockage is because contributors have to sign far more than just a simple CVS contributor's agreement. This bureaucracy is not helpful. +1 -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: When should one call Connection.sync?
Syver Enstad wrote at 2004-4-21 18:03 +0200: Syver Enstad [EMAIL PROTECTED] writes: I am using ZODB 3.2 in a twisted based web application. I have read that I need to call sync to keep the connection up to date. When exactly should I call sync? Are there any drawbacks with calling it immediately after getting a connection, like this: # for each http request. connection = db.open() # (a DB instance) connection.setLocalTransaction() connection.sync() # start using the ZODB here. # if something needs to be committed connection.getTransaction().commit() I have done some experiments with this scheme and I find that everything gets unloaded when do a connection.close() or connection.sync() so that performance takes quite a hit. Maybe, the connection cache is too small. Usually, an incremental cache garbage collection is performed in connection.close() and at transaction boundaries (sync causes an implicit transaction.abort() which means, it marks a transaction boundary). The cache garbage collection tries to flush as many objects from the cache as are necessary to reach the target cache size. -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Zope Book development moved (was Re: Call for Zope Book volunteers (was Re: Zope Book, was Re: [Zope-dev] The bleak Future of Zope?))
I've come to the unfortunate conclusion that Zope.org is just not going to cut it to do Zope Book development work due to its speed (or lack thereof). I'd like to help fix the Zope.org slowness problem, but I'm a little unclear about what's required for me to get the level of access required to do so. I read the stuff at Zope.org/About and Zope.com/Legal but it's a little hard to divine out of the combination what I need to do before I can be allowed to help. So of the Zope.org Application Server Working Group/Zope Application Working Group/Whoever wants help trying to fix it, you know where to find me! Just don't make me attend a 7am committee meeting or sign a noncompete instrument wink. In the meantime, in the spirit of expedience, I'm moving the development version of the book to plope.com. Once 2.7 edition development work is done, I will move a copy of the book back to Zope.org so it can be found easily by newbies. Interested parties can now refer to http://www.plope.com/Books/zb_signup for project information. - C On Wed, 2004-04-21 at 14:13, Chris McDonough wrote: I've set up a development BackTalk sandbox for the 2.7 edition of the Zope book at http://zope.org/Documentation/Books/ZopeBook/2_7Edition. Currently it's just an exact copy of the 2.6 Edition book (comments and all). I think the plan should be for people to: 1. take ownership of a chapter or two 2. address all the comments in the chapter and get rid of comments in places you've addressed. 3. update any material that is wrong wrt to differences between 2.6 and 2.7. The prize for taking ownership and updating two complete chapters is your name as a coauthor on the front page (as before ;-). Another thing to do is to incorporate some of John Whitener's changes the lost chapter referenced all over the place within book comments. I wonder if he's still around. At some point in the future, we can backport some of the changes to the 2.6 book if someone wants to take on that responsibility. It's advisable to use external editor to make the changes or to maybe use FTP to get sandboxed local copies of the book and make changes reuploading them as necessary. I've lost track of whether FTP access is possible or not on Zope.org at this point, however. Does anyone know? I've tried a few ports but nothing. Also, Zope.org is so slow for each request when you're logged in that we may need to move development to another system. As a data point, I've been waiting 4 minutes for Z.org to save a Wiki page... still waiting. Hilarious. Admittedly, it takes a unique brand of apathy to ignore this, but I've got an excuse. I'm waiting for the Zope.org steering committee to solve it! Chuckle. In the meantime, what slowness.. I don't know what you're talking about.. I have given Manager role in the entirety of the 2.7 edition book to both Peter and Paul. Anyone else who wants to contribute, please let me know which chapter(s) you'd like to sign up to revise and I will provide you access as necessary. I've set up a project wiki for the project at http://zope.org/Members/mcdonc/ZB_project where people can get a sense of which chapters are still available. It may not be available yet... still waiting for it to save. I will take ownership of the Installation chapter for now (I will probably take ownership of some other chapters, but I'll start small...) - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] The bleak Future of Zope?!
On Thursday 22 April 2004 05:22 pm, Dieter Maurer wrote: Writing a fundamentally complex web application within 2 months work is quite impressive, isn't it? Apparently, the framework is not too bad... Ya' think? I thought it just meant I kicked ass. :-D No, seriously Zope is great. But it's a bit rigid. Zope 3 will (I think) be a lot better. There's also the tiny detail that I haven't actually written it to the point where it can be used yet. So maybe it isn't that impressive. :-( Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
