[Zope-dev] AccessControl bug fixed
Hello, I found a bug in ZopeSecurityPolicy and fixed it. http://svn.zope.org/AccessControl/trunk/src/AccessControl/ZopeSecurityPolicy.py?rev=127548r1=113657r2=127548 Is it possible to release new version? Regards, -- Yusei TAHARA yu...@domen.cx ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope2 ZMI and HTML5
Hello, On Fri, 05 Feb 2010 15:29:03 -0300 Roberto Allende ro...@menttes.com wrote: (snip) Regarding DTML... i wonder if it dtml purpose doesn't overlap with tal/metal or even viewlets. If that's the case we wouldn't provide 'One-- and preferably only one --obvious way to do it' and for non Dutch newbies :P is kinda confusing because end up with situations like 'you've to learn it but you won't use in-real-projects'. So, wouldn't make sense to have DTML in an separated component and make its use optional ?. DTML is still very useful if we make non-xml stuff like SQL, CSS, JavaScript etc. And I have used it in many real projects for about 7 years. If there is something(online document?) which make new users confused, it would be better to fix it. ZPT is useful to generate xml/html documents, DTML is useful to generate non-xml documents. Regards, -- Yusei TAHARA yu...@domen.cx ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope2 ZMI and HTML5
Hi, On Wed, 03 Feb 2010 14:20:08 +0100 Tom Gross itconse...@gmail.com wrote: Hi all, with HTML5 the frame-elements will die. It will probably take some years before the browser-support of HTML4 will stop, but still. Are there any alternative implementations for the Zope2-ZMI? There is a package zmi.core in the Zope-svn, but except some links to other packages there is nothing in it. Is the package alive and what's the targeted platform: Zope2, BlueBream, grok? I have been working for zmi.core for several months and it is still under construction(sorry). The target was Zope3 and now it's BlueBream. Of course we can use it for grok. Zope2's ZMI is different. Regards, -- Yusei TAHARA yu...@domen.cx ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope2 ZMI and HTML5
Hi, On Thu, 04 Feb 2010 00:59:52 -0300 Roberto Allende ro...@menttes.com wrote: (snip) Probably at this point of the conversation is the right moment to ask if it would make sense to improve Zope2's ZMI, removing frames and perhaps DTML code and probably removing all the dtml from zope2. I'd say that removing all the dtml from zope2 is too much. I know that there are many web sites which have used dtml for a long time. And also dtml works quite well without any serious problems. Regards, -- Yusei TAHARA yu...@domen.cx ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] People in the Zope 3 and ZMI teams
Hi, On Tue, 21 Apr 2009 18:40:51 +0200 Martijn Faassen faas...@startifact.com wrote: Or should we break BBB and let people know that they have to install zmi.core for zmi support? (I think so) I won't break BBB as much as possible, at least I'd like to keep persistent data compatibility... But the ZMI is all views, right? What is persistent? Yes, you're right. It's my mistake...We would not have any persistent data in zmi package. For now, I don't have clear image yet. I'm checking all zope.app.* packages and make sure all tests pass. And maybe I will review current package dependencies. For that, you might want to investigate the z3c.recipe.depgraph recipe to generate dependency graphs. To try it against trunks you need to add them to 'develop' in your buildout.cfg Oh I did not know that. Thanks. Best regards, -- Yusei TAHARA yu...@domen.cx ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] People in the Zope 3 and ZMI teams
Hi, On Wed, 22 Apr 2009 09:48:40 +0200 Martijn Faassen faas...@startifact.com wrote: Hey, Roger Ineichen wrote: I think there is a little confusion about which package depends on each other. Right now there is a zmi.core package this package should contain core parts without to much dependency. After that we need several zmi.* packages which are replacements for each zope.app.* package. right? Right. Note that I'm against making too many zmi.* packages right now, keep it all in a few packages now. Concerning dependencies, let's first talk about zope.container: zmi should depend on zope.container zope.app.container.browser should have backwards compatibility imports from zmi, and zope.app.container should depend on zmi Now let's talk about a package that *hasn't* been factored away from zope.app.* yet, such as zope.app.file: in this case, zmi would depend on zope.app.file but zope.app.file.browser would depend on zmi. That's a circular dependency, which we should break as soon as possible by moving zope.app.file's content objects to zope.file or something like that. I see, this is very clear. BTW, what do you think of zope.app.form? As far as I know, it has some basic interfaces like IInputWidget and IDisplayWidget, and they are used by various packages. Then I don't see any reason to leave them under zope.app.form. So, I think maybe we could also move them to zope.form or somewhere generic package after we finish zmi package. Best regards, -- Yusei TAHARA yu...@domen.cx ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] People in the Zope 3 and ZMI teams
Hi Roger, Thank you very much for your comment, and sorry for my late reply. I did not receive your post I don't know why... Betreff: Re: [Zope-dev] People in the Zope 3 and ZMI teams Hi, I just start working on maintaining ZMI and make it optional package. For now, it is easy to participate, just porting zope.app.* (I already list up targets as directories in zmi.core) and make sure that existing tests succeeds. Can you tell a little bit about what you mean with tests succeed? Should the test in the existing package succeed? But this whould mean that the old packages we move the zmi parts from needs to depend on the new zmi.core package. Should the old zope.app.* package depend on the new zmi.core package? (I think not) No. But zmi.core might depend on zope.app.* packages. Or should we break BBB and let people know that they have to install zmi.core for zmi support? (I think so) I won't break BBB as much as possible, at least I'd like to keep persistent data compatibility... If so, then the test should succeed in the new zmi.core packages, right? Yes, my intention was to make sure that after we copy files from zope.app.* to zmi.core.*, then existing tests which were originally in zope.app.* have to work in zmi.core.*. Can you write down some comment how we sould do the refactoring like: - move the zmi part from a zope.app.* package to the new zmi.core.* package. Yes. - make sure the test pass in both packages. The zmi test should all get moved to the new zmi.core.* package Probably enhance the tests since the zmi part was not very well tested. Yes. - release the zmi.core package after each package move or at least before the zope.app.* package get released - bump up the zope.app.* package version (full not partial) e.g. 3.5.1 to 3.6.0 Hmm, I'm not sure yet... Not sure if the above is correct. Please change if not. It is at least only correct if we break BBB and move the zmi completly out of all zope.app packages to zmi.core. And probably we should also implement a testing layer setup which all test in zmi.core can share/use. Sounds good idea. For now, I don't have clear image yet. I'm checking all zope.app.* packages and make sure all tests pass. And maybe I will review current package dependencies. After that, I will copy zmi parts to zmi.core one by one. I'm sorry but I'm very slow for some reasons, I cannot make an exact schedule yet. Best regards, -- Yusei TAHARA yu...@domen.cx ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] People in the Zope 3 and ZMI teams
Hi, On Fri, 17 Apr 2009 13:09:05 +0200 Fabio Tranchitella kob...@kobold.it wrote: To be honest, zope3 (as it is today) is a nice platform for me and for my company to build web applications (and, in general, the ZCA is a nice platform for building not-only-web applications), and it would be a shame to loose it. ZCA will be improved by ZTK, so I don't worry. To make explicit: I am not talking just about maintaining the ZMI, I'm talking about making zope3 a *real* user-friendly web framework, as (for example) grok is already right now. For me, my main purpose is maintaing the ZMI as an application server on ZTK, because I find it still useful for maintenance/configuration on the spot for example. But making Zope3(though it is still ambiguous for me)/ZTK user- friendly sounds a very nice idea. I could imagine a lot of packages might makes beginners shrink a bit, although we already have nice books. Best regards, -- Yusei TAHARA yu...@domen.cx ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] People in the Zope 3 and ZMI teams
Hi, I just start working on maintaining ZMI and make it optional package. For now, it is easy to participate, just porting zope.app.* (I already list up targets as directories in zmi.core) and make sure that existing tests succeeds. Best regards, -- Yusei TAHARA yu...@domen.cx ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain the Zope 3 ZMI?
Hi, On Wed, 15 Apr 2009 09:37:33 +0200 Martijn Faassen faas...@startifact.com wrote: Perhaps one way to make the ZMI and optional package is to aggregate the relevant ZMI code into a smaller amount of packages (or a single package), for instance zmi.core. The benefit of doing that is that it should be possible to evolve the code slowly. You could still support the zope.app.* packages compatibility by putting imports from zope.app.something.browser to zmi.core. Then I'll take this way for now. Maybe z3c.zmi.core would be good? Best regards, -- Yusei TAHARA yu...@domen.cx ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain the Zope 3 ZMI?
On Wed, 15 Apr 2009 14:10:44 +0200 Martijn Faassen faas...@startifact.com wrote: Then I'll take this way for now. Maybe z3c.zmi.core would be good? Flat is better than nested (see the Zen of Python). I'd say go for zmi.core; z3c isn't necessary. Thanks. I will use the name zmi.core and will commit initial draft this weekend. Best regards, -- Yusei TAHARA yu...@domen.cx ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain the Zope 3 ZMI?
Hi, On Tue, 14 Apr 2009 18:34:47 +0200 Martijn Faassen faas...@startifact.com wrote: So, who finds the Zope 3 ZMI useful? What parts of it do you find useful? Are you interested in helping maintain it? For me, the ZMI is useful to managing local components, security settings, making views for ad hoc changes etc. I think it could be an optional package like grokui.admin. I'm interested in maintenance it. Best regards, -- Yusei TAHARA yu...@domen.cx ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Notify event for getWSGIApplication?
Hello. On Wed, 2 Jan 2008 19:13:24 +0100 Yusei TAHARA [EMAIL PROTECTED] wrote: I'd like to add a new event for getWSGIApplication. (the name is like WSGIPublisherApplicationCreatedEvent?) I've added the event in zope.app.wsgi package. Thank you, -- Yusei TAHARA [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Notify event for getWSGIApplication?
Hello, I'd like to add a new event for getWSGIApplication. (the name is like WSGIPublisherApplicationCreatedEvent?) Because, now zope3 uses no particular web server but can use any wsgi server and I'd like to make a internal webserver calling facility with a generic way. I'd appreciate any comments. Thank you very much. -- Yusei TAHARA [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
Hi. I am currently looking at getting this into 2.6.1 or 2.6.2. I would appreciate confirmation that you are all happy with this combination of patches. Thank you:-) BTW, I was asked for upload my patch on collector. Could you put it in a issue 737 page? I don't permit to upload it. Regards. -- Yusei ___ 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] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
Hi.
2.6.2 is a realistic target.
Sure.
I tried to your patch 03-properties.diff, then I found two problems.
1. browsers autodetection make a mistake.
dtml-var u' ' makes some web browsers confuse, it ignores meta tag
charset and autodetect UTF8.So I will remove dtml-var u' ', when
REQUEST has another charset value.
2. management_page_charset_tag really needs?
Because management_page_charset is approach of not using unicode.
But management_page_charset_tag exists, REQUEST will convert strings to
unicode strings.field2string has not convert_unicode method, then raise
unicodeerror. It is contradiction.
HTTPRequest.py line:499
if flagsCONVERTED:
try:
if character_encoding:
# We have a string with a specified character encoding.
# This gets passed to the converter either as unicode, if it can
# handle it, or crunched back down to latin-1 if it can not.
item = unicode(item,character_encoding)
if hasattr(converter,'convert_unicode'):
item = converter.convert_unicode(item)
else:
item = converter(item.encode('latin-1'))
I made a patch for fix those problems. It looks good work on my zope.
Regards.
--
Yusei TaharaSo it goes
[EMAIL PROTECTED]
properties.diff
Description: Binary data
Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
Hi.
Probably os.environ.get('Z_SOMETHING') might be a better way than
locale.getlocale()[1], because using locale.getlocale()[1] means that
the behaviour of Zope will be changed implicitly, whereas
os.environ.get('Z_SOMETHING') is more explicit for the users, thus
less confusing..
Nice idea.
We can get environment value everywhere in Zope.
it will be easy to make patch:-)
+1
Regards
--
Yusei
___
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] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
Hi. Sorry, I noticed that my patch is defective. It is failure when object has own Property:-( -- Yusei ___ 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] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
Hi. I made monkey patch for myself, when management_page_charset is not UTF-8, this patch remove :utf8: from non unicode type input field. because if input values are not latin-1, then unicode error raised. I think that every encoding can be used it satisfactory:-) Please consider whether it can merge into Zope2.6.1. There are some details missing from your explanation, but hopefully not from your patch. where do I find it? What thing is concretely some details? I'm very interested in Zope development, especially i18n. So I would like to contribute something about it:-) Thank you. -- Yusei TaharaSo it goes [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 )
Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
Hi. What thing is concretely some details? The fix to this situation is more complicated than removing a :utf8: from somewhere that it shouldnt be. Im sure you know this. At this point Zope2.6.x, my guess is that would not clear up this problem completely.But my patch allows to use both type string and ustring when a user set right encoding name to management_page_charset. This is a temporary trick, but works well. I'm very interested in Zope development, especially i18n. So I would like to contribute something about it:-) The patch you mentioned? I want to tackle this complicated problem in Zope development rather than make my own patches. Because the i18n is more benefit for minority languages such as japanese than major one.I need it very much. Thank you. -- Yusei ___ 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] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
Hi. As I understand it, you dont want to do anything in unicode. You store, manipulate, process, and output strings as 8-bit pre-encoded strings. You are making an assumption that these 8-bit strings use some specific character encoding. The scope of this assumption is quite broad. It has to cover: 1. All strings stored by your ZODB 2. All strings stored by your RDB. 3. All processing performed by Zope products. (must follow your assumptions, or be encoding neutral) Anything that beaks these assumptions will need special treatment. Am I right so far? yes. why I don't want to use ustring, because there are two problems for me. 1. the original encoding is not clear anymore. It does not know that it will change at once. there is no encoding which raise unicode error other than utf-8. but utf-8 is not common encoding in japanese. almost all PDAs or cellular phones are not supporting utf-8. Probably, automatic encoding detection will be required in order to become practical. 2. ustring can not join or replace to 8-bit strings other than ascii. I have an same experience in Plone i18n with Localizer and TranslationService. Zope's approach is that your application (excluding the ZMI for now) should work as in 2.5, provided you dont use any unicode values. Can you confirm that this is working OK? yes. If I input values by PythonScript without using property tab, it works well. Zope 2.5 left ZMI character encoding down to browser autodetection, and as a result most ZMI-controlled properties are encoding-neutral. For compatability with unicode pages, which are seen as the long term future, the ZMI has to specify *some* character encoding. By default in 2.6 this is latin-1, a change which I think was announced mid-way through the 2.5 development cycle. I understand that some users are very happy overriding this with a management_page_charset property on their root folder. Ive never used this, and it wasnt designed to work this way, but it looks like it works due to happy coincidence. Note that this doesnt work for management pages which explicitly set their own character encoding, or management pages which 'accidentally' encounter a unicode string. I think management_page_charset is very useful, if it function correctly. One area where this went wrong for you is the properties page, which is explicitly set to utf8 to allow unicode properties to be set. Im not yet sure on the best way to fix this for you, but I agree it needs fixing. I made monkey patch for myself, when management_page_charset is not UTF-8, this patch remove :utf8: from non unicode type input field. because if input values are not latin-1, then unicode error raised. I think that every encoding can be used it satisfactory:-) Please consider whether it can merge into Zope2.6.1. Thank you -- Yusei TaharaSo it goes [EMAIL PROTECTED] properties.dtml Description: Binary data
Re: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
Hi.
The right approach is to make it possible to change the title property to a
unicode string. All my custom products have this already, but it is a
deficiency in the standard Zope types such as 'Folder' that their
titles type can not be changed.
This approach is not useful for me.
I often use zope with RDB like MySQL.
generally japanese encoding text is in RDB.
so if object properties are unicode string,
I always encode it before publishing.
title tal:content=python:here.title.encode('euc-jp')TITLE/title
because, it always mix in RDB data(japanese) and
properties(python unicode string) in one page.
certainly I will be faced with this ustring problem everytime.
Japanese charactor is not ascii,
so if I do not encode ustring before publishing,raise unicode error.
if don't allow to use string type in properties, I regret that I
would continue to use zope2.5.1 or make my own monkey patches for
after this.
I'm sorry to my BAD English.
Thank you.
--
Yusei TAHARA
___
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] [ANN] Proposal: Integration of reStructuredText into Zope
Hi. +2 I like this Proposal very much. It allow to use multibyte charctor in document:-) Regards. ___ 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] [Zope-2.6.0b1] Property Problem
Hello.
I have a problem with property tab on zope 2.6 branch,
I can't add/edit properties in japanese.
Because, fixing latin-1 for unicode decoding in some place.
japanese or other asian language are not latin-1 encoding,
so management_page_charset won't help me.
and Folder title attribute is string not ustring.
if nothing is done, I should make a monkey patch for every zope
update, this is very bad
Yusei
#ZPublisher/ZConverters.py line:19
def field2string(v):
if hasattr(v,'read'): return v.read()
elif isinstance(v,UnicodeType) :
return v.encode('latin1') #it cause this problem...
else:
return str(v)
#ZPublisher/HTTPRequest.py line:501
if character_encoding:
# We have a string with a specified character encoding.
# This gets passed to the converter either as unicode, if it can
# handle it, or crunched back down to latin-1 if it can not.
item = unicode(item,character_encoding)
if hasattr(converter,'convert_unicode'):
item = converter.convert_unicode(item)
else:
item = converter(item.encode('latin1'))
else:
item=converter(item)
#OFS/dtml/properties.dtml line:250
input type=text name=value:utf8:ustring size=30 /
--
Yusei TaharaSo it goes
[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 )
