RE: [Zope] Security class attribute
The ClassSecurityInfo is a convenience to provide a
halfway-sane spelling for a lot of ugliness under the
hood in setting up security.
IntializeClass (among other things) tells the CSI to
apply itself to the class to set everything up, then it
gets *removed* from the class.
I can't tell for sure from your code, but I suspect that
IntializeClass is being called on MyProduct *before* you
are doing your class augmentation -- if you can defer the
call until after you hack it, it should work.
If for some reason you can't defer the call to InitializeClass,
it should be safe to create another ClassSecurityInfo and apply
it manually, e.g.:
class MyProduct(...):
security=ClassSecurityInfo()
InitializeClass happens...
setattr(MyProduct, 'FileManagement.html', MyProduct.FileManagement)
xtra = ClassSecurityInfo()
xtra.security.declareProtected('View', 'FileManagement.html')
xtra.apply(MyProduct)
HTH,
Brian Lloyd[EMAIL PROTECTED]
V.P. Engineering 540.361.1716
Zope Corporation http://www.zope.com
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Peter Bengtsson
Sent: Thursday, January 26, 2006 9:44 AM
To: [Zope]
Subject: [Zope] Security class attribute
Now in Zope 2.9 I get these warnings::
2006-01-26 14:31:45 WARNING Init Class
Products.MyProduct.Homesite.FilesContainer has a security declaration
for nonexistent method 'FileManagement'
That's understandable because I've coded it like this::
class MyProduct(...):
security=ClassSecurityInfo()
security.declareProtected('View', 'FileManagement.html')
setattr(MyProduct, 'FileManagement.html', MyProduct.FileManagement)
In other words, I create methods after the class has been defined and
squeeze them in manually. Very convenient.
To avoid the WARNING message above I thought I could use
declareProtected() _after_ the the class has been defined just as with
the additional method; but no luck :(
I tried this::
class MyProduct(...):
security=ClassSecurityInfo()
setattr(MyProduct, 'FileManagement.html', MyProduct.FileManagement)
MyProduct.security.declareProtected('View', 'FileManagement.html')
But I'm getting::
AttributeError: type object 'MyProduct' has no attribute 'security'
Which I totally don't understand. To test my sanity I wrote this test
script which works fine::
class _Z:
def __init__(self):
self.z = Z
def declareProtected(self, *a,**k):
print ++declare something+
def foo():
print I'm being called
return _Z()
class A:
security=foo()
def __init__(self):
pass
A.security.declareProtected(foo)
print dir(A)
Which works like you'd expect with the followin output::
I'm being called
++declare something+
['__doc__', '__init__', '__module__', 'security']
What's going on [differently] in Zope? What am I missing?
--
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
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] ZRS Now Available for FREE 30-day Evaluation
Hi all, We are happy to announce that Zope Corporation is now offering Zope Replication Services (ZRS) in a 30-day evaluation format! For more information and to download the evaluation release, visit: http://customers.zope.com/ZRS/ About ZRS: Zope Replication Services (ZRS) increases the reliability of all Zope enterprise clusters and eliminates the storage system as a single point of failure. Sites with high availability requirements must manage planned and unplanned downtimes. Planned outages include system maintenance, software / operating system upgrades, and backups. Unplanned outages include hardware and network failures. ZRS reduces the downtime associated with these events by replicating and distributing mission-critical data storage across distinct physical storages (possibly in distinct geographic locations). Should a primary storage fail, a secondary storage can take its place. Secondary servers can be taken off-line at any time to undergo repairs, backups, or system upgrades. When a secondary returns to service, it automatically resynchronizes with the primary server. ZRS also improves scalability since secondary servers can optionally provide additional read-only ZEO connections while maintaining their replication functions. ZEO client storages can be configured to connect to any available secondary, and can be load-balanced among the available secondary ZRS servers to implement highly-available and highly-scalable Zope clusters. ZRS is a 'battle-tested' solution that has provided the high-availability and disaster recovery solution critical to large-scale public and internal Zope deployments for years. Premier brands including the VIACOM radio and television group, AARP, Community Newspaper Holdings Inc. (CNHI), and the Joint Intelligence Center, Pacific (JICPAC) rely on ZRS to ensure reliability and scalability for their mission-critical Web sites. The 30-day evaluation release allows organizations to install and operate ZRS on up to five primary ZODB servers and on an unlimited number of secondary servers for up to thirty days. The current evaluation release (ZRS 1.4.2) is compatible with Zope versions 2.4 - 2.7. Full releases of ZRS compatible with Zope 2.8.x and Zope 3.x are also available. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Zope Technical Solutions Early-Bird Registration
A reminder to register by September 24th to get the early bird rate for the upcoming Zope Technical Solutions class on October 24-27. It will be held at our Fredericksburg, VA headquarters. This four day course familiarizes students with Zope software from introductory through advanced topics. We will demonstrate the flexibility and effectiveness of Zope as an Open Source web development and content management environment. We will also explore Zope architecture and provide hands-on exercises using Zope to develop and manage a robust web site. We offer opportunities to meet with Zope's engineering teams during lunch, including Jim Fulton, our CTO. Course Objectives: After completing this course students will understand: - Zope's use of objects, methods, etc. - Zope's Management Interface. - Zope's server-side scripting language (DTML). - Page Templates. - Web site content creation and management. - Web site security through user privileges and roles. - Using Zope to integrate web sites with existing + relational databases. - Downloading/installing a Zope Product, and - Introduction to CMF. The course is intended for those interested in using a full-featured open source environment to develop and manage robust corporate internet or intranet web sites. This includes web site designers, content creators, content managers and web developers. Participants should be familiar with HTML and basic web architecture (e.g., how a web server and web browser work together). Knowledge of object-oriented concepts and SQL is recommended. For more detailed information about the course, including pricing, travel and accommodations, please go to our website: http://www.zope.com/training/zope_technical_solutions.html Payment authorization is available at http://www.zope.com/training/payment_authorization.html Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-Annce] Zope 3 training - early bird reminder
Hi all - Zope Corporation will hold the next session of Zope 3 for Developers training September 19-21 in Fredericksburg, VA. This three day course will familiarize developers with Zope 3 software from introductory through advanced concepts. The take-away materials provide tools for further learning, since it will not be possible to cover every topic in the sessions. We will demonstrate the flexibility and effectiveness of Zope as an Open Source web development Platform. Course Objectives To understand: * Zope's component architecture, * Creating Zope components and applications, * Building web interfaces, * Controlling security, * Using powerful Zope framework features e.g., events, metadata, schemas, testing, * Configuring and installing Zope The course is intended for developers who want to build web applications using the Zope 3 web-application server. Students should be familiar with the Python programming language and the concepts associated with web application development. While not required, students will benefit from having some familiarity with Zope 2-based application development. We offer several opportunities to meet with Zope's engineering teams, including with Jim Fulton, our CTO. Prerequisites Download Zope 2.7 and take the built-in tutorial: http://zope.org/Products/Zope/2.7.0 Take the Python Tutorial: http://docs.python.org/tut/tut.html For more information or to register, please contact [EMAIL PROTECTED] For the early-bird rate, you must register by August 19th, 2005. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Announce maillist - Zope-Announce@zope.org http://mail.zope.org/mailman/listinfo/zope-announce Zope-Announce for Announcements only - no discussions (Related lists - Users: http://mail.zope.org/mailman/listinfo/zope Developers: http://mail.zope.org/mailman/listinfo/zope-dev )
RE: [Zope] bytecode cache?
I have idea about bytecode cache in Zope, it is possible to implement? What I mean: python scripts (in ZODB), DTML documents/methods, ZPT will be bytecode compiled in similar way like ordinary .py scripts into .pyc and then run much faster than noncompiled ZODB objects. I think that it should have significant speed improvement. ... or I am totally out? Python scripts already cache a bytecode representation (or at least they did last time I looked - its been awhile). Not sure what you mean by a byte-code representation of DTML or ZPT... Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
RE: [Zope-dev] Verbose security for Zope 2.8 or 2.9
+1 from me ;) Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Shane Hathaway Sent: Tuesday, June 14, 2005 11:17 AM To: Andreas Jung Cc: zope-dev@zope.org Subject: Re: [Zope-dev] Verbose security for Zope 2.8 or 2.9 Andreas Jung wrote: --On 14. Juni 2005 09:52:33 -0600 Shane Hathaway [EMAIL PROTECTED] wrote: This patch supercedes the VerboseSecurity product, so I don't plan to update the VerboseSecurity product for Zope 2.8. Should the patch be included in Zope 2.8.1? From me: +2 There is clearly support for this, so unless Jim or Brian objects, I'll work on checking in the patch to Zope-2_8-branch and the trunk right away. Shane ___ 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 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] Test failures with five-integration branch merged to head...
[Martijn Faassen] Odd, I don't get any failures, and Stefan Holek cannot report them either. Did these get resolved since then? It looks like the merge got checked in, right? The merge was checked in. I'm doing the ZODB 3.4 integration on a new branch. We suspect Brian's failures (seemingly Unicode-related) were due to a rogue site.py that mucked with the default sys.encoding. All but two tests pass on the trunk on Windows too. Sorry - I got sidetracked and didn't followup. Yes, the Python I happened to be using to run the tests had a wacky default encoding set - after I fixed that the tests all passed so I commited the merge. 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 )
RE: [Zope-dev] [Zope2.8a2] ...to be released by tomorrow....
Hi Andreas - please don't cut the release until we get the OK from Tim Peters - he's still working on merging recent ZODB changes, I believe. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Andreas Jung Sent: Friday, April 01, 2005 12:03 AM To: zope-dev@zope.org Cc: [EMAIL PROTECTED] Subject: [Zope-dev] [Zope2.8a2] ...to be released by tomorrow Hi, I am planning to make the release tomorrow (Saturday afternoon (German time :-)). So please make your final fixes very soon or cry out loud STOP if there are any show stoppers. Andreas ___ 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] heads-up: trunk(2.8) and five-integration branch merge
hiya - Just a head's up that I going to try to merge the five-integration branch to the trunk in a bit so Tim can get unblocked on stitching in the newest ZODB. 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] Test failures with five-integration branch merged to head...
I did a merge from the five-integration branch to the head
in a local sandbox, and got the following test failures -
anyone know anything about them?
Brian Lloyd[EMAIL PROTECTED]
V.P. Engineering 540.361.1716
Zope Corporation http://www.zope.com
Running unit tests from /home/brian/zhead/lib/python
er argument expected, got float
==
ERROR: testBucketGet (BTrees.tests.test_compare.CompareTest)
--
Traceback (most recent call last):
File /home/brian/zhead/lib/python/BTrees/tests/test_compare.py, line 32, in
setUp
self.assertRaises(UnicodeError, unicode, self.s)
File /home/brian/build/opt/Python-2.3.4/lib/python2.3/unittest.py, line
295, in failUnlessRaises
raise self.failureException, excName
AssertionError: UnicodeError
==
ERROR: testBucketMinKey (BTrees.tests.test_compare.CompareTest)
--
Traceback (most recent call last):
File /home/brian/zhead/lib/python/BTrees/tests/test_compare.py, line 32, in
setUp
self.assertRaises(UnicodeError, unicode, self.s)
File /home/brian/build/opt/Python-2.3.4/lib/python2.3/unittest.py, line
295, in failUnlessRaises
raise self.failureException, excName
AssertionError: UnicodeError
==
ERROR: testBucketSet (BTrees.tests.test_compare.CompareTest)
--
Traceback (most recent call last):
File /home/brian/zhead/lib/python/BTrees/tests/test_compare.py, line 32, in
setUp
self.assertRaises(UnicodeError, unicode, self.s)
File /home/brian/build/opt/Python-2.3.4/lib/python2.3/unittest.py, line
295, in failUnlessRaises
raise self.failureException, excName
AssertionError: UnicodeError
==
ERROR: testSetGet (BTrees.tests.test_compare.CompareTest)
--
Traceback (most recent call last):
File /home/brian/zhead/lib/python/BTrees/tests/test_compare.py, line 32, in
setUp
self.assertRaises(UnicodeError, unicode, self.s)
File /home/brian/build/opt/Python-2.3.4/lib/python2.3/unittest.py, line
295, in failUnlessRaises
raise self.failureException, excName
AssertionError: UnicodeError
==
ERROR: testSetMinKey (BTrees.tests.test_compare.CompareTest)
--
Traceback (most recent call last):
File /home/brian/zhead/lib/python/BTrees/tests/test_compare.py, line 32, in
setUp
self.assertRaises(UnicodeError, unicode, self.s)
File /home/brian/build/opt/Python-2.3.4/lib/python2.3/unittest.py, line
295, in failUnlessRaises
raise self.failureException, excName
AssertionError: UnicodeError
==
ERROR: testSetSet (BTrees.tests.test_compare.CompareTest)
--
Traceback (most recent call last):
File /home/brian/zhead/lib/python/BTrees/tests/test_compare.py, line 32, in
setUp
self.assertRaises(UnicodeError, unicode, self.s)
File /home/brian/build/opt/Python-2.3.4/lib/python2.3/unittest.py, line
295, in failUnlessRaises
raise self.failureException, excName
AssertionError: UnicodeError
==
ERROR: testCanonicalPath
(zope.app.traversing.tests.test_conveniencefunctions.Test)
--
Traceback (most recent call last):
File
/home/brian/zhead/lib/python/zope/app/traversing/tests/test_conveniencefunctions.py,
line 263, in testCanonicalPath
self.assertRaises(error_type, canonicalPath, value)
File /home/brian/build/opt/Python-2.3.4/lib/python2.3/unittest.py, line
289, in failUnlessRaises
callableObj(*args, **kwargs)
File /home/brian/zhead/lib/python/zope/app/traversing/api.py, line 215, in
canonicalPath
raise ValueError('canonical path must start with a /: %s' % path)
ValueError: canonical path must start with a /: £23
==
FAIL: check_unicode_mixed_unknown_encoding
(TAL.tests.test_talinterpreter.InterpolateTestCase)
--
Traceback (most recent call last):
File /home/brian/zhead/lib/python/TAL/tests/test_talinterpreter.py, line
280, in check_unicode_mixed_unknown_encoding
self.assertEqual(interpolate(text, mapping), expected)
File /home/brian/build/opt/Python-2.3.4/lib/python2.3/unittest.py, line
302, in failUnlessEqual
raise
[Zope-dev] Clarification re: Zope X3.1, 2.8
Hi all, There have been a number of threads going on today re: Zope X3.1 feature freeze and the 2.8 effort. I'd like to clarify some decisions re: Zope 2.8 Jim is the product mgr for Zope 3 and I'm it for Zope 2, so hopefully this can be considered authoritative and end part of this thread ;) - Zope 2.8 will include X3.0 (not X3.1) - The Z3 developers will have *no* extra burden or responsibility to support X3.0 beyond what they would normally do in the normal course of maintaining it for Z3-only applications. In other words, it is not the responsibility of Z3 devs to make sure Z2 tests pass, etc. - It *will be* the responsibility of the Zope 2 devs to make sure Z2 works with the version of Z3 bundled at the time. - In the next few days at most, after a few loose ends are wrapped up, we'll ask Andreas to make a 2.8 beta 1 release. While Jim still has a few things to do, people will be able to start using the beta for real work. - Anyone who cant wait for that can use the five-integration branch in SVN - As a community, we will work out how best to adapt the Zope 2 release process and schedule to that of Zope 3 going forward. We don't need to decide this immediately to continue to make progress on 2.8. I suggest an IRC meeting sometime soon to draft a proposal. 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: Clarification re: Zope X3.1, 2.8
Chris wrote: I assume these caveats are spelled out here because Z3 developers don't want to slow down Z3 development to test/maintain Z2 compatibility. I know a lot about Z2 code, but I know very little about Z3 code. I'd like that to change, but it's likely that I'll just not have the bandwidth to make sure Z3-inside-Z2 works. If that just means I can't use Z3 features but nothing else breaks, it's probably fine, but if Z3 integration actively breaks Z2, it's likely I'll just need for some extended period of time to continue to use and maintain 2.7. It'd be great if active Z3 developers could actually help make new releases of Z2 once Five is integrated but the above makes it sound like a we'll throw it over the wall and you make it work sort of thing. If it's the latter, maybe as devil's advocate, I need to ask what the point is here? It appears there is an assumption that merging Z2 and Z3 code within Z2 itself is an unmitigated good thing, but IMHO, each is complicated enough in their own right that I'd personally prefer to be dealing with one or the other at any given time and not both. This isn't exactly idle whining either, I need to do this when I maintain Z4I code, and it's definitely not a walk in the park; it's moderately difficult to do and also difficult find people who have the skills to help too. Does anyone else share this skepticism or am I about to get shouted down? ;-) - C A lot of time was spent talking about these (legitimate) concerns - unfortunately it will probably take a little time to distill all of that communication to the community. But let me take a shot ;) There are several different groups, with different goals and concerns, who are involved here: A: Z2 developers that don't care right now about Z3 B: Z2 developers that care about Z3, but can't effectively use anything Z3 related right now because it is not practical or possible to switch wholesale and there is no bridge to Z3 that doesn't require throwing away existing investments in Z2 C: Z3 developers that don't care about Z2 anymore, often because they dont have existing investments in Z2 There are a significant and growing number of people in group B. At the paris sprint, we were looking for a way to: - Allow folks in group B to start taking advantage of (and developing an interest in and contributing to!) Zope 3 technologies - Make sure that group A would not be 'forced' to do anything they don't want to do - Make sure that group C would not be 'forced' to do anything they don't want to do I feel that the approach of integrating Five into Zope officially does a pretty good job of meeting those goals. We added the Five product and a snapshot of Zope X3.0 into the core so that people could have a reliable baseline 'out of the box'. That integration touched almost nothing in the Z2 code (one or two things that were previously done as monkey patches were un-monkeyed, but that's about it). The Z3 code (and the Five code) just sits there unused unless you choose to use it, so Zope3 code breaking Z2 apps is not really a concern. But is there and available, so people can begin to plot their own migration paths based on their own situations. Like other areas of Z2 (and Z3, for that matter), contributors tend to develop areas of expertise. A new area of expertise for Z2 going forward will be the Five/Z3 integration, and there will be a set of devs who will likely focus on that aspect. I don't expect that the fact that Five and Z3 integration exists will make life any harder for someone who focuses on purely Z2 aspects of the core anytime soon. So the short answer is, we tried really hard to make sure to take an approach where z3 integration would not actively break zope2 in any way or force people into any particular direction. I *do* expect these (good) questions to recur in future Z2 releases, as integration and ability to use Z3 technologies increases, but we'll have plenty of time to work those out. For now, I think it is a huge win to make some Z3 avenues available to people who want to use them, without forcing everyone to drink the kool-aid at once ;) 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: [Zope3-dev] RE: Clarification re: Zope X3.1, 2.8
There are a significant and growing number of people in group B. Yup, that makes sense. Are these assumed to also be the folks who will try to make sure that new Z3 releases make it in to Z2 via Five? I guess what I'm driving at is that I'd hate to eventually have a very old version of Z3 sitting inside of Zope 2 due to insufficient bandwidth on the part of those developers to keep up with Z3 releases. While it wouldn't be the end of the world or anything, I suspect some dependencies will inevitably creep into the Zope 2 core on Zope 3 packages, and maintaining an older codebase can be pretty painful. The testing requirements for making sure that changes that Z2 coders make to Z3 work both in Z2 and Z3 is a pretty high bar, just as vice versa. In the past, I've seen efforts like this turn into an effective fork as a result. It won't turn into a fork. Right now there is a lot of discussion going on about the 'right' way to manage Z3 releases -- we'll need to decide on a Z2 release policy that takes that into account. I think the goal for Z2 will be to include the latest stable z3 possible. Some have suggested synchronizing the releases - that may be the way to go if it isnt impractical from an operational point of view. In any case, the goal is to gradually (but consistently!) make more and more Z3 functionality available to Z2 developers in future Z2 releases, based on the most stable Z3 baseline possible. Please correct me if I'm wrong here but I get the sense that Five is less of a migration path from Z2 to Z3 than a way to integrate Z3 technologies (like views and adapters) into Z2 right now. Obviously allowing Z2 developers to use these things will give them a some needed familiarity with Z3 if they decide to switch but the migration path to straight Z3 will always be more or less a rewrite, no? It is definitely a migration path. Lets say you have an application based on Z3 with 10 (logical) components. You couldn't feasibly rewrite all of it at once to use Z3. As of 2.8, you'll be able to add functionality to your application using adapters, views, etc. So for V.Next of your app, maybe you are able to port 2 existing components and add 1 new one. For V.Next.Next, you add 2 more and port 2 more. At some point, it *will* be feasible to jump to Z3 with a minmal effort, since you've been able to port your application to components over time. I *do* expect these (good) questions to recur in future Z2 releases, as integration and ability to use Z3 technologies increases, but we'll have plenty of time to work those out. For now, I think it is a huge win to make some Z3 avenues available to people who want to use them, without forcing everyone to drink the kool-aid at once ;) Yup... I'm still a bit skeptical but if other folks are committed to maintenance I'd be less so. Skepticism is healthy, but if it's any consolation, almost everyone involved in this effort has very real 'skin in the game' in terms of existing Zope2 investments. I think that will do a great deal to ensure that the decisions made for future 2.x work are sane and take real-world concerns into account. 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] Heads-up: Zope 2.8, Zope 3 and Five
Hi all - At the Paris sprint, a plan was hatched to integrate Five into Zope 2.8, which Jim, Andreas and others responsible for release management have endorsed. This will hopefully actually help spur 2.8 to the finish line as well as begin to provide an upgrade path into the future for Zope 2 developers. What this will essentially mean for is that: - Five will ship in the core distribution with Zope 2.8 - A subset of the Zope X3.0 packages will ship in the core distribution ...so it will be possible to use a number of Zope 3 technologies and patterns in existing Zope 2 applications. The Five integration layer provides support for Zope 3 interfaces, Zope Configuration Markup Language (ZCML), adapters, views, utilities, schema-driven content, and Zope 3 add and edit forms. Note that the Five layer does *not* attempt provide a ZMI user interface for Zope 3 components. Zope 2.8+ will include the essential Zope 3 packages, so it will not be necessary to install Zope 3 separately. If you are interested, there is now a 'five-integration' branch in Z2 SVN where this work is going on. 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: Zope Book development moved
I've come to the unfortunate conclusion that Zope.org is just not going to cut it to do Zope Book development work due to its speed (or lack thereof). I'd like to help fix the Zope.org slowness problem, but I'm a little unclear about what's required for me to get the level of access required to do so. I read the stuff at Zope.org/About and Zope.com/Legal but it's a little hard to divine out of the combination what I need to do before I can be allowed to help. So of the Zope.org Application Server Working Group/Zope Application Working Group/Whoever wants help trying to fix it, you know where to find me! Just don't make me attend a 7am committee meeting or sign a noncompete instrument wink. BTW, once Shane is safely settled out west we plan to engage him to fix a number of the ills of zope.org, so I expect we'll see a marked improvement in the near future. As to zope.org/About, it is confusing right now because the actual docs aren't yet posted. Michael is working as we speak to get the click-wrap alluded to in /About up and running and a place to organize these docs, have a place for working groups, expand the FAQ, etc. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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 )
RE: [Zope-dev] Re: bug in 2.6.2, 2.6.1 , and probably others.
I just stumbled on a bug in the python scripting parameter passing. Actually, it's a bug in the test tab support code. The parameter fields in the form are set to a , b , and c instead of a, b, and c. I'm fixing it in CVS for 2.7. Will this get into 2.6.4-final too? -1. In fact, it shouldn't even make 2.7.0 final. I don't think it is a showstopper bug, and would prefer to stick by our process (*no* non-packaging changes between the last RC and the release.) Tres. I agree. There is *always* one more bug that is important to someone, but for sanity's sake I too want to avoid any changes between the final rc final, especially given that I'd like to make finals on Friday. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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] Call for testing (2.6.4 / 2.7.0)
Hi all - Tres and I have been working to merge some final fixes, and I'd like to be able to make rc2 releases for 2.6.4 and 2.7.0 tomorrow. 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. It would be especially helpful for those who were having trouble with things like workflow scripts under the rc1 releases to give this a shot and let us know if the trouble is resolved. **Note that you need to rebuild the C extensions, due to a fix to cAccessControl. Be sure to do this before reporting any lingering issues!** Thanks, Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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 )
RE: [Zope-dev] RE: Resolved security-related collector issues forthepublic?
Brian Lloyd wrote: As the person who unfailingly gets flamed no matter which way the decisions leans :), I think we are probably at a point where we should have an official, documented and community-agreed-to policy on how these kinds of things will be handled. My intent was not flaming anyone... Sorry for that. I just tried to take the voice of the average Zope-Admin (installs Zope from a recent stable release, waits for the security-maintainers of distros to get security patches etc.). Sorry, I should have been more clear. I didn't mean to imply that your or Jamie's notes were flames (they're definitely not), just that I'd been singed in the past ;) At a minimum, having a clear and documented policy would provide the benefit of 'no surprises' - if you disagree with the policy, or some aspect of it, you would at least be able to plan around it. Very good idea...:) If all Zope-Admins can read before an installation: Security exploits will be exposed to the public as soon as they're resolved in the CVS everyone will should run Zope out of CVS. ...or will decide that doing so is unreasonable and use something else instead :( Note that I'm not necessarily criticizing that particular policy, just pointing out that _any_ policy will have some upside and some downside. The challenge will be coming to agreement on a policy with the right balance that everyone can live with. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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 )
RE: [Zope-dev] Re: RFC: backward compatibility of ps bindingsRESOLUTION
I did check with a fresh 2.6 xx
A DCWorkflow script that was not not called with the version from a few
hours ago is now called but produces the following traceback
This happens when the container binding is set to container and also
when it is cleared.
Traceback (innermost last):
Module ZPublisher.Publish, line 98, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 39, in call_object
Module Products.CMFCore.FSPythonScript, line 92, in __call__
Module Shared.DC.Scripts.Bindings, line 298, in __call__
Module Shared.DC.Scripts.Bindings, line 329, in _bindAndExec
Module Products.CMFCore.FSPythonScript, line 126, in _exec
- __traceback_info__: ({'traverse_subpath': [], 'container':
PloneSite instance at 95efa58, 'context': PloneFolder instance
at 9615280, 'script': FSPythonScript at
/zehnder/zehnder/createObject used for
/zehnder/zehnder/tasklist/Task.2004-01-21.1914/Attachments},
(None, 'File', None), {}, (None, None, None))
Module None, line 12, in createObject
Module Products.CMFCore.PortalFolder, line 362, in invokeFactory
Module Products.CMFCore.TypesTool, line 824, in constructContent
Module Products.CMFCore.TypesTool, line 516, in constructInstance
Module Products.CMFCore.TypesTool, line 420, in _finishConstruction
Module Products.CMFCore.CMFCatalogAware, line 101, in
notifyWorkflowCreated
Module Products.CMFPlone.WorkflowTool, line 26, in notifyCreated
Module Products.CMFCore.WorkflowTool, line 362, in notifyCreated
Module Products.DCWorkflow.DCWorkflow, line 367, in notifyCreated
Module Products.DCWorkflow.DCWorkflow, line 440, in _changeStateOf
Module Products.DCWorkflow.DCWorkflow, line 543, in _executeTransition
Module Shared.DC.Scripts.Bindings, line 298, in __call__
Module Shared.DC.Scripts.Bindings, line 329, in _bindAndExec
Module Products.PythonScripts.PythonScript, line 311, in _exec
Module None, line 1, in setTaskOwner
- PythonScript at
/zehnder/zehnder/portal_workflow/ZWorkflow/scripts/setTaskOwner
- Line 1
AttributeError: StateChangeInfo instance has no attribute
'getPhysicalRoot'
Robert
It would be helpful if you could go through that in the debugger
and see if you can get any more info - I don't see anything in
this that obviously points to any of the recent security changes.
That's not to say that one of those changes couldn't still be the
cause, but this traceback doesn't point to anything we can look
at :(
Alternatively, if you can make a copy of the failing script and
boil it down to the minimum possible code that demostrates something
that should be working but isn't (and that excludes app-specific or
Plone objects if possible so that we can turn it into a unit test)
I can try to look at it here.
thx,
Brian Lloyd[EMAIL PROTECTED]
V.P. Engineering 540.361.1716
Zope Corporation http://www.zope.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] RFC: backward compatibility of PythonScript bindings for 2.6.4 / 2.7.0
fixing no matter what. Thoughts? Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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] Re: RFC: backward compatibility of ps bindings RESOLUTION
Jeremy Hylton wrote: What if you used a special object that would produce a useful error message if the user tries to access the container. I like this. Make it a singleton, and put it in the global namespace for Scripts, so that we can write: if context is Inaccessible: # Do without access to context I've checked in the changes to the 2.6 branch, 2.7 branch and the head to change the binding behavior for 'container' and 'context': - If the user does not have access to the item, the script will bind an UnauthorizedBinding object instead of the real object, rather than throw an exception at binding time. - Any attribute or item access on the UnauthorizedBinding will throw an Unauthorized, including the name of the binding that the user didn't have access to. The result is that if you have scripts where the script container is inaccessible to the users of the script: - If the script does not reference 'container' in its code, things will work without any action on the part of the site admin - If the script *does* reference 'container' then a meaningful Unauthorized error will be raised. Site admins can either give users the appropriate roles on the script container or give appropriate proxy roles to the scripts to fix any problems. Note that I *didn't* put the UnauthorizedBinding in the script globals to implement the Inaccessible idea above, because: - it is kind of 'featurish', at least in that it really should have some associated documentation etc. - I want to make only absolutely necessary changes at this point and get 2.6.4 and 2.7.0 finalized. If any of the Plone folk who have been running into this issue can try the changes from cvs, I'd appreciate it. thx, Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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 )
RE: [Zope-dev] RFC: backward compatibility of PythonScript bindingsfor 2.6.4 / 2.7.0
These two facts did not cause a problem before, because the security check for the 'container' binding was not being performed at bind-time. One question - what *is* bind time? Is the container bound when the script is called? Yes - all of the bindings are figured out at the time the script is called. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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 )
RE: [Zope-dev] Resolved security-related collector issues for thepublic?
Maik Jablonski wrote: Normaly security-related stuff is not visible for the public... and this seems to be good to avoid exploits etc. Jamie Heilman wrote: Hiding the bugs doesn't avoid anything, it just leaves zope administrators helpless in the dark. I'm not going to rehash the arguments for and against full dislosure, but seriously--don't delude yourself into thinking that a problem goes away if you shut your eyes tightly enough. As the person who unfailingly gets flamed no matter which way the decisions leans :), I think we are probably at a point where we should have an official, documented and community-agreed-to policy on how these kinds of things will be handled. *Getting to that point* is what I'm afraid of :) There are pretty widely varying opinions on this, and historically as a community we've not yet found a good process to really resolve issues when there isn't a clear majority opinion. At a minimum, having a clear and documented policy would provide the benefit of 'no surprises' - if you disagree with the policy, or some aspect of it, you would at least be able to plan around it. While we at ZC try very hard to strike a delicate balance between transparency and risk management, doing so on a case-by-case basis is tough and there will *always* be some who disagree with the course chosen, no matter what it is. All in all, I think we'd better off having 'The Rules' regarding security reports, and working to make sure that we are all consistent in following them. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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 )
RE: [Zope-dev] post security update analysis
Thanks - I've marked these resolved. FYI I have a number of other issues still to mark resolved - I'll be trying to work through those today. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jamie Heilman Sent: Tuesday, January 20, 2004 12:16 AM To: [EMAIL PROTECTED] Subject: Re: [Zope-dev] post security update analysis Jamie Heilman wrote: Now that we've reached closure on some of the outstanding security issues in Zope there's a lot of stuff in the Collector that needs to be revisited... Brian Lloyd wrote: ... - Proxy rights on DTMLMethods transferred via acquisition I believe this means issue #743 and issue #977 can be resolved now. Actually, #977 already was rejected IIRC but its never been marked as public which is rather irritating. I've verified that this is the case, #977 should be made public, and #743 can resolved. - Improper security assertions on DTMLDocument objects probably fixes issue #865, but because Zope-HEAD doesn't actually run right now, due to a myriad of other bugs, I actually haven't tested it I've tested this now, #865 can be resolved. -- Jamie Heilman http://audible.transient.net/~jamie/ ...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity... -Rimmer ___ 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] win32 setup sources
I need a solution to quickly and easily deploy zope applications on the win32 platform. What I'd like to realize is a setup program that install and configure Zope bundled with all the needed products, making questions to the user for correctly setup the application. Unfortunately I have no experiences in windows programming and related setup tools and I'm lookin for good examples. Can someone tell me something about the win32 Zope installer and the tool used to build the executable? Are the sources available so I can simply customize them? (this is why I've sent the post to this list, please sorry if I'm OT!!) For versions of Zope up to and including 2.6.x, we've been using the WISE installer (5.0 I think). You can find the WISE setup script (zope2.wse) in the 'inst' directory of a Zope install on windows. For 2.7.0 and above, we've moved to using InnoSetup. We haven't worked out the best way to move that work to the public cvs yet. If you're planning to bundle 2.7, let me know and I can at least get you a snapshot of the install materials. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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 )
RE: [Zope-dev] 2.7 management_page_charset cannot be callable anymore
Hi guys - I was trying to be responsive to getting the issue resolved, since I'd like to make a (hopefully final) beta of 2.7 of Friday. I'll be happy to check in (or have you check in) whatever fixes are needed to give you the flexibility you need so long as it is b/w compatible, but I won't have the time to actively figure out what those fixes are this week. If you or Hajime can send me a patch against the current 2.7 branch, I'll make sure they get in before the beta is cut (or if either of you are committers it is also fine to checkin yourselves to the Zope-2_7-branch and head and let me know when its done). Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com -Original Message- From: Martijn Faassen [mailto:[EMAIL PROTECTED] Behalf Of Martijn Faassen Sent: Thursday, January 15, 2004 6:41 AM To: Brian Lloyd Cc: Hajime Nakagami; [EMAIL PROTECTED] Subject: Re: [Zope-dev] 2.7 management_page_charset cannot be callable anymore Brian Lloyd wrote: I forward-ported these to the 2.7 branch the head. Any testing you can do to make sure I didn't break anything would be appreciated. Now I understand that you were responding to these messages: I think the problem is same as reported by Kazuya Fukamachi http://mail.zope.org/pipermail/zope-dev/2003-December/021315.html and me. http://mail.zope.org/pipermail/zope-dev/2003-December/021338.html Fixing properties.dtml does not fix the problem that management_page_charset cannot be a callable anymore. This means that any logic to determine the right charset to use in displaying a page will fail to work (with an error) in Zope 2.7.(This can be fixed by rewriting the code to use a ComputedAttribute for management_page_charset.) So my problem and Hajime's may be different? Hajime? Regards, Martijn ___ 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.7 management_page_charset cannot be callable anymore
I forward-ported these to the 2.7 branch the head. Any testing
you can do to make sure I didn't break anything would be appreciated.
Brian Lloyd[EMAIL PROTECTED]
V.P. Engineering 540.361.1716
Zope Corporation http://www.zope.com
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Hajime Nakagami
Sent: Wednesday, January 14, 2004 1:29 PM
To: [EMAIL PROTECTED]
Subject: Re: [Zope-dev] 2.7 management_page_charset cannot be callable
anymore
+1
I think the problem is same as reported by Kazuya Fukamachi
http://mail.zope.org/pipermail/zope-dev/2003-December/021315.html
and me.
http://mail.zope.org/pipermail/zope-dev/2003-December/021338.html
At least this is important problem in Japanese (maybe Korea and Chinese)
developpers.
Hi there,
Some changes in Zope 2.7 break the possibility to make
management_page_charset
a callable (for instance a method).
This breaks Formulator, as it uses this facility. This works just fine
in Zope 2.6, but breaks in Zope 2.7.
The silly thing is that Formulator 2.6.0 breaks in Zope 2.7
exactly because
it actually is the release that tries to do unicode *right* (while still
retaining backwards compatibility with older installations and offering
a non-unicode mode), and then Zope 2.7 makes it impossible.
I heard a report that a similar problem may be occuring with ZWiki..
The problem is in lib/python/App/dtml/manage_page_header.dtml:
dtml-unless management_page_charset
dtml-call REQUEST.set('management_page_charset','iso-8859-1')
/dtml-unless
meta http-equiv=content-type
content=text/html;charset=dtml-management_page_charset;
dtml-call
RESPONSE.setHeader('content-type','text/html;charset='+management
_page_charset)
If I remember my DTML well, dtml-management_page_charset;
should still call
the method if it's a callable, so that would be all right.
The next line however breaks, as it's going to treat my method
as an attribute.
I think backwards compatibility got broken unintentionally here.. Could
this be restored? Using a ComputedAttribute for this would be rather
involved and it's possible other products are broken as well as a
result.
Regards,
Martijn
___
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] ANNOUNCE: Zope 2.6.3 Release and Security Update
Zope 2.6.3 Release and Security Update Zope 2.6.3 contains a number of security related fixes for issues resolved during a comprehensive security audit conducted in Q4 2003. You may download Zope 2.6.3 from Zope.org: http://www.zope.org/Products/Zope/2.6.3/ **Users of the VerboseSecurity add-on product for Zope please note:** some of the security-related changes in Zope 2.6.3 are incompatible with the VerboseSecurity product. Please uninstall the VerboseSecurity product before upgrading to 2.6.3 to avoid problems. It is expected that VerboseSecurity will be updated to be compatible with Zope 2.6.3 in the near future. Also note that there are binary code changes in the 2.6.3 release, making it impossible to issue an external hotfix to resolve these issues. CVS users should be sure to update their sites **and rebuild the C Python extensions** to ensure that all fixes are deployed. In the fourth quarter of 2003, a comprehensive evaluation of the changes to Python from version 2.1 to 2.3.3 was undertaken. This evaluation was designed to assess each change to the Python environment in terms of its potential impact on the Zope application server and Zope applications, with the goal of making Python 2.3.3 the required Python platform for Zope beginning with Zope 2.7. The evaluation was focused on assessing changes to Python in the following contexts: - Changes that would have compatibility or other effects on existing or new Zope applications - Changes that could potentially affect the Zope security architecture or change the behavior of the restricted execution environment used by Zope to run untrusted code In the course of the evaluation, very few of the Python changes in 2.3.3 directly affected the Zope security architecture or had impacts on the restricted execution model. However, a number of pre-existing potential issues were discovered and resolved in the course of the comprehensive security audit that was performed as a part of the Python upgrade evaluation. Zope 2.6.3 provides fixes for all of these issues. A description of each issue, who is affected and issue status is included below. For more information on what is new in this release, see the CHANGES.txt and HISTORY.txt files for the release: - http://www.zope.org/Products/Zope/2.6.3/CHANGES.txt - http://www.zope.org/Products/Zope/2.6.3/HISTORY.txt For more information on the available Zope releases, guidance for selecting the right distribution and installation instructions, please see: http://www.zope.org/Documentation/Misc/InstallingZope.html ISSUES RESOLVED BY Zope 2.6.3: - For loops, list comprehensions, and other iterations in untrusted code Issue Description Iteration over sequences could in some cases fail to check access to an object obtained from the sequence. Subsequent checks (such as for attributes access) of such an object would still be performed, but it should not have been possible to obtain the object in the first place. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - List and dictionary instance methods in untrusted code Issue Description List and dictionary instance methods such as the get method of dictionary objects were not security aware and could return an object without checking access to that object. Subsequent checks (such as for attributes access) of such an object would still be performed, but it should not have been possible to obtain the object in the first place. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Use of import as in untrusted code Issue Description Use of import as in Python scripts could potentially rebind names in ways that could be used to avoid appropriate security checks. Who Is Affected? Sites that allow untrusted users to write Python Scripts, Page Templates, and DTML. Resolution This issue is resolved in Zope 2.6.3 and Zope 2.7.0 beta 4 and higher. Affected sites are strongly encouraged to update their Zope installations to prevent this issue. - Use of min, max, enumerate, iter, and sum in untrusted code Issue Description A number of newer built-ins were either unavailable in untrusted code or did not perform adequate security checking. Who Is Affected? Sites that allow untrusted users to write
[Zope-dev] RE: api docs [Was: Re: Post-mortem ...]
What is the Right Way to keep api docs in sync? Example 1: ZCatalog/IZCatalog.py seems to be more up to date, but ZCatalog/help/ZCatalog.py is used by the Zope Help System and I guess also to generate api docs. Example 2: I did add OFS/IOrderSupport.py, but how will it become part of help and api docs? Is there a better way than copying it to OFSP/help? I hate to add redundant code because - as example 1 shows - it is hard to keep the files in sync. CMF uses the interface files also as help files. As interface files become more and more common in Zope it might make sense to do the same in Zope. Ghaaa... :( API docs come from OFSP/help, so you'll probably have to copy it for now. As you rightly pointed out, this is problematic for keeping things in sync, but we should hold our nose for now and do it, since it's too late in the 2.7 cycle to contemplate that big a restructuring. Making this sane would be a good potential project for an enterprising zopista for 2.8... Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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 )
RE: [Zope-dev] Re: Post-mortem [Was: Zope 2.7.0 b3 regressions]
Summary: absolute_url(1) didn't include the path to the virtual root, which broke code that assumed that it could just prepend / in all cases. I changed it to include the base path, and broke code that prepends BASEPATH1. Since the old behavior existed for two years (including part of the 2.7 beta), is arguably easier to work with, and works with existing CMF code, I will revert to it. This will leave /-prepending code broken. In line with Stefan's original suggestion, I will add a new method with alternate behavior. It's not hard to grep for broken code and use the new method to make it correct -- Product authors should do so. Good call. I think it would be best to make sure the docstring of the new method is clear on its reason for being. I think somewhere there is an interface file that is used to generate some of the api docs - ideally that can get updated too. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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] Announce: Zope 2.7.0 beta 3 released
Zope 2.7.0 represents a concentration on software configuration and installation improvement over older versions. Note that Zope 2.7 now requires Python 2.3.2. You may download Zope 2.7.0b3 from Zope.org at: http://www.zope.org/Products/Zope/2.7.0b3/2.7.0b3 Particular features of interest in Zope 2.7.0: - DBTab integration (mounted databases for Zope). - New logging module support. - ./configure; make; make install installation from source - configuration-file-driven configuration - integration of ReStructuredText - OrderedFolder support - Many bugxfixes For more information on what is new in this release, see the CHANGES.txt and HISTORY.txt files for the release: - http://www.zope.org/Products/Zope/2.7.0b3/CHANGES.txt - http://www.zope.org/Products/Zope/2.7.0b3/HISTORY.txt For more information on the available Zope releases, guidance for selecting the right distribution and installation instructions, please see: - http://www.zope.org/Documentation/Misc/InstallingZope.html Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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] Heads up: tag 2.7 beta 3 Tuesday
I'd like to plan to tag Zope 2.7 beta 3 this coming Tuesday and release it. Please make sure anything you may still be doing on the Zope-2_7-branch is wrapped up by Monday evening (EST). Thanks! Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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 )
RE: [Zope-dev] Re: bugday results.
HUGE PROPS to everybody today! I got caught in some unplanned things and never got there :( I *promise* we'll get a beta 3 out in the next two weeks - hopefully by this Friday now that I know how to drive the win32 install machinery (thanks Chris!) Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Maik Jablonski Sent: Tuesday, November 04, 2003 5:50 PM To: [EMAIL PROTECTED] Subject: [Zope-dev] Re: bugday results. Chris McDonough wrote: Bugs squashed: 22 1105, 1107, 1108, 273, 331, 350, 382, 391, , 1095, 1074, 1110, 1016, 616, 682, 822, 582, 445, 799, 923, 426, 1100. Not bad for a five-person IRC channel. ;-) Hi, just as a little post-contribution from me (I was out of office all the day and couldn't join :( the bug day), all the links to the fixed bugs for lazy click-and-view-people like me: http://www.zope.org/Collectors/Zope/1105 http://www.zope.org/Collectors/Zope/1107 http://www.zope.org/Collectors/Zope/1108 http://www.zope.org/Collectors/Zope/273 http://www.zope.org/Collectors/Zope/331 http://www.zope.org/Collectors/Zope/350 http://www.zope.org/Collectors/Zope/382 http://www.zope.org/Collectors/Zope/391 http://www.zope.org/Collectors/Zope/ http://www.zope.org/Collectors/Zope/1095 http://www.zope.org/Collectors/Zope/1074 http://www.zope.org/Collectors/Zope/1110 http://www.zope.org/Collectors/Zope/1016 http://www.zope.org/Collectors/Zope/616 http://www.zope.org/Collectors/Zope/682 http://www.zope.org/Collectors/Zope/822 http://www.zope.org/Collectors/Zope/582 http://www.zope.org/Collectors/Zope/445 http://www.zope.org/Collectors/Zope/799 http://www.zope.org/Collectors/Zope/923 http://www.zope.org/Collectors/Zope/426 http://www.zope.org/Collectors/Zope/1100 Cheers, Maik ___ 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] Zope doesn't know enough mime types.
fyi, I'm ok with merging this to 2.7 if it already is on the HEAD, has tests, and has at least some minimal docs. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Fred L. Drake, Jr. Sent: Thursday, October 30, 2003 11:42 PM To: robert Cc: Zope Developers list; Romain Slootmaekers Subject: Re: [Zope-dev] Zope doesn't know enough mime types. robert writes: would be nice if we had it in 2.7 That's up to Brian Lloyd. I think it's a low-risk change, but we really want to stabilize and finish 2.7. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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] Bugday Reloaded: The Sequel
Hi all - I'd like to try to have another bug day next Tuesday (Nov 3) to make up for the one that was cut short last week, in preparation for a beta 2 release of Zope 2.7. I know its short notice, but every little bit helps. If you can make it even only for an hour or two it will be much appreciated. thanks! Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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 )
RE: [Zope-dev] cvs.zope.org down
Toby Dickenson wrote That makes me nervous. How will you know that the sources in cvs havent been compromised? Surely people can compare checkouts of the various branches (2.6, 2.7) against downloaded tarballs? We can't do the same with TRUNK, but that should be still possible to check against, say, a 2.7 beta. I have checkouts of just about every branch ever + the head in a couple of places - based on those, nothing untoward appears to have happened to the source tree. Everyone with a product or other code in that cvs should do a check to make sure, but given that we caught the intrusion almost immediately and that the attacker's methods were rather unsophisticated, I think the risk is pretty low. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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] RE: [Zope] New location for Zope Collectors
Er - this one's my fault :) When I first started triage on nzo
there were a number of places where it was doing totally unbounded
searches and them sorting them for good measure. I put that in as
a stopgap so it would quit dying while I was trying to find the
culprits and forgot to remove it.
Brian Lloyd[EMAIL PROTECTED]
V.P. Engineering 540.361.1716
Zope Corporation http://www.zope.com
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Chris McDonough
Sent: Thursday, October 23, 2003 3:51 PM
To: Jens Vagelpohl
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [Zope] New location for Zope Collectors
I see it's already fixed, thanks...
On Thu, 2003-10-23 at 16:39, Chris McDonough wrote:
Aha! This is likely due to the monkey-patched searchResults method of
the catalog tool. It is patched from within the ZopeOrg product's
__init__.py:
if not kw.has_key('sort_limit'):
kw['sort_limit'] = 200
I'm sure this was put into there to foil some sort of DOS, but I think
it should be taken out on the appserver and we should see what happens
from there... do you think you can do this Jens?
On Thu, 2003-10-23 at 16:05, Chris McDonough wrote:
On the new collector instances the high size of a collection
of objects
seems to be limited to 200. Aha! Here we have evidence that someone
has hardcoded the number 200 as the upper limit for the number of
catalog results returned from the portal catalog on zope.org. This
happens with howtos and products too. I suspect that if we grep the
source for 200 we'll likely be able to fix it. I'll do that now...
On Thu, 2003-10-23 at 14:37, Jens Vagelpohl wrote:
Hi everyone,
The issue collectors formerly hosted on collector.zope.org
have been
migrated to the main zope.org website and are now available at the
following address::
http://www.zope.org/Collectors/
I have tried to find all links to these collectors, but
there might be
old links in various places that still point to
collector.zope.org. The
hostname collector.zope.org will, once the DNS change has
propagated,
point to www.zope.org.
jens
___
Zope maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
___
Zope maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
___
Zope maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
___
Zope maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
___
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] Reminder: bug day tomorrow Oct 21
Hi all - A quick reminder that we'll be having a bug day tomorrow 10/21 to try to knock out some remaining issues in the drive to get a Zope 2.7 final out. Hope to see you on #zope-bugday ! Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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 )
RE: [Zope-dev] Reminder: bug day tomorrow Oct 21
I'm getting close to needing to roll out an upgrade for a client site that will need to use python2.2 or . I have zope-2.6.2 working with python2.2.3 but when I try and use python2.3.2 things don't go so well. I'm wondering should I wait for 2.7 (and python2.3.2) or just go with what I have. I would like to roll the upgrade next week (but I might be able to put it off for another week). You are probably better off sticking with what you have for now - while 2.7 should land soon, I'd be surprised if the final were cut much before the end of November given that there are still some loose ends regarding config installation and the need for at least one more beta (more likely two). Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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] Zope.org maintenance update afternoon EST
Hi all - I will be doing some maintenance on the zope.org database, packing it and performing a reindex to get rid of some duplicate search results that we've been seeing. There should be little to no interruption of service, but the pack / reindex / replace will take an hour or so. Please avoid adding new content to the site for this afternoon (EST), as I may need to take a copy of the db to do these operations in order to avoid impacting performance on the main site. thanks, Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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 )
RE: [Zope-dev] Where is Zope 2.6 Final?
It's been a while since the last beta, and I haven't seen many (if any) changes checked into the 2.6 tree in a while. What's the holdup? With all the problems that exist with 2.6.1 (with packing, especially) I would have thought 2.6.2 would have been out months ago. --andy. We'll try to crank that out today. And why haven't you raked my leaves yet - sheesh, I thought that would have been done months ago! :^) Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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] Announce: new www.zope.org is LIVE!
At long last, http://www.zope.org has gone live with a new look and a new platform based on Zope 2.6.2, CMF 1.3 and Plone! Our thanks go to the cast of thousands who have participated in this project over time, most recently Guido van Rossum and Sidnei de Silva for getting us to the goal line. Zope.org is a big site with a lot of content. We've tried hard to test the most common resources, but we fully expect some issues to arise in the transition. We are also certain that the best way to work things out quickly is to 'make it live' and tackle the issues as they come up. If you notice anything weird, broken or missing from the site, please send us a problem reporting using the ZopeOrg issue collector: http://collector.zope.org/ZopeOrg/collector_add_issue_form Issues that we are aware of and working to resolve this week include: - Logging in as a member takes a ridiculously long time. We think this might be an LDAP interaction and we working to fix it. - We have not done extensive cache tuning yet - if you experience any unreasonably slow load times, please let us know the URL you were trying to get to help us tune caching. The old sites will remain accessible for some time at the following URLs in case anything was missed in the transition: - http://old.zope.org - http://olddev.zope.org Note that it will take some time for DNS changes to propagate, so you may not see the site changes immediately. Thanks again to everyone who has been involved in making this happen! Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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] NOTICE: Final content migration and transition to new zope.org begins today!
Hi all - sorry for the wide cross-posting, but I want to be sure that the word gets out. Starting today, we will be starting the transition of zope.org to a new look and a new platform. We plan to do the final content migration later today, so if you are a frequent content contributor to zope.org, you may want to hold off on new additions until the new site goes live (expected to be Friday). I've put a prominent notice on the current zope.org homepage with the same info. Thanks, and we'll see you on Friday with a new zope.org! Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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] Zope 2.6.2 b4 final
Hi all - We're planning to cut 2.6.2 b4 today, since there have been a few fixes committed since b3. I'd like to plan to cut the final next week with no changes from b4. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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] New zope.org rollout and transition plan
Hi all - At long last, we are preparing to 'go live' with a new and improved zope.org. The new site will put an architecture in place that will make it easier to maintain and improve the site. We're planning to make the new site live as www.zope.org at the end of July. The current site will still be accessible as old.zope.org. We plan to keep the old site available for a reasonable amount of time to ensure that important content that may have been missed by the migration can be hand-moved, etc. We'll give plenty of notice before decommissioning the old instance. Q: What does this mean for zope.org members? Generally, all membership info and most content will be transitioned to the new site automatically. Due to the amount of content and the 'organic growth' of the current zope.org over time however, there may be some bits of content that are either missed or get broken in some subtle way during transition. If you maintain product releases, articles or other content on zope.org, it would be a good idea to check on it after the transition. If you find things missing, you should be able to find it on the old.zope.org site and add it manually to the new site. If you find something broken and you don't know why, let us know so we can fix it. Q: Will there be some kind of 'public beta' period? Not per se. Experience has shown that it is hard to drum up the critical mass of usage required to really uncover non-obvious issues using a separate 'beta' site. In addition, zope.org presents a challenge in that you really need a short and choreographed 'switchover' window due to the community- contribution nature of the site. Members generally don't want to contribute their content twice (once on a beta site and once on the 'real' site), and we also need to go live quickly after a final content migration to minimize the inconvenience for people who might contribute content in the window between final migration and the launch of the new site. Q: Will the transition be quick, painless and invisible? Ha ha - silly human. :) We know from experience during the last zope.org transition that there will a period of hand-fixing after the new site goes live. Leaving the old site accessible during the transition will help with any pain we experience. I'll send another note when we finalize the dates for the final content migration and go-live date. I want to keep the window between these down to a day if possible to minimize disruptions. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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 )
RE: [Zope-dev] 2.6.2b3?
Tim says that this has been merged into the 2.6 branch (last week). Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of seb bacon Sent: Monday, June 23, 2003 4:13 AM To: [EMAIL PROTECTED] Subject: [Zope-dev] 2.6.2b3? 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.di ff?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 ) ___ 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] channel for bugday?
where are we holding bugday today? #zope-dev? Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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 )
RE: [Zope-dev] Re: [Zope-Coders] Bug day?
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 Rats - you've foiled my plan. I guess I won't be able to get away with scheduling the next one for Wed. the 32nd. In the interest of the integrity of the space-time continuum, we'll leave Tuesday where it is and do it then. ;) Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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] Bug day?
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-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?)
FYI - we plan for this to be fixed in 2.6.2, preferably by fixing the version machinery to require the join / leave versions permission (which is assigned only to managers by default. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Oliver Bleutgen Sent: Tuesday, June 10, 2003 7:35 AM To: [EMAIL PROTECTED] Subject: Re: small summary and big plea was:(Re: [Zope-dev] Versions: should they die?) Chris Withers wrote: Shane Hathaway wrote: My opinion on this is a little different. It's quite easy for anyone to make mischief on any Zope server that lets people make even minor changes to the site, such as giving feedback, posting a discussion item, etc. On the weekend I had the idea that it's even easier. See http://zope.nipltd.com/public/lists/dev-archive.nsf/ByKey/D1CAAEC689AB7BA9 how to do that on an zope server. All you have to do is include a Zope-Version cookie in the request and your changes will place a lock on any objects that the request touches. Zope doesn't even check the validity of the Zope-Version cookie. Anyone who is not a ZODB expert would have a hard time bringing the site back to sanity. This was my fear, and it's pretty shocking. Maybe Oliver should do just such a thing on both collector.zope.org and zope.org, or maybe cbsnewyork.com to prove a point and then this issue will get the attention is deserves ;-) Yeah, and I'm sure I'd get personal attention too, in a way I'd prefer not to get ;). 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] Let's have another bug day
How about the next Wed after that (9/4)? April 9th is ok for me. Florent Sounds like April 9th works best for everybody, so lets go with that. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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 )
RE: [Zope-dev] Let's have another bug day
It's been some time now since we last had a bug day. Should we have another one? Absolutely. How about Wed the 2nd? FWIW I'll be unavailable that week. Likewise... :-S Chris I just threw a date out there because someone had to :) If there is one that would work better for the bulk of the folks interested, pls do... Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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 )
RE: [Zope-dev] Let's have another bug day
It's been some time now since we last had a bug day. Should we have another one? Absolutely. How about Wed the 2nd? Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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 )
RE: [Zope-dev] ESI Integration in Zope
Out of curiosity, Beyond coding XHTML-based ZPTs with tags in the ESI namespace, what else is needed in Zope to make this work? Does Zope need to set an HTTP header for downstream proxies to know that the content of the page is supposed to be processed for ESI? Sean You won't need to set headers manually - things like that will be set for you by virtue of using the ESI tags in a template. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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 )
RE: [Zope-dev] ESI Integration in Zope
What is the roadmap for ESI integration in zope ? (http://www.zope.com/News/PressReleases/OpenSourceESI) In which version of zope : 2.6, 2.7 or 3.0 ? Thanks. We're shooting for Zope 2.7. Jim still needs to work out a lingering issue with it. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.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] FYI: Zope 2.6.1 b2 scheduled for friday
Hi all - We're planning to cut 2.6.1 b2 this Friday. I wanted to give the heads-up in case anyone was in the middle of anything that needs to get in (I saw Toby had committed some things, and it looks like that merge is complete). Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] 2.6.1b2?
afaict, the public schedule since December has been that this is imminent any day now. I have some important bug fixes that I would like to include in 2.6.1, and I would like some assurance that beta 2 will not be released mid-merge. I don't think b2 will be release without a heads-up (right, folks?), so I think you should go ahead and include them, but that's is just MHO. Still, I (and the community, I think) would like to know what's keeping b2 and if there's anything we can do to help it. Maybe this is just another case of a part of the Zope process that unecessarily depends on ZopeCorp manpower that could, perhaps, be delegated to the comunity, such as compiling packages for some platforms, etc. Mea culpa - I've not been doing nearly good enough a job at keeping the community informed :( Here's the status - an engagement that we're doing has been bringing up some issues regarding ZODB and ZEO in large-scale environments. I think that the fixes are useful enough that they should be in 2.6.1, but getting them finalized has taken longer than I expected. I'll know better later today, but I expect that the fixes will be wrapped up this week, enabling a 2.6.1 b2 next week. Because it has dragged out so long, I'd prefer to get the ZODB fixes in, release 2.6.1 b2 and hopefully soon thereafter a 2.6.1 final with no further changes. A 2.6.2 effort could start as soon after as needed, to add the other fixes mentioned and hopefully also include the fruit of another bug day. Again, sorry about the confusion... Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] 2.6.1b2?
Here's the status - an engagement that we're doing has been bringing up some issues regarding ZODB and ZEO in large-scale environments. I think that the fixes are useful enough that they should be in 2.6.1, but getting them finalized has taken longer than I expected. I'd love to know what kind of thing 'large-scale' implies here, and what kind of problems the fixes fixed. Large-scale meaning large numbers of ZEO clients, that mount multiple ZEO-served databases that are each replicated using ZRS (Zope Corp.'s replication / failover solution) :^) The changes have to do with coordination of transaction commit among multiple databases, manageability and fault-tolerance. I'll ask Jeremy to be sure to update the CHANGES.txt with the important changes. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] FYI: added Web Services Zope 3 sub-project
(Copying zope-dev because I'm not sure all of the people who started on this discussion are on zope3-dev yet. Lets use zope3-dev moving forward) Hi all - There has been a bit of discussion recently regarding plans for web services in Zope 3, with a number of people expressing interest in moving this forward (and possibly scheduling some WS sprints to kick-start the process). For those who've been paying attention to those threads, I've set up a Zope 3 sub-project at: http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/WebServices ...with a start at some organization and artifacts (largely cribbed from the old Z2 WS project). Please take a look and feel free to jump in an refine, comment or refactor. One of the first things we need to do is find someone (or a group of someones) to spearhead the effort and own the project area. Any volunteers? :^) Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] z3 sprint at pycon?
Actually, I was hoping that this is how it might fall out. By hook-or-crook, I want to get two of our developers to pycon. The possibility of a 'web services' z3 sprint would be major icing on the cake (for us). If the interest is not there, however, (hard to get a read on that) any exposure to a sprint (for us) would be great. If the interest is not there, I think we will try and steal a few hours of Brian's busy schedule to (at least) begin mapping out a strategy to move forward with his work (to date). As I said in the past, I will be able to put full-time (long term) developer resources into this effort early next year. Sounds like a plan :) I was thinking that a good near-term thing to do would be to see about setting up a Web Services SIG area on the Zope 3 dev site and start mapping out strategy there. A good start might be to schedule an IRC chat so that the players can all get together and agree on some high-level goals, so that we have some options for concrete things to do by the time of the conference. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.
Toby Dickenson [EMAIL PROTECTED] wrote: The final beta is due today. Was this announced somewhere? I really wish the release schedule was a bit more known in advance. It was announced on this list (and zope-coders) a couple of weeks ago. FYI - with the holidays and other things going on, I don't think b2 will actually be able to go out until at least Monday. It looks like there might be a few left-over issues from bug day that I'd to follow up on, but I won't be available to do that today :( Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] FYI: Zope 2.6.1 beta 1 today...
Hi all - We're planning on releasing a Zope 2.6.1 b1 today, and I wanted to give the dev folks a heads-up and let people know the plan for getting to 2.6.1 final. The release today will contain some ZODB / ZEO fixes as well as the datetime fix and some other fixes added since 2.6.0. We will be having a bug day next Tuesday, and the goal will be that those fixes will also go into the Zope-2_6-branch to be included in a 2.6.1 beta 2 to be release hopefully around the end of next week. Assuming there are no issues with the b2 release, we'll plan on making it final a week or so after that for a late xmas present :) This schedule should also provide enough time for the valiant volunteers working on the 2.6.1 version of the Zope Book to finalize things for the release. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] FYI: Zope 2.6.1 beta 1 today...
On Wednesday 10 December 2003 07:01 am PDT, Brian Lloyd wrote: We will be having a bug day next Tuesday, and the goal will be that those fixes will also go into the Zope-2_6-branch to be included in a 2.6.1 beta 2 to be release hopefully around the end of next week. In the original bug day announce, Chris McDonough said the bug day would be on Monday, December 16, not on Tuesday as you say. Could you please clarify on which day it is? Sorry - my bad. It is Monday, as Chris said. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Web Services Sprint???
On Wed, Dec 04, 2002 at 07:16:04AM -0800, Andy McKay wrote: Yes. Where are you located? I was thinking of organizing a west coast US sprint... According to this email (about a month ago: http://lists.zope.org/pipermail/zope-dev/2002-November/017898.html ) He's in Southwestern Mississippi, which puts him closer to me than you - a Gulf Coast sprint? ;-) Ross We'd also be willing to host the WS sprint here in VA if that helps - though New Orleans sounds like a lot more fun! :^) Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Bugfix release?
FYI I'd like to have a 2.6.1 beta out next week. Jeremy is still looking at a few ZODB bug reports - as soon as he's done we'll make the beta. Im not sure this is a good plan. Jeremy's sortKey changes look like they deserve a longer beta testing period than I would have thought the demand for a DateTime fix would allow. My understanding was that objects would not be required to implement sortKey (and wouldn't be adversely affected for not implementing it) unless they cared about the specific issue that it addresses. I'll verify this w/Jeremy tomorrow, but last I heard ordering should only actually be an issue for Connection objects - other objects that play with the transaction mgr will generally not be subject to the deadlock issue that the sorting is designed to prevent (the deadlock is due to connection interaction w/a storage server). Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Bugfix release?
From: Andreas Jung [EMAIL PROTECTED] Someone posted already a fix for this problem. It should not be hard to fix this single problem by exchanging the DateTime.py file on your sites Yep, it's on http://www.zope.org/Members/regebro/ somewhere. But I agree that it's time for a bugfix release pretty soon. Most serious bugs should have appeared by now, and making a bug fix release shouldn't be that hard, or? FYI I'd like to have a 2.6.1 beta out next week. Jeremy is still looking at a few ZODB bug reports - as soon as he's done we'll make the beta. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Moving forward with Zope 2.7
Is there already a schedule for Zope 2.7? (of course there is not :-) ) Now there is :) http://dev.zope.org/Wikis/DevSite/Projects/Zope2.7/FrontPage I've updated this project and tried to dispel any lingering confusion over the earlier effort labelled Zope 2.7. I proposed to include reStructuredText into Zope 2.7. This stuff is ready to be merged. If there are no objections I will merge it soon since there were only positive votes for the inclusion. Please don't merge anything until people have had a chance to see what's going on and gotten the plan finalized. Per the plan above, I'd like for there to be a (relatively short) period for people to volunteer and add proposals to the plan, followed by a process of prioritizing and coming to closure on what will / won't be included. I propose in the wiki that we should probably schedule an IRC day to do that. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Web Services for Zope; what happened?
I'd like to know what happened to this proposal: http://www.zope.org/Wikis/DevSite/Projects/WebServicesForZope/FrontPage Is the WebServices package (CVS) working? Any technical reason why it was discontinued? Thanks, Stefan I'd still like to see that get finished one day. What happened is that a) there are no paying customers driving continued development and b) I haven't had any extra time to devote to it for a long while. Parts of it are working (see the unit tests for info). As for technical reasons, the next big step is to parse and model XML Schema info. There is not currently (or at least there wasn't last I checked) a drop-in library for this that exposed what I felt would be needed, and I definitely don't have the time to implement one :) An alternative would be to implement interfaces similar to what Apache's Axis does (punt and let the programmer figure it out) when faced with non-simple data types. There are enough technologies (and constant changes to those technologies) in the WS world that it requires real stakeholders, people who use WS as a part of their day job to keep up and manage a real-world usable Web Services package. Right now I don't use WS in my day job, so I'm not that guy. I've had a number of people inquire about the status of the package, but so far no one willing to volunteer to move things forward. If you (or anyone else) is interested, I'd be happy to provide any guidance I can. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] 2.6.1 Plan?
Likewise, with Zope my impression is that once the Beta is cut, we are in feature freeze. Now, ZC may not have operated that way in the past *entirely*, but I think we should from now on. A flurry of commits *before* feature freeze seems unaviodable, however. That's what deadlines are for, after all grin. --RDM That has indeed been the case in my experience. Another aspect of this that might not be apparent if you are not the one who happens to be trying to manage the release process is that there is always a delicate balance between enforcing the letter of the law and making concessions to ensure that being a contributor is a rewarding experience rather than a frustrating one. Some things have to be taken on a case-by-case basis, and I can say with some authority that no matter what you choose, some people will praise you and some people will blast you for it :) Keep in mind, too, that the 2.6 release is really the first release that has had anywhere *near* this level of community contribution, so some rough edges should be expected. There is still plenty for all of us to learn. P.S. - I'm planning to do a little revamp of the dev homepage by the end of this week to simplify a few things and hopefully make it easier to know what's going on, as well as posting the plans for 2.6.1 and much-misunderstood 2.7. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Is the aliasing of 'hasRole' correct?
In AccessControl/User.py::
def hasRole(self, *args, **kw):
hasRole is an alias for 'allowed' and has been deprecated.
Code still using this method should convert to either
'has_role' or
'allowed', depending on the intended behaviour.
import warnings
warnings.warn('BasicUser.hasRole is deprecated, please use '
'BasicUser.allowed instead; hasRole was an alias for
allowed, but '
'you may have ment to use has_role.', DeprecationWarning)
self.allowed(*args, **kw)
Shouldn't that be::
return self.allowed(*args, **kw)
Yes, it should. Thanks Jean. I've checked in the fix for this.
Brian Lloyd[EMAIL PROTECTED]
V.P. Engineering 540.361.1716
Zope Corporation http://www.zope.com
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Windows Zope Install
Can anyone point me to the location of the configuration file for the Windows install in CVS? I'm sure Brian pointed it out to me once, but I cant find it at the moment... -- Andy McKay Hi Andy - The WISE install script is in the /inst directory of the releases. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DTML and REQUEST data changes about to be checked in
Like I said before, this is probably a good feature. If it was available as a patch then I would probably use it on a number of my sites, and would recommend it to others. I would be very happy see it (or something like it) in 2.7. But not 2.6. Then Jim wrote: WRT to this change, now that I'm back from vacation, I want to talk to Brian about it. ;) Hear ye, hear ye :^) Zope 2.6 is a second-dot release, meaning that it is expected that there will be new features and that it is possible (though we always try to avoid it) that some things can break in the name of progress. (See http://dev.zope.org/CVS/ZopeReleasePolicy for more details). Zope 2.5.x will be a third-dot release, intended to be bug-fix only (and thus not allowed to break things). So here's what we'll do. Zope 2.6 will include the string tainting changes, enabled by default. The tainting can be turned off by providing an environment variable. The next Zope 2.5.x release will contain the tainting code, but it will be *disabled* by default. If you are worried about the issues it addresses, you will be able to enable it explicitly using an environment variable (without having to upgrade to 2.6). 2.7 and later releases will behave as 2.6. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] bug in RESPONSE.appendHeader
Glad to help. The error in the documentation string seems to have propagated to other locations. It appears in /lib/python/Products/OFSP/Response.py(line 130) and in the Zope Book http://www.zope.org/Documentation/ZopeBook/AppendixB.stx. Ok - I've fixed the help system .py file and added a comment to the book site so that this should get fixed for the next rev. Thanks! Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] bug in RESPONSE.appendHeader
First off, the on-line documentation description of this method is 'Append a value to a cookie'. Second, it breaks if you are in fact adding a second value to a header that already exists. Thanks - I've checked in the fix for 2.6 and on the 2.5 branch. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Bug Day for June?
Are we having a Bug Day on Friday? I'd prefer if we could have Bug Days on Thursdays instead of Fridays. Friday means I have to stay late at work when the weekend has already started and everybody else is at the pub/café/parties :-) Same thing for all of us Europeans I guess. How about _next_ Thursday (the 20th)? Things are pretty hectic here this week, and I'd like to try to push out 2.6 a1 (which we're already running a little behind on). Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] ACTION: 2.6 project status updates...
The appointed time is upon us :) We'd like to shoot for a 2.6 alpha 1 release at the beginning of next week (around the 10th). Eeek - six days before a hard deadline is less notice than I would have liked. What?! It's a month past the hard deadline I gave at the beginning! :^) http://lists.zope.org/pipermail/zope-dev/2002-March/015587.html All my items are code complete. They all have documention *somewhere*, but for some the documentation hasnt been merged into *all* the appropriate places. I definitely wont have time to do that before the alpha1 deadline. That's ok, so long as it won't be a problem to get that done in the next 2 weeks. There are a number of items for which people have committed, but are now marked as deferred. Its a PITA that people couldnt have retracted the commitment sooner. In particular, I would have been keen to take over the HTTP_X_FORWARDED_FOR proposal. but not before the 10th. I fully expect that this first community-driven release cycle will teach us a lot. For one, I think that there were way too many proposals on the 2.6 plan. For the next rev, we need to refine the process to try to keep the scope tighter and probably also refine the commitment process so that we know the real status of things sooner. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] ACTION: 2.6 project status updates...
Hi all - The appointed time is upon us :) We'd like to shoot for a 2.6 alpha 1 release at the beginning of next week (around the 10th). I updated the 2.6 proposed feature page this morning: http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures ...but there are a number of items that we need to clarify the status of. There are a couple of 99% complete notes, etc. For everyone who is on the hook for a 2.6 feature that is not marked Complete on the list, I'd like to get a status update that includes: - whether the work _and_ docs are done - if not, whether you will be able to do them by Fri. - whether your branch is merged. Note that Complete on the feature page means that you have finished both the code and docs, and have merged your working branch to the HEAD (and run and passed the unit tests). If something is marked complete that isn't really, let me know that as well! Silence is consent for me to move your incomplete item to the deferred items section, so please drop me a status update even if its just to say I still want to do it, but I don't think I can make the deadline. Note that its OK if you won't be able to get done in time - that comes with the territory. I'll add anything that doesn't make the deadline to the 2.7 plan, assuming the volunteers are still actively trying to work on it. FYI, I expect that the main focus of Zope 2.7 will be updating the supported platform to Python 2.2. My best guestimate at timing at this point is early-to-mid Q4. Thanks all! Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Speaking of 2.6...
...I sent out a note a while ago now trying to scare up some ideas on how to vet the current list of 2.6 proposals and get to a final plan. I didn't get much (any?) response :( I am, as the author of the dtml-set tag, of course willing to commit to the implementation of this tag for 2.6 How about 'vetted' - It's set to N, when will I know if I should start coding? Ivo - I don't have a problem with the spelling of this. I _do_ have a problem with the fact that it (your existing release) actually stores the variable in REQUEST. If it were to store them somewhere more appropriate in the DTML namespace stack, I'd be happy to OK it. We'd also need someone to commit to providing the extra docs for the help system and the dtml reference section of the online Zope book. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] REMINDER: Bug day tomorrow...
Hi all - Just a quick reminder that our inaugural Bug Day is tomorrow Friday, April 12 9:00 am EST until... until we've all had enough. We'll be coordinating on the #zope-dev channel on irc.zope.org. Some more info and general guidelines for bugdays are at: http://dev.zope.org/CVS/BugDays Hope to see you there! Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-Coders] Re: [Zope-dev] Speaking of 2.6...
The idea is to allow user to specify several points of presence (pop) for an object. Does this break security? Probably yes, but in what case? If an object from higly secure envionment appeared somewhere in Anonymous zone, what then? Yes, Anonymous is able to alter object. But there was reason for that! Maybe - but maybe you just made the link without realizing the effect on security. That is one of the biggest conceptual problems here. Security behavior has to be as simple and understandable as possible for it to be useful. If people don't feel like they understand it, they will always have a nagging fear that they are vulnerable - and they will probably be right. One could argue that we are already pushing the boundaries with the current security implementation, which is why the bar is so high for adding things to the core that potentially make things more complex yet. Comparing it to Unix hard links is fine, but Unix doesn't use Acquisition to handle security, so the comparison is not apples-to-apples :) We need to spell out the exact semantics (*especially* wrt security, but also in terms of its effect on ZODB identity semantics, effects on undo, etc.) Ok. I am not too well in English but I'll try to do my best. If it is not hard for you give several words of explanation of ZODB identity semantics and effects on undo, not everything is clear for me. Undo uses the place of an object as part of the criteria for deciding whether you can undo changes to it. If the meaning of place changes, undo behavior is likely to change. To use your earlier example, now Anonymous users might be able to undo changes made by a manager (in a different place on the same object). Is this acceptable? I don't know, but before we think about allowing changes like this into the core, the differences in behavior need to be spelled out in detail with specific examples. Likewise with ZODB. What effects would links have on cache behavior (which are based on persistent identity)? On packing behavior? Why we are not willing to allow such scenario? AFAIK there was and are a lot of concernes refarding soft- and hardlinks in /tmp folder, with sticky bit, etc... But they are usually solved with different means. Yes, Zope and ZODB is much more complex. But why we have to limit ourselves because something is difficult. I'm not trying to say that we shouldn't do something because it is difficult - just that in order to make changes like this we need to elaborate and understand all of the details and have a workable answer for all of the problems. Why not mark the feature as experimental (red button, a lot of warnings, for instance) and make it available to SuperManager only ;) Because that's the textbook case for making it a Product :) We shouldn't be putting things in the core that come with flashing red warnings and can only be used by superusers. What is wrong with leaving this as an add-on product? Why does it _need_ to be a part of the core at all? Useful products are useful, whether or not they come with Zope, and there are plenty of very useful products that don't come built in. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] [RFClet]: What about the request method and the client side trojan?
should not accept REQUESTs with REQUEST_METHOD GET. This is hard, hard, problem. While some good ideas have been proposed, there is not really a quick fix that doesn't have some downside that some group somewhere considers a showstopper :( I agree Olivers suggestion is not a total solution, but does it have a showstopper problem? Only if you happen to have an application deployed and might ever want to upgrade your Zope installation without having to do a total code audit :^) Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] RedstrictedCreation proposal
IMO, this comes at this at the wrong direction. Objects should not decide whether they can be added to a given folder, the folder should be the one that makes that decision. It gives me the heebie geebies to think that every time the add list is rendered, a whole slew of class methods are potentially called to determine what gets put there. I think (correct me though, if I'm wrong!) that Toby actually implemented the suggestion that Jim made on the comments page of the proposal (add a filter to the meta type info, allowing products to do this without killing performance). We need to find a reasonable place to document the API addition for this before merging it. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] [RFClet]: What about the request method and the client side trojan?
The issue of client side trojan recently came to my mind again. Looking at http://www.zope.org//Members/jim/ZopeSecurity/ClientSideTrojan I found nothing new since Oct. 2001, so I thought I bring up the issue again, maybe it's something which could be taken care of for zope = 2.6. I wrote something about that at the wiki, but let me repeat my proposal. I think zope's management methods (the potentially destructive ones) should not accept REQUESTs with REQUEST_METHOD GET. This is in accordance with the http/1.1 rfc (reposted from the wiki): snip RFC citation... The win would be that disabling javascipt would make a client save from this form of attack, AFAIK, OTOH I can't think of anything which would break ATM. While I don't necessarily disagree about making GETs idempotent, this still doesn't make you safe, even with JS turned off. A quick example: images can be used as form submit buttons. If I can get you to visit a page and click on my innocent looking image... you're done :) This is hard, hard, problem. While some good ideas have been proposed, there is not really a quick fix that doesn't have some downside that some group somewhere considers a showstopper :( Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Speaking of 2.6...
...I sent out a note a while ago now trying to scare up some ideas on how to vet the current list of 2.6 proposals and get to a final plan. I didn't get much (any?) response :( For a couple of things that were ready to go and fairly non controversial (like Toby's unicode work), I put on the BDFL hat and said merge it!. But there are still a lot of things on the proposed features that are undone, and some that are controversial enough that we need to get to closure on them. I'll volunteer to convert the current proposed feature list into a draft plan, where the conversion boils down to adding some columns to the table: Proposal - name and link to the proposal Resources - who is working on it Committed - Y/N whether the volunteers have committed to have the implementation and docs done by the first week in June. I'll fill in what I know has been committed to, people can update this (or let me know and I'll do it), and anything that doesn't get a 'Y' in a reasonably short time will be put in the cooler. Vetted - Y / N whether the community and / or the relevant BDFLs have come to some agreement on whether it *should* be done. The list of items without a 'Y' will be our next order of business. Getting to closure on those either via the list, IRC, or whatever is the main block on the critical path. Status - Complete or incomplete I've taken a first stab at this. I've set the committed to 'Y' for those things that I know I've gotten commitments for. For those set to 'N', please let me know if you can commit to the date (or change it yourself in the wiki). The updated plan is at: http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures Once we get the commitments up to date, we can start wrangling with the vetting... Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] How about a Bug Day this Friday?
Hi all - A while back I posted a summary of the semi-regular bug days we'd like to start having: http://dev.zope.org/CVS/BugDays We are planning to have the inaugural bug day this Friday (April 12th) from around 9 a.m. US /Eastern until we've all had enough :^) If things go well, I'd like to see this become a regular thing (say the second Fri. each month). Whaddya think? Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] How about a Bug Day this Friday?
We are planning to have the inaugural bug day this Friday (April 12th) from around 9 a.m. US /Eastern until we've all had enough :^) Sounds good. Make it #zope-dev, as nothing ever happens there :-) Good idea - I've changed the BugDays description. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Re: [Zope] isecure XML-RPC handling.
I think most people missed the point here. I don't think Rossen is asking for help on running zope or getting xml-rpc to work with it. He's observed a security problem: he believes the fact that a traceback including path names is included in the error response is a security exposure. This has been discussed on zope-dev before, but the fact remains that the security community *does* treat exposure of filesystem path information as a security issue. Right. There is already code for Zope 2.6 and Zope 3 that addresses this. Shane's new traceback formatting makes the trace information far more readable in addition to removing filesystem path information. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Next steps on Zope 2.6 plan
One suggestion Casey had was to start to codify a set of rules that features have to abide by to be considered for inclusion. Hmm, these rules seem to have several thinly veiled references to my pet project. :-) I do firmly agree with the rules in spirit, but I think a little clarification/discussion is in order so it doesn't get cut without good reason. Of course. Note that my references were not (and were not intended to be, veiled or otherwise :) knocks on your proposal or any _particular_ proposal. My point was to say that one big change should be the limit for any given feature release. This can be a helpful guideline for the future: if as a developer you know that total security rewrite is already on the list for some feature release, then you can be pretty sure that you'll have a hard fight to get some other major change into the same release. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Next steps on Zope 2.6 plan
Hi all, As talked about last week, I've updated the proposed features document for Zope 2.6: http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures ...to cut out those proposals without volunteers. Now comes the hard part :^) There are quite a few proposals there. The current list is still a laundry list - it reflects every idea that someone had and volunteered for without any consideration of whether the proposals are good / bad / indifferent. Now we need to do a quality chop to turn the laundry list into an actual project plan consisting of only things that: 1 Have volunteers committed to producing the code AND associated documentation 2 Are generally agreed to be good ideas, for some definition of generally and good :) 3 Can realistically be completed (code and docs) by the May 1 target we are setting for 2.6 alpha 1. Getting from laundry list to project plan is made a bit harder this time around because this is the first really community-driven release, and we don't have any real process in place for getting there :( I think that we have #1 above under control, and #3 does not bother me that much, but #2 is a tough cookie. Right now, the laundry list includes some competing proposals (things that solve the same or similar problems in different ways), as well as some better XXX proposals that compete with things already in the core and some pretty big overhaul XXX proposals with wide ranging non-trivial impacts on documentation, packaging and other non-software concerns. Somehow we need to get to resolution on these things. I know that realistically we'll be winging it for 2.6 (there's no way that we could get any sort of well-thought-out generally agreed upon process in place in time). But while we're winging it, I'd like for us to be starting to think about these things and putting pieces in place as we're able. One suggestion Casey had was to start to codify a set of rules that features have to abide by to be considered for inclusion. Some examples here would be: - A feature that is a better X than X (where X is a feature or component already in Zope), has a much higher bar to jump over since it will almost never be worth the user confusion and extra documenation burden to add another component that does almost (but not quite!) the same thing as an existing builtin component. For example, if you have a better Folder implementation, the right approach is to add your betterness to the current builtin Folder, because Zope is not going to ship with two kinds of Folder (with the associated two sets of docs, etc.) without a very, very good reason *. * Exhibit A for multiple similar objects causing confusion: DTML Document and DTML Method. - A feature release should never contain more than one blow-it- up-and-redo-it type project (such as radical changes to key parts of packaging or infrastructure). For example, it would probably be a bad idea to totally redo the ZODB, packaging and installation and the security system all in one release (unless it is a major release like Zope2 - Zope3). The aggregate impact in terms of obsoleting existing knowledge and documentation is too great to do many of these at once. It takes time for users and developers to catch up after something major is refactored, and we need to keep this in mind. - Features or components added to the Zope core should address a clear and generally agreed-upon need. Otherwise, accumulation of components over time will become a significant support burden for the zope maintainers. - Features that affect the security system face a higher analysis, design and documentation burden :^) I'm sure there are many other good guidelines, but you get the idea. Having a set of ground rules that everyone agrees on will make it easier to keep focused on arguing edge cases (instead of every detail) when it's time to define a release. Thoughts? I'll volunteer to maintain the guidelines document on dev.zope.org if folks can send their guideline suggestions. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Collector issue #30: Empty dates
http://collector.zope.org/Zope/30 What are people take on empty dates? snip This is a problem, because we need to be able to have empty dates. Also, enetering something magick (like None, or 1980/0/0 isn't usable. We fix this with this simple patch, which so far has caused us no problems: snip code allowing empty dates I was told that this had some type of compatibility issue. If thats the case, how do you suggest we fix it? This is something that comes up again and again - perhaps we should commit to doing something for Zope 2.6. There are many entries in the Collector with a patch similar to this, that works for me. The problem is that you are changing a semantic that currently deployed production applications depend on. I, for one, would be quite displeased if the documented behavior I was depending on in my app (raising an error if a valid date was not provided) suddenly changed, probably wreaking havoc on my data integrity. This is the reason why the change to converters to accept empty dates has never been accepted. I propose that we could add a new field type with a name like optional_date. The converter handler for that type could handle an empty field in whatever way we feel is reasonable, without breaking existing applications. (Let the fight over reasonable begin! :^) Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Collector issue #30: Empty dates
I propose that we could add a new field type with a name like optional_date. The converter handler for that type could handle an empty field in whatever way we feel is reasonable, without breaking existing applications. (Let the fight over reasonable begin! :^) That's fine by me. And reasonable would be '', since otherwise it really isn't optional. :-) OK, I could accept that None would work too, but '' *has* to work. You can't force end-users to enter magick cookies. I agree. I'd specify this by saying: o An empty string sent from a browser for an optional_date field is interpreted as a null (not specified) value o The internal representation of an optional_date (the value you find in the REQUEST after conversion) is always either a valid DateTime instance or None I'd also be interested on you take on issue #171, returning empty lists... I don't have much to add to that thread. It has the same backward-compatibility issue, but I don't perceive it to be as big an issue as the date thing (probably because it can be dealt with in a single line from DTML or Python). Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] RE: Object links/references
You told us that you will be refining Zope 2.6 plan. ProposedFeatures table contains an Implement links (object references) entry by Mario Valente. I've created SoftLink proposal in ProposalsWiki . These works appear related. We (Mario and me) discussed and decided that we can dedicate some efforts to make it working (Mario has working code already). The plan is to release Patch-like product for Zope 2.3, 2.4 and 2.5 to get feedback. And to incorporate functionality into Zope 2.6 without patching functionality. Please give us your recommendations / feedback / instructions for us, To be honest, I'm a little worried about the approach. Links can be very, very hard to get right (which is why they are not in the core now), especially with regard to security issues. Creating an object that impersonates another object is tough, because there a potentially unknown number of contracts that the impersonator must fulfill. This usually leads to problems :( For the SoftLink proposal in particular, the main problem you note in the proposal is that you want to avoid 404's when people go to a resource that has been moved. It seems to me that the best way to address that problem is to have a RedirectObject that you could add with the name of the object that was moved. It would _not_ try to impersonate the moved object, but when you went to view the object, you would be automatically redirected to the new location. That would avoid a lot of the problems of the link approach, with little overhead. Note that I'm not saying that object links are not a valid requirement, but it sounds like the problem you want to solve is definitely different than Mario's. In many ways, the correct required behavior of a link depends on what you expect to be able to do with it (the problem you are trying to solve). I can easily imagine that right behavior of a link if your main goal is to avoid 404s will _not_ be right if you are using the link in other ways. For example, if you went to a URL that had been moved, what is the right context that it should render itself in? I highly suspect that the right context is the place that it was moved to, rather than the context where the link lives (redirect semantics). That is basically the opposite of another possible usage of a link, where you would want to use the link to virtually include an object into a different context. I submit that trying to do both is too complex and probably too insecure as well (as managers of security would have to evaluate N possible security scenarios, most of which are not readily visible to them at the time they are setting up security). I think that the RedirectObject approach could sidestep all of these issues and provide an incremental step while still solving your problem. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Bug days
Hi all - In an effort to better keep up with the collector, I'd like to throw out the idea of doing periodic bug days (a la the mozilla bug days), where Zope geeks and committers would get together on IRC and spend a few hours knocking out issues. I've drafted a preliminary bug day manifesto that describes how it would work in a little more detail: http://dev.zope.org/CVS/BugDays I'd like to hear what people think, as well as work out a few logistics: - Given the wide geographic area that committers (and patch submitters) cover, what is a good time of day for a bug day to start / end (where start and end are always going to be fuzzy, of course). - Would it be better for bugdays to be ad-hoc, or should we try to set up regularly-scheduled bugdays at some reasonable interval? If the latter, we need to come up with a day / time that is agreeable to as many of the committers as possible. Thoughts? -Brian ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] where is Zope 2.5.1?
- Absolutely eliminate SQL db access as a cause (it sounds like we have proof of this now) This sounds like it is not specific to any DA. Is that the case? The only one I know of is the MySQL DA, but what I was getting at here was that eliminating ANY sql db access lets us discard the possibility of a DA problem and focus on other possibilities (IOW, is this really in Zope, or is this related to use or misuse of database libraries, which can vary widely in their thread support (or lack thereof). Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Moving forward on Zope 2.6
Hi all - 1) If the projects for which I have volunteered are accepted as a goal for Zope 2.6 then I have some work cut out for me, and I'd like to try to schedule the necessary time intelligently and early. Any ideas on when the grocery list will be evaluated? I think that this needs to happen Real Soon. I propose that this friday (the 15th) is the deadline for adding/volunteering for the 2.6 plan. After Friday, we need to cull the list to something managable (there is quite a lot there now). I further propose that any item on the list that does not have a sponsor (someone who has explicitly signed up to see the feature through, incl. associated tests, documentation, API help etc.) by Friday gets dropped from the plan. The working timeline for Zope 2.6 is to have an alpha out in about 6 weeks (beginning of May). Things whose sponsors don't think they can make that timeline should probably come off of the 2.6 plan (though they certainly can continue the projects, they would just go into a later release). So let's see what the list looks like after Friday when we know what is unchampioned or will not fit in the timeframe. Early next week, we should plan to debate the remaining items and finalize the list. It would be great if those who have volunteered to lead 2.6 projects could contact me with a rough est. of how long you think it will take and what collateral tasks there will be (any updating of existing documentation, new docs / API help and unit tests). I'll volunteer to update the plan in a little more detail. 2) If we had a brief Zope 2.6 style guide, similar to the Zope 3 stuff, that would be cool. In particular I'd like to be able to see state of the art 2.x ZC unit test approaches. Just point to a canonical example in Zope 2.5 or CMF, maybe? I think any of the /tests directories in the Zope core are decent examples. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] More Zope 2.6 requests
Folks - if you have proposals (*and are volunteering to do and/or document them), please put them in the project wiki: http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures ...otherwise they will get lost in the rushing current of the mailing list and you'll be sad. :) Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com While we are asking, I have two things that I would consider valuable additions to Zope 2.6: 1. UserSniffer. Currently an External Method, but has functionality that should be available OOTB to assist making those (horrors!) browser-dependent hacks. It has other uses, too, like explaining to clients that their browser is five years old and needs the free upgrade that is available. 2. Support for HTTP_X_FORWARDED_FOR. Many (most?) of us run zope behind Apache ProxyPass or Squid, and the Zope logs therefore save the ip address of the proxying machine rather than any semblance of where the client browser is. I realize that other proxies do not always follow the rules, etc., etc., but I think that using HTTP_X_FORWARDED_FOR if not null would be better than a log full of 192.168.1.1. Apologies if these have already been discussed under another heading. -- Jim Washington +1 on #2 - definitely useful. Sean ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Join the Zope team
Hi all, Zope Corp. is looking to add a Project Manager / Technical Lead to our team. You can find a full description of the position here: http://www.zope.com/Corporate/CareerOpportunities/ The position is roughly 50 / 50 engineering and project management. In addition to planning and executing customer engagements, you will be working with team members and management to develop and deliver high quality solutions. The ideal candidate will have: - Deep technical knowledge of Zope / CMF and Python, and experience building high-quality production systems with these tools - Experience managing software projects for internal and external customers - Strong planning, requirements anaysis and documentation skills - Experience managing the full lifecycle of a software project from inception to delivery and support If you are interested in working with us, please send your resume and salary requirements in .pdf format to [EMAIL PROTECTED] Brian Lloyd[EMAIL PROTECTED] Software Engineer 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Zope 2.6 project updated
Well, lets fix one of those things. :-) The Enhanced virtual hosting part of the Enhanced virtual hosting / local roles blacklist entry is really the same as the Virtual Host Folder further down, so that has a volunteer. And we at torped (That is me and Johan Carlsson) could do the Local roles blacklist part. We are not contributors yes, but Paul E suggested that we'd become that to fix some bugs that we want fixed in 2.5.1, and then we could do this also. Great - I've update the proposed feature list. Brian Lloyd[EMAIL PROTECTED] Software Engineer 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope 2.6 project updated
Hi all - I'm glad to see a thriving thread on 2.6 features :) To try to keep things manageable, I've created a project in the fishbowl at: http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ ...to start getting the effort organized. In particular, I spent some time today going through the call for contributors thread and harvesting the various proposals: http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures I tried to capture who volunteered for what, but please look this over and let me know if I have you volunteered for something that you didn't mean to volunteer for :) You can also fix it yourself if you like (its a wiki). The next step will be to whittle down the proposals, so if anyone wants to add to the list (or volunteer themselves for something on it), now is the time. At this point there are as many items without volunteers as with, so please don't add any more proposals to the list unless you are also volunteering :) Brian Lloyd[EMAIL PROTECTED] Software Engineer 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
