Re: [Zope-dev] Re: [patch] More secure cookie crumbler?
fwiw, Simon Eisenmann checked in a SessionStorage product into the collective which does much the same. released under the zpl http://cvs.sourceforge.net/viewcvs.py/collective/SessionCrumbler/ -kapil ___ 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 + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?)
On Mon, 2004-04-12 at 18:03, [EMAIL PROTECTED] wrote: G'Day, Well, step one is done ... I now have Zope + Ape using Subversion as it's filesystem !! cool! This is step one because, as Shawn suggested (Thanks for the pointer, that's what I needed!), this simply means that Zope uses SVN purely as a filesystem. Because of subversion's nature, I want to look at 2 things beyond this that traditional filesystems don't support: - Use zope's username for SVN logging. using AccessControl.getSecurityManager().getUser().getId() and setting it up as a revision prop ( or directly when creating the repo transaction) should do it. - History/Undo support: View past revisions of an object, and revert to such a past revision. perhaps the code for this would be helpful, (remove image for code link) http://zope.org/Members/k_vertigo/Products/CMFSubversionBrowser/FileRevisions.png - Zope Version support: SVN is fully transactional and atomic, this should allow for support of Zope versions (I think ?) zope version support isn't really all that worthwhile, esp in a cmf context. in general zope's version support (or zodb more particularly) is a database level feature masquerading as an application one. since objects modified in a version are in essence locked from participating in other transactions, actions like modifying content in a version in a cmf site amounts to locking the catalog from changes outside of the version, which amounts to shutting down write activities to a cmf site. otoh, integration with zope's transaction manager would be a good thing, although its problematic to integrate between svn and zope txn models, more on that in a moment. In the longer term, there's great opportunity for: - Built-in conflict management and resolution: No more need for a SafetyBelt type approach. Right now I haven't looked at this at all. I plan to implement smart merging where possible (It might work already actually, I just need to test it). True conflicts (Where a merge can't be accomplished withouth user interaction) would raise some sort of conflict error. i don't know that conflict management is really useful in this context. svn like zope relies on optimistic concurrency control, and currently doesn't support dav locking (which zope does). ie, it will just throw an error if the content has been changed since the transaction began. the 'normal' concurrency control of svn is better but dependent on using the working copy (wc) layer, which is additional programming and storage overhead. so at the layer of the svn client this is already done and working and good, but integrating this functionality into zope is a bit harder without wc overhard. this also makes the transaction integration becomes harder because both zope and svn are using what amounts to optimistic concurrency control which makes it impossible afaics, to get real txn integration, ie in zope's two phase commit strategy, the last chance for a participant to safely abort is tpc_vote, but there is no real way of knowing if the svn txn will suceed or not until its tried. if it is tried at this stage and succeeds then there is the possibility of a latter txn participant failing the tpc_vote and the txn being aborted, and if waits till tpc_finish (last part of two phase commit) and the svn txn fails it can hose the composite txn integrity. once svn supports dav locks, doing txn integration via resource locking as part of tpc_vote (or earlier) would be possible, till then.. i dunno, i can't see a way around this for real txn integration. i'm also curious how you dealt with svn transactions as part of the ape integration work to date. - Editing Zope content objects through interaction with the svn repository. I can checkout the repository, edit some objects, and chek them back in, never interacting with Zope directly ... I've already tried this ! Works great for text based content types such as PageTemplates or DTML Documents and so on ... I even did it with a JPG, though because the properties hold width and height, you get some weird looking pictures :) The concept is valid though. There may someday be a way to leverage this functionality better with a purpose built client of some sort. to me this is one of the fundamental benefits of using svn, giving users the ability to use interfaces like tortoisesvn (win shell extensions) or mac finder extensions to interact directly with content. - Leveraging SVN's property management. Content in SVN has properties, much like Zope does. I haven't looked at it yet, but I've noticed .properties file appearing ... I'm guessing those are the Zope properties, which would be better handled by subversion's property mechanism. And properties are versioned too ! definitely! In the realm of the wishful thinking, there's even more: Right now, HEAD (Latest/youngest revision) is always used and worked with. The really powerful feature I want to eventually
Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?)
Hi all, I've read your discussion about version control, it seems a cool thing you guys making good progress. Btw, can I ask is the Ape using Subversion in Zope stable? how able CMF stuff? I wanna make/find a document management system which can provide some kinda version control in Plone. Thanks Arthur On Tue, 13 Apr 2004 04:06:26 -0400, Kapil Thangavelu wrote On Mon, 2004-04-12 at 18:03, [EMAIL PROTECTED] wrote: G'Day, Well, step one is done ... I now have Zope + Ape using Subversion as it's filesystem !! cool! This is step one because, as Shawn suggested (Thanks for the pointer, that's what I needed!), this simply means that Zope uses SVN purely as a filesystem. Because of subversion's nature, I want to look at 2 things beyond this that traditional filesystems don't support: - Use zope's username for SVN logging. using AccessControl.getSecurityManager().getUser().getId() and setting it up as a revision prop ( or directly when creating the repo transaction) should do it. - History/Undo support: View past revisions of an object, and revert to such a past revision. perhaps the code for this would be helpful, (remove image for code link) http://zope.org/Members/k_vertigo/Products/CMFSubversionBrowser/FileRevisions. png - Zope Version support: SVN is fully transactional and atomic, this should allow for support of Zope versions (I think ?) zope version support isn't really all that worthwhile, esp in a cmf context. in general zope's version support (or zodb more particularly) is a database level feature masquerading as an application one. since objects modified in a version are in essence locked from participating in other transactions, actions like modifying content in a version in a cmf site amounts to locking the catalog from changes outside of the version, which amounts to shutting down write activities to a cmf site. otoh, integration with zope's transaction manager would be a good thing, although its problematic to integrate between svn and zope txn models, more on that in a moment. In the longer term, there's great opportunity for: - Built-in conflict management and resolution: No more need for a SafetyBelt type approach. Right now I haven't looked at this at all. I plan to implement smart merging where possible (It might work already actually, I just need to test it). True conflicts (Where a merge can't be accomplished withouth user interaction) would raise some sort of conflict error. i don't know that conflict management is really useful in this context. svn like zope relies on optimistic concurrency control, and currently doesn't support dav locking (which zope does). ie, it will just throw an error if the content has been changed since the transaction began. the 'normal' concurrency control of svn is better but dependent on using the working copy (wc) layer, which is additional programming and storage overhead. so at the layer of the svn client this is already done and working and good, but integrating this functionality into zope is a bit harder without wc overhard. this also makes the transaction integration becomes harder because both zope and svn are using what amounts to optimistic concurrency control which makes it impossible afaics, to get real txn integration, ie in zope's two phase commit strategy, the last chance for a participant to safely abort is tpc_vote, but there is no real way of knowing if the svn txn will suceed or not until its tried. if it is tried at this stage and succeeds then there is the possibility of a latter txn participant failing the tpc_vote and the txn being aborted, and if waits till tpc_finish (last part of two phase commit) and the svn txn fails it can hose the composite txn integrity. once svn supports dav locks, doing txn integration via resource locking as part of tpc_vote (or earlier) would be possible, till then.. i dunno, i can't see a way around this for real txn integration. i'm also curious how you dealt with svn transactions as part of the ape integration work to date. - Editing Zope content objects through interaction with the svn repository. I can checkout the repository, edit some objects, and chek them back in, never interacting with Zope directly ... I've already tried this ! Works great for text based content types such as PageTemplates or DTML Documents and so on ... I even did it with a JPG, though because the properties hold width and height, you get some weird looking pictures :) The concept is valid though. There may someday be a way to leverage this functionality better with a purpose built client of some sort. to me this is one of the fundamental benefits of using svn, giving users the ability to use interfaces like tortoisesvn (win shell extensions) or mac finder extensions to interact directly with content. - Leveraging SVN's property
Re: [Zope-dev] Re: [patch] More secure cookie crumbler?
From: Shane Hathaway [EMAIL PROTECTED] Making cookie authentication secure is surprisingly difficult, and you've barely taken one step. I don't want CookieCrumbler to go in this direction at all. A much more fruitful endeavor would be to simply add digest authentication support to Zope's user folders. See the middle of this page for a fairly clear explanation: http://frontier.userland.com/stories/storyReader$2159 The problem with that is that as far as I know, it still doesn't offer a nice, clean, cross-browser way of logging out. Which means most people will still use cookie-authentication... ___ 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] PlacelessTranslationService syntax
What's the correct ZPT syntax for PlacelessTranslationService? I tried this: b i18n:translate= i18n:domain=ibc i18n:target=string:czGood morning/b This gets rendered into: bGood morning/b No translation, although I do have an entry for 'Good morning' in my .po file under an 'ibc' domain. Is my syntax wrong? -- Milos Prudek ___ 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 + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?)
On 12 Apr 2004 at 18:03, [EMAIL PROTECTED] wrote: Anyways, I'm just rambling by now ... Comments, thoughts and constructive criticism welcome ! This sounds wonderful! Regarding versions. Perhap you can have a control panel setting that selects the branch to publish by default. The ZMI could offer another mechanism that uses cookies to select the desired branch or version That is, a branch name or PREV, HEAD etc. But, I use jEdit and FTP for most of my Zope work, so would really like to have a way to access version/branches via FTP. Maybe that can be done by having pseudo subdirectories named after revisions or branches. So /myFolder/.Prev/index_html would do what you expect (note you can't save to old versions anyway ..) -- Brad Clements,[EMAIL PROTECTED] (315)268-1000 http://www.murkworks.com (315)268-9812 Fax http://www.wecanstopspam.org/ AOL-IM: BKClements ___ 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-CMF] Tests (Was: some small proposals)
I would like to see the following functionality when it comes to unit testing: 1. An easy consistent way to run ONE unit test, no matter if it's made for Zope, or CMF, and no matter it it's done with straight unittest or ZopeTestCase. 2. An easy and consistent way to run all unit test in a directory. No matter if its... and so on. 3. An easy way to run all unit tests in Products. No matter etc, etc... 4. An easy way to run all unit tests in both Products and lib/python. No matter blablabla... 5. This should be reasonably easy to do from both Windows and Unix. To me, it seems like testrunner should be able to do this, if it weren't for the CMF tests for some reason unknown to me breaking this pattern. I would like that fixed. I'm not 100% sure what the problems are and my feeble attempt of suggesting fixes earlier haven't been any good. I think it would be great if thsi could be dicsussed, and useful solutions suggested. ___ 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 and zope
Zope 2 has a package named Zope. Zope 3 has a package named zope. Starting with Zope 2.8, parts of Zope 3 will be included in Zope 2. As things stand, this will require having both Zope and zope packages. Python can handle this fine, however, it will require putting the packages in separate directories (for Windows). A typical Zope installation will probably add at least two directories to the Python path, for: - The Zope software - Instance (site) specific packages So adding two directories, rather than one for the Zope software isn't a big deal. Of course, having two packages with names differing only in case is a bit ugly. Do we want to consider renaming one or both of these packages to avoid the conflict? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope and zope
+1 It looks like in the Zope 2 trunk, there are only a very few places that rely on import Zope or from Zope import. It looks like it would be possible to change the name of the Zope package in Zope 2 to zope2 or something without a tremendous amount of work. And as long as a module alias was created to alias that to Zope, 3rd party products would continue to work. This strategy would only work if we didn't plan on supporting systems where PYTHONCASEOK (see python -h) was set to be case-ignoring (are there any?). One potentially nasty problem is that the Zope 2 bootstrap code lives inside the Zope package within Zope.Setup, and some 3rd-party utilities (like the Plone Controller and many 3rd party tests that don't use the testrunner/test.py framework) rely on being able to import Zope. Renaming the package pushes the responsibility for knowing about the name change out to those utilities (because there's really just nowhere to insert a module alias shim before they attempt to import Zope). Considering the pain that I know would be involved with doing a zope - zope3 rename, however, this might be an acceptable breakage (except of course to those whose code it breaks, so they should speak up). - C On Tue, 2004-04-13 at 10:40, Jim Fulton wrote: Zope 2 has a package named Zope. Zope 3 has a package named zope. Starting with Zope 2.8, parts of Zope 3 will be included in Zope 2. As things stand, this will require having both Zope and zope packages. Python can handle this fine, however, it will require putting the packages in separate directories (for Windows). A typical Zope installation will probably add at least two directories to the Python path, for: - The Zope software - Instance (site) specific packages So adding two directories, rather than one for the Zope software isn't a big deal. Of course, having two packages with names differing only in case is a bit ugly. Do we want to consider renaming one or both of these packages to avoid the conflict? Jim ___ 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: start_new_thread / user issue
On Tue, 13 Apr 2004, Tres Seaver wrote: Given that you trust yourself ;), you can add a security context from within the second thread; you could pass the user ID to the thread via one of several forms of currying, e.g. via instance variables:: I'm not sure if I trust myself in real life, but in this case I do. :) Your code below did not work for me because I could not find the newSecurityContext method. However, I was able to use the SecurityManagement.newSecurityManager instead, and that worked great. Thanks for pointing me in the right direction. class TrustedSecurityTask: def __init__(self, user_id): self._user_id = user_id def __call__(self, *args, **kw): sm = getSecurityManager() sm.newSecurityContext(None, User(self._user_id)) # your code here . thread = Thread(TrustedSecurityTask(user_id)) thread.start() Tres. Take care, --Toby. --- Toby Gustafson Senior Software Engineer Tyrell Software Corporation Email: [EMAIL PROTECTED] --- ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Developers
Hello, I was wondering if someone on this list could point me in the direction of an appropriate place to post Zope job openings. I am looking for an audience well-versed in Zope. Thanks for any guidance! -Paul Brinich ___ 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 Developers
On Tuesday 13 April 2004 01:44 pm, Paul Edward Brinich wrote: I was wondering if someone on this list could point me in the direction of an appropriate place to post Zope job openings. I am looking for an audience well-versed in Zope. Thanks for any guidance! There's the Python Job Board: http://www.python.org/Jobs.html -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] zLOG is dead
zLOG is dead The zLOG package used for logging throughout ZODB, ZEO, and Zope 2 has been declared obsolete. All logging for Zope products will use the logging package from Python's standard library. The zLOG package still exists in Zope 2 and the separate package for ZODB, but it is now an API shim (or façade) over the logging package. It is expected to wither away to nothing at some point. Why should you care? This means that the environment variables EVENT_LOG_FILE, EVENT_LOG_SEVERITY, STUPID_LOG_FILE, STUPID_LOG_SEVERITY, and ZSYSLOG are no longer honored for Zope 2.8, ZODB, or ZEO. Zope 2 reads logging configuring from the zope.conf configuration file, and the test.py script for developers reads a log.ini file using the obnoxious configuration syntax provided by the logging package itself. If you use the ZODB distribution but not the rest of Zope, you probably want to start changing any of your code that uses zLOG to use the logging package. ZODB and ZEO will be changed to use the logging package directly as well to avoid dependence on the API shim. How can you help? - If you have some time to contribute to Zope development, the removal of zLOG calls from the ZODB and ZEO packages would be a welcome contribution. I've converted Signals/Signals.py and Zope/Startup/__init__.py, and some modules of ZODB and ZEO already use the logging package directly; these can serve as examples. -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] Re: PlacelessTranslationService syntax
Milos Prudek wrote: What's the correct ZPT syntax for PlacelessTranslationService? PTS is just a translation service for ZPT. It doesn't add any functionality to ZPT. I tried this: b i18n:translate= i18n:domain=ibc i18n:target=string:czGood morning/b This gets rendered into: bGood morning/b No translation, although I do have an entry for 'Good morning' in my .po file under an 'ibc' domain. Is my syntax wrong? Maybe. Get i18ndude (google) and search for i18n docs for ZPT (google, too) :) Christian ___ 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 + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
Hello, Hmmm, well it's as stable as Ape and Subversion are respectively :) I wouldn't call it stable no, it's something I did over the long week-end we just had, and that's about it :) Ape is at 0.8 and therefore becoming quite mature, I'd have to let others speak as to it stability however ... Subversion is also probably quite stable (It just reached 1.0), though I don't know how heavily tested it's been in a long running process (Might it have some memeory leaks ?) ... Basically, I wouldn't recommend for usage yet. I'm not even distributing it just yet, mostly simply because right now it's code is still intermingled with Ape's ... As soon as I pull it out into a seperate product I'll be sure ot post it on zope.org and notify the list, as I'm sure I'll be looking for feedback/testers. I would estimate that moment to be weeks away though ... Thanks, J.F. -Original Message- From: Arthur Chan Chi Chuen To: Kapil Thangavelu; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: 13/04/2004 2:13 PM Subject: Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?) Hi all, I've read your discussion about version control, it seems a cool thing you guys making good progress. Btw, can I ask is the Ape using Subversion in Zope stable? how able CMF stuff? I wanna make/find a document management system which can provide some kinda version control in Plone. Thanks Arthur On Tue, 13 Apr 2004 04:06:26 -0400, Kapil Thangavelu wrote On Mon, 2004-04-12 at 18:03, [EMAIL PROTECTED] wrote: G'Day, Well, step one is done ... I now have Zope + Ape using Subversion as it's filesystem !! cool! This is step one because, as Shawn suggested (Thanks for the pointer, that's what I needed!), this simply means that Zope uses SVN purely as a filesystem. Because of subversion's nature, I want to look at 2 things beyond this that traditional filesystems don't support: - Use zope's username for SVN logging. using AccessControl.getSecurityManager().getUser().getId() and setting it up as a revision prop ( or directly when creating the repo transaction) should do it. - History/Undo support: View past revisions of an object, and revert to such a past revision. perhaps the code for this would be helpful, (remove image for code link) http://zope.org/Members/k_vertigo/Products/CMFSubversionBrowser/FileRevi sions. png - Zope Version support: SVN is fully transactional and atomic, this should allow for support of Zope versions (I think ?) zope version support isn't really all that worthwhile, esp in a cmf context. in general zope's version support (or zodb more particularly) is a database level feature masquerading as an application one. since objects modified in a version are in essence locked from participating in other transactions, actions like modifying content in a version in a cmf site amounts to locking the catalog from changes outside of the version, which amounts to shutting down write activities to a cmf site. otoh, integration with zope's transaction manager would be a good thing, although its problematic to integrate between svn and zope txn models, more on that in a moment. In the longer term, there's great opportunity for: - Built-in conflict management and resolution: No more need for a SafetyBelt type approach. Right now I haven't looked at this at all. I plan to implement smart merging where possible (It might work already actually, I just need to test it). True conflicts (Where a merge can't be accomplished withouth user interaction) would raise some sort of conflict error. i don't know that conflict management is really useful in this context. svn like zope relies on optimistic concurrency control, and currently doesn't support dav locking (which zope does). ie, it will just throw an error if the content has been changed since the transaction began. the 'normal' concurrency control of svn is better but dependent on using the working copy (wc) layer, which is additional programming and storage overhead. so at the layer of the svn client this is already done and working and good, but integrating this functionality into zope is a bit harder without wc overhard. this also makes the transaction integration becomes harder because both zope and svn are using what amounts to optimistic concurrency control which makes it impossible afaics, to get real txn integration, ie in zope's two phase commit strategy, the last chance for a participant to safely abort is tpc_vote, but there is no real way of knowing if the svn txn will suceed or not until its tried. if it is tried at this stage and succeeds then there is the possibility of a latter txn participant failing the tpc_vote and the txn being aborted, and if waits till tpc_finish (last part of two phase commit) and the svn txn fails it can hose the
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
Brad, About the branch thing ... That's basically the idea! The bigger problem here is how to manage this both internally and from a user/administrator perspective. This paradigm only really makes sense in the CMF world anyways, and I want to focus on basic Zope before moving up to the extra layer CMF represents. I'm also worried getting something like this to work with CMF woudl require an ungodly amount of monkey patching :P The main things with CMF would be: 1) published type states vs. other states: how does one tell/define the difference ? How does this information get passed to/from the publishing system or the storage layer ? Possible solution: Have the subversion/zope interface interact with DCWorkflow. When an object is changed, consult DCWorkflow settings and determine what state the object is in. If the state is deemed published, copy the object into the publishing branch. 2) If we got this far, then I need to know when to use the branch vs. the trunk. From a user prespective this isn't too big a deal, a ZMI interface, cookies, etc ... That's all ok ... The problem is that by the time the request comes to the storage side of things, that information is most likely gone (Don't know though, I'm still learning). Then there's the whole caching thing that would probably complicate things. 2) Message logging: CMF comments when doing a workflow action could go straight into SVN's logging, again how this might be accomplished isn't clear as of yet. This is all for the future though, I'm nowhere near this yet!! Also, I'm thinking the cooler features may just have to wait for Zope 3 ... Implementing them in Zope might be too convoluted. I should probably start a Wiki on this topic ! J.F. -Original Message- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 13/04/2004 8:40 AM Subject: Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?) On 12 Apr 2004 at 18:03, [EMAIL PROTECTED] wrote: Anyways, I'm just rambling by now ... Comments, thoughts and constructive criticism welcome ! This sounds wonderful! Regarding versions. Perhap you can have a control panel setting that selects the branch to publish by default. The ZMI could offer another mechanism that uses cookies to select the desired branch or version That is, a branch name or PREV, HEAD etc. But, I use jEdit and FTP for most of my Zope work, so would really like to have a way to access version/branches via FTP. Maybe that can be done by having pseudo subdirectories named after revisions or branches. So /myFolder/.Prev/index_html would do what you expect (note you can't save to old versions anyway ..) -- Brad Clements,[EMAIL PROTECTED] (315)268-1000 http://www.murkworks.com (315)268-9812 Fax http://www.wecanstopspam.org/ AOL-IM: BKClements ___ 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 + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
Shane, Thanks for the extra tips, I'll check out those interfaces! I'm also getting up to speed on the whole mapper concept, where the work regarding properties handling seems to be ? I've done some reading, and I need to do some more, but I'll get there :) As for the seperation of code ... I now have a subversion directory as a sibbling to fs ... I had to edit a couple of files outside that directory, but still the seperation is nicer. eventually I'd have to make it into a product, is that doable ? J.F. -Original Message- From: Shane Hathaway To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: 13/04/2004 11:43 AM Subject: Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?) On Mon, 12 Apr 2004 [EMAIL PROTECTED] wrote: This is step one because, as Shawn suggested (Thanks for the pointer, that's what I needed!), this simply means that Zope uses SVN purely as a filesystem. Because of subversion's nature, I want to look at 2 things beyond this that traditional filesystems don't support: To take this to the next level, you need to implement IFSReader and IFSWriter instead of the more basic file operations interface. See Ape/lib/apelib/fs/interfaces.py. In IFSReader/IFSWriter, you're a little closer to objects, and you work with OIDs instead of paths. I expect that history and version support will require us to augment IFSReader or add another interface. - Use zope's username for SVN logging. - History/Undo support: View past revisions of an object, and revert to such a past revision. - Zope Version support: SVN is fully transactional and atomic, this should allow for support of Zope versions (I think ?) These seem doable. In the longer term, there's great opportunity for: - Built-in conflict management and resolution: No more need for a SafetyBelt type approach. Right now I haven't looked at this at all. I plan to implement smart merging where possible (It might work already actually, I just need to test it). True conflicts (Where a merge can't be accomplished withouth user interaction) would raise some sort of conflict error. This could be complicated, because after the merge you have to be sure Zope caches the merged state rather than either of the intermediate states. The idea has potential, though! - Editing Zope content objects through interaction with the svn repository. I can checkout the repository, edit some objects, and chek them back in, never interacting with Zope directly ... I've already tried this ! Works great for text based content types such as PageTemplates or DTML Documents and so on ... I even did it with a JPG, though because the properties hold width and height, you get some weird looking pictures :) The concept is valid though. There may someday be a way to leverage this functionality better with a purpose built client of some sort. Sounds neat. Fortunately, Ape doesn't have to be aware of this. :-) - Leveraging SVN's property management. Content in SVN has properties, much like Zope does. I haven't looked at it yet, but I've noticed .properties file appearing ... I'm guessing those are the Zope properties, which would be better handled by subversion's property mechanism. And properties are versioned too ! I think you'll find this easy to do once you implement IFSReader/IFSWriter. In the realm of the wishful thinking, there's even more: Right now, HEAD (Latest/youngest revision) is always used and worked with. The really powerful feature I want to eventually get to is publsihing something of a given revision, while editing another. One potential paradigm for distiguishing between the two modes of operation could be to use anonymous vs. authenticated. This is not useful to everyone, but can be in certain circumstances, most notably where authenticated = authors/developpers and anonymous = normal users. This however requires ZMI interfaces, and in my case CMF ones as well ... This would be global though ... Eventually it'd be nice to have per object control of this stuff. Andy McKay says it can't be done, anybody care to contradict him ? :P I image I'd have to monkey pathc something DEEP in the Zope code base, but I find the mix-in class that's the commonn denominator ... why not ? Well, CMFStaging is designed to address this need. To do this at the database level, you could use versions. Right now I've been working within the fs module of apelib. I'm going to split it off into a seperate one so that it's a clean merge with Ape's code base, in case someone wants to try it, or it eventually makes into Ape's default distribution ?? ;) You can add a new module, perhaps 'svnops.py', to the 'fs' package. Then we should make the choice between fileops and svnops configurable. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML
RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
Hi J.F, Thanks for your comments first. I understand more about the process of SVN in zope now. I am very eager to have/make a document management system with good version ctrl in Plone. Some products like Silva has versions but it's just not exactly what we need. Wish you have a good progress, and let me know if I can help you in the dev. or testing pharse. Arthur On Tue, 13 Apr 2004 20:53:30 -0400, Jean-Francois.Doyon wrote Hello, Hmmm, well it's as stable as Ape and Subversion are respectively :) I wouldn't call it stable no, it's something I did over the long week-end we just had, and that's about it :) Ape is at 0.8 and therefore becoming quite mature, I'd have to let others speak as to it stability however ... Subversion is also probably quite stable (It just reached 1.0), though I don't know how heavily tested it's been in a long running process (Might it have some memeory leaks ?) ... Basically, I wouldn't recommend for usage yet. I'm not even distributing it just yet, mostly simply because right now it's code is still intermingled with Ape's ... As soon as I pull it out into a seperate product I'll be sure ot post it on zope.org and notify the list, as I'm sure I'll be looking for feedback/testers. I would estimate that moment to be weeks away though ... Thanks, J.F. -Original Message- From: Arthur Chan Chi Chuen To: Kapil Thangavelu; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: 13/04/2004 2:13 PM Subject: Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?) Hi all, I've read your discussion about version control, it seems a cool thing you guys making good progress. Btw, can I ask is the Ape using Subversion in Zope stable? how able CMF stuff? I wanna make/find a document management system which can provide some kinda version control in Plone. Thanks Arthur On Tue, 13 Apr 2004 04:06:26 -0400, Kapil Thangavelu wrote On Mon, 2004-04-12 at 18:03, [EMAIL PROTECTED] wrote: G'Day, Well, step one is done ... I now have Zope + Ape using Subversion as it's filesystem !! cool! This is step one because, as Shawn suggested (Thanks for the pointer, that's what I needed!), this simply means that Zope uses SVN purely as a filesystem. Because of subversion's nature, I want to look at 2 things beyond this that traditional filesystems don't support: - Use zope's username for SVN logging. using AccessControl.getSecurityManager().getUser().getId() and setting it up as a revision prop ( or directly when creating the repo transaction) should do it. - History/Undo support: View past revisions of an object, and revert to such a past revision. perhaps the code for this would be helpful, (remove image for code link) http://zope.org/Members/k_vertigo/Products/CMFSubversionBrowser/FileRevi sions. png - Zope Version support: SVN is fully transactional and atomic, this should allow for support of Zope versions (I think ?) zope version support isn't really all that worthwhile, esp in a cmf context. in general zope's version support (or zodb more particularly) is a database level feature masquerading as an application one. since objects modified in a version are in essence locked from participating in other transactions, actions like modifying content in a version in a cmf site amounts to locking the catalog from changes outside of the version, which amounts to shutting down write activities to a cmf site. otoh, integration with zope's transaction manager would be a good thing, although its problematic to integrate between svn and zope txn models, more on that in a moment. In the longer term, there's great opportunity for: - Built-in conflict management and resolution: No more need for a SafetyBelt type approach. Right now I haven't looked at this at all. I plan to implement smart merging where possible (It might work already actually, I just need to test it). True conflicts (Where a merge can't be accomplished withouth user interaction) would raise some sort of conflict error. i don't know that conflict management is really useful in this context. svn like zope relies on optimistic concurrency control, and currently doesn't support dav locking (which zope does). ie, it will just throw an error if the content has been changed since the transaction began. the 'normal' concurrency control of svn is better but dependent on using the working copy (wc) layer, which is additional programming and storage overhead. so at the layer of the svn client this is already done and working and good, but integrating this functionality into zope is a bit harder without wc overhard. this also makes the transaction integration becomes harder because both zope and svn
Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
[EMAIL PROTECTED] wrote: Brad, About the branch thing ... That's basically the idea! The bigger problem here is how to manage this both internally and from a user/administrator perspective. This paradigm only really makes sense in the CMF world anyways, and I want to focus on basic Zope before moving up to the extra layer CMF represents. I'm also worried getting something like this to work with CMF woudl require an ungodly amount of monkey patching :P The main things with CMF would be: 1) published type states vs. other states: how does one tell/define the difference ? How does this information get passed to/from the publishing system or the storage layer ? Possible solution: Have the subversion/zope interface interact with DCWorkflow. When an object is changed, consult DCWorkflow settings and determine what state the object is in. If the state is deemed published, copy the object into the publishing branch. 2) If we got this far, then I need to know when to use the branch vs. the trunk. From a user prespective this isn't too big a deal, a ZMI interface, cookies, etc ... That's all ok ... The problem is that by the time the request comes to the storage side of things, that information is most likely gone (Don't know though, I'm still learning). Then there's the whole caching thing that would probably complicate things. 2) Message logging: CMF comments when doing a workflow action could go straight into SVN's logging, again how this might be accomplished isn't clear as of yet. This is all for the future though, I'm nowhere near this yet!! Also, I'm thinking the cooler features may just have to wait for Zope 3 ... Implementing them in Zope might be too convoluted. I should probably start a Wiki on this topic ! J.F. -Original Message- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 13/04/2004 8:40 AM Subject: Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?) On 12 Apr 2004 at 18:03, [EMAIL PROTECTED] wrote: Anyways, I'm just rambling by now ... Comments, thoughts and constructive criticism welcome ! This sounds wonderful! Regarding versions. Perhap you can have a control panel setting that selects the branch to publish by default. The ZMI could offer another mechanism that uses cookies to select the desired branch or version That is, a branch name or PREV, HEAD etc. But, I use jEdit and FTP for most of my Zope work, so would really like to have a way to access version/branches via FTP. Maybe that can be done by having pseudo subdirectories named after revisions or branches. So /myFolder/.Prev/index_html would do what you expect (note you can't save to old versions anyway ..) François, we did a versioning Product here at redCOR which is about to go into production. It is served trough DCWorkflow state changes. It stores a series of objects per versioned object. One for each version. No diff's or such. I would be very much interested to adapt it such that it uses an APE/svn augmented storage for it. Robert ___ 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: start_new_thread / user issue
Toby Gustafson wrote: Your code below did not work for me because I could not find the newSecurityContext method. However, I was able to use the SecurityManagement.newSecurityManager instead, and that worked great. Thanks for pointing me in the right direction. Great! Sorry for leaving off the untested.../untested brackets, and for typing code from memory after an all-day planes, trains, and automobiles trip. Tres. -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers 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 and zope
Chris McDonough wrote: +1 It looks like in the Zope 2 trunk, there are only a very few places that rely on import Zope or from Zope import. It looks like it would be possible to change the name of the Zope package in Zope 2 to zope2 or something without a tremendous amount of work. And as long as a module alias was created to alias that to Zope, 3rd party products would continue to work. This strategy would only work if we didn't plan on supporting systems where PYTHONCASEOK (see python -h) was set to be case-ignoring (are there any?). One potentially nasty problem is that the Zope 2 bootstrap code lives inside the Zope package within Zope.Setup, and some 3rd-party utilities (like the Plone Controller and many 3rd party tests that don't use the testrunner/test.py framework) rely on being able to import Zope. Renaming the package pushes the responsibility for knowing about the name change out to those utilities (because there's really just nowhere to insert a module alias shim before they attempt to import Zope). Considering the pain that I know would be involved with doing a zope - zope3 rename, however, this might be an acceptable breakage (except of course to those whose code it breaks, so they should speak up). On Tue, 2004-04-13 at 10:40, Jim Fulton wrote: snip Of course, having two packages with names differing only in case is a bit ugly. Do we want to consider renaming one or both of these packages to avoid the conflict? -1 to renaming 'Zope'; the amount of third-party code which we would break is incalculable. -0 to renaming 'zope' to 'z3', or something; at least third party code for Zope3 was built in the test-driven culture, and has at least some chance of migrating cleanly with confidence. Tres. -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers 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: [Zope3-dev] Re: Zope and zope
On Tuesday 13 April 2004 22:17, Tres Seaver wrote: snip Of course, having two packages with names differing only in case is a bit ugly. Do we want to consider renaming one or both of these packages to avoid the conflict? -1 to renaming 'Zope'; the amount of third-party code which we would break is incalculable. -0 to renaming 'zope' to 'z3', or something; at least third party code for Zope3 was built in the test-driven culture, and has at least some chance of migrating cleanly with confidence. You wanna rename 'zope' to 'z3' for the purpose of merging the two? I really hope that will not be the case. Or is this for Zope 2 only? I would hate to have imports like z3.app.foo or even z3.i18n. I am definitely -1 on this option, if it also applies to standalone Zope 3. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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 + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
On Tue, 13 Apr 2004 [EMAIL PROTECTED] wrote: Thanks for the extra tips, I'll check out those interfaces! I'm also getting up to speed on the whole mapper concept, where the work regarding properties handling seems to be ? Ape supports both annotations and Zope properties. Annotations are blocks of multi-line text, while Zope properties are less constrained. On the filesystem, Ape stores many Zope properties together in a single annotation called properties. Other annotations include object classification, the remainder pickle (encoded in base 64), and security information. What are the expectations and limits of Subversion properties? If they are blocks of multi-line text, you can store the annotations as Subversion properties. If not, we'll still need a .properties file. (Note that the name .properties is thus confusing. Oops.) As for the seperation of code ... I now have a subversion directory as a sibbling to fs ... I had to edit a couple of files outside that directory, but still the seperation is nicer. eventually I'd have to make it into a product, is that doable ? Why not add your code to Ape? I think it would be easier for both of us to maintain that way. Shane ___ 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: [Zope3-dev] Re: Zope and zope
Stephan Richter wrote: On Tuesday 13 April 2004 22:17, Tres Seaver wrote: snip Of course, having two packages with names differing only in case is a bit ugly. Do we want to consider renaming one or both of these packages to avoid the conflict? -1 to renaming 'Zope'; the amount of third-party code which we would break is incalculable. -0 to renaming 'zope' to 'z3', or something; at least third party code for Zope3 was built in the test-driven culture, and has at least some chance of migrating cleanly with confidence. You wanna rename 'zope' to 'z3' for the purpose of merging the two? I really hope that will not be the case. Or is this for Zope 2 only? Note that I am -0 to the idea. I would hate to have imports like z3.app.foo or even z3.i18n. I am definitely -1 on this option, if it also applies to standalone Zope 3. I am just arguing that it would be saner to rename 'zope' to 'z3' (or 'zope3', or whatever) than to rename 'Zope' to 'zope2' (or whatever). Tres. -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers 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: [Zope3-dev] Re: Zope and zope
Jim Fulton noted: Of course, having two packages with names differing only in case is a bit ugly. Do we want to consider renaming one or both of these packages to avoid the conflict? A bit ugly, but I can live with it. On Tuesday 13 April 2004 22:17, Tres Seaver wrote: -1 to renaming 'Zope'; the amount of third-party code which we would break is incalculable. -0 to renaming 'zope' to 'z3', or something; at least third party code for Zope3 was built in the test-driven culture, and has at least some chance of migrating cleanly with confidence. On Tuesday 13 April 2004 10:44 pm, Stephan Richter wrote: You wanna rename 'zope' to 'z3' for the purpose of merging the two? I really hope that will not be the case. Or is this for Zope 2 only? I would hate to have imports like z3.app.foo or even z3.i18n. I am definitely -1 on this option, if it also applies to standalone Zope 3. Tres has a good objection, *if* we actually expect 3rd-party Zope 2 code to work in Zope 3. (I don't know if we have this requirement or not; I've no personal interest in doing so.) If we don't expect 3rd-party Zope 2 code to work in Zope 3, then the second entry on sys.path seems good enough; having a collection of code identified by two different names is unworkable. (Think absolute imports here.) Any requirement that states 3rd-party Zope 2 code work in Zope 3 will have to be worked out; that's the key here. -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 )
Re: [Zope-dev] Re: [Zope3-dev] Re: Zope and zope
Fred Drake wrote: Jim Fulton noted: Of course, having two packages with names differing only in case is a bit ugly. Do we want to consider renaming one or both of these packages to avoid the conflict? A bit ugly, but I can live with it. On Tuesday 13 April 2004 22:17, Tres Seaver wrote: -1 to renaming 'Zope'; the amount of third-party code which we would break is incalculable. -0 to renaming 'zope' to 'z3', or something; at least third party code for Zope3 was built in the test-driven culture, and has at least some chance of migrating cleanly with confidence. On Tuesday 13 April 2004 10:44 pm, Stephan Richter wrote: You wanna rename 'zope' to 'z3' for the purpose of merging the two? I really hope that will not be the case. Or is this for Zope 2 only? I would hate to have imports like z3.app.foo or even z3.i18n. I am definitely -1 on this option, if it also applies to standalone Zope 3. Tres has a good objection, *if* we actually expect 3rd-party Zope 2 code to work in Zope 3. (I don't know if we have this requirement or not; I've no personal interest in doing so.) If we don't expect 3rd-party Zope 2 code to work in Zope 3, then the second entry on sys.path seems good enough; having a collection of code identified by two different names is unworkable. (Think absolute imports here.) Any requirement that states 3rd-party Zope 2 code work in Zope 3 will have to be worked out; that's the key here. -Fred I have not done anything with z3 yet, tough we intend to start working with it soon. We have a number of products that are mostly plain python within a thin zope-shell. Since we probably would like to use them in z3 and must maintain them in z2 I would like to see a way to mix the two. Robert ___ 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] zLOG is dead
+1 What is the recommend way to migrate existing code? I assume using: import logging logger = logging.getLogger(loggername). When I look through the Zope HEAD code then you are using e.g. 'zodb.conn' or 'zodb.storage' but also 'Zope' as loggername. Do we have to agree on some common usage of the logger names? E.g. for logging calls in the reST packagebetter using 'Zope' or 'reST'? -aj --On Dienstag, 13. April 2004 15:53 Uhr -0400 Fred Drake [EMAIL PROTECTED] wrote: zLOG is dead The zLOG package used for logging throughout ZODB, ZEO, and Zope 2 has been declared obsolete. All logging for Zope products will use the logging package from Python's standard library. The zLOG package still exists in Zope 2 and the separate package for ZODB, but it is now an API shim (or façade) over the logging package. It is expected to wither away to nothing at some point. Why should you care? This means that the environment variables EVENT_LOG_FILE, EVENT_LOG_SEVERITY, STUPID_LOG_FILE, STUPID_LOG_SEVERITY, and ZSYSLOG are no longer honored for Zope 2.8, ZODB, or ZEO. Zope 2 reads logging configuring from the zope.conf configuration file, and the test.py script for developers reads a log.ini file using the obnoxious configuration syntax provided by the logging package itself. If you use the ZODB distribution but not the rest of Zope, you probably want to start changing any of your code that uses zLOG to use the logging package. ZODB and ZEO will be changed to use the logging package directly as well to avoid dependence on the API shim. How can you help? - If you have some time to contribute to Zope development, the removal of zLOG calls from the ZODB and ZEO packages would be a welcome contribution. I've converted Signals/Signals.py and Zope/Startup/__init__.py, and some modules of ZODB and ZEO already use the logging package directly; these can serve as examples. -Fred ___ 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 )
