OracleStorage? Re: [Zope-dev] DCOracle2 Beta 3
Are there any plans to port OracleStorage over to use DCOracle2? John On Tuesday 12 June 2001 10:46, Matthew T. Kromer wrote: For all of you (or at least, BOTH of yousmirk) Oracle users out there, I packed up DCOracle2 Beta 3 this morning, including Z Oracle Stored Procedures as part of ZOracleDA. It can be found in the usual place, http://www.zope.org/Members/matt/dco2 This isn't much different from Beta 2 except for some SP tweaks and the Z Oracle Stored Procedures, except that the NT builds are release versions with Oracle 8i (e.g. SP discovery code) features enabled -- when I built Beta 2 I goofed the build and packaged a debug release without the 8i specific features on. I'll confess that I'm not a heavy user of Stored Procedures, so your mileage may vary; particulary when using IN/OUT binds where type conversions need to take place from unweildy Oracle native types (like SQLT_NUM.) If you play with the stored procedure objects in Zope, it's probably worth pointing out that the default permissions won't include execute permission -- you have to specifically enable that for non-manager roles. On the far-out front, a few people have asked how you might do user-specific connections to the database (ie instead of pooling by a common connection, you individually authenticate to Oracle with your own password). Clearly, cloning the base Connection object would be fairly straighforward, but authenticating it to Oracle would not be, as the user password wouldn't be available. If anyone feels strongly about that (ie you have a notion on how you would make it work and/or you need it), feel free to write me. From a performance standpoint it would be terrible, but security auditors would love it. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bulletproof ZCatalog proposal
Me too! Me too! John On Thursday 07 June 2001 08:49, Chris Withers wrote: Shane Hathaway wrote: But I think I have a solution for all of the issues in conflict resolution. If you, or anyone else, is also interested in this, please show support (if only by saying please do this!) :-) I can't work on it unless I have a reason to. Please do this! :-) I'm particularly interested in ZCatalog becoming a standard ZODB feature, and I know there are otehrs on ZODB-dev who are dying for this right now... cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] another Zope hanging..
I've added a patch to Python 2.1 on sourceforge that helped me considerably when diagnosing multi-threaded Python lock ups. See http://sourceforge.net/tracker/index.php?func=detailaid=421709group_id=5470atid=305470 for the submitted patch. I created this to give me at least as much functionality as Java has to dump the stack trace of all Java threads and Java monitors. For an example of how I used it see http://lists.zope.org/pipermail/zodb-dev/2001-May/000703.html in the ZODB dev list. Hope this helps, John On Friday 18 May 2001 09:13, Christian Scholz wrote: Hi! Just FYI: The server still hangs once a day and another one is doing the same.. It even does this when simply accessing one page or image over and over again. More precisely I've started the server and did ab -n 10 -c 10 http://foo.bar/we/pics/someimg.gif (ab being the apache benchmarking utility) and after a while I get the broken pipe error. I've also changed my python version to 2.0 and tested it with this but still the same effect. Also changing the server (and thus hardware and system) did not help it. I've also removed the mysqlda from the zope installation but also this did not help.. I will try now to create the smallest version of the site that still hangs.. Dunno if anybody has some idea, I actually have none.. I'll keep you informed.. -- christian PS: strangely it works on the development server but also here I am doing some tests with ab right now.. and this one is still 1.5.2 On Thu, May 03, 2001 at 02:16:30PM -0400, Chris McDonough wrote: Well, my problem might be that in my case most sql statement are done inside some attribute provider of ZPatterns.. This is using ZSQL methods internally but actually those then won't show up I guess.. Even if you weren't using ZPatterns, the error probably wouldn't jump out and say here I am! So I don't think there's much difference between using ZPatterns and not using ZPatterns. The process of detecting when something hangs is just like any other troubleshooting process, it's a matter of exclusion. If you notice that the request named foobargorf/fleafang *always* hangs, you investigate what it does, and try to reproduce it. If it's incidental, so be it, and move on to the next theory. I've also seen that some more recent version of the mysql stuff is around and I am using this now.. The problem's also that I just have a few methods to invoke from the outside which do lots of things by calling other object. Thus I might not really see what's really causing the problem.. I hope though that my upgrade will show some benefit.. The -M log perhaps won't show you the actual operation that's causing the hang, but it will show you the entry point into a routine which causes the hang. It's your job from there to track down the cause. This is just like debugging a program. You get an error somewhere, and you need to track it back to its root, which may be six levels up the call stack buried in some godforsaken regex. ;-) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Experiments with ORMapping
I think this is a great idea! I would definetely like to use and contribute to this effort. Having this kind of flexibily would be fantastic. After demonstratable Python code is working I would request that usability issues (UI Schema mapper, data migration/schema evolution tools, ZEO integration, multi-Storage uses) be addressed sooner than later. John On Monday 14 May 2001 10:47, Shane Hathaway wrote: Chris Withers wrote: Shane Hathaway wrote: I'm telling you there's a lot more you can do with the code that makes snip The next thing to do is to write a fishbowl proposal. This sounds cool but made my head hurt :-S Can you try and bring this back down to the level of us mere mortals by explaining how your OR stuff would let me take a table of data in an RDBMS table and have it appear as objects in the Management Inteferace? Sorry, this is at a pretty low level and I do need to explain it better. One would define an ObjectMappingSchema whose job it is to store and retrieve objects of a specific type and in a specific location. It would usually grab a database connection object to do its work. When loading, it would perform a query then manually put attributes into a persistent object. When storing, it would grab specific attributes from the persistent object and execute a statement to store those attributes. So let's say you want a ZODB to store and retrieve users in a specific table while putting everything else in pickles. You would create an instance of PickleSchema, which implements the ObjectMappingSchema interface, and tell it to manage everything *except* the users mapping in BasicUserFolder objects. You would tell it to store and retrieve this object using your UserFolderSchema instead. Your UserFolderSchema would store and retrieve the users from the USERS and USER_PREFS tables. The user table wouldn't require the use of OIDs but would require unique user IDs. So in the management interface nothing would change. Nor would the application-level Python code. You would only define a layer that maps objects to a relational database. You would still see the user folder as you do now. Now, it may be useful to provide a management interface for defining the schema mapping. I haven't approached that yet; AFAICT this is where the work done on SmartObjects and DBObjects would be very useful. Initially I was planning for people to code the mapping purely in Python so we could gain experience and find common patterns before inventing a UI. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] External transaction integration bug?
I can't directly address the concerns you've raised, but for my project I have rewritten TM.py to work better within the begin/vote/finish/abort protocol framework. I've also added more documentation. John Randall F. Kern wrote: I may just be missing something obvious here, but it seems like there is a hole in ZODB.Transaction.Transaction.commit and Shared.DC.ZRDB.TM.TM, that can cause external transactions (those that use the TM mixin class, like psycopg) to be abandoned (never get committed or rolled back). Let's say somewhere around line 300 in Transaction.py (the call to j.commit(o, self)) we get an exception. Furthermore, let's say the TM derived database object has already been committed (the only effect of which is to move the DB into the jars mapping, since TM.tpc_begin() and TM.commit() both do nothing). The exception dumps us down to about line 353, where we call _p_jar.abort() on all the uncommitted objects (note: it's important that the database connection isn't in this list, because TM.abort() will rollback the transaction. the way we keep the db out of this list is by having it appear in objects _before_ the object that failed the commit). Next we reach line ~366, where we should "unwind TPC for the jars that began it". What this means is calling tpc_abort() on each jar from the objects that were already committed (which includes the database). However, TM.tpc_abort() does nothing, leaving the external database transaction open. Does this make sense? If this makes sense (i.e. seems bad :), does catching tpc_abort() in TM and calling TM.abort() seem like a valid fix? Thanks, -Randy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ## # # Zope Public License (ZPL) Version 1.0 # - # # Copyright (c) Digital Creations. All rights reserved. # # This license has been certified as Open Source(tm). # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions are # met: # # 1. Redistributions in source code must retain the above copyright #notice, this list of conditions, and the following disclaimer. # # 2. Redistributions in binary form must reproduce the above copyright #notice, this list of conditions, and the following disclaimer in #the documentation and/or other materials provided with the #distribution. # # 3. Digital Creations requests that attribution be given to Zope #in any manner possible. Zope includes a "Powered by Zope" #button that is installed by default. While it is not a license #violation to remove this button, it is requested that the #attribution remain. A significant investment has been put #into Zope, and this effort will continue if the Zope community #continues to grow. This is one way to assure that growth. # # 4. All advertising materials and documentation mentioning #features derived from or use of this software must display #the following acknowledgement: # # "This product includes software developed by Digital Creations # for use in the Z Object Publishing Environment # (http://www.zope.org/)." # #In the event that the product being advertised includes an #intact Zope distribution (with copyright and license included) #then this clause is waived. # # 5. Names associated with Zope or Digital Creations must not be used to #endorse or promote products derived from this software without #prior written permission from Digital Creations. # # 6. Modified redistributions of any form whatsoever must retain #the following acknowledgment: # # "This product includes software developed by Digital Creations # for use in the Z Object Publishing Environment # (http://www.zope.org/)." # #Intact (re-)distributions of any official Zope release do not #require an external acknowledgement. # # 7. Modifications are encouraged but must be packaged separately as #patches to official Zope releases. Distributions that do not #clearly separate the patches from the original work must be clearly #labeled as unofficial distributions. Modifications which do not #carry the name Zope may be packaged in any form, as long as they #conform to all of the clauses above. # # # Disclaimer # # THIS SOFTWARE IS PROVIDED BY DIGITAL CREATIONS ``AS IS'' AND ANY # EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR # PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL DIGITAL CREATIONS OR ITS
Re: [Zope-dev] FTP interface being worked on?
ur immediate need (which is to allow a distributed team of developers to share code and track changes via a central CVS repository), maybe it makes the most sense just to segment the existing XML export into directories and files and enhance the existing import to allow overwriting objects. b) A hybrid XML and custom dump solution. An Image for example could dump out as a binary image file with meta-data in a similiarly name XML file. Yes, each object should make its own policy regarding its body. Its metadata format should be standardized, however. I like this idea. After I have the XML export/import working in a way that fits better with CVS (even if the sreialized representation is essentially a black box), then I can tackle how each object represents its body in a "morally plain text" serialized format. I want to add here that it may be very useful to not specify that any object have only one serial format separate from the XML default. Specifically it might make it an easier problem if the author of the export code for a type of object can dump property "x" as object-name-x.format and property "y" as object-name-y.format For example instead of just: | -- foo_page.xml -- foo_page.dtml it might be useful to have arbitrary other files created when foo_page is dumped: | -- foo_page.xml -- foo_page.dtml -- foo_page-description.txt This would imply that the description property is not captured in the foo_page.xml,but instead the easier to use text file. I'm worried about the parsing complexity when trying to build a single "morally plain text" serialized format, and I think that "morally plain" can be applied at a sub-object level to make it easier to work with. The example that comes to mind it Image: | -- icon.xml -- icon.png -- icon-description.txt The "morally plain" output here would be binary, not text. A single output file would be hard pressed to allow binary and text editing in the same file. John -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FTP interface being worked on?
Chris McDonough wrote: I think there is really only one issue nobody has been able to sort out: do we want the objects to be actually stored on the filesystem or do we want to be able to mirror a ZODB? Or do we want both? My conception of it is that objects won't be served from the filesystem, but just put in a editable serialized format for version control and tool purposes. How useful/difficult would it be to put the SMB protocol on top of a ZEO server? As serialized formats are build, would this be useful to anyone? Another use for this that I think would be great for is schema migration. Right now with ZODB we can have custom __setstate__() methods that do schema migration, but being able to perform text processing changes with common tools would be great. Just thinking out loud... Nobody wants to edit XML, AFAICT. Careful, that's a religious issue in some circles. :-) I know of many people who prefer that data be stored in XML just because humans can read and change it if the need arises. (This from a guy who has actually edited ZODB XML export files. :-) Eek. ;-) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FTP interface being worked on?
mmand line). If you want a lossless "morally binary" representation, it's probably best to use XML export, which is great for your purposes, because it already exists! ;-) I've heard it said that all progress is due to the unreasonable man. So to do my part for progress, what I want is a lossless "morally plain text" representation. ;-) If the existing XML export really was great for our purposes, I'd be done! The problem is that everything comes out in one big monolithic file. That's not good for project management using CVS. (At least, as far as I can tell.) I think there is the potential for a really good solution that solves our need to manage our project via CVS, and to solve the greater need to enhance the Zope management interface to support tools that work with filesystem objects. I am about to jump into this project next week. I do want to stay in touch with anyone who is working on similar projects, so please keep in touch! I will post reports as I make progress in case anyone is interested. Thanks, Fred -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] is there a hook for before the transaction is committed
Hi Tim, I have two suggestions, I hope one of them helps. 1) Attached is a TM.py file that I wrote based on the one you mention below. I've tried to make it more obvious and better documented. 2) Don't use this kind of functionality, but rather use sub-transaction commits. The first suggestion has more overhead than what I assume you would need, but the second one won't work for all situations. A Fishbowl proposal of mine, HashingSupport, was going to use the same kind of hook you are asking about. In this case though, using sub-transaction commits made a lot more sense. In general though, I think that _v_* attributes pose a non-trivial problem that probably requires a hook on abort() if not commit() as well. John Tim McLaughlin wrote: Is there a hook for before the transaction is committed for objects which subclass Persistent? I found __inform_commit__ for a "registered" object, but I can't seem to get that to work as I thought it did. I also tried subclassing TM like a DA, but to no avail. TIA, Tim ___ Tim McLaughlinBCSwebservices.net Director, Technical Group 1950 Old Gallows Road tel: (703) 790.8081 x111 Suite 201 [EMAIL PROTECTED]Vienna, VA 22182 www .bcswebservices. net ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ## # # Zope Public License (ZPL) Version 1.0 # - # # Copyright (c) Digital Creations. All rights reserved. # # This license has been certified as Open Source(tm). # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions are # met: # # 1. Redistributions in source code must retain the above copyright #notice, this list of conditions, and the following disclaimer. # # 2. Redistributions in binary form must reproduce the above copyright #notice, this list of conditions, and the following disclaimer in #the documentation and/or other materials provided with the #distribution. # # 3. Digital Creations requests that attribution be given to Zope #in any manner possible. Zope includes a "Powered by Zope" #button that is installed by default. While it is not a license #violation to remove this button, it is requested that the #attribution remain. A significant investment has been put #into Zope, and this effort will continue if the Zope community #continues to grow. This is one way to assure that growth. # # 4. All advertising materials and documentation mentioning #features derived from or use of this software must display #the following acknowledgement: # # "This product includes software developed by Digital Creations # for use in the Z Object Publishing Environment # (http://www.zope.org/)." # #In the event that the product being advertised includes an #intact Zope distribution (with copyright and license included) #then this clause is waived. # # 5. Names associated with Zope or Digital Creations must not be used to #endorse or promote products derived from this software without #prior written permission from Digital Creations. # # 6. Modified redistributions of any form whatsoever must retain #the following acknowledgment: # # "This product includes software developed by Digital Creations # for use in the Z Object Publishing Environment # (http://www.zope.org/)." # #Intact (re-)distributions of any official Zope release do not #require an external acknowledgement. # # 7. Modifications are encouraged but must be packaged separately as #patches to official Zope releases. Distributions that do not #clearly separate the patches from the original work must be clearly #labeled as unofficial distributions. Modifications which do not #carry the name Zope may be packaged in any form, as long as they #conform to all of the clauses above. # # # Disclaimer # # THIS SOFTWARE IS PROVIDED BY DIGITAL CREATIONS ``AS IS'' AND ANY # EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR # PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL DIGITAL CREATIONS OR ITS # CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDI
Re: [Zope-dev] is there a hook for before the transaction is comm itted
Hi Tim, I'm glad that worked for you. I think _vote() is the right place to do what you want. See my reply to Steve Alexander for my comments on _v_* attributes. John Tim McLaughlin wrote: In what respect are the _v_* attribs gonna cause problems. My guestimate was that they disappeared upon transaction commit/abort. I'm also not sure as to why I would need subtrans since I'm only messing with properties of the object. To my knowledge, subtrans are only necessary to conserve resources. Anyway, what you gave me works! Thanks. It seems I need to override the _vote method (since it is only called once and allows exceptions). As to the other stuff, I'm sure you can enlighten me further as to why. I appreciate the help. Cheers. Tim -Original Message- From: John D. Heintz [mailto:[EMAIL PROTECTED]] Sent: Monday, March 05, 2001 12:45 PM To: Tim McLaughlin Cc: '[EMAIL PROTECTED]' Subject: Re: [Zope-dev] is there a hook for before the transaction is committed Hi Tim, I have two suggestions, I hope one of them helps. 1) Attached is a TM.py file that I wrote based on the one you mention below. I've tried to make it more obvious and better documented. 2) Don't use this kind of functionality, but rather use sub-transaction commits. The first suggestion has more overhead than what I assume you would need, but the second one won't work for all situations. A Fishbowl proposal of mine, HashingSupport, was going to use the same kind of hook you are asking about. In this case though, using sub-transaction commits made a lot more sense. In general though, I think that _v_* attributes pose a non-trivial problem that probably requires a hook on abort() if not commit() as well. John Tim McLaughlin wrote: Is there a hook for before the transaction is committed for objects which subclass Persistent? I found __inform_commit__ for a "registered" object, but I can't seem to get that to work as I thought it did. I also tried subclassing TM like a DA, but to no avail. TIA, Tim ___ Tim McLaughlin BCSwebservices.net Director, Technical Group1950 Old Gallows Road tel: (703) 790.8081 x111Suite 201 [EMAIL PROTECTED] Vienna, VA 22182 www .bcswebservices. net ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] is there a hook for before the transaction is committed
Hi Steve, ZPatterns is something that is very high on my must investigate list, but I am not doing Zope development, but rather ZODB based development. I'm sure that I can still get lots of good ideas though... My comment below about _v_* attributes is primarily about not using functionality like Keeper or TM, but rather just taking advantage of _v_* attributes for caching purposes. What I would want from caching, volatile variables is to reset only when the object, or more safely the session, has conflicted and needs to be reset. I wouldn't want to take the performance hit for the cases where I have only successful commits on the same Connection cache of objects. In that case I would needlessly be reseting my volatile cache. In our code we are overriding _p_deactivate() like this: def __p_deactivate__(self): temp = _v_something Persistent.__p_deactive__(self) _v_something We are only doing this for instance vars that are not sensitive to commit/abort cycles. I think that the ideal situation would allow the volative cache to be reset only in the case of a Conflict, i.e. abort() There are two scopes that this can happen at: 1) The _v_* vars that are only local to the Persistent object that they are defined within. This would be a __p_reset__() method or something that is called by the ZODB Connection mechanism. 2) Session wide, i.e. _v_* vars that are dependent on multi-object state but happen to be stored on one of the Persistent objects. This would be handled by Keeper or TM like solutions. Anyway, this is just my current mental state dump. ;-) Thanks, John Steve Alexander wrote: John D. Heintz wrote: Hi Tim, I have two suggestions, I hope one of them helps. 1) Attached is a TM.py file that I wrote based on the one you mention below. I've tried to make it more obvious and better documented. 2) Don't use this kind of functionality, but rather use sub-transaction commits. The first suggestion has more overhead than what I assume you would need, but the second one won't work for all situations. A Fishbowl proposal of mine, HashingSupport, was going to use the same kind of hook you are asking about. In this case though, using sub-transaction commits made a lot more sense. In general though, I think that _v_* attributes pose a non-trivial problem that probably requires a hook on abort() if not commit() as well. Take a look at ZPatterns; specifically, the classes Keeper and Kept from ZPatterns/Transactions.py You can see examples of how they are used in DataSkins.py and Rack.py, although there really isn't much to it. I've included the docstrings below. class Keeper: """Resets an object's per-transaction cache attributes at txn boundaries Note that Keepers are created by Kept objects semi-automatically, and there is usually no need to create one manually. A Keeper automatically registers itself with the Zope transaction upon creation, and instructs its Kept client to clear its per-transaction cache at all transaction boundaries. Keeper methods are called only by the Zope transaction, so don't mess with them.""" class Kept(Base): """Thing which has a Keeper to clear its per-transaction cache. Objects derived from Kept should reference the 'self._v_Keeper' attribute whenever they need to flag that they have made changes to their cache that would require it to be cleared. (Note that '_v_Keeper' is an *attribute*, not a method, and so should not be called, just referenced.) Once this has been done, the next transaction state transition that occurs (sub/main transaction commit or abort) will cause the object's Keeper to call for a cache reset. Subclasses of Kept should define a '__per_transaction_cache_attrs__' attribute as a sequence of attributes which they would like to have deleted from their '__dict__' at reset time. """ -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Storing part of an object on the file system
Andy, I'm just checking an assumption that I'm making about the Ext* Products: They do no work out of the box with ZEO, right? That is, they would require some sort of shared network drive for all ZEO clients to functions correctly. Thanks, John Andy McKay wrote: Actually just follow up I realised I never told you how I solved this problem. I compacted all data types into File, Image or DTML Document. Since I had ExtFile and ExtImage I chopped those into one class called it ExtThing, and the wrote classes off it. ExtFile and ExtImage I cut and pasted (not complete) for the most part. Then I wrote a class that called ExtHTML that is a DTML Document that overrides the munge() and read() read functions. Instead I passed those onto ExtThing. And there you go a DTML Document that has the main body stored on the local file system. Thanks McGregor. -- Andy McKay. - Original Message - From: "Andy McKay" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 08, 2001 4:15 PM Subject: [Zope-dev] Storing part of an object on the file system Ok whack idea #34... Well sort of, the idea was sparked by ExtFile (yes its all his fault honest). We want to have files on the file system for many reasons which I won't go into now, just take it for granted. But we also want some of the objects information to be in the standard data.fs, so we can catalog it use acquisition provide a simple interface to it and so on. So far you are saying thats ExtFile and you are right. But we want to extend it to any object anywhere, instead of storing the data attribute in the object and pickling it in the ZODB I want to be able to store the data attribute on the file system. This gives us loads of advantages we also thought this would be extremely useful to other people. We've bounced around ideas on how to do this and here the only two so far: -we could overload the data attribute with a class that on Pickling into the ZODB instead writes it on to the filesystem... -we could in the ZODB put a hack to say if pickling something with so and so attribute do this instead... I feel like this something I should just not be doing, but it would be great if I could get it work... -- Andy McKay. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Q: Specialists, Racks, and ZCatalogs?
Wow, it's fun to hear people talking about Catalysis! Catalysis is an analysis and design methodology that focuses on components and frameworks. It stresses being able to specify component interactions with invariants, pre/post conditions, and supporting graphics. The book, "Objects, Components, and Frameworks with UML" by Desmond D'Souza and Alan Wills is no light read, but well worth it. Composing multiple frameworks together with package substitutions is really cool. ;-) We are actually combining the analysis precision from Catalysis with the code focus from XP and having really good success. John "who worked for Desmond in past life" Heintz Johan Carlsson wrote: ... When you're thinking about a system, it is often helpful to think about just a part of the system rather than the system as a whole. To do this, you define a limited "scope" around a particular subsystem. In this case, an Actor represents the role something from outside your subsystem plays when interacting with something inside your subsystem. The "something" can be an object, a person, a separate computer system, a corporation... Thanks Steve, You cleared up my confusion. How should I look at roles in ZPatterns? This is all standard object-oriented stuff, and is not specific to ZPatterns. Get the Coad book, read it, and things should get clearer :-) It's on my ToReadList :-) Also, the Catalysis method puts an emphasis on defining interactions and collaborations between objects in terms of roles. You might want to take a look at that. Is Catalysis method a pattern in Coads book? Regards, Johan Carlsson ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope] Re: [Zope-dev] ANNOUNCE: Zope 2.3.0 beta 3 released - Plea for bug #1884
Zope-maintainers, Please evaluate the patch in bug #1884. There is an ExtensionClass.c bug in CMethod_call that prevents calling unbound super-class methods when the __call_method__ hook exists. http://classic.zope.org:8080/Collector/1884/view thanks, John Brian Lloyd wrote: Hi all, Zope 2.3.0 beta 3 is now available. You can download it from Zope.org: http://www.zope.org/Products/Zope/2.3.0b3/ This beta contains fixes for various issues reported to date in the beta cycle, and some older Collector bugs. Barring any major unforseen problems, this will be the last 2.3 beta release. For more information on what is new in this release, see the CHANGES.txt and HISTORY.txt files for the release: - http://www.zope.org/Products/Zope/2.3.0b3/CHANGES.txt - http://www.zope.org/Products/Zope/2.3.0b3/HISTORY.txt Brian Lloyd[EMAIL PROTECTED] Software Engineer 540.371.6909 Digital Creations http://www.digicool.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope-dev] How would I keep _v_* attributes from getting thrown away?
Thanks for the warning Dieter, but I'm managing threads/connections/sessions/POAs and a few other things already to expose ZODB objects through CORBA sessions. I wanted the _v_* attributes to live for the life of the DB Connections. Last night I found a fix for the bug that prevented me from overriding the _p_deactivate() method on Persistent objects, so I think that I will just do this: class ... def _p_deactivate(self): temp_position = self._v_position Persistent._p_deactivate(self) self._v_position = temp_position Thanks for the help though. John Dieter Maurer wrote: John D. Heintz writes: I am using ZODB along with CORBA to expose peristent objects. Some of my objects have per-connection/session state. ... My initial idea is to have a _v_position attribute ... Using "_v_" attributes for session state is a very bad idea. They are thread(!) local and not session local. This means, if a following request of your user (in the same session) happens to get assigned a different thread, it will read and update a different position. Chaos is garanteed (though you will see it only, if your site is loaded). Use a session product (- zope.org) for session data. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Better test case for Bug 1783: Persistent __call_method__() interferes with __getstate__
Hello all,
The following is the best test case I have so far for bug 1783.
The behavior of the bug is that no CMethods from Persistent can be
called indirectly when the __call_method__ hook is present. This means
that I can't override any of __getstate__, __setstate__, _p_deactivate.
#!/usr/bin/python
import ZODB
from Persistence import Persistent
class P(Persistent):
def __call_method__(self, meth, methArgs, methKW={}):
return apply(meth, methArgs, methKW)
p = P()
p.__getstate__()
#This throws exception!
Persistent.__getstate__(p)
TypeError: function requires exactly 0 arguments; 1 given
--
. . . . . . . . . . . . . . . . . . . . . . . .
John D. Heintz | Senior Engineer
1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | [EMAIL PROTECTED]
w w w . d a t a c h a n n e l . c o m
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] How would I keep _v_* attributes from getting thrown away?
Hello all, I am using ZODB along with CORBA to expose peristent objects. Some of my objects have per-connection/session state. The clear example is file-like objects - effectively exposing persistent StringIO objects through CORBA. The issue is that I want multiple clients to be able to read() iterate over the same file-like corba objects. My initial idea is to have a _v_position attribute that is unique for each Connection cache object and maintains the correct position in the StringIO for each session. I obviously wouldn't want this to be a persistent attribute because a spurious commit would put it into the db and mess up any other users iterating through the same object from a different session. A volatile attribute, _v_position, however can be destroyed at any time with a cache cleanup via deactivate() call. How do I maintain volatile, but per connection stable, attributes on persistent objects? I thought about overriding the _p_deactivate() method, but I am also defining the __call_method__() hook and am bound by Bug 1783 that prevents this kind of thing. My thoughts on building this into cPersistent.c after looking through the code is to provide special processing to not remove some special attributes that also don't get saved into the db. Two ideas come to mind for this: 1) define _vs_* as volatile stable that is neither persisted nor clear()ed. This would slow down the deactivate() method though. 2) define _v_stable as a special volatile that doesn't go away. This would be quick processing in deactivate() and could be a dictionary to account for many stable volatile attributes. Thanks for any help, John -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Announcing ZODB-Corba code release
Here is the first release of code that exposes a ZODB database through CORBA (omniORB). The code is functioning, the docs are sparse, and it should work on your machines. ;-) I am only going to be in town for the next two days, then I will be unavailable until Jan 1. See http://www.zope.org/Members/jheintz/ZODB_CORBA_Connection to download the code. It's not perfect, but it works for me. Enjoy, John -- .. . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Bug reports, feature requests, etc. go in the ZEO Tracker: http://www.zope.org/Products/ZEO/Tracker Conversations etc. can take place in the Wiki: http://www.zope.org/Products/ZEO/Wiki Zope-ZEO maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-zeo ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Significance of the ZODB split?
The Sourceforge exposure gives people like me with an itch to scratch a place to work on a publicly visible branch of ZODB for my two proposals without breaking anything or relying on patch files continually. John Heintz PS My proposals are ExplicitTransactions and PersistentBlob ;-) Michel Pelletier wrote: On Fri, 8 Dec 2000, Robin Becker wrote: Anyone know why AM Kuchling needs to split off a Sourceforge project based on ZODB? I don't think it's a "split", but AMK is using ZODB internally at his job, and externally with his own projects, so I can see him wanting to have some control over the distribution that he uses. Other than that, there could be other reasons, we, for example, do not provide a mechanism for community checkin privledges, Sourceforge does. I don't think we have a ZODB specific mailing list, sourceforge offers this. That being said, I'm pretty sure we've allways kept up with Andrew's patches and suggestions, and we'd be happy to create a mailing list. Andrew has also extended any developer at DC checkin privledges at the sourceforge project; although I suspect we'll just continue to check into our CVS and he'll "sync" with us that which he wants. I am, in particular, barely not lazy enough to check stuff into branches, much less whole other repositories. ;) I really liked the ZEO examples, but where's this going? It's just open source. More power to him in my opinion. He's definatly taking Zope and ZEO to new levels and audiences. -Michel ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) -- . . . . . . . . . . . . . . . . . . . . . . . . John D. Heintz | Senior Engineer 1016 La Posada Dr. | Suite 240 | Austin TX 78752 T 512.633.1198 | [EMAIL PROTECTED] w w w . d a t a c h a n n e l . c o m ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CORBA-ZODB: Is replacing global get_transaction() the only way...
Connection is always associated with one Transaction. If this assumption is true, then it should be safe to make the change I'm proposing. If not, then I need to understand why so that I can rethink how to solve my problem. ;-) I hope that I've made my problems and ideas for solutions clear, if not please let me know. I dunno. You'll probably be able to tell from my response. :) Only the difference between thread/Connection/transaction per request versus exposing the same cached object across multiple CORBA requests. Also, I think that I should be able to make the changes to ZODB myself within the next few week, but only if there is the _possibility_ of folding them back into the main Zope codebase. I sincerely hope that no ZODB changes are necessary. This is, in Python, the changes to Persistent that I feel would solve my problem. I think that in general this code would allow multiple thread to modify ZODB objects while still keeping the right transaction up to date. import ZODB from Persistence import Persistent class TestPersistent(Persistent): self __changed__(self): "Completely ignoring self-state from c code..." if self._p_jar: self._p_jar.transaction.register(self) and then in DB.py the open() method must add a transaction attribute to the connection before returning. I've got one more question. What happens if I: - make a connection to a database - navigate to some objects and store references to them - make some changes to these objects - call get_transaction().abort() - make some changes to the same objects (that I have references to) - call get_transaction().commit() Will everything do what I expect in this case? Thanks so much for you time, John Heintz Thanks for any help, John D. Heintz CORBA Threading description: CORBA defines the POA, which has two standard threading policies: ORB Controlled Model Single Threaded Model The POA is basically a controller for requests to one or more distributed objects, with thread policy as one of its parameters. The first threading policy means whatever the ORB gives you - single or multi, and you have to deal with all synchronizations. The second I consider a mis-nomer because there can be many threads, but only one at a time will access objects for a given POA. (This is the model that I perceive being used by default for ZODB object from a specific Connection.) No. Multiple threads can be accessing the same logical object. Each thread has it's own copy (and DB connection and transaction). Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! Technical Director (888) 344-4332http://www.python.org Digital Creationshttp://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. -- John D. Heintz DataChannel, Inc. Senior Engineer 512-633-1198 [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Only using ZODB, not Zope Re: New Proposal: PersistentBlob
Hi Greg, Thanks for the pointer. I briefly looked at this Product and the CVSMixin Product as well, but have one requirement that unfortunately I _didn't_ explain clearly in my proposal. I am not using Zope, only the ZODB so a Zope Product will not help me. My first goal with the proposal was to get feedback on if my idea is correct and what implementation problems could occur, i.e. transactions and file locking. My second goal is to inspire someone to implement it and merge it into the official ZODB. I think that the idea has enough merit and could be useful for a large number of applications. We might have the time and need to implement PersistentBlob ourselves, but I can't say for sure now. Thanks all, John Gregor Heine wrote: Hi all, Yesterday I put up a new proposal on the http://dev.zope.org site that documents my vision of PersistentBlob. The main idea is the be able to mark blocks of strings (text or binary) content for storage in a file system as individual files. (Or blobs in a relation table.) The two motivations for this are keeping a ZODB FileStorage small and exposing blocks of string content to external processes (i.e. full-text indexing). Thanks for taking a look. John Hi John! Have you had a look at the ExtFile Product (http://www.zope.org/Members/MacGregor/ExtFile)? It basically does all the things you want to achive with the PersistentBlob (i.e. storing files externally and making them accessible for external processes), except that it's not that deeply integrated into the Zope machinery and stores the files only in the file system and not in an RDBMS (which nevertheless could be implemented). Cheers, Gregor! -- John D. Heintz DataChannel, Inc. Senior Engineer 512-633-1198 [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] New Proposal: PersistentBlob
Hi all, Yesterday I put up a new proposal on the http://dev.zope.org site that documents my vision of PersistentBlob. The main idea is the be able to mark blocks of strings (text or binary) content for storage in a file system as individual files. (Or blobs in a relation table.) The two motivations for this are keeping a ZODB FileStorage small and exposing blocks of string content to external processes (i.e. full-text indexing). Thanks for taking a look. John -- John D. Heintz DataChannel, Inc. Senior Engineer 512-633-1198 [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
