[Zope-Checkins] SVN: Zope/branches/2.9/lib/python/Shared/DC/ZRDB/DA.py Backport fix for Collector #1429 to 2.9 branch: Fix name/value traversal of ZSQL methods

2006-06-21 Thread Casey Duncan
Log message for revision 68159:
  Backport fix for Collector #1429 to 2.9 branch: Fix name/value traversal of 
ZSQL methods
  

Changed:
  U   Zope/branches/2.9/lib/python/Shared/DC/ZRDB/DA.py

-=-
Modified: Zope/branches/2.9/lib/python/Shared/DC/ZRDB/DA.py
===
--- Zope/branches/2.9/lib/python/Shared/DC/ZRDB/DA.py   2006-05-17 06:11:27 UTC 
(rev 68158)
+++ Zope/branches/2.9/lib/python/Shared/DC/ZRDB/DA.py   2006-05-17 06:48:19 UTC 
(rev 68159)
@@ -527,10 +527,10 @@
 class Traverse(ExtensionClass.Base):
 Helper class for 'traversing' searches during URL traversal
 
-_r=None
 _da=None
 
 def __init__(self, da, args, name=None):
+self._r=None
 self._da=da
 self._args=args
 self._name=name

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


[Zope-Checkins] SVN: Zope/branches/Zope-2_8-branch/lib/python/Shared/DC/ZRDB/DA.py Backport fix for collector #1429 to 2.8 branch: Fix name/value traversal of ZSQL methods

2006-06-21 Thread Casey Duncan
Log message for revision 68160:
  Backport fix for collector #1429 to 2.8 branch: Fix name/value traversal of 
ZSQL methods
  

Changed:
  U   Zope/branches/Zope-2_8-branch/lib/python/Shared/DC/ZRDB/DA.py

-=-
Modified: Zope/branches/Zope-2_8-branch/lib/python/Shared/DC/ZRDB/DA.py
===
--- Zope/branches/Zope-2_8-branch/lib/python/Shared/DC/ZRDB/DA.py   
2006-05-17 06:48:19 UTC (rev 68159)
+++ Zope/branches/Zope-2_8-branch/lib/python/Shared/DC/ZRDB/DA.py   
2006-05-17 06:51:42 UTC (rev 68160)
@@ -527,10 +527,10 @@
 class Traverse(ExtensionClass.Base):
 Helper class for 'traversing' searches during URL traversal
 
-_r=None
 _da=None
 
 def __init__(self, da, args, name=None):
+self._r=None
 self._da=da
 self._args=args
 self._name=name

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins


[Zope-dev] Re: CatalogBrains.getObject and unrestricted code

2004-11-29 Thread Casey Duncan
In article [EMAIL PROTECTED], Florent Guillaume [EMAIL PROTECTED] 
wrote:

 In ZCatalog's brains, getObject currently does a restrictedTraverse to 
 get the object. That's a problem for unrestricted code that needs to get 
 to the object nevertheless, even if the user cannot get to it.
 
 For instance CMF is impacted, when it tries to reindex the security of 
 all subobjects of a given object.
 
 Unless someone is opposed to it, I'll add a _getObject method that does 
 an unrestrictedTraverse, and make CMF use it if available.
 
 Florent

getObject must be restricted since it can be called by untrusted code. 
It has been argued that it is currently too restrictive, and it should 
only validate the leaf object, but nothing has been done about this 
AFAIK.

You can work around this issue by using::

  unrestrictedTraverse(brain.getPath())

A (restricted) convenience method to do this could be added, but it 
doesn't really seem worth the effort IMO.

-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: Running Zope tests in 2.7 fails

2004-08-20 Thread Casey Duncan
IIRC this is caused by having a Python compiled without UCS4 support.
Some pre-built pythons that come with certain Linux distros (RedHat is
one I think) are built with different unicode support then the default.

I would suggest building your own python from source and trying it with
that instead.

-Casey

On Fri, 20 Aug 2004 12:12:31 +0200
Lennart Regebro [EMAIL PROTECTED] wrote:

 I have finally realized that the way tests are run in 2.7 is different
 
 from earlier version of Zope, and I'm trying to get them to run.
 
 It's Zope 2.7.2 on Debian. Python 2.3.4 and 2.3.2, so I guess 2.3.3 
 would give the same error. Could it be a side effect of the compiling
 or something?
 
 
 
 Here is the traceback:
 
 Running unit tests from /home/regebro/Zopes/Zope-2.7.2-0
 /home/regebro/Zopes/Zope-2.7.2-0/lib/python/DocumentTemplate/cDocumen
 tTemplate.so: undefined symbol: PyUnicodeUCS4_DecodeLatin1
 ['/home/regebro/Zopes/Zope-2.7.2-0/lib/python', 
 '/home/regebro/Zopes/Zope-2.7.2-0', '/usr/local/lib/python23.zip', 
 '/usr/local/lib/python2.3', '/usr/local/lib/python2.3/plat-linux2', 
 '/usr/local/lib/python2.3/lib-tk', 
 '/usr/local/lib/python2.3/lib-dynload', 
 '/usr/local/lib/python2.3/site-packages']
 Traceback (most recent call last):
File test.py, line 841, in ?
  process_args()
File test.py, line 831, in process_args
  bad = main(module_filter, test_filter, libdir)
File test.py, line 629, in main
  files = find_tests(module_filter)
File test.py, line 460, in find_tests
  os.path.walk(walkdir, finder.visit, rx)
File /usr/local/lib/python2.3/posixpath.py, line 290, in walk
  walk(name, func, arg)
File /usr/local/lib/python2.3/posixpath.py, line 290, in walk
  walk(name, func, arg)
File /usr/local/lib/python2.3/posixpath.py, line 282, in walk
  func(arg, top, names)
File test.py, line 439, in visit
  __import__(pkg)
File 
 /home/regebro/Zopes/Zope-2.7.2-0/lib/python/AccessControl/__init__.p
 y, line 16, in ?
  import DTML
File 
 /home/regebro/Zopes/Zope-2.7.2-0/lib/python/AccessControl/DTML.py, 
 line 18, in ?
  from DocumentTemplate import DT_Util
File 
 /home/regebro/Zopes/Zope-2.7.2-0/lib/python/DocumentTemplate/__init_
 _.py, line 22, in ?
  from DocumentTemplate import String, File, HTML, HTMLDefault,
  HTMLFile
File 
 /home/regebro/Zopes/Zope-2.7.2-0/lib/python/DocumentTemplate/Documen
 tTemplate.py, line 112, in ?
  from DT_String import String, File
File 
 /home/regebro/Zopes/Zope-2.7.2-0/lib/python/DocumentTemplate/DT_Stri
 ng.py, line 17, in ?
  from DT_Util import ParseError, InstanceDict, TemplateDict, 
 render_blocks, str
File 
 /home/regebro/Zopes/Zope-2.7.2-0/lib/python/DocumentTemplate/DT_Util
 .py, line 42, in ?
  from cDocumentTemplate import InstanceDict, TemplateDict, \
 ImportError: 
 /home/regebro/Zopes/Zope-2.7.2-0/lib/python/DocumentTemplate/cDocumen
 tTemplate.so: undefined symbol: PyUnicodeUCS4_DecodeLatin1
 
 
 Any ideas why this is? The Zope in itself seems to work fine. I have a
 
 2.7.0 instance to, it also fails, but with a completely different
 error.
 
 //Lennart
 
 ___
 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 )


[Zope-dev] Re: Referencial Integrity in ZCatalogs

2004-08-02 Thread Casey Duncan
You should be able to access it now anonymously.

-Casey

On Mon, 02 Aug 2004 17:07:30 -0300
Leonardo Rochael Almeida [EMAIL PROTECTED] wrote:

 Forgot to Cc: zope-dev
 
 -Mensagem encaminhada-
 From: Leonardo Rochael Almeida [EMAIL PROTECTED]
 To: Santi Camps [EMAIL PROTECTED]
 Subject: Re: [Zope-dev] Referencial Integrity in ZCatalogs
 Date: Mon, 02 Aug 2004 17:05:53 -0300
 
 I would suggest you take a look at mxmRelations, however Zope.org
 workflow is keeping it out of reach, and I couldn't find it on MaxM's
 own site.
 
 The URL for it would be:
 
 http://www.zope.org/Members/maxm/products/mxmRelations
 
 but right now it requires a login.
 
 If any kind soul from the Zope web team could release it, or if MaxM
 could post it somewhere else, that would be very nice.
 
 Cheers, Leo
 
 ___
 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 )


[Zope-dev] Re: any limits on object number?

2004-07-14 Thread Casey Duncan
On Wed, 14 Jul 2004 13:46:57 +0530
Nagarjuna G. [EMAIL PROTECTED] wrote:

 We are builiding a large portal using Zope.  We need to create a large
 number of objects.  The data component of the objects is small, but
 each object carries lots of metadata.  My question is: Is there any
 limit on the number of objects in a given folder?  I am not planning
 to use any external RDBMS. Are there any known performace isssues when
 the numbeer of objects increase, particularly when we store them in
 the same folder?

Normal zope folders should probably not be used to hold more than a few
dozen items. They store a list of their children in a single ZODB
record, and as their numbers increase so do the size of the transactions
that change the folder. Also normal Zope folders do not handle
concurrent updates and will thus not perform well when multiple users
are adding items to the folder.

Shane Hathaway's BTreeFolder2 product solves these problems. It is the
thing to use when you want to store large numbers of objects in a single
folder. It also handles concurrency much better.

hth,

-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: hasattr geddon

2004-07-09 Thread Casey Duncan
On Fri, 9 Jul 2004 16:22:17 +0200
Dieter Maurer [EMAIL PROTECTED] wrote:
[..]
 The hasattr replacement in Python's __builtin__ could look like:
 
 _marker = []
 def hasattr(obj, attr):
   return getattr(obj, attr, _marker) is not _marker
 
 
 Opinions?

+1

Another advantage to a global patch is that 3rd party products (such as
CMF) would benefit automatically. I noticed yesterday some hasattr calls
in DCWorkflow that could cause inaccurate results if the hasattr
returned false due to a ConflictError.

It might be worth profiling this and an alternate implementation in C to
see if the latter is worthwhile. I can't imagine the C implementation
would be all that complex. That would dispense with any performance
disadvantage of the patch.

-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: AccessControl Problems on Mac OSX

2004-07-08 Thread Casey Duncan
It looks like this bug was closed due to lack of feedback from the
original poster. I would suggest opening a new collector issue and
reference that one if you think it is the same issue (it certainly
appears to be on the surface).

The collector issue would stand a much better chance of being acted on
if you also submit a patch with a cooresponding unittest that fails on
Mac OS X with the current implementation.

-Casey

On Thu, 8 Jul 2004 15:12:13 +1000 (EST)
Terry Kerr [EMAIL PROTECTED] wrote:

 Hi,
 
 I seem to be having problems relating to AccessControl on MacOSX.  I
 have a python product which I previously ran in Zope2.4.3/Python 2.1.3
 and have upgraded it to run in Zope2.7.1/Python2.3.3.  It runs fine on
 Linux and FreeBSD, however I get this traceback with some actions
 within the product on Mac OSX 10.1
 
   Module Products.PageTemplates.Expressions, line 201, in __call__
 
   Module Products.PageTemplates.Expressions, line 189, in _eval
 
   Module Products.PageTemplates.Expressions, line 145, in _eval
 __traceback_info__: shopper
 
   Module Products.PageTemplates.Expressions, line 340, in
   restrictedTraverse
 __traceback_info__: {'path': ['name'], 'TraversalRequestNameStack':
 []}
 
 SystemError: NULL result without error in PyObject_Call
 
 
 
 I narrowed this down to a guarded_getattr() problem in the
 AccessControl module.  One thing I notice is that there is a C and a
 Python implementation of the access control stuff.
 
 If I explicitly set name='PYTHON' at the beginning of
 AccessControl/Implementation.py::setImplementation(), my product works
 fine, so I gather the problem is related to the C implementation.
 
 Has anyone experienced any similar problems on MacOSX?
 
 I notice this related issue in the zope collector, but it was
 rejected? http://zope.org/Collectors/Zope/232
 
 Should I add another issue to the collector?
 
 terry
 
 
 
 
 ___
 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 )


[Zope-dev] Re: CatalogBrains since Zope2.7.1b1

2004-06-25 Thread Casey Duncan
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] Re: CatalogBrains since Zope2.7.1b1

2004-06-25 Thread Casey Duncan
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

2004-06-25 Thread Casey Duncan
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: zope-dev list policies

2004-06-25 Thread Casey Duncan
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 )


Re: [Zope-dev] Re: CatalogBrains since Zope2.7.1b1

2004-06-25 Thread Casey Duncan
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] Re: zope-dev list policies

2004-06-24 Thread Casey Duncan
-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 rarely see spam get through list either (unless Gmane is filtering it
all out for me), so I fail to see the problem from that point of view.

-Casey

On Wed, 16 Jun 2004 21:24:07 -0400
Tim Peters [EMAIL PROTECTED] wrote:

 Over on the zope and zope-dev lists, there's currently agitation to
 make them members-only mailing lists.  The point is that spam could
 not get thru then (unless posted by a member).
 
 What would zodb-dev members like?
 
 Posting by a list member would not be affected, unless you attempted
 to send a message from an email account other than one you subscribed
 with.  In the latter case, your message would be bounced back to you.
 
 You could worm around that by subscribing to zodb-dev with that
 address too, then going to your list membership page on the web and
 checking the box to suspend email delivery on that account.  Then you
 could post using that account too, but wouldn't also get zodb-dev
 email on that account.
 
 I'm the list admin for zodb-dev, and don't have a preference.  If you
 do, and it's strong enough to scream it, shout.  The loudest screamer
 will winwink.  By default, I won't change the current policy (anyone
 can post here, member or not).


