[Zope-dev] Trying to understand the nuances of a VerboseSecurity report ..
Hi all (and Shane in particular :)
I'm triggering this error:
Unauthorized: The owner of the executing script is defined
outside the context of the object being accessed. Access to
'basic' of (License_PropertySheetsClass instance at e204528)
denied. Access requires Access_contents_information_Permission,
granted to the following roles: ['Administrator', 'Manager',
'Owner', 'Supporter']. The executing script is (PythonScript
instance at e208eb8), owned by jean.
I can't understand why .. there is exactly one acl_users in this
Zope instance, in the root, where user 'jean' is defined. The
whole application normally works fine. Currently, the error is
being triggered by a ZUnit unit test. All the other unit tests
(adding, editing and deleting instances of various kinds) works
fine. The code where the error is occuring is this:
# Create a new License instance and grab its propertysheet
license_id = context.ObjectCounters.newID('License')
new_license = container.newItem(license_id)
new_license_propertysheet = new_license.propertysheets.basic
All I can think is that that object 'basic' lacks context for
some reason (i.e. lacks an acquisition wrapper?). I can't think
why it lacks context .. we use that idiom all over the app, and
don't normally get any problems.
I'm trying to see if reading VerboseSecurity's source will
help, but all I've found so far is a suspect double negation:
def userHasRolesButNotInContext(user, object, object_roles):
'''Returns 1 if the user has any of the listed roles but
is not defined in a context which is not an ancestor of object.
'''
Surely either one of those 'not's should go?
--
Jean Jordaan
http://www.upfrontsystems.co.za
___
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 2.5.1 with ZEO 2.0.2
Brian R Brinegar wrote: Hello, We are trying to upgrade the ZEO component of our Zope 2.5.1 system from ZEO 1.0 to ZEO 2.0.2. We are using Python 2.1.3, everything is compiled from source. I'm pretty sure ZEO 2 requires Zope 2.6.x... cheers, Chris ___ 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] RDF Musings and TinyTables
I just read the RDF article published here: http://www.xml.com/pub/a/2003/02/12/rdflib.html I've understood the mechanics of RDF for a while, but never understood what makes it better than what we already have. Now I think I get it: RDF theory is a new kind of database abstraction. It is NOT just abstraction:) The point is you can read RDF and understand it, and machine can understand it too, what makes Web a huge database (of course in future). Its not just HTML or XML it is structured text, so for example you can search web - based on logic (like searching in library catalog), and not like to day - which is just matching words. In other words now you have content, RDF gives you content and metadata (content description). Ontologies are next step which gives you relation between objects and so on. It's similar to a relational database in that you put pieces of data into the database and later search for data. But it's much more ad-hoc than a relational database. Serialization of RDF into XML and the relationship between RDF and the Semantic Web are distinct concepts from RDF theory. Semantic Web are based on RDF: One path might be (not only one): RDF - DAML+OIL - OIL - Description Logics further for example FaCT - ALC and so on. This ad-hoc data storage made me think of TinyTables. TinyTables is a good Zope product that fills the need for simple tables of data, but it needs attention. What if it got replaced by some Zope product called RDFBucket? An RDFBucket object would let you input data in a variety of ways, including object introspection, forms, and XML with embedded RDF. It would let you run queries similar to ZCatalog. Maybe it would also generate RDF for embedding metadata in web pages. 1st idea: You can implement RDF almost in any SQL language, and be able to Query rdfs. 2nd idea: Besides any document in ZOPE can be RDF - special tags in html-header. On the other hand Plone uses Dublin Core, so you can easily make RSS (syndication), and RDF. But its limited to documents and basic Plone types. So you can, and Plone uses ZCatalog for searching 3rd idea: I haven't done research on RDF and Zope/Python, yet, but it seams to be a good idea to do something like RDFBucket especialy using ZODB (maybe not derivied from TinyTable). I also consider this idea but I would do it more like RDFS - Folder like object with (rdf) properties containing other objects (subclasses). This is about 5 minutes of programing. My consideration are going further - I'm thinking, about further develepment of this idea into OIL, DAML compatibile (restrictions, constraints), but I've to get check also OWL:) I'm wondering if I'm thinking in line with RDF theory, or if I've veered off track. If you're familiar with RDF: What do you think? Shane Hope this gives you some light:) Lukasz ___ 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] RDF Musings and TinyTables
Lukasz Racon wrote: I just read the RDF article published here: http://www.xml.com/pub/a/2003/02/12/rdflib.html I've understood the mechanics of RDF for a while, but never understood what makes it better than what we already have. Now I think I get it: RDF theory is a new kind of database abstraction. It is NOT just abstraction:) The point is you can read RDF and understand it, and machine can understand it too, what makes Web a huge database (of course in future). Its not just HTML or XML it is structured text, so for example you can search web - based on logic (like searching in library catalog), and not like to day - which is just matching words. In other words now you have content, RDF gives you content and metadata (content description). Ontologies are next step which gives you relation between objects and so on. That's all fine and good, but I'd like someone to confirm my thinking: that the *core principle* of RDF is a new database abstraction. I believe that all the other concepts derive from this core principle. It's similar to a relational database in that you put pieces of data into the database and later search for data. But it's much more ad-hoc than a relational database. Serialization of RDF into XML and the relationship between RDF and the Semantic Web are distinct concepts from RDF theory. Semantic Web are based on RDF: One path might be (not only one): RDF - DAML+OIL - OIL - Description Logics further for example FaCT - ALC and so on. Please don't use so many new acronyms. DAML and OIL are weird enough. FaCT? ALC? I have no idea what you just suggested. :-) This ad-hoc data storage made me think of TinyTables. TinyTables is a good Zope product that fills the need for simple tables of data, but it needs attention. What if it got replaced by some Zope product called RDFBucket? An RDFBucket object would let you input data in a variety of ways, including object introspection, forms, and XML with embedded RDF. It would let you run queries similar to ZCatalog. Maybe it would also generate RDF for embedding metadata in web pages. 1st idea: You can implement RDF almost in any SQL language, and be able to Query rdfs. What does that mean? Do you mean that an RDF database could have a SQL query interface? 3rd idea: I haven't done research on RDF and Zope/Python, yet, but it seams to be a good idea to do something like RDFBucket especialy using ZODB (maybe not derivied from TinyTable). I will not derive anything from TinyTable. That would not be pretty. I also consider this idea but I would do it more like RDFS - Folder like object with (rdf) properties containing other objects (subclasses). This is about 5 minutes of programing. I don't know what you're suggesting. Hope this gives you some light:) Right now, I'm looking for milk, not meat. :-) Shane ___ 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] Trying to understand the nuances of a VerboseSecurityreport ..
Jean Jordaan wrote: All I can think is that that object 'basic' lacks context for some reason (i.e. lacks an acquisition wrapper?). I can't think why it lacks context .. we use that idiom all over the app, and don't normally get any problems. That's all I can think of also. Try examining basic.aq_chain. I'm trying to see if reading VerboseSecurity's source will help, but all I've found so far is a suspect double negation: def userHasRolesButNotInContext(user, object, object_roles): '''Returns 1 if the user has any of the listed roles but is not defined in a context which is not an ancestor of object. ''' Surely either one of those 'not's should go? Yes. I think the first one should go. Shane ___ 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: Bare except dangerous to ZODB?
On Wed, 2003-02-12 at 04:23, Toby Dickenson wrote: On Tuesday 11 February 2003 5:21 pm, Jeremy Hylton wrote: On Tue, 2003-02-11 at 12:10, Shane Hathaway wrote: I'd like to do the transaction states, because it would keep the code in zodb3 and zodb4 similar. There are application-level reasons to mark a transaction as doomed, and I would like to keep *that* code looking similar ;-). The transaction states approach would work in that context too, right? Here's a late answer: If an application needs to mark a transaction as doomed, it is supposed to call get_transaction().abort(). If a transactional resource manager, like a database connection, needs to mark a transaction as doomed, it: - returns False from prepare() -- the ZODB4 spelling - raises an exception in tpc_vote() -- the ZODB3 spelling Jeremy ___ 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: Bare except dangerous to ZODB?
On Thursday 20 February 2003 5:17 pm, Jeremy Hylton wrote: There are application-level reasons to mark a transaction as doomed, and I would like to keep *that* code looking similar ;-). The transaction states approach would work in that context too, right? Here's a late answer: If an application needs to mark a transaction as doomed, it is supposed to call get_transaction().abort(). If a transactional resource manager, like a database connection, needs to mark a transaction as doomed, it: - returns False from prepare() -- the ZODB4 spelling - raises an exception in tpc_vote() -- the ZODB3 spelling Thanks for that idea. Normally in the Zope context, transaction and request boundaries are co-aligned. This assumption runs deep in zope. I can see problems because an application calling abort wont stop the publisher calling commit at the end of the request. Having application state revert mid-request to the pre-transaction state seems like a bad idea. Commiting application changes made in the second half of the request seems bad too. (All from theory - I ve not tested this) -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson ___ 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: RDF Musings and TinyTables
Good grief, how did I miss this!! Shane Hathaway wrote: I just read the RDF article published here: http://www.xml.com/pub/a/2003/02/12/rdflib.html Yes indeed, that is a very good article. I've understood the mechanics of RDF for a while, but never understood what makes it better than what we already have. Now I think I get it: RDF theory is a new kind of database abstraction. It's similar to a relational database in that you put pieces of data into the database and later search for data. But it's much more ad-hoc than a relational database. I think you are 100% correct, maybe 110%. :^) In the last two years I made several attempts at grokking Mozilla and RDF was always the wall I ran into that prevented further progress. In the last three months I slowly, surely, forced myself to study it. Write things down, take notes, rewrite them down, etc. The light bulb has definitely gone off for me now, and I see things exactly the way you describe it: 1) It's an abstraction. Once you start working with it, you realize what this means. You take a bunch of information and throw it into a bucket. You also throw in how the information relates to each other. 2) It's a database. You have a pretty formal way of asking questions and making sense of the stuff in the bucket. You also have a way to put things in the bucket, and also to rearrange the stuff in the bucket. 3) It's ad-hoc. You don't have to know everything beforehand like SQL. You also don't have to control the containment hierarchy like you do with XML. (Took me a LONG time to realize the significance of the latter point.) The ad-hoc part is, for me, the key. Relational theory provided the theoretical foundation for modern online transaction processing. But things like content management are a much different problem. (One analyst states that unstructured content is 80% of the information in a business.) RDF, in my view, is the equivalent of a set theory, a formal foundation, for content management. Without it, everyone has to build their own framework for stitching things together, for connecting the dots. Serialization of RDF into XML and the relationship between RDF and the Semantic Web are distinct concepts from RDF theory. That's right. I've always been surprised when I threw some RDF/XML into Mozilla, then got a dump of the serialized results. What I put in doesn't look like what I get out. That's because there is an abstract model. The XML can look a couple of different ways, and you still have the same abstract model. It took me a while, but I learned how to take advantage of this. With Moztop, I'm taking a pretty loose, distributed approach to content managment. I collect RDF from a bunch of different servers, throw it all into one big graph, and use this to draw widgets on the screen. The ability to make an assertion into a completely different part of the tree is something you can't do in XML. This ad-hoc data storage made me think of TinyTables. TinyTables is a good Zope product that fills the need for simple tables of data, but it needs attention. What if it got replaced by some Zope product called I will do everything in the universe to help such a project. How is that? :^) I know what the practical benefits that RDF can mean for content management. And it isn't esoteric Semantic Gibberish. I'm unable, though, to map it on the server side. However, I'm having luck on the client side: http://www.zope-europe.org/Members/paul/tmp/moztop-pinstripe.png RDFBucket? An RDFBucket object would let you input data in a variety of ways, including object introspection, forms, and XML with embedded Yes, this is very similar to the client side model in Mozilla. I'm doing things like: o Assembling a hierarchy o Making up new hierarchies where none existed before o Generating property sheets o Doing conditional display o Making rich connections between loosely-coupled objects, meaning, objects that didn't expect to be coupled o Allowing data from Zope 2 and Zope 3 sites to be collected, presented, and related in the same interface Mozilla's template model is interesting to at least investigate. What's interesting about it is the way you can follow relationships in the model to draw things on the screen: http://www.mozilla.org/docs/xul/xulnotes/template-primer.html In this very simple example: http://www.mozilla.org/docs/xul/xulnotes/template-bindings.html ...note the last two resources shown in friends.rdf. Instead of repeating information in every row, you get the equivalent of a join. Except the result of that join can produce another join. The template builder keeps following relationships. Also, you can join to something on another server. RDF. It would let you run queries similar to ZCatalog. Maybe it would also generate RDF for embedding metadata in web pages I'm wondering if I'm thinking in line with RDF theory,
Re: [Zope-dev] Re: Bare except dangerous to ZODB?
On Thu, 2003-02-20 at 13:33, Toby Dickenson wrote: On Thursday 20 February 2003 5:17 pm, Jeremy Hylton wrote: There are application-level reasons to mark a transaction as doomed, and I would like to keep *that* code looking similar ;-). The transaction states approach would work in that context too, right? Here's a late answer: If an application needs to mark a transaction as doomed, it is supposed to call get_transaction().abort(). If a transactional resource manager, like a database connection, needs to mark a transaction as doomed, it: - returns False from prepare() -- the ZODB4 spelling - raises an exception in tpc_vote() -- the ZODB3 spelling Thanks for that idea. Normally in the Zope context, transaction and request boundaries are co-aligned. This assumption runs deep in zope. I can see problems because an application calling abort wont stop the publisher calling commit at the end of the request. Good point. One possibility is that the publisher should more explicitly manage the relationship between transaction and request. It could call get_transaction() at the start of a request to get a transaction object. Store that object explicitly and call its abort() or commit() method at the end of the request. Having application state revert mid-request to the pre-transaction state seems like a bad idea. Commiting application changes made in the second half of the request seems bad too. That does seem like a bad idea, and explicitly using a single transaction object would prevent it. On the other hand, maybe Zope app code that detects an error should not call abort(). Perhaps the publisher should be responsible for the transaction and the app code should information the publisher that something went wrong. Jeremy ___ 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: RDF Musings and TinyTables
Paul Everitt wrote: Shane Hathaway wrote: I've understood the mechanics of RDF for a while, but never understood what makes it better than what we already have. Now I think I get it: RDF theory is a new kind of database abstraction. It's similar to a relational database in that you put pieces of data into the database and later search for data. But it's much more ad-hoc than a relational database. I think you are 100% correct, maybe 110%. :^) Whew, that's good to know. In the last two years I made several attempts at grokking Mozilla and RDF was always the wall I ran into that prevented further progress. In the last three months I slowly, surely, forced myself to study it. Write things down, take notes, rewrite them down, etc. The light bulb has definitely gone off for me now, and I see things exactly the way you describe it: 1) It's an abstraction. Once you start working with it, you realize what this means. You take a bunch of information and throw it into a bucket. You also throw in how the information relates to each other. 2) It's a database. You have a pretty formal way of asking questions and making sense of the stuff in the bucket. You also have a way to put things in the bucket, and also to rearrange the stuff in the bucket. 3) It's ad-hoc. You don't have to know everything beforehand like SQL. You also don't have to control the containment hierarchy like you do with XML. (Took me a LONG time to realize the significance of the latter point.) With all this in mind, I just studied my Mozilla mimeTypes.rdf file again. At first, this file looks nasty. I've only defined handlers for two mime types, application/pdf and application/x-zope-edit, yet the string application/pdf shows up 8 times in the file! I only typed it once. ;-) But if I think of RDF files as database export files (or maybe the results of a database query), it all makes sense. - The order in which the RDF elements appear in the file doesn't matter, just like the physical order of inodes on a hard disk doesn't matter. - The obvious way to read this file is to search for XML elements that look like 'RDF:Description about=urn:mimetype:*'. But that's not the right way: that's like scanning filesystem inodes sequentially. Instead, there is a root URI, urn:mimetypes, and the RDF elements make connections to other elements from there. - RDF is hard to read, but legibility by humans isn't its primary focus. It's more concerned with providing a way to declare any relationship about anything. The ad-hoc part is, for me, the key. Relational theory provided the theoretical foundation for modern online transaction processing. But things like content management are a much different problem. (One analyst states that unstructured content is 80% of the information in a business.) RDF, in my view, is the equivalent of a set theory, a formal foundation, for content management. Without it, everyone has to build their own framework for stitching things together, for connecting the dots. So RDF seems like a replacement for, or maybe enhancement of, relational theory. But I wonder how object-oriented databases fit in the mix? Serialization of RDF into XML and the relationship between RDF and the Semantic Web are distinct concepts from RDF theory. That's right. I've always been surprised when I threw some RDF/XML into Mozilla, then got a dump of the serialized results. What I put in doesn't look like what I get out. That's because there is an abstract model. The XML can look a couple of different ways, and you still have the same abstract model. How do you (1) throw RDF into Mozilla and (2) get a dump of the results? Is there a utility for doing this? Are the results in RDF, and are they pretty much equivalent to cat file1 file2? :-) It took me a while, but I learned how to take advantage of this. With Moztop, I'm taking a pretty loose, distributed approach to content managment. I collect RDF from a bunch of different servers, throw it all into one big graph, and use this to draw widgets on the screen. The ability to make an assertion into a completely different part of the tree is something you can't do in XML. This ad-hoc data storage made me think of TinyTables. TinyTables is a good Zope product that fills the need for simple tables of data, but it needs attention. What if it got replaced by some Zope product called I will do everything in the universe to help such a project. How is that? :^) I know what the practical benefits that RDF can mean for content management. And it isn't esoteric Semantic Gibberish. I'm unable, though, to map it on the server side. However, I'm having luck on the client side: http://www.zope-europe.org/Members/paul/tmp/moztop-pinstripe.png I can see that the benefits on the client side would be enormous. For interfacing clients to Zope, we've always thought in two directions: either connect the client
Re: [Zope-dev] RDF Musings and TinyTables
Hi Shane In case your not aware Chandler OSAfoundation is basing their new PIM on RDF/ZODB/Python etc... if you haven't already it might be worth having a look at how they see RDF fitting into the picture. http://www.osafoundation.org/Chandler_rel._0.1.htm See ya Tim On Wed, 2003-02-19 at 03:21, Shane Hathaway wrote: I just read the RDF article published here: http://www.xml.com/pub/a/2003/02/12/rdflib.html I've understood the mechanics of RDF for a while, but never understood what makes it better than what we already have. Now I think I get it: RDF theory is a new kind of database abstraction. It's similar to a relational database in that you put pieces of data into the database and later search for data. But it's much more ad-hoc than a relational database. Serialization of RDF into XML and the relationship between RDF and the Semantic Web are distinct concepts from RDF theory. This ad-hoc data storage made me think of TinyTables. TinyTables is a good Zope product that fills the need for simple tables of data, but it needs attention. What if it got replaced by some Zope product called RDFBucket? An RDFBucket object would let you input data in a variety of ways, including object introspection, forms, and XML with embedded RDF. It would let you run queries similar to ZCatalog. Maybe it would also generate RDF for embedding metadata in web pages. I'm wondering if I'm thinking in line with RDF theory, or if I've veered off track. If you're familiar with RDF: What do you think? Shane ___ 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] RDF Musings and TinyTables
On 02/20/2003 09:06 PM, Tim Hoffman wrote: In case your not aware Chandler OSAfoundation is basing their new PIM on RDF/ZODB/Python etc... if you haven't already it might be worth having a look at how they see RDF fitting into the picture. http://www.osafoundation.org/Chandler_rel._0.1.htm Wow, that's exactly what I was looking for. I guess I'll find out more when they open up their CVS. I hope it's soon. If they've had any difficulty persisting ZODB objects to RDF, I bet I could help them. Shane ___ 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: RDF Musings and TinyTables
Paul Everitt wrote: On jeudi, fév 20, 2003, at 22:15 Europe/Paris, Shane Hathaway wrote: - RDF is hard to read, but legibility by humans isn't its primary focus. It's more concerned with providing a way to declare any relationship about anything. Right. That's what the graph tool at the W3C online validator is for. :^) Just throw it some RDF and let it draw a picture for you. Fascinating discussion. Could you please share the URL of this validator you mentioned? I am assuming it is based on GraphViz/IsaViz technology? Or is it something totally new? Thanks, --Craeg ___ 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: RDF Musings and TinyTables
On Friday, Feb 21, 2003, at 04:16 Europe/Paris, Craeg K Strong wrote: Paul Everitt wrote: On jeudi, fév 20, 2003, at 22:15 Europe/Paris, Shane Hathaway wrote: - RDF is hard to read, but legibility by humans isn't its primary focus. It's more concerned with providing a way to declare any relationship about anything. Right. That's what the graph tool at the W3C online validator is for. :^) Just throw it some RDF and let it draw a picture for you. Fascinating discussion. Could you please share the URL of this validator you mentioned? http://www.w3.org/RDF/Validator/ I am assuming it is based on GraphViz/IsaViz technology? Or is it something totally new? Nope, it is indeed GraphVis underneath. --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 )
