[Zope-dev] Zope tests: 8 OK
Summary of messages to the zope-tests list. Period Wed Dec 28 12:01:01 2005 UTC to Thu Dec 29 12:01:01 2005 UTC. There were 8 messages: 8 from Zope Unit Tests. Tests passed OK --- Subject: OK : Zope-2_6-branch Python-2.1.3 : Linux From: Zope Unit Tests Date: Wed Dec 28 21:04:03 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003874.html Subject: OK : Zope-2_6-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Wed Dec 28 21:05:33 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003875.html Subject: OK : Zope-2_7-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Wed Dec 28 21:07:03 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003876.html Subject: OK : Zope-2_7-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Wed Dec 28 21:08:33 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003877.html Subject: OK : Zope-2_8-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Wed Dec 28 21:10:03 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003878.html Subject: OK : Zope-2_8-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Wed Dec 28 21:11:34 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003879.html Subject: OK : Zope-2_9-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Wed Dec 28 21:13:04 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003880.html Subject: OK : Zope-trunk Python-2.4.2 : Linux From: Zope Unit Tests Date: Wed Dec 28 21:14:34 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003881.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Curious about age old WebDAV decisions...
I wasn't around during the development of the WebDAV code, so I'm loathe to just jump in and start changing things, but why isn't 'HEAD' exempted from the NullResource as well, given that HTTP specs state that HEAD *must* return the same headers that a GET would provide (ignoring for the moment the Collector issue thread over whether HEAD should provide the length of the source of a document or its fully rendered content - let's just try to make sure both methods work on the *same object*). What was the reasoning behind the decision? These changes happened way back in the Dark Ages (late March 1999 or so, earlier in the month, this code was added to OFS.Folder with the initial WebDAV support). A trip through the WayBackMachine™ shows no discussion in the Zope-dev lists in early 1999 when this was being worked on, and no real mention of WebDAV in Zope for most of the rest of that year (on Zope-dev or the general Zope list). Am I mistaking this for a problem? The HEAD method is a bit of problem generally -- by the book it should return the exact same thing as a GET sans the content body. In a dynamic system like Zope about the only way I can think of to have the right thing happen would be to have goo in the publisher that turns a HEAD into a GET to let normal GET control flow happen, then have the response bits know that this has happened and discard the content body. ...sound of retching... In any case, treating HEAD like the other lesser-used HTTP methods like DELETE, etc. is probably not the right thing to do, but what exactly the right thing should be is unclear. Another fun tidbit is that DAV clients often use HEAD to test for the existence of resources and other things, so if HEAD is treated *exactly* like a GET in Z2 you'll get problems due to acquisition (you might get a HEAD response for an acquired object that isn't really there, which will make DAV clients go insane). That convoluted code in the publisher pre-dates the idea of a dedicated DAV server -- probably the right thing to do today would be to have the DAV server config the publisher to never acquire, then you dont have unresolvable ambiguities. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] RE: [ZODB-Dev] Re: Connection pool makes no sense
[EMAIL PROTECTED] Not agree. Can you answer the question? Does self.all.remove(c) mean that we WANT to destroy connection instance? [Tim Peters] It means that _ConnectionPool no longer has a reason to remember anything about that Connection. Application code can continue keeping it alive forever, though. [Denis Markov] But what about RDB-Connection what stay in cache forever? Sorry, I don't know anything about how your app uses RDB connections. ZODB isn't creating them on its own ;-) On the next peak load we get some next ZODB-Connections with RDB-Connection After repush() old ZODB-Connections will be killed (if pool_size) I don't like the word killed here, because it seems highly misleading. ZODB doesn't destroy any Connections or any caches. ZODB destroys all its strong references to old Connections, and that's all. Nothing can be done to _force_ Connections to go away forever. It's ZODB's job here to make sure it isn't forcing Connections (beyond the pool_size limit) to stay alive, and it's doing that job. It can't kill Connections. but RDB-Connection stay in cache forever And so on There's one cache per Connection. If and when a Connection goes away, its cache goes away too. So when you say something stays in cache forever, I don't know what you mean -- you apparently have many (hundreds? thousands?) of Connections, in which case you also have many (hundreds or thousands) of caches. I don't know how an RDB-Connection gets into even one of those caches to begin with. as a result we get many RDB-Connections what will never use but hang our RDB At this point I have to hope that someone else here understands what you're doing. If not, you may have better luck on the zope-db list (which is devoted to using other databases with Zope): http://mail.zope.org/mailman/listinfo/zope-db ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RE: [ZODB-Dev] Re: Connection pool makes no sense
Oops! I sent this to zope-dev instead of zodb-dev by mistake. Nevertheless, if you can help Denis Markov, don't let my mistake inhibit you ;-) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Curious about age old WebDAV decisions...
Zachery Bir wrote at 2005-12-28 14:27 -0500:
I've got a Folder (indirection) and a DTML Method (found) in the root
of a Zope site. HEAD requests fail on the indirected DTML Method due
to OFS.ObjectManager's __getitem__ method:
def __getitem__(self, key):
import pdb;pdb.set_trace()
v=self._getOb(key, None)
if v is not None: return v
if hasattr(self, 'REQUEST'):
request=self.REQUEST
method=request.get('REQUEST_METHOD', 'GET')
if request.maybe_webdav_client and not method in ('GET',
'POST'):
return NullResource(self, key, request).__of__(self)
raise KeyError, key
I wasn't around during the development of the WebDAV code, so I'm
loathe to just jump in and start changing things, but why isn't
'HEAD' exempted from the NullResource as well, given that HTTP specs
state that HEAD *must* return the same headers that a GET would
provide
Looks like a bug (not only here but probably at other places as well).
Altogether, this treatment is buggy: it cannot be the responsibility
of ObjectManager.__getitem__ to handle things only senseful during
traversal; ObjectManager[...] can be called long after traversal
finished and then returning a NullResource definitely is stupid.
--
Dieter
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