___
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: Prohibiting Spams on the List

2004-06-23 Thread Casey Duncan
On Tue, 15 Jun 2004 20:41:16 -0400
Tim Peters [EMAIL PROTECTED] wrote:

 [Mohsen Moeeni]
  Fristly excuse me for cross-posting. Actually, I did not like to be
  the person who comes this up however the amount of spams which is
  propagated thru the lists is annoying. I wonder why the guys at Zope
  Inc. does not tweak the list settings so posting is only allowed by
  the members.
 
 Perhaps just the weight of history, and/or trying to keep the barriers
 to participation as low as possible.  Speaking as zodb-dev's list
 admin, I'd be happy to restrict posting to members, *if* people don't
 object to the idea. I spend an increasingly resented part of each day
 doing list-admin triage(for zodb-dev and about 6 other mailing lists).
 
 A predictable irritation is that Mailman's answer to member? is
 based on the posting's sender's email address, but many people post
 from more than one account.  If you want the default action for
 non-member posts to behold for review, I won't do it -- I can't
 afford the additional time sink.reject is the no-manual-intervention
 default action, but it would place a new burden on members posting
 from non-member accounts (their posts would be rejected, at least
 until they asked the list admin to add their other posting accounts to
 Mailman's list of non-members to accept -- and they would need to do
 that on a per-list basis).

Another issue is posting from Gmane, which I am doing right now.
Although that may look like a post from me to mailman, I dunno.

-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

2004-06-20 Thread Casey Duncan
On Fri, 18 Jun 2004 07:13:15 +0200
Andreas Jung [EMAIL PROTECTED] wrote:

 
 
 --On Donnerstag, 17. Juni 2004 11:32 Uhr +0200 Eric Brun 
 [EMAIL PROTECTED] wrote:
 
 
 
  My object really exist and I check the getPath path : it's a correct
  path.
 
  When I use CatalogBrains.py of Zope2.7.0 on a Zope2.7.1b1,
  my object is correctly returned. The changes in the version of
  CatalogBrain= s.py in Zope2.7.1b1 can't find my existing object with
  a good path. I think=  there is a problem here. =
 
 
  I just alert a potential bug for the zope-dev community.
 
 
 I would really appreciate if you could provide a reproducable
 testcase. Otherwise
 it is unlikely that this will be fixed (for 2.7.1 final). Guessing is
 one thing, providing
 reasonable evidence is another thing. As Zope 2.7 release manager I am
 
 interested to
 have such bugs fixed *but*  I don't have time to figure out for *you*
 what might be the
 problem on *your* system.

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.

For hysterical raisins, REQUEST.traverse() does not behave this way. It
instead checks only the final object traversed. It might be reasonable
for ZCatalog to act this way, but I would need to be convinced ;^). I
consider the difference in these traversal behaviors to be a wart, but
one that is not easily fixed given application reliance on both
behaviors.

Another suspect behavior we might reconsider is the implicit contract
that getObject should not raise exceptions. Right now if the object
cannot be returned for any reason (such as it cannot be accessed due to
parent security settings) getObject returns None. It would probably be
better for it to raise the appropriate exception, but I think this would
break BW compatibility, *sigh*.

-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

2004-06-19 Thread Casey Duncan
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.

-Casey

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.
 
 is there any bug here ?
 
 Thanks
 
 
 Eric Brun
 Ingénieur de développement
 [EMAIL PROTECTED]
 
 Pentila
 Bâtiment Euclide
 73370 Le Bourget du Lac
 Savoie Technolac
 http://www.pentila.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 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: Bad idiom to access optional attributes

2004-06-07 Thread Casey Duncan
On Mon, 7 Jun 2004 07:46:41 +0200
Dieter Maurer [EMAIL PROTECTED] wrote:

[..]
 Meanwhile, the best way to access optional attributes seems to be
 
   if getattr(aq_base(obj), attrname, notFound) is not notFound:
   attr = getattr(obj, attrname)
 ...

Ahhh, the miracle of acqfuscation...

-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: {Spam?} Re: [Zope3-dev] Re: RFC: TALES adapters and TAL/Tales variable namespaces

2004-05-24 Thread Casey Duncan
On Mon, 24 May 2004 17:25:19 +0300
Steve Alexander [EMAIL PROTECTED] wrote:

 
 Of course, Steve suggested:
 
ob:adaptername   context:dc/title
  
  
  This really doesn't make sense. To me it reads In the namespace of
  context get the title of dublin core.
 
 I'm not reading : as having anything to do with namespaces.  Rather,
 I see '/' as the traverse operator, and : as the adapt operator.

Understood, that's just how it reads to me. Adapters are in a sense like
mini-namespaces, enough so that I think it is confusing to reuse the XML
namespace token here.

-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: Zope Bug Day - Friday 28th May?

2004-05-21 Thread Casey Duncan
On Fri, 21 May 2004 19:57:08 +0100
Chris Withers [EMAIL PROTECTED] wrote:

 Hi People,
 
 I offered to schedule and organise the Zope bug days for the last
 Friday of each month, and the first one of those is looming.
 
 Do people have any objections to Friday 28th May as a bug day?
 
 If I hear nothing, I'll begin more widely advertising next week...

+1, count me in.

How does this coincide with the 2.7.1 schedule?

-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 )


Re: [Zope-dev] Re: Zope Bug Day - Friday 28th May?

2004-05-21 Thread Casey Duncan
On Fri, 21 May 2004 21:27:02 +0200
Andreas Jung [EMAIL PROTECTED] wrote:

 
 
 --On Freitag, 21. Mai 2004 15:19 Uhr -0400 Casey Duncan
 [EMAIL PROTECTED] wrote:
 
  On Fri, 21 May 2004 19:57:08 +0100
  Chris Withers [EMAIL PROTECTED] wrote:
 
  Hi People,
 
  I offered to schedule and organise the Zope bug days for the last
  Friday of each month, and the first one of those is looming.
 
  Do people have any objections to Friday 28th May as a bug day?
 
  If I hear nothing, I'll begin more widely advertising next week...
 
  +1, count me in.
 
  How does this coincide with the 2.7.1 schedule?
 
 
 I am planning to release beta1 next Monday.

Sounds pretty much perfect to me. That leaves 3-4 days for beta bugs to
get submitted before bug day.

-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: [ZODB-Dev] Re: BTrees strangeness (was Zope 2.X BIG Session problems - blocker - our site dies - need help of experience Zope developer, please)

2004-05-17 Thread Casey Duncan
On Mon, 17 May 2004 19:00:16 +0200
Dieter Maurer [EMAIL PROTECTED] wrote:

 Chris McDonough wrote at 2004-5-15 13:04 -0400:
  ...
 Dieter, do you think you can read this patch and give a thumbs up or
 down on it?
 
 The patch looks good.
 
 On a different subject, the publisher probably shouldn't pass around
 traceback objects (e.g. when it calls into err_hook) as Tres believes
 that may be a memory leak waiting to happen.
 
 The traceback is vital for error analysis.
 
 It may not be necessary that ZPublisher touches the traceback
 but we will definitely need access to it during error handling.

Perhaps the traceback can be passed as a string to avoid leaks?
Furthermore why can't the traceback be retrieved later from
sys.exc_info()?

-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: Dis-allow anonymous bug posting?

2004-05-10 Thread Casey Duncan
On Mon, 10 May 2004 13:21:26 +0100
Chris Withers [EMAIL PROTECTED] wrote:

 Casey Duncan wrote:
  No, some very valuable bugs are submitted anonymously. People can be
  very paranoid (rightly) about their privacy. We do want to encourage
  bug submissions even if that means more noise.
 
 So on the one hand we say we rarely care about anonymous bug posts
 and on the other close anonymous bug posts as soon as we can.

I didn't say that. To me a bug is a bug. The only difference is that
anonymous postings can't really be replied to for more info, so vague
anonymous bug reports will likely be closed quicker because of this.

-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: Dis-allow anonymous bug posting?

2004-05-07 Thread Casey Duncan
On Fri, 07 May 2004 09:56:45 +0100
Chris Withers [EMAIL PROTECTED] wrote:

 Tim Peters wrote:
 
  While that *should* be a good example, it isn't:  I only knew that
  bug existed because someone closed it on Bug Day (and I'm subscribed
  to the Collectors, and read the email they generate).
 
 *bangs head against desk*
 
  Some bugs are so vaguely described nobody could guess -- and when
  they're anonymous too, there's no effective way to get more info. 
  Those ought to be closed.
 
 Indeed.
 
 How about removing the ability for people to post bugs withotu
 specifying n email address? And, if they do specify an email address,
 using that to contact them by sending notification mails to it?

No, some very valuable bugs are submitted anonymously. People can be
very paranoid (rightly) about their privacy. We do want to encourage bug
submissions even if that means more noise.

AFAIK the collector does mail the poster on state change if they have an
email address.
 
 For all I know, this happens already, but people don't perceive it as
 happening so the ythink anonymous bug postings will never be heard
 from and so close them straight away as anonymous, therefor we don't
 care

Nope, many times we do care. But when we don't we will close them.

To be clear: big -1 on restricting anonymous posting

-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: XML-RPC incorrect 404 return code

2004-05-07 Thread Casey Duncan
On Thu, 6 May 2004 22:30:49 -0500
[EMAIL PROTECTED] wrote:

 I reported this a few month ago with a patch and was told that it'll
 be applied 'soon':
 http://collector.zope.org/Zope/1175

Who told you that? I see no comment on that issue.
 
 IMHO the xml-rpc error handling is a mess. You can't define your own
 standard_error_message like method, sometimes it returns html code,
 sets the status code to 200 even if there's an error, etc. Is there an
 intention to fix these in 2.X?

By all means become a Zope contributor and fix this. That is the best
way to get things the way you want them.

See: http://dev.zope.org/CVS/ContributorIntroduction

-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 )


Re: [Zope-dev] Bug day report

2004-05-06 Thread Casey Duncan
On Thu, 6 May 2004 10:45:03 -0400
Tim Peters [EMAIL PROTECTED] wrote:
[..]
 On the Python bug tracker, I don't close vague bug reports instantly.
 Instead I add a note, saying that unless more information is added,
 the bug will be closed a month later.  It's rare that more info gets
 added then, so they usually do get closed -- but it's more graceful
 when the OP does add more info.

I intend to do this as well in the future. I assumed that bug reports
posted years ago with no followup had little or no chance of ever being
clarified now.

I will try to tread a little lighter on the Reject button and add a
comment requesting clarification regardless of age. If I don't hear any
for a month or so, then the bug will be closed.

-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: [Collector] Strange reject policy

2004-05-06 Thread Casey Duncan
On Thu, 06 May 2004 12:09:18 -0300
Leonardo Rochael Almeida [EMAIL PROTECTED] wrote:

 On Thu, 2004-05-06 at 11:56, Lennart Regebro wrote:
  From: Ken Manheimer [EMAIL PROTECTED]
   All the actions are verbs, won't fix is not a verb.  Can you
   suggest a verb the more clearly indicates the result is won't
   fix? 
  
  Tough one...
  
  Live with 
  Ignore
  Keep this bug as is
  Zenify
  Featurize (as in This is not a bug, it's a feature)
  Shove under carpet
  Forget
  Procrastinate
  Pretend to be deaf

How about:

Dis
Blow-off
Lose
Getouttahere

Or perhaps a passive-aggressive bent:

Agree
Yup
IDontDisagree
HowNice

Or my personal favorite:

Interesting

-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: [Collector] Strange reject policy

2004-04-30 Thread Casey Duncan
In retrospect I probably should have just marked it as deferred rather
than rejected, the idea was more to provoke action (which I did) then to
reject it as not-a-bug.

-Casey

On Fri, 30 Apr 2004 17:54:58 +0200
Dieter Maurer [EMAIL PROTECTED] wrote:

 I got a reject message for http://collector.zope.org/Zope/444;
 with the comment:
 
ZClasses are not being actively maintained, so unless you provide a
patch, it is not likely to be fixed.
 
 I see this as a strange reject policy.
 
 In my view, bug reports in the collector should only be rejected
 when they are not bugs or when they can not longer occur.
 We want that people with strange effects look into the collector
 to find out whether this is a known problem, don't we?
 Rejected bug reports are much more difficult to find than
 open ones.
 
 In this case, the issue reports a true bug which pose a potential
 security risk because a permission mapping unexpectedly has no effect.
 
 
 I do not argue that this bug needs a fix but the report should at
 least be easily found.
 
 
 -- 
 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 )


[Zope-dev] Re: [Collector] Strange reject policy

2004-04-30 Thread Casey Duncan
On Fri, 30 Apr 2004 13:46:26 -0400
Chris McDonough [EMAIL PROTECTED] wrote:

 On Fri, 2004-04-30 at 13:43, Casey Duncan wrote:
  In retrospect I probably should have just marked it as deferred
  rather than rejected, the idea was more to provoke action (which I
  did) then to reject it as not-a-bug.
 
 I think there needs to be another category named wontfix that
 doesn't imply that it will ever be fixed like deferred seems to. 
 This category should also be selected in the default search settings.

