Re: [Zope-dev] ZCatalog scalability
We seem to have disposed of the wildcard issue [snipped out below], and I'm looking forward to Eric's results, but does anyone else have any information about whether there is a practical upper limit on how many objects can be indexed and searched in a ZCatalog? Michael Bernstein wrote: > > After comsidering the feedback I got from the previous > 'Massive scalability' thread, I decided to split my queries > into two areas: Rack scalability and ZCatalog scalability. > This email deals with the latter. > > [snip] > > What I am interested in for my application are two things: > > - ZTopics populated using one or more keyword indexes > > - Full text search on a single computed attribute that > concatenates several fields including the aforementioned > keyword index fields and a few simple string attributes > (title, caption, description, etc.) > > I need to know how far the ZCatalog will scale using this > indexing and search strategy. Does anyone have anectodal or > benchmark data to suggest if (and when) I will hit a 'wall' > regarding the number of objects being indexed and searched? > Some anectodal data suggests that single field indexing will > scale easily to 60,000 objects, but what about hundreds of > thousands or even millions of objects? > > [snip] ___ 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] Is manage_add for products broken?
Hello all, One of the Local File System users pointed out that calling manage_addLocalFS from dtml doesn't work. I did some checking and discovered that calling manage_addXXX doesn't work for any of the built-in products either. My testing was with 2.2.5. Am I crazy or didn't this work at one time? Is there a way to work around this? I couldn't find one. Thanks very much. Any help is appreciated. --jfarr ___ 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] Specialist/Rack scalability
"Phillip J. Eby" wrote: > > Just to expand a little on the abov... Racks should scale at least as > well, if not larger than a ZCatalog, given the same storage backing for the > ZODB. This is because ZCatalog has to manage a minimum of one forward and > reverse BTree for *each* index, plus another few BTrees for overall storage > and housekeeping. Also, keyword and full text indexes store multiple BTree > entries per object, so that's a factor as well. > > So don't worry about the Rack. If you're using a Rack, you can store the > data anywhere, and you can index it in an RDBMS, LDAP directory, ZCatalog, > or some combination thereof, using triggers to keep the data in sync. Thanks Philip, that's reassuring. I guess now I need to make certain that the ZCatalog can scale as far as I need it to. Michael Bernstein. ___ 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] Membership and the 2.3 beta2 ... bug in the latter!
Broke. broke badly. Not sur ecompletely why yet, but in 2.3b2, I can't move or copy a ZCatalog. There is one in the Membership interface, so as a result, no workie there. After deleteing int from teh membership interface folder, I get a traceback complaining about too many arguments in checkRoles (3 instead of 2). I haven't had time to dig into it yet, so I thought I would toss it up here so anyone with visibility to this issue can look at it. Bill Anderson ___ 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] Local roles and security of ZClass instances in Specialists
Hi, I'm trying to work out a security strategy for data stored in Specialists, where specific users need access to specific data instances. For example: A Customer object is linked to a Person and Address objects. The customer needs permission to edit the her - and only her - Address object. Using the Owner local role won't work, because customers can be registered by site managers and customer support people, in which case Owner won't be the customer. I can solve this by giving the customer a local role when creating her Address object: Customers.addCustomer(REQUEST): ni = container.addItem(some_id) container.Addresses.addAddressFor(ni.id, REQUEST) Addresses.addAddressFor(for_id, REQUEST): ni = container.addItem(some_id) ni.manage_addLocalRole(for_id, 'EditMyDetails') But this can be a lot of work - If an Address object can also be created for a CreditCard object, addCreditCard will have to both set its own local role, and pass the customer id on to Address... But the main problem is that I'm not sure if it will work at all - can local roles be set for DataSkins that aren't stored in the ZODB? From what I can see ZPatterns doesn't support this, so I'll have to do it myself. __ac_local_roles__ can't be accessed in a SkinScript - so will I have to override has_local_roles, get_local_roles and get_local_roles_for_userid and call them from the SkinScript? This is getting hairy... Without local roles, all I can think of is explicitly checking that the logged in user is the right customer in all the methods that display and edit the object, which is very ugly. Plus it would require Address to know a customer_id even when it actually belongs to a CreditCard, not a Customer... there goes Demeter. Or I can add a findUserID to Address, CreditCard and Customer, all of which pass the request upwards until one is reached that actually knows the customer. Still ugly. TIA for Any comments/suggestions. Itai -- Itai Tavor"Je sautille, donc je suis." C3Works[EMAIL PROTECTED] - Kermit the Frog "If you haven't got your health, you haven't got anything" ___ 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] 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] DTML block parsing - Patch
Ok here goes:
Install these patches on a 2.3.0b1 installation. The files to patch are
found in {Zope Dir}/lib/python/DocumentTemplate.
Thus far it seems stable, and I would like for anyone willing to test it
out.
WHY SHOULD YOU?
Although the original purpose of this patch is solve my own problem, it
also solves a behavioral bug in . That is you no longer
need correctly formed and balanced dtml code inside of a
pair. This allows them to function as you
would expect. Code inside the comment tags is simply ignored.
If you develop your own dtml tag class that you want to use to create
blocks of something other than dtml, simply add the class attribute
disable_dtml_block_parsing=1 along with blockContinuations=() in the
tag's class definition.
Here are the patches:
*** DT_String.old Mon Jan 22 13:06:33 2001
--- DT_String.pyMon Jan 22 15:55:57 2001
***
*** 272,277
--- 272,308
sname=stag
sstart=start
sa=sargs
+
+ if hasattr(scommand, 'blockContinuations') and\
+hasattr(scommand, 'disable_dtml_block_parsing'):
+ # Tag doesn't want the block parsed as dtml, so just find
the
+ # end tag and don't parse what's inside
+
+ while 1:
+ l=tagre.search(text,start)
+ if l < 0: self.parse_error('No closing tag', stag,
text, sloc)
+
+ try:
+ tag, args, command, coname=
self._parseTag(tagre,scommand,sa)
+ except:
+ start = l + 1 # Skip malformed tags without
raising exceptions
+ else:
+ start = l + len(tag)
+
+ if not command and not coname:
+ # Block end tag
+ section = String(text[sstart:l],
__name__=sname)
+ section._v_blocks = section.blocks =
[section.raw]
+ section._v_cooked = None
+ blocks.append((tname, sargs, section))
+ try:
+ r=scommand(blocks)
+ if hasattr(r,'simple_form'):
r=r.simple_form
+ result.append(r)
+ except ParseError, m:
self.parse_error(m[0],stag,text,l)
+
+ return start
+
while 1:
l=tagre.search(text,start)
*** DT_Var.old Mon Jan 22 15:27:30 2001
--- DT_Var.py Mon Jan 22 15:28:14 2001
***
*** 461,466
--- 461,467
'''
name='comment'
blockContinuations=()
+ disable_dtml_block_parsing = 1
def __init__(self, args, fmt=''): pass
Feedback on this is definitely welcome. If it is generally well-liked, I
will submit it to the collector.
--
| Casey Duncan
| Kaivo, Inc.
| [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] CSS file serving
Dieter Maurer wrote: > > [EMAIL PROTECTED] writes: > > > http://www.zope.org/Members/haqa/ZStyleSheet > > > >Hrm - that's a little heavy for what I want - which is just an analog of > > HTMLFile but for CSS files. That is, something I can add to my Python > > product as an attribute. Definitely no management or other sorts of > > trickiness required. > Look at "App.ImageFile". > If you are lucky, you can immediately use it to wrap your > CSS files. If not, you should extend "OFS.content_types.guess_content_type" > such that it recognizes the ".css" extension. That (or rather Image.File) was where I started. I decided to go with HTMLFile as a basis so we could have some DTML in the CSS file - but overrode it so we weren't forced to have the .dtml extension (much happier web designers that way :) Richard -- Richard Jones [EMAIL PROTECTED] Senior Software Developer, Bizar Software (www.bizarsoftware.com.au) ___ 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] Annouce Developer Version DTML-Page-Contract
hello zen masters i just finished documenting a developer version of a port of the ACS's (arsdigita community system) acs_page_contract to dtml. test it out, i'm pretty sure everyone will be happy with the simplification of the resulting dtml. feed back and thoughts welcome. if no bugs are found in the next week or so i'll make it a general release, new filters are always welcome. available at http://www.zope.org/Members/k_vertigo/PageContract.tgz kapil readme included below. README.txt INSTALL: extract PageContact.tgz in your zope directory. it will create a python product in lib/python/Products. you will need to restart zope before you can use dtml-contract UNINSTALL: remove the PageContract directory from lib/python/Products and restart zope. I. What Page-Contract is a python product that adds a new type of dtml-tag to your zope installation. dtml-contract is a multi-purpose tag that is designed to provide documentation, marshalling and filtering of request data, and custom error handling of the request data. the documentation comes from a read only section of the contract which should describe the purpose of the object, its author, and some information about its parameters. the marshalling and filtering is done by naming variables expected in the request and associating one or more filters with those variables. PageContract comes with a set of prebuilt filters although it can easily be extended by writing new filters. lastly it allows association of different error handlers to different variables. II. Why Zope already includes facilties to perform simple marshalling of REQUEST values submitted via GET/POST into python data_types. This facility is built into ZPublisher. There are a couple of problems with this facility in real world usage. First, ZPublishers marshalling isn't secure because it retrievesmarshalling info from the REQUEST, a cracker could perform url surgery to by pass the marshalling. Second, ZPublishers marshalling isn't easily extensible to provide application level support of. The marshalling is buried square in the guts of the Publishing process, even if you did extend it would be too early in the Publishing of the object to perform any meaningful application specific processing (ie you don't know where you're going so how do you know what you'll see when you get there). Third ZPublisher has no concept of excluding parts of the REQUEST that aren't needed, this is mitigated by Zope placing the REQUEST on the bottom of the namespace stack, however it still provides a means for accidents (ie. you're expecting this object to have this attr, but it doesn't but the REQUEST has that attr). dtml-contract can optionally strip the REQUEST of variables not explicitly named within it. Fourth, ZPublisher is inflexible about how it handles errors. ZPublisher has hardcoded return values whenever it hits a bad input AND it short circuits the evalutation. Users don't get informative messages regarding their errors other than they made one. dtml-contract differs in that it collects all errors and associates them with their variables and provides the option of custom error pages on a variable by variable basis with information passing about the errors. (The current implementation is limited in that it only passes a list of filter errors to the error handler via a url string.) The dtml-contract also hopes to offer a standardized form of documenting your zope objects (DTML_METHODS, DOCUMENTS, and the like) by standardizing on a documentation format and a location for that documentation. III. How So how do you use it? Documentation about this object @author Kapil Thangavelu <[EMAIL PROTECTED]> @params myobj_id the id of the object where after @params title we'll set the object's title to this value @params thedate should be the range of the bada and bing @params foobar optional integer value that tells us whats going on myobj_id:objid foobar:integer,optional thedate:range(date, 1.1.1, 11/11/11) title:string myobj_id:my_error_page generic_error_page Generally dtml-contracts should be used at the start of a dtml page. why? so they can be easily referenced for documentation and knowledge of the expected parameters. Caveats. Note that there are no strict enforcements of the documentation section. Although some future documentation extraction utility would benefit from it:) Also note oth
Re: [Zope-dev] ZCatalog scalability
Steve Alexander writes: > Michael Bernstein wrote: > > > > Also, is there a way to disable wildcards in full text > > searches? > > Do not allow direct queries to search the catalog. Instead, make > searches go through an external method (or a PythonScript with Proxy > permissions) that uses string.replace to change '*' and '?' to ''. Simply do not use a globbing vocabulary is another alternative. 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 )
Re: [Zope-dev] How would I keep _v_* attributes from getting thrown away?
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 )
Re: [Zope-dev] dtml-in batching
This was submitted to the collect quite a while ago as a bug.. Also I submitted a patch about 2 months ago for this, about the same patch as yours. On 22 Jan 2001, at 12:03, [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Date sent: Mon, 22 Jan 2001 12:03:14 +1100 To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Subject:Re: [Zope-dev] dtml-in batching > [EMAIL PROTECTED] wrote: > > > > The dtml-in batching mechanisms are quite difficult to debug - the DTML > > documentation I have has examples which break it and there's no > > indication of why. It turns out the DT_In renderwb() code gobbles all > > exceptions from the rendering of the previous and next blocks. I've > > hacked my code so that there's no try/except clause any more. I'm not > > sure what exception it's trying to catch, but could it perhaps be made a > > little more picky? > > And here's a diff - I'm pretty sure this was the intended behaviour... > > > *** /tmp/DT_In.py.origMon Jan 22 12:00:53 2001 > --- DT_In.py Mon Jan 22 12:00:58 2001 > *** > *** 561,566 > --- 561,570 > # there are more items, without actually > # computing a length: > sequence[end] > + except IndexError: > + if self.elses: result=render(self.elses, md) > + else: result='' > + else: > pstart,pend,psize=opt(end+1-overlap,0, > sz,orphan,sequence) > kw['next-sequence']=1 > *** > *** 568,576 > kw['next-sequence-end-index']=pend-1 > kw['next-sequence-size']=pend+1-pstart > result=render(section,md) > - except: > - if self.elses: result=render(self.elses, md) > - else: result='' > else: > result = [] > append=result.append > --- 572,577 > > > -- > Richard Jones > [EMAIL PROTECTED] > Senior Software Developer, Bizar Software (www.bizarsoftware.com.au) > Brad Clements,[EMAIL PROTECTED] (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements ___ 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] sql methods and the namespace stack
Does anybody know why sql methods only search the request object instead of traversing the dtml namespace stack? TIA, Tim McLaughlin ___ 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] DTML block parsing
On Monday 22 January 2001 08:54, Casey Duncan wrote: > I am working on a custom DTML tag (that I may unleash on the world when > finished) that has brought to my attention an interesting feature of the > DTML parser: > > It preparses everything in the block(s) between the start and end tags > before the document containing the code is committed. > > My tag is a little different in that I don't want to put DTML inside it, > therefore this parsing is undesirable. There is however one built-in tag > that this is true for as well: . Many a thread has been > burned about that issue. i've been bitten by this 'feature' as well. i hacked out a bad solution where i checked the length of the block, and raised an error if it was larger than one. but this didn't solve the problem that the nested dtml was still evaluated. which troubles me since i think it could be a security problem in the context of my tag. > I propose a change to DT_String to allow a tag to turn off this > preparsing feature. It should be easy enough to implement by adding a > class attribute to the tag class such as disable_dtml_block_parsing = 1. > Is this abhorrent to anyone? sounds good to me. > If not, I will make a patch for DT_String to support this. The > beneficial side affect would be that could be "fixed" so > that its contents need not be parsable anymore, just like every other > language I know of. cool. Kapil Thangavelu ___ 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] SiteAccess and Catalog
Toby Dickenson wrote: > > Has anyone got a ZCatalog working with SiteAccess? Ive tried 2.2.0 > through 2.2.5, and Im seeing that it is storing paths to objects that > it cant later traverse. I think 2.3 is probably your best bet. I did manage it, but only by carefully making sure that stuff was catalogued under the correct virtual host, that only works if people only acces the stuff through one virtual host, more than one and you're stuffed :-S (I think I did something cunning in Squishdot to get around this, but that was a while ago :-S) 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 )
[Zope-dev] SiteAccess and Catalog
Has anyone got a ZCatalog working with SiteAccess? Ive tried 2.2.0 through 2.2.5, and Im seeing that it is storing paths to objects that it cant later traverse. Any help greatly appreciated, Toby Dickenson [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] DTML block parsing
I am working on a custom DTML tag (that I may unleash on the world when finished) that has brought to my attention an interesting feature of the DTML parser: It preparses everything in the block(s) between the start and end tags before the document containing the code is committed. My tag is a little different in that I don't want to put DTML inside it, therefore this parsing is undesirable. There is however one built-in tag that this is true for as well: . Many a thread has been burned about that issue. I propose a change to DT_String to allow a tag to turn off this preparsing feature. It should be easy enough to implement by adding a class attribute to the tag class such as disable_dtml_block_parsing = 1. Is this abhorrent to anyone? If not, I will make a patch for DT_String to support this. The beneficial side affect would be that could be "fixed" so that its contents need not be parsable anymore, just like every other language I know of. -- | Casey Duncan | Kaivo, Inc. | [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] OpenBSD 2.8 and Zope - thread errors
Hi, I stumbled across a problem when trying to run Zope on our brand new OpenBSD 2.8 installation - Zope crashes when you try to access it. I did a search of the mailing lists, and found out that there is something wrong with libc_r in OpenBSD that prevents it from running Zope. The message can be found here: http://lists.zope.org/pipermail/zope/2001-January/038400.html Does anybody here know if anything has been done about this? I tried the OpenBSD mailing lists, but couldn't find anything. And is running Zope 2.3beta2 on Python 2.0 an option? Will that work? Or is Python 2.0 also suffering from this bug? The LD_LIBRARY "hack" mentioned in the mail I referred to above doesn't sound like a good idea to me. Not a lasting one, anyway :) Regards, Alexander Limi ___ 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] Added rename to ZOPE FTP server
Tom Vijlbrief wrote: > > Hi, > > I've added the rename capability to the Zope FTP-server, > so I could use the KDE FTP client (this is a known Zope bug). Cool :-) Thank you very much Have you put them into the collector? http://classic.zope.org:8080/Collector/ 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 )
