[Zope-dev] Re: [ZODB-Dev] [Warning] Zope/ZEO clients: subprocesses can lead to non-deterministic message loss
On Fri, Jun 25, 2004 at 07:23:19PM +0200, Dieter Maurer wrote: > ATTENTION: Crosspost -- Reply-To set to '[EMAIL PROTECTED]' > > Today, I hit a nasty error. > > The error affects applications under Unix (and maybe Windows) which > > * use an "asyncore" mainloop thread (and maybe other asyncore applications) > > Zope and many ZEO clients belong to this class > > and > > * create subprocesses (via "fork" and "system", "popen" or friends if > they use "fork" internally (they do under Unix but I think not > under Windows)). Hm. this applies to external methods and product code that makes these calls? -- Paul Winkler http://www.slinkp.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] RE: [ZODB-Dev] [Warning] Zope/ZEO clients: subprocesses can lead tonon-deterministic message loss
[Dieter Maurer] > ATTENTION: Crosspost -- Reply-To set to '[EMAIL PROTECTED]' Which I've honored. > Today, I hit a nasty error. > > The error affects applications under Unix (and maybe Windows) which > > * use an "asyncore" mainloop thread (and maybe other asyncore > applications) > > Zope and many ZEO clients belong to this class Note a possible complication: ZEO monkey-patches asyncore, replacing its loop() function with one of its own. This is done in ZODB's ThreadedAsync/LoopCallback.py. > and > > * create subprocesses (via "fork" and "system", "popen" or friends if > they use "fork" internally (they do under Unix but I think not > under Windows)). It may be an issue under Cygwin, but not under native Windows, which supports no way to clone a process; file descriptors may get inherited by child processes on Windows, but no code runs by magic. > The error can cause non-deterministic loss of messages (HTTP requests, > ZEO server responses, ...) destined for the parent process. It also can > cause the same output to be send several times over sockets. > > The error is explained as follows: > > "asyncore" maintains a map from file descriptors to handlers. > The "asyncore" main loop waits for any file descriptor to > become "active" and then calls the corresponding handler. There's a key related point, though: asyncore.loop() terminates if it sees that the map has become empty. This appears to have consequences for the correctness of workarounds. For example, this is Python's current asyncore loop (the monkey-patched one ZEO installs is similar in this respect): def loop(timeout=30.0, use_poll=False, map=None): if map is None: map = socket_map if use_poll and hasattr(select, 'poll'): poll_fun = poll2 else: poll_fun = poll while map: poll_fun(timeout, map) If map becomes empty, loop() exits. > When a process forks the complete state, including file descriptors, > threads and memory state is copied and the new process > executes in this copied state. > We now have 2 "asyncore" threads waiting for the same events. Sam Rushing created asyncore as an alternative to threaded approaches; mixing asyncore with threads is a nightmare; throwing forks into the pot too is a good working definition of hell . > File descriptors are shared between parent and child. > When the child reads from a file descriptor from its parent, > it steals the corresponding message: the message will > not reach the parent. > > While file descriptors are shared, memory state is separate. > Therefore, pending writes can be performed by both > parent and child -- leading to duplicate writes to the same > file descriptor. > > > A workaround it to deactivate "asyncore" before forking (or "system", > "popen", ...) and reactivate it afterwards: as exemplified in the > following code: > > from asyncore import socket_map > saved_socket_map = socket_map.copy() > socket_map.clear() # deactivate "asyncore" As noted above, this may (or may not) cause asyncore.loop() to plain stop, in parent and/or in child process. If there aren't multiple threads, it's safe, but presumably you have multiple threads in mind, in which case behavior seems unpredictable (will the parent process's thread running asyncore.loop() notice that the map has become empty before the code below populates the map again? asyncore.loop() will or won't stop in the parent depending on that timing accident). > pid = None > try: > pid = fork() >if (pid == 0): ># child ># ... > finally: > if pid != 0: >socket_map.update(saved_socket_map) # reactivate "asyncore" Another approach I've seen is to skip mucking with socket_map directly, and call asyncore.close_all() first thing in the child process. Of course that's vulnerable to vagaries of thread scheduling too, if asyncore is running in a thread other than the one doing the fork() call. ___ 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: CatalogBrains since Zope2.7.1b1
On Fri, 25 Jun 2004 20:26:30 +0200 Dieter Maurer <[EMAIL PROTECTED]> wrote: > Casey Duncan wrote at 2004-6-25 09:36 -0400: > >On Thu, 24 Jun 2004 19:04:55 +0200 > >Dieter Maurer <[EMAIL PROTECTED]> wrote: > > ... > >> I think, you should only require access rights to the object itself > >> and not to all folders from the root to the object. > > ... > >> That ZCatalog identifies objects by physical path is an > >implementation> artifact. It should not make it impossible to access > >an> object via the catalog that otherwise can be accessed without > >> problem. > >> > >> > ... > >> >For hysterical raisins, REQUEST.traverse() does not behave this > >way.> >It instead checks only the final object traversed. > >> That's a good behaviour... > > > >Except when it isn't ;^) OTOH it is closer to the behavior of > >getObject in 2.7.0. Ironically it used to use restrictedTraverse long > >ago... > > Have you gotten the main argument? Yes, I intend to change it to use unrestrictedTraverse and then validate the returned object. So there... 8^P -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] [Warning] Zope/ZEO clients: subprocesses can lead to non-deterministic message loss
ATTENTION: Crosspost -- Reply-To set to '[EMAIL PROTECTED]' Today, I hit a nasty error. The error affects applications under Unix (and maybe Windows) which * use an "asyncore" mainloop thread (and maybe other asyncore applications) Zope and many ZEO clients belong to this class and * create subprocesses (via "fork" and "system", "popen" or friends if they use "fork" internally (they do under Unix but I think not under Windows)). The error can cause non-deterministic loss of messages (HTTP requests, ZEO server responses, ...) destined for the parent process. It also can cause the same output to be send several times over sockets. The error is explained as follows: "asyncore" maintains a map from file descriptors to handlers. The "asyncore" main loop waits for any file descriptor to become "active" and then calls the corresponding handler. When a process forks the complete state, including file descriptors, threads and memory state is copied and the new process executes in this copied state. We now have 2 "asyncore" threads waiting for the same events. File descriptors are shared between parent and child. When the child reads from a file descriptor from its parent, it steals the corresponding message: the message will not reach the parent. While file descriptors are shared, memory state is separate. Therefore, pending writes can be performed by both parent and child -- leading to duplicate writes to the same file descriptor. A workaround it to deactivate "asyncore" before forking (or "system", "popen", ...) and reactivate it afterwards: as exemplified in the following code: from asyncore import socket_map saved_socket_map = socket_map.copy() socket_map.clear() # deactivate "asyncore" pid = None try: pid = fork() if (pid == 0): # child # ... finally: if pid != 0: socket_map.update(saved_socket_map) # reactivate "asyncore" -- 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: CatalogBrains since Zope2.7.1b1
Casey Duncan wrote at 2004-6-25 09:36 -0400: >On Thu, 24 Jun 2004 19:04:55 +0200 >Dieter Maurer <[EMAIL PROTECTED]> wrote: > ... >> I think, you should only require access rights to the object itself >> and not to all folders from the root to the object. > ... >> That ZCatalog identifies objects by physical path is an implementation >> artifact. It should not make it impossible to access an >> object via the catalog that otherwise can be accessed without >> problem. >> >> > ... >> >For hysterical raisins, REQUEST.traverse() does not behave this way. >> >It instead checks only the final object traversed. >> That's a good behaviour... > >Except when it isn't ;^) OTOH it is closer to the behavior of getObject >in 2.7.0. Ironically it used to use restrictedTraverse long ago... Have you gotten the main argument? That ZCatalog identifies objects by physical path is an implementation artifact. It should not make it impossible to access an object via the catalog that otherwise can be accessed without problems. When you implement "getObject" via "restrictedTraverse", then you let "getObject()" fail for some objects that *are* accessible by the current user (because this access need not to use the complete path from the root). Do not do that! -- 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] Specific Qs about diffs btw Zope 3 & Zope 2.x (2.7, etc)
On Fri, Jun 25, 2004 at 09:38:15AM -0500, Eric Hielscher wrote: > The project involves a web page where users can upload files of a > specific format (zipped SCORM-conformant e-learning files to be exact). > The system would then rip out all of the meta data and perhaps the full > text of the files in the zip and index them for searching. If searching is important to your project, part of the answer depends on when you need to release your project. AFAIK the current zope X3 release (http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ZopeX3300b1 ) does not support indexing & searching at all. I have no idea when these features will be available. Quoting from ZopeX3/doc/CHANGES.txt: """ - We had an object hub service. The object hub service was responsible for: - Managing short ids for objects, useful for indexing - Keeping track of object locations. This was important when the object hub was created, because it wasn't practical to use direct object references. No it is, so hub ids are no-longer useful for implementing location-independent object references. The object hub service is dead. In the future, there will be a utility for use by indexes, that maintains short ids for objects. Perhaps this will be an indexing id service. The index and catalog machinery depend heavily on a facility for assigning shot ids to objects, currently the hub. Rather than trying to remove this dependency now, and ad it back later when we have an index-id utility, it makes more sense to just remove the index and catalog facilities for now. Later, when we create an index-id utility, we'll port the code, which will still be in the repository, back. """ -- Paul Winkler http://www.slinkp.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Specific Qs about diffs btw Zope 3 & Zope 2.x (2.7, etc)
Hi, I’m trying to decide which version of Zope would work best for a project on which I’ve been assigned to work. I’ve personally had no contact with Zope before yesterday when I downloaded 2.7.1 and 3.0.0b1 to start playing around a bit. The project involves a web page where users can upload files of a specific format (zipped SCORM-conformant e-learning files to be exact). The system would then rip out all of the meta data and perhaps the full text of the files in the zip and index them for searching. The MD is in XML, but we’d also perhaps like to support RDF and some others like RSS. Each file in the system would then be linked to the MD by some sort of GUID-equivalent. Then the users could search the MD and text and the system would return a results list, and afterward repackage their content. Now, I’ve been asked to decide which version of Zope would work better for this. I would think that native XML support (which I read will be better in 3 but don’t understand how yet) would be a huge plus. Also, the new ObjectHub replacement for the ZCatalog might really help me. Zope’s native authentication services have also been given a huge overhaul and we’d like to leverage those as well. I was hoping that someone out there with better in-depth knowledge of Zope would be able to read this list of reqs and be able to tell me in (semi-)detailed fashion just why 3 or 2.x would be a better decision. Thanks all for your help, Eric Hielscher ___ 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-dev list policies
On Fri, 25 Jun 2004 10:06:21 +0200 Godefroid Chapelle <[EMAIL PROTECTED]> wrote: [..] > I am administring plone-i18n mailing list. Non members cannot post. I > always post through gmane and my messages get accepted ! As long as posting from Gmane still works, then I'm fine with restricting postings to members. If we decide to go ahead I suggest restricting just one list first to see if there are issues. IMO zope-dev is a reasonable candidate for a trial list. -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: CatalogBrains since Zope2.7.1b1
On Thu, 24 Jun 2004 09:59:30 + Santi Camps <[EMAIL PROTECTED]> wrote: > "Security was tightened for getObject recently as part of a > general refactor of that code. I am happy to consider whether the > security is too tight, in which case it could be backed off a bit. > > Previously getObject performed no security checks and returned > objects for catalog results regardless of security permissions (it > used unrestrictedTraverse). I switched it to use > restrictedTraverse which checks security all the way down on all > of the containing folders and on the final object itself. This is > how path expressions work, for example." > > I think this new security checks could be a problem in some cases. > They are Ok when using restricted code, but from trusted code I'm not > sure that force to use restrictedTraverse could be considered a goal. That is a good point, however since getObject is not itself a protected method, and cannot tell whether it is being called by restricted code, it must always do its own checking. > For instance, imagin an application with employees of one department > managing dossiers with economic data inside. Employees of accounting > department shouldn't have access to these dossiers objects, but they > need to obtain some reports with a sum of all dossiers economic data. > So, accounting department users shouldn't have access to dossiers > objects, but from reports trusted code these dossiers need to > accessed. > > I think a possible solution could be an additional optional parameter > of .getobject used from trusted code when unrestrictedTraverse want to > be used. What do you think ? Optional arguments will still allow untrusted code to bypass security checks. Here are three solutions to this, two of which do not involve catalog changes: - Use a proxy role on the script that invokes getObject which grants the permissions needed. - Use self.unrestrictedTraverse(brain.getPath()) from trusted code - Add a private method: unrestrictedGetObject() to the catalog brain API which does no security checking, but is inaccessible to untrusted code. I think the last one is a good idea and I will implement it. The other two are available options for now. The problem is that if the existing getObject offers a mode to do no checking, it is conceivable for untrusted code to arrange for an object to be cataloged whos path actually points to an otherwise inaccessible object (granted a more likely senario is that the object is already cataloged). It could then find that catalog result, call getObject() and then pass it to the publisher to render it. This would allows a scripter to publish any object in Zope, because it effectively gives them a way to call unrestrictedTraverse. -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: CatalogBrains since Zope2.7.1b1
On Thu, 24 Jun 2004 19:04:55 +0200 Dieter Maurer <[EMAIL PROTECTED]> wrote: > Casey Duncan wrote at 2004-6-18 09:58 -0400: > > ... > >Security was tightened for getObject recently as part of a general > >refactor of that code. I am happy to consider whether the security is > >too tight, in which case it could be backed off a bit. > > I think, you should only require access rights to the object itself > and not to all folders from the root to the object. > > It is not uncommon that upper levels are more restricted than > subhierarchies. This is what Zope's URL traversal > allows: Only the object identified by URL traversal is > accessed checked. > > That ZCatalog identifies objects by physical path is an implementation > artifact. It should not make it impossible to access an > object via the catalog that otherwise can be accessed without > problem. > > > ... > >For hysterical raisins, REQUEST.traverse() does not behave this way. > >It instead checks only the final object traversed. > That's a good behaviour... Except when it isn't ;^) OTOH it is closer to the behavior of getObject in 2.7.0. Ironically it used to use restrictedTraverse long ago... -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: CatalogBrains since Zope2.7.1b1
On Sat, 19 Jun 2004 20:14:47 -0300 Leonardo Rochael Almeida <[EMAIL PROTECTED]> wrote: > On Wed, 16 Jun 2004 11:16:55 +0200 > > Eric Brun <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > Hi, > > > > > > I have a problem with 'getObject' method of CatalogBrains class on > > > Zope271b1 : it's return None. But with a Zope2.7.0 my object is > > > correctly find and returned. The permissions are right. > > > > Em Qua, 2004-06-16 às 11:28, Casey Duncan escreveu: > > getObject was refactored recently and its security was increased. It > > uses restrictedTraverse() now, which means that you need access to > > all of the enclosing folders as well as the object. Before, no > > security checking was performed by getObject. > > > > I suspect you do not have access to one of the containing folders. > > I certainly hope he'd get a permission error instead of silent 'None' > for '.getObject()' in this case or I'd consider it a bug :-) Me to, except that changing this behavior will break existing apps. There is an implicit contract the getObject should not raise errors. Perhaps this means we need a different method with better behavior. Somehow that doesn't seem all that appealing, however. -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] Email marketing
Email Marketing ! We offer you e-mail addresses databases for advertisement mailing; we sell databases also carry out mailing and hosting for the advertising projects. Products World Email Lists . Their validity and originality are verified. Details please go to our website Country or area total emails and price America 175 Million Email Address Europe 156 Million Email Address Asia 168 Million Email Address China(PRC) 80 Million Email Address HongKong 3.25 Million Email Address TaiWan 2.25 Million Email Address Japan 27 Million Email Address Australia 6 Million Email Address Canda 10 Million Email Address Russia 38 Million Email Address England 12 Million Email Address German 20 Million Email Address France 38 Million Email Address India 12 Million Email Address other Country or Area - Category Name total emails Apparel, Fashion, Textiles and Leather 4,654,565 Automobile & Transportation 6,547,845 Business Services 6,366,344 Chemicals 3,445,565 Computer & Telecommunications 654,655 Construction & Real Estate 3,443,544 Consumer Electronics 1,333,443 Energy, Minerals & Metals 6,765,683 Environment 656,533 Food & Agriculture 1,235,354 Gems & Jewellery 565,438 Health & Beauty 804,654 Home Supplies 323,232 Industrial Supplies 415,668 Office Supplies 1,559,892 Packaging & Paper 5,675,648 Printing & Publishing 6,563,445 Security & Protection 5,653,494 Sports & Entertainment 3,488,455 Toys, Gifts and Handicrafts 2,135,654 - ・All of Country email lists + email sender express +add url express + etrae express+Ebook - Send Your Ad to Millions 5 million bulk email 50 million bulk email 100 million bulk email 200 million bulk email Imagine emailing 500,000 recipients and 1 out of every 1000 orders your product, that's 500 new orders! * We go all-out to make sure our customers are completely satisfied * If any emails fail to make delivery, we replace them free of charge * 100% Spam free, rest assured you will not be accused of spamming * Almost all of our emails are sent to valid email addresses * No software required, we do all the mailing from our own server * Don't be fooled in signing up with similar sites offering services that cannot compare to ours * Get the most bang for your buck with bulk email advantage! - Details go to website Thank you! the silver star internet information company copyright・2004-2005 all reserved remove please email: [EMAIL PROTECTED] ___ 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 Collector issue #1384
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I just submitted issue #1384 to zope.org's collector but got this error message: Email notice error: '(110, 'Connection timed out')' Therefore i send the note of this collector issue to the dev list. See the issue at: http://zope.org/Collectors/Zope/1384 Cheers, ~ Simon *** snip *** len(LazyCat) doesnt work when tried to read more elements as in the LazyCat before: ~From time to time we had some problems with doing Zcatalog based OR searches. To do this we simply add one catalog result to the other. An addition of LazyMap's produces a LazyCat object. In some conditions our application raised "AttributeError: LazyCat instance has no attribute '_seq'". Today i looked into this in detail and found the problem in the LazyCat implementation. So the problem is that when you iterate over more LazyCat list elements that there are actually in the list an IndexError is raised. This is fine of course. But afterwards you are no longer able to get the length of this LazyCat, because the error above is raised. You need to read the length of a LazyCat _before_ you have code which probably could raise an IndexError of this list. To test this behavior use the following script on a ZCatalog: """ catalog = context.portal_catalog res1 = catalog(SearchableText="admin") res2 = catalog(SearchableText="icoya") res = res1 + res2 for x in range(6): ~try: print "x", x, res[x] ~except: pass print "len", len(res) return printed """ In this case the real length of the res LazyCat is 5 .. so i iterate to 6 which raises an IndexError. Afterwards it's no longer possible to retrieve the length of this (now borked) LazyCat. If i had read the length before the iteration, all works perfectly, since the implementation "remembers" the len if it was computed once. So if this is to be fixed then the implementation of the LazyCat length method has to be changed slightly to check for the missing _seq attribute and then use the self._data for length retrieval. *** snip *** - -- Simon Eisenmann [ mailto:[EMAIL PROTECTED] ] [ struktur AG | JunghansstraÃe 5 | 70469 Stuttgart ] [ T. +49.711.896656.68 | F.+49.711.89665610 ] [ http://www.struktur.de | mailto:[EMAIL PROTECTED] ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA2+yqcKXkdvrBGTARAnZYAKCinwA7HLamr0ZTzVQNgi8oCpkh+QCeK31k zqaOTHEqiUN9D8hYxgq4AwM= =kEId -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 )
[Zope-dev] Re: zope-dev list policies
Tres Seaver wrote: Leonardo Rochael Almeida wrote: On Mon, 2004-06-21 at 11:59, Casey Duncan wrote: -1 on changing the list policy. I read and post to all of the public lists through Gmane, which won't work if the policy is changed. I might be wrong but I think this is incorrect. From the headers of this message you sent it's possible to see that you sent it thru gmane, yet the "From:" address is your zope.com address, so you should not have a problem posting thru the list this way. I think you got a direct reply (but could be wrong). I got the original mail bounced to me just now. Tres. This surprises me. I am administring plone-i18n mailing list. Non members cannot post. I always post through gmane and my messages get accepted ! Further, I think Mohsen has a very good point when he mentions the fact that spam pollutes the archives ! IOW, I think we really could make advantage of "Non-members not allowed" on zope lists. -- Godefroid Chapelle (aka __gotcha)http://bubblenet.be ___ 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 )