+1

I volunteer Chris to implement it ;^)

-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 )


Re: [Zope-dev] Bug day report

2004-04-30 Thread Casey Duncan
On Fri, 30 Apr 2004 20:14:30 +0200
Dieter Maurer [EMAIL PROTECTED] wrote:

 Casey Duncan wrote at 2004-4-29 22:19 -0400:
 I'm happy to report a successful bug day with a final tally of almost
 40 issues closed. The specific issues we squashed were:
 
 #28,#181,#321,#340,#349,#439,#444,#495,#511,#532,#540,#543,
 #544,#545,#546,#553,#562,#574,#584,#602,#637,#644,#654,#658,#666,
 #678,#724,#800,#810,#811,#875,#1003,#1042,#1050,#1148,#1227,#1298,
 #1300.
 
 However, you closed (at least one) bug reports without resolving the 
 the issue.
 
 I do not think this is good practice...
 
 Bug reports should remain open until they are either fixed
 or can no longer occur. They should not be closed just because you
 do not plan to fix them in the near future...

If a bug will not be fixed, judged by::

 - The bug description

 - The time it has remain open without action

 - The lack of a patch provided for the bug

 - The lack of assignment or interest of a sponsor

This means it is an unsponsored bug. It should not remain open forever.
The bug collector is not a substitute for documentation and issues that
will never be resolved should be closed. Otherwise it wastes the time of
volunteer bug-fixers. 

I think the current collector is a bit flawed in the available statuses.
There is no specific way to denote an issue as won't fix which means
that it is possibly a bug, but either it is not fixable, is not deemed
worth fixing, cannot be fixed with the information provided, or nobobdy
has fixed it for years so it's not gonna happen.

I chose to reject the bug hoping that it would cause a reaction, which
it did. I'll admit that reject is not exactly the right status,
however the right status is not currently an option for the collector.

Since I can see you feel strongly about this issue, please feel welcome
to reopen to bug or change it to a status that better suits it. At this
point I see no chance of it being fixed without a champion, 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] Bug day!

2004-04-29 Thread Casey Duncan
Just a reminder that bug day is on today. Meet us over on the #zope-dev
channel of irc.zope.org if you can!

-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] Bug day report

2004-04-29 Thread Casey Duncan
I'm happy to report a successful bug day with a final tally of almost 40
issues closed. The specific issues we squashed were:

#28,#181,#321,#340,#349,#439,#444,#495,#511,#532,#540,#543,
#544,#545,#546,#553,#562,#574,#584,#602,#637,#644,#654,#658,#666,
#678,#724,#800,#810,#811,#875,#1003,#1042,#1050,#1148,#1227,#1298,
#1300.

Thanks to all who participated!

-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] Zope Bug Day Next Thursday (April 29)

2004-04-22 Thread Casey Duncan
I proposed this yesterday, but I wanted to make sure that everyone say
it. I think we should have a bug day, we're long overdue. I'm proposing
we hold it on Thursday, April 29.

We'll convene on the #zope-dev irc channel.

-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: The bleak Future of Zope?

2004-04-21 Thread Casey Duncan
On Wed, 21 Apr 2004 11:36:31 +0200
Andreas Jung [EMAIL PROTECTED] wrote:

 Some remarks from my side as a Zope2 core developer on this issue:
 
 The Z2 community and development is currently at a bad point:
 
  - very few people are contributing to the Z2 in terms of new code and
  bug 
 fixes
 (see the tons of open bugs in the collector)

I agree that bugs deserve more attention. We need to have more bug days.
I meant to suggest a date last week, but I got diverted. How would
people feel about next Thursday, April 29?
 
  - very few people are willing to contribute to documentation

On a bright note, I think zopewiki.org could change that. It *greatly*
lowers the bar on contributing substantive docs for Zope. I would
implore all of you (as in you, the reader of this message, yes you!) to
go there and write something, now! You know something that has not been
written down yet, so go write it down! You can even do so anonymously.

-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: Zope Book, was Re: The bleak Future of Zope?

2004-04-21 Thread Casey Duncan
On Wed, 21 Apr 2004 13:10:51 -0400
Chris McDonough [EMAIL PROTECTED] wrote:

 On Wed, 2004-04-21 at 10:18, Peter Sabaini wrote:
  That being said, I wonder if there are people interested to make an 
  effort for a 2.7 Edition of the Zope book?
 
 I am.  I think Paul is too.  It won't be nearly as much work as 2.5 -
 2.6.  Let's just do it.  Wanna pick chapters?  I'll get the new book
 set up on Zope.org (another BT book) and send the link to whomever is
 interested.

Joel Burton recently updated the ZCatalog chapter, which should be all
set for 2.7. So that one's already done.

-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: The bleak Future of Zope?

2004-04-21 Thread Casey Duncan
On Wed, 21 Apr 2004 20:36:29 +0200
Andreas Jung [EMAIL PROTECTED] wrote:

 
 
 --On Mittwoch, 21. April 2004 10:41 Uhr -0400 Casey Duncan
 [EMAIL PROTECTED] wrote:
 
  On a bright note, I think zopewiki.org could change that. It
  *greatly* lowers the bar on contributing substantive docs for Zope.
  I would implore all of you (as in you, the reader of this message,
  yes you!) to go there and write something, now! You know something
  that has not been written down yet, so go write it down! You can
  even do so anonymously.
 
 
 Yeah...just had a look a zopewiki.org it seems to be a great place. I 
 wonder why we were not
 able to built a such place there were it would belong to: zope.org?

I see no reason why it being or not being on Zope.org is relevant. Its a
social thing: Simon decided to do something and had the software,
bandwidth and hardware to do it. People have gravitated to it and it
looks like it has momentum. I see no downside, Darwin has spoken... ;^)

-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: Patch for CMFActionIcons: make edit work if icon expr is empty

2004-04-20 Thread Casey Duncan
On Tue, 20 Apr 2004 13:03:32 +0200
Joachim Bauch [EMAIL PROTECTED] wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hi,
 
 as it's possible to create an action icon with an empty icon
 expression, but this action icon can never be edited again (a KeyError
 is raised), I propose the attached patch against ActionIconsTool.py
 
 After applying this patch, you can edit the empty action icons.

Post this to the CMF collector so that the patch doesn't just wither
away in the mailing list archives:

http://zope.org/Collectors/CMF

-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: I want to fix App.Management.Tabs.manage_workspace

2004-04-19 Thread Casey Duncan
On Mon, 19 Apr 2004 10:16:08 +0100
Chris Withers [EMAIL PROTECTED] wrote:

 Hi there,
 
 App.Management.Tabs.manage_workspace sucks as I've described in
 http://zope.org/Collectors/Zope/1286:
 
 1. manage_workspace is only protected by the Authenticated role, and
 that is done directly, not even through a permission.

I think that is probably because this method is an abstraction for the
default managment screen. It does not know what the correct permission
is, but assumes you at least must be logged in to see any management
screen.

What are you suggesting to do about this?
 
 2. self.filtered_manage_roles then limits the options of what can be
 shown, which might end up being nothing. But, because the method is
 only protected by 'Authenticated', no chance is given to specify other
 user credentials (say, from a user folder higher up in the tree) which
 might be able to see something.

Can you give a concrete use case for what you describe?
 
 3. There's a bare try/except which masks errors. From what I can see,
 it should ONLY catch IndexError's.

Yep, bare excepts == bad. Kill it.
 
 4. The raise TypeError could do with some explanation.

Ok.
 
 5. The Unauthorized could raise a more helpful message You are not
 authorized to view an of this object's management itnerface

-0, I think it may be better to say nothing which discloses less
information to would-be attackers. Perhaps VerboseSecurity might be able
to elaborate, I dunno.
 
 What do people feel about the right way to solve this? 3,4 and 5 I'm
 comfortable with fixing, but I'm stumped as to what the right thing
 is to do on 1 and 2 which combine to create a thorny problem.
 
 The semantics I want are: Show the 1st management tab the user is
 allowed to see, if they're not allowed to see anything, check if a
 user of the same name further up the userfolder tree can see anything

Why? Is this consistent with behavior elsewhere? Are you concerned that
lower user folders could lock out global managers by creating
non-privileged users with the same name locally? I say YAGNI unless this
behavior is somehow inconsistent.
 
 Is that right? If so, how do I go about implementing it? Finally, what
 branches should I do this on?

2.7 and the HEAD are likely suspects for bug fixes. I doubt there will
be another 2.6 release.

-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: RFC: A proposal for ZODB schema migration in Zope 3

2004-04-19 Thread Casey Duncan
On Sat, 17 Apr 2004 08:14:35 -0400
Jim Fulton [EMAIL PROTECTED] wrote:

 
 I've posted a proposal:
 
http://dev.zope.org/Zope3/DatabaseGenerations
 
 for a framework for managing the migration of application/database
 schemas in ZODB databases in an orderly manner.  The proposal is to
 apply this new framework in Zope 3, however, if it works well, it
 would be applicable to Zope 2 and other ZODB applications.
 
 Comments are welcome.

+1

It might be nice if some of this mechanism was distributed in ZODB
itself, or at least the ZODB docs pointed to the implementation as an
example of how it could be done. This is definitely a problem not
limited to Zope.

-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: Zope + Ape + Subversion (was: RE: Using a truely revis ion based storage for Zope ?)

2004-04-16 Thread Casey Duncan
On Thu, 15 Apr 2004 20:40:09 -0400 (EDT)
Shane Hathaway [EMAIL PROTECTED] wrote:

 On Wed, 14 Apr 2004, Kapil Thangavelu wrote:
 
  although i wonder if there is some hand waving in progress here that
  i can't see. i guess my semantic notion of versions has been that of
  long lived transactions, and is there a better means of thinking of
  them? how do they play across with multiple mounted zodbs? what
  would something like merge mean in the context of a catalog?
 
 By my understanding, outside the storage, different versions are
 completely independent.  You could even simulate multiple databases
 using versions.  It is the storage that knows how to create new
 versions, merge versions, and prevent objects being used in a version
 from being changed.
 
 Mounted databases try to use the same version as the root connection.
 
 To merge a catalog, you could bring one of the stored catalogs to life
 within the storage and replay the sequence of transactions that
 occurred in the other catalog.  This could be tricky, and opening a
 catalog within a ZEO server would make the ZEO server less stable.

Ok, running the catalog on the storage server. Now that's crazy talk ;^)

running-awayly y'rs,

-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: Zope + Ape + Subversion (was: RE: Using a truely revis ion based storage for Zope ?)

2004-04-14 Thread Casey Duncan
On Wed, 14 Apr 2004 06:59:05 -0400
Kapil Thangavelu [EMAIL PROTECTED] wrote:

 On Tue, 2004-04-13 at 12:01, Shane Hathaway wrote:
  On Tue, 13 Apr 2004, Kapil Thangavelu wrote:
  
   since
   objects modified in a version are in essence locked from
   participating in other transactions, actions like modifying
   content in a version in a cmf site amounts to locking the catalog
   from changes outside of the version, which amounts to shutting
   down write activities to a cmf site.
  
  This is only true of FileStorage.  Some other storage could
  implement ZODB versions with merging capability rather than locking.
  
 
 good point, just because hasn't been doesn't mean it can't ;-)
 
 although i wonder if there is some hand waving in progress here that i
 can't see. i guess my semantic notion of versions has been that of
 long lived transactions, and is there a better means of thinking of
 them? how do they play across with multiple mounted zodbs? what would
 something like merge mean in the context of a catalog?

Catalogs are actually fairly easy to handle, at least in theory. The
state of the catalog directly depends (and is derived from) the current
state of the cataloged objects. So merging the catalog should mean:
merge the content first and then reindex it.

From this pov, it would be possible to get cataloging right in the
current version machinery as well. This machinery would need to allow
objects to override the locking behavior in some way. In the case of the
catalog it would be fine for a current catalog and the one in the
version to ignore each other (i.e., changing the one in the version does
not lock the current one). Then when the version is saved/merged, the
affected objects are recataloged.

In practical terms this would mean that the versioned catalog would need
to keep track of the uids that had been cataloged, uncataloged and
reindexed in the version. The merge would mean cataloging,
uncataloging and reindexing those same uids in the current catalog.

-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: Zope + Ape + Subversion (was: RE: Using a truely revis ion based storage for Zope ?)

2004-04-14 Thread Casey Duncan
On Wed, 14 Apr 2004 09:50:17 -0400
Casey Duncan [EMAIL PROTECTED] wrote:
[..]
 In practical terms this would mean that the versioned catalog would
 need to keep track of the uids that had been cataloged, uncataloged
 and reindexed in the version. The merge would mean cataloging,
 uncataloging and reindexing those same uids in the current catalog.

A complicating factor to this though is that it would need to be done
*after* all of the other content merges. That implies some sort of
dependancy graph, *bleah*. I've never been terribly fond of the idea of
catalogs as top-level instance space objects (i.e., peers to the content
they catalog), and things like this are one of the reasons why.

In any case it might be good enough for an object to be able to say
merge me last. Other toolsy and servicey sorts of objects that depend
on content (like a workflow state repository) might want to do so as
well. As long as the state of the tools doesn't depend on each other,
then it's ok. That last sentence is making me a little ill, 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] Re: Zope and zope

2004-04-14 Thread Casey Duncan
+1 this is a problem.

The question is whether curing it is *more* of a problem.

-Casey

On Wed, 14 Apr 2004 09:00:26 -0400
Jim Fulton [EMAIL PROTECTED] wrote:

 Jim Fulton wrote:
  
  Zope 2 has a package named Zope. Zope 3 has a package named
  zope. Starting with Zope 2.8, parts of Zope 3 will be included in
  Zope 2. As things stand, this will require having both Zope and
  zope packages. Python can handle this fine, however, it will
  require putting the packages in separate directories (for Windows). 
  A typical Zope installation will probably add at least two
  directories to the Python path, for:
  
  - The Zope software
  
  - Instance (site) specific packages
  
  So adding two directories, rather than one for the Zope software
  isn't a big deal.
  
  Of course, having two packages with names differing only in case is
  a bit ugly.
  
  Do we want to consider renaming one or both of these packages
  to avoid the conflict?
 
 I should have been clearer.
 
 The first question is:
 
 Is it a problem to have two packages with names differing only in
 case?
 
 I haven't gotten as many responses on this as I expected.  I'll try to
 summarize so far:
 
 - Chris feels strongly that this is a problem
 
 - I've been swayed by Chris' response from neutral to thinking that
 this
is a problem.
 
 - Tres seems not to think this is a problem, but I'm not sure.
 
 - Fred doesn't seem to think this is a problem.
 
 - I can't tell from Robert's and Stephans responses whether they think
 this
is a problem or not.
 
 Perhaps we can get more input on whether there's a problem.
 
 A response with a positive sign (e.g. +1, +0, +2, ...) indicates
 agreement that this is a probelm. :)
 
 Jim
 
 -- 
 Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
 CTO  (540) 361-1714http://www.python.org
 Zope Corporation http://www.zope.com   http://www.zope.org


___
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: circular referenced persistent objects

2004-04-12 Thread Casey Duncan
On Sat, 10 Apr 2004 14:11:56 -0500
[EMAIL PROTECTED] wrote:

 I have the following setup (unrelated lines are omitted):
 
 class Deliverer(Folder):
 def manage_afterAdd(self, item, container):
 if item is self:
 self.__ac_local_roles__ = dr_localroles(self)
 
 class dr_localroles(Persistent):
 def __init__(self, dr):
 self.dr = dr
 
 dr_localroles implements a few methods of the dictionary interface, so
 I can always check the effective settings via the Security/local roles
 zmi page. In order to computing roles, dr_localroles requires its
 parent object instance (Deliverer), that's why I store a reference to
 it as an attribute.
 Question:
  - Is there a way for dr_localroles to refer its parent without
  holding
 a reference to it or using weak reference?

Yes, use acquisition. Make dr_localroles inherit from
Acquisition.Implicit or Acquisition.Explicit.

  - Is there an equivalent of sys.getrefcount for ZODB persistent
 objects?

Cycles like this will not be a problem for ZODB. When either object is
deleted it will no longer be reachable from the root, regardless of
cycles between them. When the database is packed, unreachable objects
are removed.
 
 Also a note for the archives:
 I wanted to make sure that if I delete a Deliverer object, it will
 indeed be removed from ZODB. 

Once you pack, yes.

 For this I got the oid of the object,
 deleted it and than tried to get it back via the oid. The trick is,
 that you'll only get a POSKeyError if you pack the database and flush
 the cache. This latter one was not obvious for me.

Such tricks are not necessary and cause your app to rely too much on the
curent implementation of ZODB. Just let the database take care of this
for you.

In any case, there is a (new) persistent weakref class in ZODB 3.3 which
allows you to weakly refer to other persistent objects without causing
them to stay in the database like normal references do.

-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 )


Re: [Zope-dev] Re: circular referenced persistent objects

2004-04-12 Thread Casey Duncan
On Mon, 12 Apr 2004 10:57:43 -0500
[EMAIL PROTECTED] wrote:

 Casey,
 
 Thanks for the clarification.
 
- Is there an equivalent of sys.getrefcount for ZODB persistent
   objects?
 
 This is still a question. Is there any way, to determine how many
 times a zodb persistent object is referenced? sys.getrefcount seems to
 tell me only those references which are currently loaded in the
 memory. Also another very interesting question is that who referring
 to a specific object.

Not from a given object. You would need to walk the forward references
(which are tracked) of all the objects to find this out. I posted some
code to do this from any starting object in the ZODB a long time ago.
Search the mail archives if you're interested.
 
   For this I got the oid of the object,
   deleted it and than tried to get it back via the oid. The trick
   is, that you'll only get a POSKeyError if you pack the database 
  and flush
   the cache. This latter one was not obvious for me.
  
  Such tricks are not necessary and cause your app to rely too 
  much on the
  curent implementation of ZODB. Just let the database take care of
  this for you.
 
 I used this trick only for exploring ZODB behavior. The application
 doesn't do any nasty tricks.

ok.

-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: Unique ID generation with ZODB.

2004-04-06 Thread Casey Duncan
On 05 Apr 2004 14:18:25 +0200
Syver Enstad [EMAIL PROTECTED] wrote:

 
 How does one implement a unique id generator in ZODB. The id's should
 be strictyl ascending and be a an int. Would opening a temporary
 connection increment a persistent counter and commit do the trick?

Why does it need to be ascending? If you remove that requirement it
makes it nearly trivial to implement.

-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: Proposal: Sanitize HelpSys API Reference, was Re: Reasons for the current API reference docs implementation?

2004-04-05 Thread Casey Duncan
On Sun, 4 Apr 2004 17:50:13 -0400
Paul Winkler [EMAIL PROTECTED] wrote:

 I've posted my proposal:
 http://dev.zope.org/Wikis/DevSite/Proposals/SanitizeHelpSysAndAPIReference

I am 100% for this proposal and I have been thinking on and off about
the same thing for years. I agree that we need to create interfaces
everywhere. With that I propose the following to prevent future help
skew:

- That all interfaces in the system be verified in unittests. 

- We eliminate the duplicate interfaces currently used by the help
system (Some of these are actually fairly up-to-date, so we should look
at them first).

- If we create examples that they be runnable doctests, which are
executed by test.py

The latter may mean we need a better integration test framework, I don't
know. I think we'd need to try out a few and see. I can certainly help
here.

IMO this is a task ripe for a divide and conquer strategy. Maybe we
should have a Help Day to kick this off?

-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: Proposal: Sanitize HelpSys API Reference, was Re: Reasons for the current API reference docs implementation?

2004-04-05 Thread Casey Duncan
On Mon, 5 Apr 2004 11:00:59 -0400
Paul Winkler [EMAIL PROTECTED] wrote:

 On Mon, Apr 05, 2004 at 09:44:30AM -0400, Casey Duncan wrote:
  On Sun, 4 Apr 2004 17:50:13 -0400
  Paul Winkler [EMAIL PROTECTED] wrote:
  
   I've posted my proposal:
   http://dev.zope.org/Wikis/DevSite/Proposals/SanitizeHelpSysAndAPIReference
  
  I am 100% for this proposal and I have been thinking on and off
  about the same thing for years. I agree that we need to create
  interfaces everywhere. With that I propose the following to prevent
  future help skew:
  
  - That all interfaces in the system be verified in unittests. 
 
 Pardon my ignorance, but what tests can you write for an interface?

You can verify that a class or object implements an interface using the
Verify module of the Interface package. It give you at least some
protection against interface changes. It doesn't protect against all
skew (the object can implement a superset of the interface and still
verify), but it at least performs a sanity check.

Whenever I write tests, the first one is generally an interface check.

It might be nice to think about ways to make this check more rigorous.
For example, methods protected by permissions or marked public should
*always* be part of an interface. We could write a check to make sure
that the interfaces implemented by an object cover all of the published
API of that object. The deep inheritance in Zope2 might make that
tricky, but it's food for thought.

A *very nice* side-affect of all this will be that we will have
interface coverage throughout Zope2 (and at least minimal test coverage
to check the interface). This will obviously help integrating with Zope3
down the line.

-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: [ZODB-Dev] Re: BTrees strangeness (was Zope 2.X BIG Session problems - blocker - our site dies - need help of experience Zope developer, please)

2004-03-10 Thread Casey Duncan
On Wed, 10 Mar 2004 17:50:41 -0500
Chris McDonough [EMAIL PROTECTED] wrote:

 Nevermind.  http://zope.org/Collectors/Zope/789 and
 http://zope.org/Collectors/Zope/786
 
 The bug neglector is really living up to its name lately (not pointing
 fingers, mea culpa).

'Bout time fer a bug day I reckon... ;^)

-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: Folderish object's __call__ fails

2004-03-04 Thread Casey Duncan
On Thu, 4 Mar 2004 13:03:20 -0800 (PST)
Dirksen [EMAIL PROTECTED] wrote:

 Hi,
 
 I'm developing a product, which extends ObjectManager. Meanwhile, I'd
 like it to behave like a script object, similar to DTML method. So I
 define a __call__ method. But it never gets run if called from the
 browser. If I change the base class to SimpleItem, it works. How can I
 make __call__ works for folderish object?

Try adding a class attribute index_html and set it to None. This is what
the CMF does to get __call__ invoked.

It's what we affectionately call a dead chicken, a sacrafice to the
Zope gods...

hth,

-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: server for new protocol?

2004-03-01 Thread Casey Duncan
On Mon, 1 Mar 2004 10:09:36 -0500
Fred Drake [EMAIL PROTECTED] wrote:

 On Sunday 29 February 2004 11:21 pm, Nikolay Kim wrote:
   P.S. i'm developing smtp server for zope and already have working
   code.
 
 Ooh!  This is really cool.  Will this be open source?  I'll be a lot
 of people will be interested in this.

Me too, me too! ;^)

-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: Usability tweaks

2004-03-01 Thread Casey Duncan
On Mon, 01 Mar 2004 20:25:54 +
Christian Theune [EMAIL PROTECTED] wrote:

 Hi,
 
 as I'm tweaking stuff here and there right now, I stumbled over the
 findSupport dtml that has a multiple select menu with a height of 4.
 It's almost impossible to find what you look for easily. Increasing
 the height to 8 would be good. Anything against that?

Sounds great to me.
 
 Christian
 
 PS: Anything against simply doing those small changes?

I say go ahead. Just make sure you write liberal check-in comments and
test in various browsers (even stupid stuff breaks on *some* browsers).
Also update CHANGES.txt so people can tell what they're getting into
when they install the new release. I think enough of us monitor the
checkins to catch anything wacky pretty early.

At least that's my opinion...

-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: Maybe Corrupted ZCatalog but ...

2004-02-27 Thread Casey Duncan
On Fri, 27 Feb 2004 16:47:19 +0100
Eric Brun [EMAIL PROTECTED] wrote:

 
 
 Yes but impossible to update it because it is too big, and the
 transaction never finish or abort because of time out.
 
 I don't know how to do this.
 
 Have you a idea for help me ?

You might try using another browser (like mozilla) or updating the
catalog from python. In theory though the browser timeout shouldn't
cause the transaction to fail although I could be wrong about that.

-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: Zope 2.7 and objects turning into None

2004-02-22 Thread Casey Duncan
On Fri, 20 Feb 2004 22:18:33 +0100
Dieter Maurer [EMAIL PROTECTED] wrote:

 Casey Duncan wrote at 2004-2-20 10:53 -0500:
  ...
 This is a guess, but perhaps the Catalog is masking some other
 low-level error and returning None instead? I'll see if that seems
 possible from the code.
 
 Some time ago, I found out that
 OFS.Traversable.Traversable.unrestrictedTraverse
 catched ConflictError and returned default if a default has been
 specified.
 
 I filed a bug report but I am not sure whether this was fixed
 (it is fixed in our Zope version, of course).

I think so, I was just checking this code the other day working on
similar ConflictError swallowing happening in the Catalog. 

-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: Zope 2.7 and objects turning into None

2004-02-20 Thread Casey Duncan
On Fri, 20 Feb 2004 09:47:47 +1100
Richard Jones [EMAIL PROTECTED] wrote:

 On Friday 20 February 2004 05:52, Dieter Maurer wrote:
  We have a report for Zope 2.7 about an object magically turning
  into None (1 or 2 weeks ago).
 
 Sorry, I haven't been following this thread, but I will note that I've
 seen (repeatably) in my test Zope environment this behaviour.
 
 This is probably unrelated though...
 
 For me, the situation comes about when I am loading up my fresh (ie.
 clean ZODB) test Zope with a thousand users. While the load script is
 running (it runs on the command-line and goes TTW using urllib to
 register the users) if I access a page which summarises all users, I
 *sometimes* get None for some of the users. The page uses a Catalog to
 find basic user info, and sometimes uses getObject() to find the real
 user object. The getObject() appears to return None sometimes.

This is a guess, but perhaps the Catalog is masking some other low-level
error and returning None instead? I'll see if that seems possible from
the code.

-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: Image ranges

2004-02-19 Thread Casey Duncan
On Thu, 19 Feb 2004 14:55:08 +0100
Florent Guillaume [EMAIL PROTECTED] wrote:

 Is there a reason why OFS.Image.Image does not __implement__
 HTTPRangeInterface like OFS.Image.File does ?
 
 As far as I can see there's no reason it shouldn't, as their
 index_html method (and HEAD inherited from webdav.Resource) are the
 same.

No reason comes to mind. Are there any tests for range support?

-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 )


Re: [Zope-dev] Strange loop with ZCatalog

2004-02-13 Thread Casey Duncan
I already replied to this, but I never heard back from you.

What does the following return for a value:

len(list(context.TheCatalog.searchResults(Type='TypeTest')))

??

-Casey

On Fri, 13 Feb 2004 13:01:35 +0100
Pascal Samuzeau [EMAIL PROTECTED] wrote:

 Hi,   
   
 For some tests I have done :  
   
 - Create about 5000 folders under the Root Zope Site  
 - Inside those folders, I have created about 30 000 objects ( as  
 document, just an id, title and a Type).  
 - I've catalogued all inside a catalog named TheCatalog   
   
 I have written just this function, in intend to test my CPU ( that why
 I've written it like this):   
   
 allobject = context.TheCatalog.searchResults(Type='TypeTest') 
 l=len(allobject)  
 i = 0 
 #for i in range(len(allobject)):  
 for object in allobject:  
 #path = allobject[i].getPath()
 #course = allobject[i][0] 
 path = allobject.getPath()
 course = allobject[0] 
 thepath = string.split(path,'/')  
 lepath  = string.join(thepath[:-1],'/')   
 lieu=context.restrictedTraverse(lepath)   
 lieu.manage_delObjects(course)
 i+=1  
 return Len: %s and Number parsed: %s %(i,l) 
   
 Phase A:  
 I have 30 000 objects and the message following:  
 Len: 3 and Number parsed: 15001   
 In my catalog: 15000 object only were destroyed. !!!  
   
 Phase B:  
 I de-comment my comment lines, but I've got the same message. 
   
 I try to understand what it happens, but I can't. Anyone has a
 brillant idea?
   
 Sincerily 
 PS
 --
 Oreka ! Nous sommes l'internet moins cher !   
 Surfez 25% moins cher avec http://www.oreka.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 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] Strange loop with ZCatalog

2004-02-13 Thread Casey Duncan
On Fri, 13 Feb 2004 16:14:05 +0100
Pascal Samuzeau [EMAIL PROTECTED] wrote:

 Hi,   
   
   
  I already replied to this, but I never heard back from you. 
   
 I haven't seen your answer before, I'll search for it.  

That's ok. I think there are inconsistencies in the loop code. In my
message I explained what didn't make sense to me.
   
  What does the following return for a value: 
  
  len(list(context.TheCatalog.searchResults(Type='TypeTest')))
   
 Just for now 62418.   
   
 len (context.TheCatalog.searchResults(Type='TypeTest')) returns 62418 
 too.

Good, so that means that len() of the result set isn't lying.

-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 )


Re: [Zope-dev] Strange loop with ZCatalog

2004-02-13 Thread Casey Duncan
On Fri, 13 Feb 2004 19:10:07 +0100
Pascal Samuzeau [EMAIL PROTECTED] wrote:

 Hi Casey, 
   
 Yes it doesn't lie at all, but i've tried till I suppress all and even
 with 2 it suppressed only one.
   
 Can you tell me more about your message, I haven't found it.  

Bud, Google is your friend:

http://aspn.activestate.com/ASPN/Mail/Message/zope-List/1993758

-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 )


Re: [Zope-dev] How to make Zope fail nicely under high load?

2004-02-11 Thread Casey Duncan
On Wed, 11 Feb 2004 20:25:14 +0800
Bjorn Stabell [EMAIL PROTECTED] wrote:

 Toby wrote:
 [...]
  Zope's ZServer manages a queue of requests that have been 
  recieved over http, 
  but not dispatched to the publisher. This is handled in 
  PubCore/ZRendezvous.py. I suspect this queue will be holding 
  your backlog. 
  
  You might get some benefit from capping the length of that queue.
 
 Thanks Toby.
 
 It doesn't seem like that queue (the requests list) has a cap at all.
 Have been stresstesting Zope for a few minutes and the queue is up to
 300+ requests in the backlog queue.  Not sure how to force a 503
 return from within ZRendezvous.handle(), though; that's ZServer medusa
 magic.
 
 300 requests at 1 request per 2 seconds yields a backlog of work of 10
 minutes.  This is before we've started optimizing.

What kinds of requests are these? Do they all require a dynamic output?
If not, then you should put better caching in front of Zope, or at a
minimum tweak you caching headers so that some could be served as 304s
for instance.

If they are all dynamic, how dynamic? How different is the page for one
session than another? If much of the page is the same then you might
benefit from an ESI approach where you cache parts of pages and assemble
them in the cache, serving only small pieces from Zope.

I'm a bit surprised that you have not (from what I can see), used the
most common Zope speedup (and often the cheapest overall): Buy more
hardware and use ZEO.

 I wonder if Zope also processes requests that have been closed from
 the client end?  I know Zope will continue processing a request even
 if it times out at least (so you can do long-running requests, like
 packing, through the web).  Many (all?) of these 300 requests would
 have been closed by the time Zope got to process them, and so Zope
 shouldn't bother with them.

Why would they be closed by the client?

-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 )


Re: [Zope-dev] Adapters in Zope 2

2004-02-10 Thread Casey Duncan
On Mon, 09 Feb 2004 21:48:29 +0100
Santi Camps [EMAIL PROTECTED] wrote:

 Hi all,
 
 I know that adaptors are introduced in zope3 but, anybody knows if
 this technique can be used in zope2 ?

Adapters are a general pattern. Zope 3 has infrastructure (component
architecture and ZCML) that automates registering and using them, but
the general pattern can certainly be applied to Zope 2 without it. Just
create a class which defines the methods you want, and accepts a folder
in its constructor. When you want to use the adapter, instantiate the
class around the folder.
 
 I've been trying to add some extra functionallity to a Folder object
 without inheriting, but I'm not able to make it work.  To maintain the
 adapted object publishable I've rewrited __getattr__, but then some
 extra problems appears.  

__getattr__ hooks are notoriously tricky to get right, especially for
Zope due to acquisition and especially for folders.
 
 Anybody knows if there is a way to use adapters in zope2 ?  Or, if
 not, there is some other way to add functionallity on-the-fly, without
 inheriting ?

Zope2 folders are designed for this. They are really just blank
objects where you can specify your own methods in instance space.
Traditionally in Zope2, there are two ways to do this: by adding
method objects (External Methods, DTML methods, python scripts, ZPT)
directly to the folder. Or by adding these objects above the folders
and aquiring them which is a type of environmental inheritance. In the
CMF this is codified in the skins tool which contains global methods
which can be applied to basically any object in the site.

hth,

-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 )


Re: [Zope-dev] Re: Adapters in Zope 2

2004-02-10 Thread Casey Duncan
On Tue, 10 Feb 2004 15:26:00 +0100
Michael Haubenwallner [EMAIL PROTECTED] wrote:

 Casey Duncan wrote:
  Zope2 folders are designed for this. They are really just blank
  objects where you can specify your own methods in instance space.
  Traditionally in Zope2, there are two ways to do this: by adding
  method objects (External Methods, DTML methods, python scripts,
  ZPT) directly to the folder. Or by adding these objects above the
  folders and aquiring them which is a type of environmental
  inheritance. In the CMF this is codified in the skins tool which
  contains global methods which can be applied to basically any object
  in the site.
 
 Great explanation - would you give me a hint on the CMF part ?
 Which global methods do you speak of ?

The CMF has a Tool infrastructure. Tools are persistent objects
typically at the top of the CMF site. Tools provide methods and
configuration for use by all objects in the site via acquisition. For
example, the membership tool (portal_membership), provides methods to
access member information and member folders.

The portal_skins tool is special in that it actually contains framework
and application defined method objects (scripts, templates, etc)
organized into layers and configured into skins (which are lists of
layers to use). The CMF Site object is a special Skinnable folder
which allows methods available in the current skin (as described in the
skins tool) to be acquired through it. This makes all of the method
objects in the skin's layers globally available to all objects in the
CMF site. 

This solves several problems, one of which is a tendancy of top-heavy
hierarchies in zope where lots of objects are in the root because they
need to be global. The skin and layer mechanisms allow different sets of
methods to be available depending on the application, products
installed, site policy and user preferences.

-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 )


Re: [Zope-dev] Re: Adapters in Zope 2

2004-02-10 Thread Casey Duncan
On Tue, 10 Feb 2004 17:34:39 +0100
Santi Camps [EMAIL PROTECTED] wrote:
[..]
 Very interesting.  That's what I was looking for.  I will try to
 extract this mechanism from CMF.

See: http://www.plope.com/Members/chrism/standalone_skins

8^)

-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 )


Re: FW: [Zope-dev] strange behavior of VirtualHostMonster

2004-02-05 Thread Casey Duncan
On Wed, 4 Feb 2004 22:50:27 -0600
[EMAIL PROTECTED] wrote:

 Okay, I debugged a bit more:
  [u'loginUser', u'usermgrFolder', '/', 'VHM']  = this looks weird to
 me
 
 It seems it's pretty okay, however the last line in
 VirtualHostMonster.__bobo_traverse__ says:
 return parents.pop() # He'll get put back on
 
 Of course, the popped item is 'a', that's the one with the
 beforetraversal hook, so if it's really put back on later, than the
 hook will run again. I think this is the explanation, but the question
 remains: how can I avoid the second call to the beforetraverse hook?

I also ran into this problem recently with an extension I wrote to
CookieCrumber (which has a before traverse hook). It had the unfortunate
affect of working on my local machine (where I was not virtual hosted)
but not on the production box (which did). Luckily I had a test Zope
instance on the production box. The obvious lessons: you can't test too
much, when you're sure it works test it some more and always test in the
*exact* environment as production (in other words the actual production
boxen).

The way CC handles this issue is to set a flag on the REQUEST on the
first run and check for the flag on subsequent runs. Not elegant to be
sure, but workable.

It seems like at the very least this should be a documented feature of
VHM, if not a subtle bug.

-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 )


Re: [Zope-dev] Re: Call for testing (2.6.4 / 2.7.0)

2004-01-28 Thread Casey Duncan
On Wed, 28 Jan 2004 13:36:31 +0100
yuppie [EMAIL PROTECTED] wrote:

 Hi!
 
 
 Brian Lloyd wrote:
  In the meantime, it would be helpful for anyone who runs from 
  the 2.6 or 2.7 branches in CVS to update and let us know if you 
  have any unresolved problems.
 
 Right now I have no time to track this down myself, but the attached
 CMF test failures seem to be related to the last Zope changes. Don't
 know if these tests need to be updated or if they reveal a bug in
 Zope.

These tests seem pretty naive. I don't thing user objects promise to
compare to one another in any way. Looks to me like the tests should be
changed to something like:

self.failUnless(f.getOwner() is ownership)

-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 )


Re: [Zope-dev] Re: Resolved security-related collector issues for the public?

2004-01-21 Thread Casey Duncan
On Wed, 21 Jan 2004 16:16:15 -0800
Jamie Heilman [EMAIL PROTECTED] wrote:

 Maik Jablonski wrote:
  There are many admins / users out there who aren't able to do this 
  (maybe they should learn it, but that's another point). Installing
  Zope 2.6.3 was a big mess (even renaming in the ZMI was broken) and
  most people rolled back to 2.6.2. Some people run even 2.5.1 (lots
  of Debian-Users etc.).
 
 Debian users who continue to use the 2.5.1 packages are being done an
 injustice, I agree, and its too bad, but the Debian security policy
 fails when a maintainer takes on a package they can't keep up with and
 the security team isn't able to step in and cover for them.  It
 happens, the answer is usually to either find a new maintainer who can
 keep up, or remove the package from Debian.  One of Debian's strengths
 though is that they don't hide this information, users are encouranged
 to review the bug tracking system to get a feel for a package's
 relative stability and weigh the risks on their own.

ZC has developed (thanks largely to Tres) a patch-set against 2.6 for
the security fixes (and one can be regenerated from cvs as well, but the
patches are better segregated). These could in theory be used as a basis
for a patch set against 2.5.1.

Saying it would be a large, difficult task to effectively backport the
changes to 2.5 is an understatement, but it could be done. The
change-set for 2.6 is Python 2.1 compatible, so at least you don't have
to contend with that.

Selectively backporting only certain fixes, that affect the widest range
of sites, would be much easier to consider. This could mean some of the
more invasive and tricky fixes, such as the ones for vulnerabilities in
untrusted code, which IMO are really only a concern in a small minority
of sites, could be skipped for a 2.5 backport.

-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 )


Re: [Zope-dev] Re: [Zope3-dev] ZConfig: Keytype and section type extension

2003-12-29 Thread Casey Duncan
On Mon, 29 Dec 2003 15:48:03 -0500
Fred L. Drake, Jr. [EMAIL PROTECTED] wrote:
 Phillip J. Eby writes:
[snip]
   (The issue here is that Python requires keyword arguments to be
   strings rather than Unicode, even though attribute names can be
   Unicode.  ZConfig sets attributes using unicode because ZConfig
   schemas are XML, and therefore Unicode.)
 
 Annoying, isn't it?  Not sure it's worth fixing in Python.

I guess this just furthers my theory that all sufficiently advanced bugs and 
mis-features are indiscernible from unicode. Or, more succinctly: Blame Unicode ;^)

-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 )


Re: [Zope-dev] bizarre slicing behaviour in Zope

2003-12-17 Thread Casey Duncan
On Wed, 17 Dec 2003 15:30:50 -0500
Gerry Kirk [EMAIL PROTECTED] wrote:

 try this in a script in zope 2.7b3 (maybe others, too) if you want to go 
 crazy:
 
 dd = ('dd', 'diocese', 'Parish.2003-12-16.8636751973', 'bob', 
 'Workspace.2003-12-17.8140751750','gerry.2003-12-17.8140751750')
 
 return dd[4:]
 
 you should get the last two items from the tuple, but I get the last 
 item returned as a string
 
 if i loop through the slice, it's ok. it seems to be a publishing problem.
 
 Gerry

Look at the title of the browser window to see the other item of the tuple.

Welcome to 2-tuple publication ;^)

-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 )


Re: [Zope-dev] Re: On with the show....

2003-12-15 Thread Casey Duncan
On Mon, 15 Dec 2003 10:02:58 -0600
Evan Simpson [EMAIL PROTECTED] wrote:

 Sidnei da Silva wrote:
  If you look at FSPageTemplate, its obvious that it doesn't subclass
  ZopePageTemplate, but the solution is not so obvious. Using:
  
  pt_getContext = ZopePageTemplate.pt_getContext.im_func
 
 Wow, FSPageTemplate is lousy with this sort of thing, isn't it?  I'd 
 have spelled it ZopePageTemplate.__dict__['pt_getContext'], but your 
 code works out to the same thing.  I don't endorse this sort of 
 cross-tree method copying, but if we're going to do it on this scale, at 
 least we can make it tidier.  Before the Globals.InitializeClass:
 
 zpd = ZopePageTemplate.__dict__
 for m in ('func_code', '_default_bindings', 'manage_FTPget',
'get_size', 'PrincipiaSearchSource', 'document_src',
'pt_getContext', 'ZScriptHTML_tryParams'):
setattr(FSPageTemplate, m, zpd[m])
 
  A similar error also happened with FSImage.__str__ (which is assigned
  Image.__str__, but FSImage just subclasses FSObject).
  
  Any thought on those?
 
 Yep -- it seems very silly to copy a one-line method like that.

Smells like a broken class hierarchy to me. I really think we need to consider 
refactoring the code so this sort of sillyness isn't necessary.

-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 )


Re: [Zope-dev] virtual hosting variables [was: Re: Zope 2.7.0 b3 regressions]

2003-12-03 Thread Casey Duncan
On Wed, 03 Dec 2003 20:43:23 +0100
Yuppie [EMAIL PROTECTED] wrote:

[snip]
 
 So I think it would be great if VHM would add a variable like 
 'REQUESTED_URL' (should have a better name) that isn't further modified 
 on traversal.
 'http://example.org/test/path/to/object'

+1

I actually had a case recently where using traverse_subpath in a python script screwed 
up CookieCrumbler (which uses REQUEST.URL to determine where it should redirect). 
Basically it ate the end of the URL value so the login form redirected to the wrong 
place.

The evil hack fix was actually a REQUEST.set('URL', ...), in the python script before 
any unauthorized errors could be raised. Perhaps it should be called ACTUAL_URL or 
ORIGINAL_URL. This would be the thing that CookieCrumber would redirect to...

-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 )


Re: [Zope-dev] Re: New-style ExtensionClasses (Zope 2.8) -- MRO issue

2003-11-24 Thread Casey Duncan
On Mon, 24 Nov 2003 14:06:07 -0500
Jeremy Hylton [EMAIL PROTECTED] wrote:

 [snip] Then programmers
 will be able to understand the code :-).

Very interesting conclusion... I might argue that it would be a premature optimization 
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 )


Re: [Zope-dev] __before_publishing_traverse__problem

2003-11-21 Thread Casey Duncan
On Fri, 21 Nov 2003 17:33:43 +0100
lukasz [EMAIL PROTECTED] wrote:

 I have a problem.When I import my plone site from one server to other I 
 got :
 
 AttributeError:
 __before_publishing_traverse__
  
 What should I do  with that?

Post it to the *Plone* mailing 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 )


Re: [Zope-dev] Zope 2.7 b3 problem with reindexing catalog

2003-11-19 Thread Casey Duncan
On Wed, 19 Nov 2003 17:15:13 +0100
robert [EMAIL PROTECTED] wrote:

 If I try to reindex a (plone) portal_catalog I get the following error
 
 Traceback (innermost last):
 
 * Module ZPublisher.Publish, line 100, in publish
 * Module ZPublisher.mapply, line 88, in mapply
 * Module ZPublisher.Publish, line 40, in call_object
 * Module Products.ZCatalog.ZCatalog, line 474, in manage_reindexIndex
 * Module Products.ZCatalog.ZCatalog, line 459, in reindexIndex
 
 TypeError: catalog_object() got an unexpected keyword argument 
 'update_metadata'
 
 Display traceback as text

What version of Zope? I think you need to use 2.6.2+ which has this argument.

-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 )


Re: [Zope-dev] Structured text img html tag not working properly in Zope 2.61

2003-11-12 Thread Casey Duncan
On Wed, 12 Nov 2003 20:43:51 +0100
Max M [EMAIL PROTECTED] wrote:

 I have a site with lots of structured text.
 
 There are many img src='/some/image' tags in the texts. But after 
 upgrading from Zope 2.51 to Zope 2.61, I get broken images all over the 
 place.
 
 Example::
 
  img src='images/kreativ.jpg' align='left'
 
 This tag is turned into::
 
  img src=%3Ccodeimages/kreativ.jpg align='left'gt;
 
 While::
 
  img src=images/kreativ.jpg align=left

I think this is because single quotes are used to designate inline preformatted code 
sections. This causes unintended markup to occur inside image tags containing single 
quotes.

Maybe you can just mass replace the single quotes with double quotes.

-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 )


Re: [Zope-dev] Structured text img html tag not working properly

2003-11-12 Thread Casey Duncan
On Wed, 12 Nov 2003 21:52:55 +0100
Max M [EMAIL PROTECTED] wrote:
 
 
 Ay, that sucks. Customers have been using it for 2-3 years now. And they 
 have many many documents. I could write a converter, for converting it 
 into the new image tag, but that would suck too.

You could maybe try installing the old structured text package in the new Zope. It 
might be worth a shot.

-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 )


Re: [Zope-dev] Zope 2.7 beta 3

2003-11-10 Thread Casey Duncan
On Mon, 10 Nov 2003 10:27:10 +0100
robert [EMAIL PROTECTED] wrote:

 Hi there,
 there was talk about a 2.7 b3.
 I would like to test it out.
 We are going do deploy a new server by end of this month and I would like to 
 have it running 2.7 (reckless I know, but that is how I am)

Obi-wan would say, So was I, if you remember. I personally prefer the term leading 
edge over reckless ;^).

As for beta 3, Brian Lloyd, our fearless release meister became the father of a new 
child over the weekend. He had originally promised to do the beta 3 release this week, 
but I'm not sure whether that will go forward or not at this point.  I'm sure he will 
respond in email when he becomes available (sometime in 2008 ;^).

-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 )


Re: [Zope-dev] KeywordIndex performance / multiunion

2003-11-07 Thread Casey Duncan
On Fri, 07 Nov 2003 12:02:07 +
Seb Bacon [EMAIL PROTECTED] wrote:

 Casey Duncan wrote:
  On Thu, 06 Nov 2003 19:11:55 +
  Seb Bacon [EMAIL PROTECTED] wrote:
 A simple query for [A or B or C] against a KeywordIndex containing 
 27k objects is taking about 7 seconds on a Celeron 1.6Ghz, which seems 
 an absurdly long time to me.
  
  guess
  This time may be caused by fetching from the database. If so, then the
   only way to speed it up is increase the ZODB cache or get faster disks.
   Try the former and see if it helps. /guess
 
 Yup, absolutely right.  Upping the cache speeds it up to something sane. 
   However, I don't understand why.  The code does something like:
 
   set1 = self.index.get(1)
   set2 = self.index.get(2)
   sets = [set1, set2]
 
 ...so the sets will have come from the ZODB.  But the bit which takes 
 the time is the following line:

These are TreeSets most likely. The actual members of the sets are stored in separate 
persistent objects. This is done so that large sets can be fetched in chunks rather 
than all at once.

The ZODB tries to be lazy with fetching objects. If an object is very large it often 
makes sense to split it up between many persistent objects so that each part can be 
loaded and unloaded separately. This is what BTrees and TreeSets do. When you fetch a 
value from a BTree or test for an element in a set it only needs to load the part (in 
this case a Bucket) that contains the element, rather than the whole enchilada which 
could be huge (in reality its not quite that simple, but that's the general idea).

This is why BTrees and TreeSets are used when you need to store and manipulate 
arbitarily large numbers of elements.

   result = multiunion(sets)

This iterates the sets which loads all the buckets from the database if they are not 
in the cache.
 
 At which point the sets have already been fetched, no?
 
 looking forward to the day I understand ZODB caches...;-)

Actually this is not so much a function of the cache but a function of the 
organization of the set objects themselves.

-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 )


Re: [Zope-dev] CookieCrumbler and WebDAV

2003-11-06 Thread Casey Duncan
On Thu, 06 Nov 2003 14:38:03 +0100
Lennart Regebro [EMAIL PROTECTED] wrote:

 CookieCrumbler doesn't seem to allow cookie authenticifation over 
 WebDAV. It stops authentication if the request is not PUT, GET or POST 
 and also it stops anything over the webdav source port.
 
 Anybody knows WHY?

CookieCrumbler is expressly designed for interactive login with a human through a web 
browser. It steps out of the way for WebDAV because it is not appropriate to subvert 
the normal HTTP authentication mechanism in that case. WebDAV clients cannot display 
the HTML login form that CookieCrumber returns. Actually in some cases (like MS 
Office) they can display the form and they mistakenly think that is the document the 
user requested 8^(
 
 I took this code for my Cookie Identification plugin for 
 PLuggableUserFolder, so it does the same, but we now have a client whos 
 WebDAV client seems to try to use cookies, adn that fails of course.

It might be reasonable not to bail so early, however. Maybe it would be better to bail 
only if there wasn't a proper authentication cookie already. Instead it should try to 
use it to authenticate.

-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 )


Re: [Zope-dev] KeywordIndex performance / multiunion

2003-11-06 Thread Casey Duncan
On Thu, 06 Nov 2003 19:11:55 +
Seb Bacon [EMAIL PROTECTED] wrote:

 A simple query for [A or B or C] against a KeywordIndex containing 
 27k objects is taking about 7 seconds on a Celeron 1.6Ghz, which seems 
 an absurdly long time to me.

guess
This time may be caused by fetching from the database. If so, then the only way to 
speed it up is increase the ZODB cache or get faster disks. Try the former and see if 
it helps.
/guess
 
 The bit of the operation that is taking the time is the part of the 
 index which does a union of the results of each of the 3 query 
 parameters.  Reproducing this BTree union operation outside Zope in a 
 unit test takes milliseconds.  Very occasionally it takes milliseconds 
 inside the KeywordIndex too.  Something to do with memory usage perhaps? 
   I'll continue looking into it.

Are you saying that sometimes it's faster? If so, that probably supports my guess 
above. In those times it's all or mostly in memory.
 
 But main the reason I'm posting is to wonder if there any reason not to 
 use the multiunion operator instead of the union operator in 
 UnIndex.py... it should be faster, right?  It seems a touch faster in 
 some informal tests.

Yes, it probably should be used. I think it is much faster when unioning very small 
and very large sets as well. Tim would know better, tho.

-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 )


Re: [Zope-dev] _p_deactivate() and _v_ variables?

2003-10-15 Thread Casey Duncan
Seb Bacon wrote:

Chris Withers wrote:

Casey Duncan wrote:

I would argue that a better plan would be to only use _v_ vars for 
completely disposable data only. The application should expect that 
this values will be gone at any random time, not just at transaction 
boundaries.


Agreed. Are there any situations, apart from the already discussed 
CMF skindata, where this currently isn't the case?


I'm a bit puzzled - of what use is a variable which may disappear at 
any random time?
It's not exactly random. It would happen when the object was deactivated 
(removed from cache). If the object is marked as changed (ala 
_p_changed=1) then its __getstate__ will be called before it is 
deactivated. If it hasn't changed though then it doesn't really get a 
chance to do anything about it.

Deactivation only happens AFAIK at transaction or subtransaction 
boundaries. This gives at least some predictability, since 
subtransactions are rarely used. Perhaps this is why database adapters 
have been historically incompatible with subtransactions?

It seems to me that DAs are a bit broken with regard to where they store 
their database connection objects. They should register an object with 
the transaction that holds the connection so that it can be properly 
committed or aborted regardless of what happens with _v_ variables in 
the interim.

-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 )


Re: [Zope-dev] _p_deactivate() and _v_ variables?

2003-10-15 Thread Casey Duncan
Toby Dickenson wrote:

On Wednesday 15 October 2003 14:53, Casey Duncan wrote:

 

Agreed. Are there any situations, apart from the already discussed
CMF skindata, where this currently isn't the case?
   

I'm a bit puzzled - of what use is a variable which may disappear at
any random time?
 

It's not exactly random. It would happen when the object was deactivated
(removed from cache).
   

The proposal earlier in the thread was aiming towards allowing objects to get 
deactivated at any time if the cache was overfull, not just at transaction 
boundaries. This is desirable from a cache management point of view.

Apart from the most trivial cases, it would allow _v_ attributes to disappear 
at random. Its a similar problem to the one that makes it hard to write an 
optimiser for python code, and I am unconvinced that this is sane.
 

I agree. If objects disappeared from cache randomly, I think the system 
as a whole would not be stable or predictable.

I also think it would tend to make a loaded server even more loaded by 
thrashing the cache unnecessarily. As it is, the hard cache 
implementation, although beneficial from a memory management perspective 
cause loaded servers to do alot more work because they are constantly 
pruning the cache and then reloading objects again immediately thereafter.

It might be worth considering a more gradual cache mgmt policy which has 
a target size, a maximum size and a prune rate. Currently, we have only 
a maximum size. Then again, since Python never really returns memory to 
the OS, I'm not sure it matters much in the end.

-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 )


Re: [Zope-dev] _p_deactivate() and _v_ variables?

2003-10-10 Thread Casey Duncan
Toby Dickenson wrote:
On Thursday 09 October 2003 14:01, Florent Guillaume wrote:


I agree with this. How do we go about find code that uses the assumption
that _v_ stuff won't change unless it's at a transaction boundary?
Note that we had a problem related to this with a client recently: In
CMF, skin data is stored in portal._v_skindata, and is actually needed
for the whole request, but in some ZEO setting this go cleared by a
get_transaction().commit(1) which was unexpected and led to breakage
because in that batch treatment we used some skin methods too...


Something after the subtransaction commit must be tickling the cache garbage 
collector. Thats generally what subtransactions are used for.

A while ago there was a discussion on zodb-dev about _v_-like attributes that 
would be automatically cleared at the end of a transaction. Do we need 
something similar that guarantees it will _not_ be cleared until the end of 
the transaction?


IMO YAGNI. I think the application should tolerate the disappearance of 
_v_ vars. I would consider the problem with CMF skins a bug that needs 
to be fixed. AFAIK there is nothing stored in _v_skindata that cannot be 
reconstructed from data in the skins tool.

Has an issue been filed in the CMF collector regarding this?

-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 )


Re: [Zope-dev] Re: catalogObject changes (Zope-2_6-branch)

2003-10-07 Thread Casey Duncan
This is broken in 2.6.2 and I would consider it a bug in that release. I would 
support an improved api such as:

catalog_object(obj, idxs=[], metadata=1)

The way it is currently breaks at least one of my applications as well 
(ironically, this was an application the Chris was also working on).

I am happy to make the change if we agree it is the right thing.

-Casey
 

On Tuesday 07 October 2003 07:13 am, Yuppie wrote:
 Hi!
 
 
 Chris McDonough wrote:
  Option 1:
   Add an update_metadata flag to the catalogObject method with a default 
   of True on all branches.
  
  Option 2:
   Do nothing, but add the updateMetadata method to the ZCatalog  
   interface.
  
  Option 1 would only take effect when 2.6.3 was released (if ever) and
  2.7 final would have the new flag.  Because since the behavior change
  has already been released in 2.6.2, it might be better to do option 2
  and fix the places in CMF/SilvaMetadata that specify indexes, leaving it
  the way it is.
 
 I agree backwards compatibilty is broken anyway. Whatever the solution 
 is, products using the idxs argument for metadata changes have to be 
 changed to work with 2.6.2.
 
 Regarding migration, I agree option 2 would be better.
 
 Regarding the interface, I still prefer option 1 or even option 1 *and* 
 2. The fact that
 
zcat.catalog_object(obj)
 
 does update metadata while
 
zcat.catalog_object(obj, idxs=zcat.indexes())
 
 doesn't, isn't intuitive at all. At least this difference has to be 
 mentioned in the interface definition.
 
 Just my 2 cents. I can live with both options.
 
 
 Cheers,
   Yuppie
 
 
 
 ___
 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] Re: catalogObject changes (Zope-2_6-branch)

2003-10-07 Thread Casey Duncan
On Tuesday 07 October 2003 10:41 am, Yuppie wrote:
 Hi!
 
 
 Casey Duncan wrote:
  This is broken in 2.6.2 and I would consider it a bug in that release. I 
would 
  support an improved api such as:
  
  catalog_object(obj, idxs=[], metadata=1)
 
 I'm sure you mean catalog_object(obj, uid, idxs=[], metadata=1) if we 
 are talking about the ZCatalog interface.

No I figured while we were at it, we'd break compatibilty for a completely 
different reason ;^)

Seriously, I meant what you said...

-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 )


Re: [Zope-dev] Re: catalogObject changes (Zope-2_6-branch)

2003-10-07 Thread Casey Duncan
On Tuesday 07 October 2003 12:08 pm, Chris McDonough wrote:
 On Tue, 2003-10-07 at 09:52, Casey Duncan wrote:
  This is broken in 2.6.2 and I would consider it a bug in that release. I 
would 
  support an improved api such as:
  
  catalog_object(obj, idxs=[], metadata=1)
  
  The way it is currently breaks at least one of my applications as well 
  (ironically, this was an application the Chris was also working on).
 
 FWIW, those changes have been in there for two months on the 2.6
 branch.  This includes 2.6.2b3, b4, b5, and b6.  The breakage couldn't
 have been *that* bad. ;-)

I guess that means I should start using releases ;^)

Nah

-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 )


Re: [Zope-dev] _p_deactivate() and _v_ variables?

2003-09-29 Thread Casey Duncan
On Friday 26 September 2003 04:37 am, Toby Dickenson wrote:
 On Friday 26 September 2003 09:32, Chris Withers wrote:
  Toby Dickenson wrote:
   On Thursday 25 September 2003 11:51, Chris Withers wrote:
  Hmmm, does _p_deactivate() clear the contents of the object's _v_
  variables?
  
   Yes
 
  Then given your earlier comment that _v_ variables are supposed to last at
  least teh length of the request, John's idea of using _p_deactivate() to
  reduce memory usage for large ZCatalog results sets could be seen as
  playing with fire, right?
 
 He had code that would only deactivate objects at the end of a loop if they 
 were not active at the start of the loop. Its not entirely safe, but I think 
 it mitigates the most serious risks here.
 
 ZCatalog (and others) have used this same technique for a while.

It should be entirely safe so long as the application does not store 
non-redundant data in _v_ variables. If the application does do this, then it 
needs to register the object as changed in the transaction and override 
__getstate__ so that the value of the _v_ variables are stored.

I would argue that a better plan would be to only use _v_ vars for completely 
disposable data only. The application should expect that this values will be 
gone at any random time, not just at transaction boundaries.

_p_deactivate is only effective if the object is in the up-to-date state. So 
if by some chance the object was changed after being loaded from the catalog 
results set, _p_deactivate() would do no harm.

-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 )


Re: [Zope-dev] PCGI-Problem

2003-09-21 Thread Casey Duncan
On Friday 19 September 2003 04:31 am, Andre Schubert wrote:
 On Thu, 18 Sep 2003 14:32:52 +0200
 Andre Schubert [EMAIL PROTECTED] wrote:
 
  Hi all,
  
  i have a little problem.
  We have several Zope's running in our company.
  Versions are 2.5.1,2.6.1,2.6.2. All are running on Redhat Linux.
  All versions have the same problem, if i access them via pcgi and hit the 
Restart
  button in the Control Panel then the server goes down.
  If i do the same via ZServer port 8080 everything works fine.
  
 Hi all,
 
 i think i have found a solution.
 A patch is included for PCGIServer.py.
 Could anybody check this patch please.
 If there are no problems i could file a bug into the collector.

I would recommend putting it into the collector so that it does not get lost. 
Please ignore the muted sound of laughter in the background... ;^)

-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 )


Re: [Zope-dev] Functional testing of export/import?

2003-07-28 Thread Casey Duncan
You can usually commit a subtransaction to get a _p_jar and oid (I think) set. 
You can still abort this at the end of the test to clean up.

hth,

-Casey

On Monday 28 July 2003 12:39 pm, Paul Winkler wrote:
 I'm trying to write a functional test that verifies that an instance
 of my Product works correctly after it's been exported and re-imported.
 I'm stuck on how to give the test object a valid _p_oid which is needed
 to do the export.
 
 Background:
 This Product is a dynamic content object for CMF. Its behavior depends on 
 another CMF type instances, which it keeps a path to. So I need to ensure
 that things work even when one or both objects have moved. I've got
 moving  renaming handled well and now I want to test import/export.
 
 So my test suite sets up a dummy CMF instance. I do this by swiping 
 stuff from the CMFCore and CMFDefault tests; I subclass SecurityRequestTest
 and then do
 
 manage_addCMFSite(self.root, 'cmf_test_site' )
 self.site = self.root.cmf_test_site
 
 I've also got a portal folder in the site which I keep a handy 
 reference to as self.fol1. 
 
 All tests are passing, now I move on to writing the export / import tests.
 
 Let's say the object I want to export is self.cmf_test_site.fol1.cp1.
 I have a shorthand reference to this stored as self.cp1.
 So I think the first thing I need to do is get the export data
 like this:
 data self.fol1.manage_exportObject('cp1', download=1)
 
 ... and once that works, I'll use the same data to do an import.
 
 But the export fails. Using pdb and browsing some source I've learned 
 that cp1 needs a _p_jar and _p_oid in order to be exported.  
 The _p_jar I've already dealt with in my move / rename tests, by swiping
 a hack from CMFCore/tests/test_portalFolder.py:
 
 id = self.cp1.getId()
 
 # W! must get _p_jar set
 old, self.cp1._p_jar = self.cp1._p_jar, self.root._p_jar
 try:
 data = self.fol1.manage_exportObject(id, download=1)
 finally:
 self.cp1._p_jar = old
 
 That seems to work fine. 
 
 But now I'm stuck on _p_oid. How do I give the object a valid one?
 I'm sure I can't just use the same trick and swipe the _p_oid of the app 
 root :-P
 
 I must say that using pyunit to write functional tests for zope 2 / CMF 
 is a royal pain. It requires too much knowledge of implementation.
 (why should i need to worry about _p_foo???)
 Also I've found that if there's an error in your class' setUp(),
 it can cause the test to hang and never show you a traceback.
 
 -- 
 
 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 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] ZCatalog Indexes tab crawls...

2003-07-18 Thread Casey Duncan
On Friday 18 July 2003 01:29 pm, Dieter Maurer wrote:
 Anthony Baxter wrote at 2003-7-18 15:14 +1000:
   
Andreas Jung wrote
I agree but the current implementation sux. Switching to a counter 
based
solution would solve the problem. The only problem I see is to keep the
code fully backward compatible.
   
   if there's no counter present:
  create one, do a count of the docs, initialise the counter
 
 We can use the size of the _unindex.
 
 
 However, is it really worth it?
 
 #objects suggests that it is the number of objects indexed by
 this index. Who is interested in this information?
 
 Unless one has inhomogeous objects, almost all objects are indexed
 by every index. Thus, #objects is likely to be similar for
 many indexes.
 
 A much more interesting information would be the size of the index measured
 by the number of index terms.

I agree. and as a plus, its a minor change to the software...

-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 )


Re: [Zope-dev] ZCatalog Indexes tab crawls...

2003-07-17 Thread Casey Duncan
Actually I regard the current behavior as a feature. Using a stopwatch and a 
slide-rule I can estimate to within 100 objects, how many values are indexed 
in a catalog by measuring the time it takes to draw the indexes page.

Please do not remove this most valued feature!

-Casey

On Thursday 17 July 2003 04:35 pm, Dieter Maurer wrote:
 Chris Withers wrote at 2003-7-17 11:12 +0100:
   Has anyone noticed that the ZCatalog Indexes tab crawls if you have loads 
of 
   objects indexed.
   
   My guess is that some types of index take way too long to figure out how 
many 
   objects are indexed. Anyone know which index types those could be?
 
 The one that provide the correct number of indexed objects
 (rather than just the number of indexed terms).
 
 Because the same object can be indexed under several terms,
 determining the number of indexed objects requires to
 build the union of all the index values. This almost surely
 has quadratic (worst case) runtime characteristics.
 
   BTW, would anyone object if I removed that object count, since it's not 
often 
   very useful...
 
 You probably should replace it with the size of the index (i.e.
 the number of index terms).
 
 Formerly, the index overview displayed this information but
 under a buggy # objects title. Someone fixed this for most
 indexes, they now show the number of objects but at a high
 price.
 
 I suggest to change the title to # index terms and
 revert for the indexes to the old behaviour.
 
 
 Others pointed out, that also the size determination for an
 index may be expensive. However, it is at most linear in the number
 (rather than quadratic) and all recently created indexes now
 use BTrees.Length to maintain their size (which gives constant time).
 
 Having a feeling how large an index is is valuable information.
 
 
 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 )
 


___
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] 2.6.2b3?

2003-06-23 Thread Casey Duncan
Post this to zodb-dev.

-Casey

On Monday 23 June 2003 05:12 am, seb bacon wrote:
 Just a quick repeat from last week in case it slipped from anyone's
 radar... Here is the important bit again: 
 
 a) Any reason why I shouldn't merge BTree bugfixees into the 2.6 branch?
 b) If no, how about a 2.6.2b3?
 
 seb
 
 
 On Wed, 2003-06-18 at 17:25, seb bacon wrote:
  There lave been various BTree fixes lounging in the HEAD since Jan 2003
  which I'd like to get into a release, basically because we have seen one
  of the bugs causing segfaults in production - this is the culprit:
  
  
http://cvs.zope.org/Zope/lib/python/BTrees/BTreeItemsTemplate.c.diff?r1=1.17r2=1.18
  
  a) Any reason why I shouldn't merge it into the 2.6 branch?
  b) Any chance of a 2.6.2b3?
  
  Seb

___
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] weak examples, weak exploits

2003-06-23 Thread Casey Duncan
I would be in favor of making the Examples opt-in like the Zope tutorial. It 
seems silly to have it in evey ZODB by default. Make people add it if they 
want it.

-Casey

On Monday 23 June 2003 05:12 am, Jamie Heilman wrote:
 seb bacon wrote:
  No.  Just go ahead and make the changes.  It would be instructive for
  others reading the examples to add a comment or two explaining the
  rationale behind the extra checking code.
 
 'k I can do that
  
  The file upload vulnerability was fixed in version 1.3 of Examples.zexp,
  though.  The reason it's still turning up in 2.6.x versions is probably
  due to upgrades.  Therefore I suppose additionally there should be a
  patch which examines the ZODB on startup and prints a warning if an old
  Examples folder is present.
 
 You know, ironically, I don't think this advisory even covers that hole.
 There's obvious DoS potential in the guest book and such, but thats
 easily limited without degrading the value of the example.  Anyway,
 I'll scrape over the examples and see what I can clean up.
 
 -- 
 Jamie Heilman   http://audible.transient.net/~jamie/
 Most people wouldn't know music if it came up and bit them on the ass.
 -Frank Zappa
 
 ___
 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] Memory Error

2003-06-17 Thread Casey Duncan
On Tuesday 17 June 2003 11:47 am, Andy McKay wrote:
 If you've visited ZopeZen you might have noticed this lovely error that 
 seems to occur intermittently..
 
 [snip rest of traceback]
  * Module Products.CMFCore.CatalogTool, line 214, in searchResults
  * Module Products.ZCatalog.ZCatalog, line 619, in searchResults
  * Module Products.ZCatalog.Catalog, line 732, in searchResults
  * Module Products.ZCatalog.Catalog, line 480, in search
  * Module Products.PluginIndexes.common.UnIndex, line 365, in 
 _apply_index
  * Module ZODB.Connection, line 534, in setstate
 
 MemoryError: (Also, an error occurred while attempting to render the 
 standard error message.)
 
 Its:
 
 Zope 2.6.1 (source release, python 2.1, linux2)
 python 2.1.3
 openbsd3
 
 I believe all the appropiate python stack patches are applied.

In my experience, (at least on FreeBSD) it would simply fall over when it ran 
out of stack space, I don't remember ever seeing MemoryError. But I may not 
have been paying close enough attention ;^)

Looks like its running out of memory when a BTree subobject is being loaded. 
Do you have any idea how much memory the process was using when you got the 
error?

-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: [Zope-Coders] Bug day?

2003-06-16 Thread Casey Duncan
I assume you meant Tuesday the 17th. 

It is currently the 16th, but it is not yet Tuesday. However, if it is the 
management's decision that today shall be Tuesday, than I shall do my duty 
and respect that decision ;^)

time-is-relatively y'rs,

-Casey

On Wednesday 11 June 2003 10:08 pm, Brian Lloyd wrote:
 Hi all - 
 
 We had been planning to make a Zope 2.7a1 release on Friday, 
 and another 2.6.2 beta soon as well. Someone noted (rightly!) 
 that it would be ideal if we could have a bugday first.
 
 So I'll propose next Tuesday the 16th be bug day, and we'll 
 plan to make both releases by the end of next week. 
 
 Thoughts?
 
 
 Brian Lloyd[EMAIL PROTECTED]
 V.P. Engineering   540.361.1716   
 Zope Corporation   http://www.zope.com
 
 
 ___
 Zope-Coders mailing list
 [EMAIL PROTECTED]
 http://mail.zope.org/mailman/listinfo/zope-coders
 


___
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] ZCTextIndex Improvements

2003-06-06 Thread Casey Duncan
For the past few days I have been working on database conflicts stemming from 
ZCTextIndex (no pun intended). The version currently released causes 
conflicts for *any* concurrent index/unindex operation. I have changed both 
the lexicon and index classes to fix this. Now conflicts coming from the 
BTrees are the only ones you will get, and they are internally resolved in 
most cases.

Also, there was a bug in the query machinery that made it far more expensive 
for large indexes then it needs to be. This has also been fixed.

These improvements have now landed on the Zope head and 2.6 branch (soon to be 
2.6.2 beta 3 I think). Any of you running Zope in production with any amount 
of write concurrency should benefit. I ]encourage you to test the new 
ZCTextIndex code with your applications (in a test environment of course). 
You should be able to simply replace the ZCTextIndex product in your zope 
with the one in CVS (no reindex is necessary). I would certainly appreciate 
any feedback you might have on it.

Please note, that the code does make some minor data structure changes to the 
index and lexicon the first time they are updated. Therefore you cannot 
simply remove the new product and go back to the old one by swapping the 
code. You will need to rebuild your Lexicons and ZCTextIndexes to go back. 
The hope though, is that you'll never want to ;^)

-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 )


Re: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?)

2003-06-06 Thread Casey Duncan
One man's opinion:

- Version support (at the application level) should be optional in 2.7. You 
should be able to turn it off (maybe through ZConfig). The default should 
probably be off, since I think more people avoid them than use them.

I would suggest these approaches:

1: File a bug in the collector and be prepared to wait an indefinite time for 
it to be acted upon.

2: develop a patch and submit it and/or check it in probably after vetting the 
change on a branch.

I'm afraid the only way to get your favorite issue fixed quickly is to fix it 
yourself.

The security implications do not seem dire enough to me to warrent trying to 
squeeze this into 2.6.x. If you do not use versions then none of the 
implications apply. Perhaps it might be possible to do additional security 
checks to make entering versions more protected. This might be an appropriate 
change for 2.6.

-Casey

On Friday 06 June 2003 05:46 am, Oliver Bleutgen wrote:
 Ok, I still have the impression that not enough people are aware of the 
 full implications of the version functionality as it is implemented in 
 zope. So let me summarize.
 
 versioning-as-implemented-in-zope consists of two parts:
 
 First, there's the database backend part (which I know nothing about) 
 with a small glue layer (inside ZODB.ZApplication.ZApplicationWrapper). 
 This resides where the db-connection is opened on the very start of 
 every request.
 
 The second part is the Version product (capitalized to distinguish them) 
 which is zope's mechanism to get a variable named 'Zope-Version' 
 (==version_support) with the value of the path to the version object 
 inside the REQUEST (by setting a cookie).
 
 
 Bad properties of this implementation:
 
 1. The Join/Leave Versions permission doesn't secure entering versions
 2. Zope doesn't care if a correspondending Version instance to the value 
 of REQUEST['Zope-Version'] exists, more exactly, zope doesn't care for 
 the value of that Zope-Version variable at all.
 3. And (minor problem, but whatever), since zope relies completely on 
 the browser to send cookies only the right time (i.e. that the path set 
   for the cookie must match a prefix of the request-URI), this might 
 also give unexpected results with acquisition.
 
 
 Security implications:
 
 Doh, anybody who can read/write to a zope server can get it to 
 read/write from/to any version he likes, and the admin has no way of 
 anticipating that short of patching zope. Combine that with sites like 
 squishdot, collector.zope.org and you get chaos.
 
 Big plea:
 
 Really, this _is_ a security bug, and it should be handled that way and 
 fixed in 2.6.2 by any meansm, so that all(!) bad properties I listed 
 above are gone.
 
 Sorry for getting a bit worked up about that issue.
 
 cheers,
 oliver
 
 
 
 
 
 
 
 
 
 ___
 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] Conflict reduced BTrees for cataloging

2003-03-14 Thread Casey Duncan
Although I'm not an expert on _p_independent, AFAIK, it can only be used for 
objects which are not in any way dependant on the state of other persistent 
objects.

This is certainly not the case for BTrees, which is pretty much covers the 
data structures used for cataloguing and indexing.

I would definitely recommend discussing this on zodb-dev before going forward 
with this. The current BTree intelligensia are over there.

-Casey


On Thursday 13 March 2003 04:39 pm, Dieter Maurer wrote:
 I am working on a CMS on top of ZODB for large amounts of
 large SGML/XML documents.
 
 To speed things up, a colleague started two import processes
 and we get incredible amounts of database read conflict errors
 from cataloguing (although we already use QueueCatalog for
 most indexes).
 
 I think, the data structures used for cataloguing and indexing
 could have a def _p_independent(self): return 1.
 
 Does anybody objects?
 
 If not, I will implement _p_independent BTrees and friends.
 
 
 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 )
 


___
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] Following the Zope Collector

2003-02-26 Thread Casey Duncan
Done.

-Casey

On Wednesday 26 February 2003 02:41 pm, Florent Guillaume wrote:
 On Wed, 2003-02-26 at 19:31, Steve Alexander wrote:
   So I'd like to propose to switch the Zope collector to dispatcher Off.
   This would mean more email traffic for the supporters, but it's easy
   enough to filter and I think the benefits are worth it.
  
  I get my notifications by subscribing to this list:
  
  http://mail.zope.org/mailman/listinfo/zope-collector-monitor
 
 Thanks Steve.
 
 Once again I failed to use the correct tools. sigh this kind of info
 really should be present on the http://collector.zope.org site besides
 being on http://dev.zope.org/CVS/CommitterGuidelines ...
 
 Florent
 
 -- 
 Florent Guillaume, Nuxeo (Paris, France)
 +33 1 40 33 79 87  http://nuxeo.com  mailto:[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 )


Re: [Zope-dev] Python core dump zope 2.6.1+CMF1.3

2003-02-12 Thread Casey Duncan
On Wednesday 12 February 2003 09:20 am, R. David Murray wrote:
[snip]
 I sup regularly, and rebuild regularly.  That patch is already
 applied.  Also, 2.2 appears to not need the patch, and it crashes, too.

I can confirm that 2.2 does need to be configured with a larger stack size to 
work correctly with Zope/CMF on FreeBSD. Whether the port has this patch or 
not included I'm not sure. I don't use the port to run Zope apps, I only use 
it for others apps and testing.

This also affects MacOSX, but I think the stack size *is* automatically bumped 
up during the Python compile (Go figure).

As for Windows, no-one can honestly be surprised at software crashes there, it 
all part of the experience ;^)

-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 )



Re: [Zope-dev] ExternalEditor losing its lock?

2003-02-04 Thread Casey Duncan
Hmmm, I think this may be due to a typo in the helper app code. Try applying 
the attached diff to zopeedit.py and see if it helps.

-Casey

On Tuesday 04 February 2003 03:58 am, Jean Jordaan wrote:
 Hi all
 
 A couple of times now, I've noticed this:
 
   - I open a Python Script using ExternalEditor. A GET is issued,
 My editor starts up, and a LOCK gets set.
 
   - Now I view and execute the script (more GETs) while editing
 and saving in my editor (PUTs get issued).
 
   - That's fine. But then the lock goes away, and I successfully
 edit the script in the ZMI: a POST goes thru. But there hasn't
 been any UNLOCK yet. This shouldn't happen, right?
 
 (Zope 2.5.1 (source release, python 2.1, linux2), python 2.1.3, linux2)
 
 Excerpt from Z2.log:
 
 192.168.1.5 - jean [03/Feb/2003:18:25:38 +0200] GET /externalEdit_/test 
 HTTP/1.1 200 1088 http://blommie:17081/manage_main; Mozilla/5.0 (X11; 
 U; Linux i686; en-US; rv:1.1) Gecko/20021212
 192.168.1.5 - jean [03/Feb/2003:18:25:40 +0200] LOCK /test HTTP/1.1 
 200 789  Zope External Editor/0.6
 192.168.1.5 - jean [03/Feb/2003:18:25:56 +0200] PUT /test HTTP/1.1 204 
 251  Zope External Editor/0.6
 192.168.1.5 - jean [03/Feb/2003:18:25:58 +0200] GET 
 /test/manage_workspace HTTP/1.1 302 467 
 http://blommie:17081/manage_main; Mozilla/5.0 (X11; U; Linux i686; 
 en-US; rv:1.1) Gecko/20021212
 192.168.1.5 - jean [04/Feb/2003:10:32:25 +0200] PUT /test HTTP/1.1 204 
 251  Zope External Editor/0.6
 192.168.1.5 - jean [04/Feb/2003:10:46:11 +0200] POST /test HTTP/1.1 
 200 12877 http://blommie:17081/test/ZPythonScriptHTML_editForm; 
 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20021212
 192.168.1.5 - jean [04/Feb/2003:10:46:11 +0200] GET 
 /manage_page_style.css HTTP/1.1 200 3014 http://blommie:17081/test; 
 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20021212
 192.168.1.5 - jean [04/Feb/2003:10:46:16 +0200] PUT /test HTTP/1.1 204 
 251  Zope External Editor/0.6
 192.168.1.5 - jean [04/Feb/2003:10:46:18 +0200] GET 
 /test/manage_workspace HTTP/1.1 302 467 http://blommie:17081/test; 
 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20021212
 
 -- 
 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 )
 

*** zopeedit.py.old	Tue Feb  4 09:06:48 2003
--- zopeedit.py	Tue Feb  4 09:07:14 2003
***
*** 415,421 
  return 0 # Already have a lock token
  
  headers = {'Content-Type':'text/xml; charset=utf-8',
!'Timeout':'infinite',
 'Depth':'infinity',
}
  body = ('?xml version=1.0 encoding=utf-8?\n'
--- 415,421 
  return 0 # Already have a lock token
  
  headers = {'Content-Type':'text/xml; charset=utf-8',
!'Timeout':'infinity',
 'Depth':'infinity',
}
  body = ('?xml version=1.0 encoding=utf-8?\n'



  1   2   3   4   >