[Zope3-dev] Re: adapter registration question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Chris Withers wrote: Christian Theune wrote: The problem you have is to provide a specification for the 'str' interface. There are a couple of problems here... 1. str is both a function and a class Nope. It's a class since Python 2.2. 2. I was to register the function str as an adapter for, say, the class int to the class str, so there's not factory for the adapter, since it's a function Let's create a marker interface that promises everything that 'str' does: class IString(zope.interface.Interface): A marker for the 'str' interface. As discussed elsewhere, you shouldn't need the marker interface, as you can adapt classes. Right, as an *input* of the adaption it's ok just to specify a class. But the output obviously always has to be specified by an interface. Otherwise the whole point of using of adaption is perverted... Like adapting to None? Using adaptation to look up value factories is not any weirder than using it to look up event subscribers whose return values are always discarded. Thnk of cataloguing / indexing use cases: adapting the catalogued object to a string value (or tuple, or whatever) using named adapters is a very natural way to make indexing pluggable: what is *unnatural* (or at least a dead chicken) is the requirement to adapt to an 'IString', when what I really want is a 'str'. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFWK2o+gerLs4ltQ4RAsNxAJ4uXSOSup8PyQd2lQPm1Fqr/C3fGgCgwmiG PgKweYkpKMpulOK46qtJFx0= =twN/ -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: adapter registration question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Tres Seaver wrote: snip Thnk of cataloguing / indexing use cases: adapting the catalogued object to a string value (or tuple, or whatever) using named adapters is a very natural way to make indexing pluggable: what is *unnatural* (or at least a dead chicken) is the requirement to adapt to an 'IString', when what I really want is a 'str'. Well, part of Python idea is duck typing and requiring that you get a 'str' may be too much. Perhaps you would really only like to get something that quacks like str. OTOH, perhaps you absolutely want a 'str' and that use case should perhaps be allowed... Heh, in this case using 'IString' is really a trussed duck (duck typing with BD) ;) Python's duck typing breaks down with strings, because they can by quack tested like sequences, but you almost *never* want to treat them the same way as other sequences, so you end up with 'isinstance(obj, basestr)' tests to prevent handling them that way. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFWLUf+gerLs4ltQ4RAt/1AKCUvR230iCgNOq7kUpqAcFrSQVp5wCfedXY WI/ty3z7ektpMS/9Mh+l/PI= =IM7g -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [OT] Python interpreter examples in Thunderbird
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shane Hathaway wrote: Martin Aspeli wrote: OT: Thunderbird makes a real mess of interpreter examples, thinking the '' is an indent and making it a coloured line. Anyone got an idea how I stop it from doing that? If you find out, PLEASE tell me too. :-) I use View | Message Source to deal with that. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFU59Q+gerLs4ltQ4RAmEpAJ94TXnMSJaoy5w2Az/1aAJI4EVA0wCgo0ox Wg64/Ety5yhDZp7GFnGquqg= =IcLf -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Checkins] SVN: zope.fssync/trunk/ Initial commit of zope.fssync for eggification.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: Baiju M wrote: On 10/29/06, Benji York [EMAIL PROTECTED] wrote: I'm really glad to see so much work being done on eggification, but am a little concerned as to the mechanics. I'm worried that if dozens of packages are separated out before they are actually knit into Zope proper, we'll get drift between the two. It would seem to make more sense to eggify one or a few packages and get them properly working in the core, and then go from there. zope.fssync and some other packages are not distributed with Zope 3. That doesn't answer my question, for two reasons. There are still duplicate copies of the code. I suspect we should be removing the code from the core tree as the packages are separated out (of course we have to have a story for people who use those packages from the trunk first). Leave an 'svn:external' behind to the new location, perhaps with a 'DEPRECATED.txt' file stating when the external would go away? Also, there are several packages that have been copied that /are/ included in the core. Again, 'svn:external' is the way to avoid the duplication. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFRipk+gerLs4ltQ4RAig6AKCpsRi8ujRQIhV7cG7pzNncDDOSuACfe2D5 aoGikoyTk16vn846i2eDboE= =P0Nb -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Zope Configuration Egg Support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: Jim Fulton wrote: Perhaps we should change the package option so that it uses the pkg_resources API to load ZCML files from packages. +1 I'd prefer not having to specify if the source was an egg or just a normal package. +1 here as well, because it avoids breaking user-edited ZCML for the simple case (a package which used to be installed traditionally is now installed as an egg). The rarer cases (namespace packages, or those whose egg names don't match their package names) may still require the extra syntax. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFPLmP+gerLs4ltQ4RArVTAJ9HGvJsDi7yKFiDXolJMb7Sm2uBlACfXCsr GQsQZxSPbPLZd+wGBLFVRys= =m9EQ -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.i18n dependency in zope.configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Drake wrote: On 10/22/06, Baiju M [EMAIL PROTECTED] wrote: So any module imported should be added as a dependency. Then, what about modules imported in test files (*.txt or test*.py files) ? Pretty much; there are cases where a package might import something conditionally in order to improve integration, but if it isn't available, the package as a whole can function just fine on its own. In those cases, no dependency should be recorded. Ideally, dependencies of the implementation and the tests should be separated, but we've been treating them as one so far. Moving to eggs should allow improvements along these lines. Rkght: we should record that using the extra features of eggs[1] (so that the dependency is pulled in, but only if that feature is required). [1] http://peak.telecommunity.com/DevCenter/setuptools Tres - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFO6Kv+gerLs4ltQ4RApfWAJwPsipjprz88WkzOIRVcpuJFcWsogCgkzsA IVZ9I1duQIthrhTMLeR1lGM= =U686 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: testing and savepoints
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: Hi all, (sorry if some of this is Zope 2 - ish, the thread kinda started here and the underlying bits of this are certainly relevant to Zope 3) As you may have guessed by the flurry of mails today, I've been refactoring a 2000 test suite to use layers. I was hoping to use savepoints to speed things up... Each layer drops a savepoint in setUp and then rolls it back it in tearDown. Likewise, the TestCase's setUp would drop a savepoint and the tearDown would roll back to it. Sounds great, no? Well, no, actually: 1. Usual problems of some datamanagers not supporting savepoints. MaildropHost and some of the project's own products datamanagers do. mxODBC does not :-/ 2. dropping savepoints is slow. Figuring this might be due to saving data from the layer each time transaction.savepoint() is called, I thought of getting round this by dropping a savepoint at the end of the layer's setUp method. This did make thing a litte better, but: 3. savepoints are really slow :-( What's the usecase for savepoints? I would have thought this kind of thing would be ideal, but they seem really slow... For example, the above test suite takes about 300s to run prior to introducing layers. Using savepoints in place of transaction.commit()'s meant it took over 400s! :-( So I'm left what the actual use for savepoints is and if they could be made any faster? Dunno, but this question belongs on zodb-dev. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFNRbm+gerLs4ltQ4RArYgAJ9NYbG6fk3dL2D554JYkr1WxX17IgCg1UKU 2r+I33mqdDRHaUWTPKyvXfc= =h1Tg -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Why do we distribute SSL server keys and certs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: I'll probably reveal my ignorance of SSL here, but it is worrisome to me that we distribute a PEM file that contains a default server key and certificate. This seems like an exceedingly bad idea. It is. We also distribute a private key to be used for sftp. (Shouldn't there be a corresponding public key?) This seems like a very bad idea too. Keys should be generated inside 'mkzopeinstance.py', never shipped. We should probably add scripts for (re)doing the generation, as well. The good news is that neither are these are enabled by default, however, there are commented examples in the configuration file with comments blithely telling people to uncomment them to get HTTPS or SFTP support, using public private keys. Am I missing something? I don't think so. I didn't realize that we were shipping them at all. Are the shipped certs part of Twisted? In that case, we need to report this as an upstream bug. BTW, are there tests of the HTTPS and SFTP support? No se. Remove the code and see what breaks ;). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFMbFo+gerLs4ltQ4RAhWDAJ9fEynyLnvY3OJjaWIyrzf9AVliBQCfatGh n802vxTRnPwfpG9W+2AHI48= =1OnO -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.testing.testrunner: issue with remove_stale_bytecode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Wichert Akkerman wrote: Previously Andrew Bennetts wrote: The real problem as you noted in your original message is that there's no way to distinguish between a pyc file that is only intended to be used as a cache of bytecode for a py file, and a pyc file that is intended to be used standalone. Isn't the existing or non-existing of a corresponding .py file a good indication? No, because you may have intended to remove the module. Marking the directories containing the sourceless .pyc files as readonly would be a reasonable workaround: if your forgot the '-k', the testrunner would just whine and halt. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFLWiZ+gerLs4ltQ4RAls5AJ4uWRuEx3mG4QUignNAk6GAOG9LnACgipti HwY/HqIds70ZCIecVeHpA/g= =WmcQ -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: __all__ for zope.schema
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fernando Correa wrote:
Hi
I was just wondering if it would be interesting to have a __all__ list
just like zope.interface has.
This would be cool for someone (like me :-) ) that is trying to get
all the usable Fields that zope.schema provides.
code:
import zope.interface
zope.interface.__all__
('Interface', 'Attribute', 'implements', 'directlyProvidedBy',
'classImplementsOnly', 'implementsOnly', 'moduleProvides',
'alsoProvides', 'directlyProvides', 'implementer', 'implementedBy',
'noLongerProvides', 'Declaration', 'providedBy', 'classProvides',
'classImplements')
import zope.schema
zope.schema.__all__
Traceback (most recent call last):
File stdin, line 1, in ?
AttributeError: 'module' object has no attribute '__all__'
I just think that similar approach would give a better index for the
package.
- -1, mostly becuase '__all__' is primarily intended to support the
'import *' misfeature in Python; any change which encourages 'from
zope.schema import *' cannot be the Right Thing (TM).
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFJQ+O+gerLs4ltQ4RAgFqAJ0bNiokCcoZcVtda0xo22m/4HmSNwCfZVUX
Teuq8bF0v0SmapXurtQV9iE=
=bSRF
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Python version for Zope 3.4 ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Shell wrote: On 9/28/06, Martijn Faassen [EMAIL PROTECTED] wrote: Jim Fulton wrote: Baiju M wrote: Hi, What is the target Python version for Zope 3.4, is it Python 2.5? That's a good question. I fear it will take a fair bit of work to get to it and, frankly for me there are higher priorities. I think we'd be okay in not supporting Python 2.5 yet for this release. Python 2.5 has just been released, and the 9 months or so will give it time to gell out, Python extensions a bit of time to catch up with the newer version, and for us to do some experimenting. Linux distributions will likely still be supporting Python 2.4 (along with 2.5) at that stage as well. Are you talking not-supporting Python 2.5 at all? Or just not wanting to require it? The proposal is not to support it at all, unless somebody takes one for the team and works out all the nasty breakage which 2.5 induces on Zope. If Zope 3 can't at least run on Python 2.5 within three months of Python 2.5's release, I don't think that looks good for us. I would hope that by being more Pythonic and free from the old ExtensionClass magic - especially in Zope 3 - that Zope could keep better pace with Python. But nine months? A year? Can I expect the developers of toolkits we use, in some cases more heavily than Zope itself, like SQLAlchemy to hold off on requiring Python 2.5 for that long? The change from 2.4 to 2.5 is *massively* disruptive for a framework like Zope: much more so than any change since 2.2, I think (maybe even 2.0/2.1). The hardest bit is the change to the way the compiler works: RestrictedPython is completely incompatible with the new AST-based strategy. So unless a volunteer steps up to do lots of hard work between now and march next year, let's stick with Python 2.4. Otherwise let's plan it in for Zope 3.5 and Zope 2.12 I really really really hope it doesn't take that long to be able to at least run on Python 2.5: even if it has to be with some caveats or mild warnings. If security and restricted python / security proxies are the main issue, what about if one is running Zope sites with absolutely ZERO through the web code - no page templates, nothing - can't there be a lighter weight security implementation that wouldn't take half a year of lots of hard work? Even if you have no templates defined TTW, Zope3's security machiner still needs some support from RestrictedPython for handling filesystem-based templates. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFHJr3+gerLs4ltQ4RAnmFAKCuFkvWIAVn60mLP8AIik9LcttATgCcDrIL KQjhDIoPaj9N9pL1JHGIZU4= =D1Zt -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: emit ObjectModifiedEvent when object changed and zodb noticed?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: Hi All, Just been wondering about the need to retrofit: notify(ObjectModifiedEvent(self)) ...into lots of code. Can we do anything less intrusive? I mean, if a non-Zope object has changed, why should it have to think about emitting events? I would say that, in general, view code should be emitting the events, rather than content objects. In any case, could we do anything clever to do with event emitting when objects are committed to the zodb? No. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFGWWJ+gerLs4ltQ4RArOJAKCKyEgScvygoFXO1OSKp+8T4IsFZACglTnW OHC83OO1LK2vtvqDWwYiXG8= =ePmE -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [z3-five] zcml questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dieter Maurer wrote: Chris Withers wrote at 2006-9-25 18:44 +0100: ... Can we have a papal edict that zcml that has side effects is a bug? (including the dotted name thing...) Hm: the purpose of zcml is to have side effects (register things, patch classes with marker interfaces, add permissions, ...) But not during *parsing* of the ZCML: parsing is supposed to create a sequence of actions, which, when executed in sequence, make those changes. Because we check some kinds of errors too early (during parsing: in particular, we check the resolvability of dotted names), we force some directives to have early effects. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFGWuy+gerLs4ltQ4RAjlIAJwK15uUCu6ZRTID+lYnQcsxekQCzQCfbkwI MukYTI07cG07nUAgdVudcTQ= =OU26 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zcml questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: On Sep 25, 2006, at 1:44 PM, Chris Withers wrote: Jim Fulton wrote: It would *also* require that we implement the no side-effects during parsing policy (my other favorite dead horse in arguments about ZCML's implementation / usage). Beat away. :) I've been in favor of this for some time. This is definitely a goal. Can we have a papal edict that zcml that has side effects is a bug? (including the dotted name thing...) No, but I'm definitely in favor of refactoring existing handlers so they do pretty much all of their work in the actions they generate. We'll need to remove the parse-time error checking of name resolution then, which means storing filename / line number information with each dotted name so that the failed resolution can be reported when actions are running. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFGCT3+gerLs4ltQ4RAjubAKCAx3bjFDTQIJP2+NljAPNQJcwyYACglvno K4C1uDLz8e4M2MvIy1+w2TA= =srEr -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: the maintenance of change logs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: On Sep 22, 2006, at 11:47 AM, Martijn Faassen wrote: Hi there, I am about to do a new egg release of zc.catalog and will be putting out other eggs as well (to the cheeseshop as we now have our own category there). I notice in the SVN that there have been quite a few changes to zc.catalog. We do not have any CHANGES.txt or such, so it's very hard for me to determine what in fact changed without digging through SVN commit messages and such. So, I propose we start maintaining CHANGES.txt in packages, and mark changes there when we make them. I'd rather see this in projects, not packages. So this would be in the root of an SVN project alongside of setup.py. Maybe this is what you meant. The format I propose is in restructured text, like so: == zc.catalog changes == 0.2 (2006-11-22) Features added -- * zc.catalog can now do even more wonderful things. Bugs fixed -- * fixed a bug where zc.catalog wasn't doing the right thing. What do you think? See what I've been doing for zc.buildout: http://svn.zope.org/zc.buildout/trunk/CHANGES.txt?view=auto Some things to note: I knit all of the .txt files, including documentation-oriented doctest files together in the distutils long description. This causes the pypi page to be pretty informative: http://www.python.org/pypi/zc.buildout The knitting happens in setup.py, http://svn.zope.org/zc.buildout/trunk/setup.py?rev=70198view=auto While this is still pretty experimental, I'm pretty happy with it. To make this work requires coordinating headings across all of the text files. which lead to my use of *s in the root text files. Also, for individual packages, I think we can be a little more lightweight. For example, I think we can avoid separating features and bugs. - -1. I *like* the split, as it forces the maintainer to think harder about how to present the release to the world (ultra-stable vs. current vs. in development) I also think it's nice to provide some information about status and plans. I find putting dates on releases to be a bother. If it's a bother for me, it's probably a bother for others. Is it really worth it? Absolutely. Correlating what release happended when by grubbing through the logs is a chore, but better the releasing maintainer does it (once), and then keeps it aligned, than have everybody who might need to use the package have to do so. I've done a bad job of tagging releases, I need to get better about that. Finally, I'm experimenting with using launchpad for bugs: https://launchpad.net/products/zc.buildout/+bugs and feature requests: https://features.launchpad.net/products/zc.buildout/ So far this is working OK. I haven't really stressed it. Launchpad makes this very easy to set up and I don't think they are allergic to having us create lots of projects. If we're going to change horses, I'd rather go to something which can correlate checkins with issues, via some kind of convention about spelling the issue ID in the commit message (Trac, cvstrac, etc. do this). I don't know whether launchpad can be persuaded to do this (maybe via subscription to a checkins list?) Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFFZu2+gerLs4ltQ4RAkWYAKCLI/PHLTV5q2NshdXbRu+dxFnctQCffhmU XS4CC2Uu6hvKajR1JVYDZHI= =FzOf -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zcml questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Chris Withers wrote: Philipp von Weitershausen wrote: AFAIK, getUtilitiesFor is not supposed to order these in any way. While the returned iterator does find them in a reproduceable order due to the implementation, you shouldn't rely on that. OK, so you should always sort this list when using it for a UI? If you explicitly want the list to be sorted, sure. The question is how you want it to be sorted. Perhaps not everyone wants it to be sorted by the utility name. Also, getUtilitiesFor is a generator. That makes it efficient if you just get a few utilities, realize you have the one you want and don't get the rest. If you expect a sorted output, you lose that efficiency. Hmm, seems odd, is getUtilitiesFor used for anything other than generating UI's? I can't say off of the top of my head. Why don't you grep :) Also, if a site administrator wanted to unregister one of these in site.zcml, maybe because they didn't want the Traverse executor to be available, how would they go about doing that? ZCML has no way of unregistering specific utilities or adapters (though there's a Python API). That sucks :-( I thought the whole point of ZCML was that a site manager could override setup in site.zcml. 50% of that aim isn't done if they can't turn stuff off as well as on... Right. I think zcml:condition was a first step into that direction. Its implementation was very use case-driven. It seems you have a use case for more control over ZCML, so it'd be nice to hear from suggestions how you would envision a directive disabling feature in ZCML. Where can the python api for unregistration be found? On site managers. They have unregister* methods. So, *after* your ZCML has been loaded, you could poke at the global site manager and unregister the utilities that ZCML registered. In ZCML we typically define features and apply a condition using the feature: Why? So you can have yet another (pointless in this case) layer of indirection?! *sigh* We use it quite well in Zope 3 to enable/disable development tools like APIDoc. We have a feature called 'devmode' so all debugging tools can hook into that. APIDoc itself also enables a feature when it is loaded so you can register things with APIDoc, but only if APIDoc is available. zcml:condition also has another verb, installed, that allows you to load directives only when a certian Python package is available, e.g.: include zcml:condition=installed reportlab package=worldcookery.pdf / meta:provides feature=twidder.defaulttraverser / utility ... zcml:condition=have twiddler.defaulttraverser / This is missing the point. There are an array of inputs, outputs and traversers available. There's a sensible default set registered, but site managers might have different requirements which are likely to include disabling some of the default registrations. Why woudl they have to disable existing ones? Can't they just choose different ones, leaving the default ones sitting there? How should I do things such that they can do that? I'm just wondering whether you really need the disabling feature. I've wanted it. My major beef with the way we are *using* ZCML now is that we expect package authors to provide policy-laden configuration for their packages (sensible defaults) but provide no means for the admin to reuse that configuration selectively; their only realy choice is to *copy* the configuration and edit it. I argued *long* ago (after the first ZC-internal Zope3 sprint, I think) that the 'include' directive should be allowed to be complex, with subelements like 'except' or 'only' to pull in specific directives. Such a practice would require either that we have XPath support available, or else that we come up with a way to mark the directives (e.g., a 'zcml:id' attribute). It would *also* require that we implement the no side-effects during parsing policy (my other favorite dead horse in arguments about ZCML's implementation / usage). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFEpBV+gerLs4ltQ4RAlldAJ9FwPgZV3NCE16wXiZGwpljrpZfswCeLwU5 PdZXr3WyOcBeEpcAzEe2QEg= =XbgN -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zcml questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Tres Seaver wrote: How should I do things such that they can do that? I'm just wondering whether you really need the disabling feature. I've wanted it. Okay :). My major beef with the way we are *using* ZCML now is that we expect package authors to provide policy-laden configuration for their packages (sensible defaults) but provide no means for the admin to reuse that configuration selectively; their only realy choice is to *copy* the configuration and edit it. True. I argued *long* ago (after the first ZC-internal Zope3 sprint, I think) that the 'include' directive should be allowed to be complex, with subelements like 'except' or 'only' to pull in specific directives. Such a practice would require either that we have XPath support available, or else that we come up with a way to mark the directives (e.g., a 'zcml:id' attribute). Well, we already sort of that this marking with features + zcml:condition. But except and only could be more powerful wrt packages, modules, or even classes and interfaces. It would *also* require that we implement the no side-effects during parsing policy (my other favorite dead horse in arguments about ZCML's implementation / usage). Yup. I think there are very little side effects currently. I can't think of one off of the top of my head, to be honest (but I'm sure there are). We do eager checking of dotted names (during the parse), which makes it impossible to write a directive which synthesisizes the target of a dotted name without side-effects (e.g., the 'five:bridge' directive). If we delayed the check until after parsing was complete, then we could eliminate one source of side effects. Side-effect-free parsing would open a lot of possibilities: ZCML introspector tools, for instance. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFEpeX+gerLs4ltQ4RApuDAJ9GW+vIzSOzCQ7vj6iUBpmkh5LeFwCcC29l V2u8kqNL/VJKTXOEPc1Ryl0= =gIbE -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zc.selenium, Selenium 0.7.1 bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Drake wrote: Hi all, The zc.selenium package includes Selenium 0.7.1 (the latest release), which includes this unresolved issue: http://jira.openqa.org/browse/SRC-99 Selenium just released version 0.8 for the Core portion last night; it doesn't appear that they have fixed that bug: http://www.openqa.org/selenium-core/release-notes.html http://jira.openqa.org/ReleaseNote.jspa?projectId=10030styleName=Htmlversion=10271 This impacts one of our projects, and the workaround described avoids the problem. It's not clear that the workaround is more than that (or that it's not). Is anyone else affected by this? Does the workaround have a negative impact for anyone? I've attached a patch against zc.selenium that implements the workaround. I'd like to commit this in zc.selenium if there are no objections. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFEbFq+gerLs4ltQ4RAh4OAKCPRwVqQUP+KAQvg/5uQ7j9qG/cUQCgoSAH 56KXafPxffhLfNihT6OZDZY= =1xcS -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Naming tags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Monday 18 September 2006 07:13, Jim Fulton wrote: but not both and not mixed for the same version. My personal preference is 'rc'. My preference is c1. Me too, because then you have a, b, c. :-) +1 for 'c1', because it fits the way other Python packages are numbered, and how setuptools interprets the value. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFDt9A+gerLs4ltQ4RAvI4AKCOMs9QikAfEoLCHBskhnhsYwqUIACgiOfJ EgcSrvC8vA5mkaJy+WCV+Fw= =8Yyr -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Working on the 3.3.0rc1 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 TAHARA Yusei wrote: Hi. At Tue, 12 Sep 2006 17:43:27 +0200, Christian Theune wrote: Then this is a small reminder to Yusei, that the 3.3 branch has been tagged for RC candidate and only *very critical* changes are allowed to go there until we do the release. Oups, Sorry I missed the announcement. I'll be more careful in the future. You didn't miss it: the announcement of the freeze came out about 15 minutes after your last checkin on the 3.3 branch. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFBxyp+gerLs4ltQ4RAnwxAJsEtK3uFfS9/U09R0d7Jj+2l79H/gCgopZ4 guoewgIgKoQUpb9iJSokokw= =di8m -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3.2 maintenance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Jim Fulton wrote: I agree in principle. In practice, I'm not sure we have enough maintainers to get a release out, let alone maintain two previous release branches. :( We need more volunteers. The marginal effort to do the bugfix correctly (i.e., first on the release branch, then forward-porting to any beta branch and the trunk) is not that big. If we can't get our volunteers to do that, then maybe we need to quit pretending that Zope3 is or ever will be production ready. Without such a practice (which Zope2 has had since before community checkins), how can we expect anybody to take Zope3 seriously? If we want to maintain releases for a year, I suspect we need to release once a year. Backporting a fix from the current release branch (3.2, in the current case, since we still haven't released 3.3) to older release branches is more iffy to me: I would say that we should only mandate that bugfixers consider it for critical or security-related bugs: they may, if they wish, backport, other fixes, but we make no committment that there will ever be a subsequent release from that branch. I did Zope 3.2.1 mostly because some formlib fixes were needed in Zope 2.9. I'm prepared to do more Zope 3.2.x releases as they are necessary. People just need to backport their fixes. That they haven't done this is also partially the fault of the checkin police (which I count myself a member of ;)). I'll be more attentive in the future. I'm prepared to do this mercilessly (also for older bugfixes), the question is whether we shall adopt this policy now or not. I'm already on record in favor. ;) Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFBYC2+gerLs4ltQ4RAsZrAJ9Z1DuhIZcQu5KYQkelEhY/NiAHKQCeLE33 65TECNNtZ9wbEb5EjK6hzio= =S6f6 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3.2 maintenance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rocky Burt wrote: On Mon, 2006-11-09 at 11:28 -0400, Tres Seaver wrote: Philipp von Weitershausen wrote: Jim Fulton wrote: I agree in principle. In practice, I'm not sure we have enough maintainers to get a release out, let alone maintain two previous release branches. :( We need more volunteers. The marginal effort to do the bugfix correctly (i.e., first on the release branch, then forward-porting to any beta branch and the trunk) is not that big. If we can't get our volunteers to do that, then maybe we need to quit pretending that Zope3 is or ever will be production ready. Without such a practice (which Zope2 has had since before community checkins), how can we expect anybody to take Zope3 seriously? I've only ever worked on one open source project where I was not supposed to backport my fixes to the maintenance release branches and that is Plone. For Plone we have someone responsible for back-portting that stuff in bulk. It makes his job harder if we manually back-port fixes as then he has to be more selective with the patches he backports. Thanks Hanno! That is an enormous amount of effort: major kudos to him for being willing to tackle it. I think that in some cases, such a practice will not necessarily going to give the highest-quality result: the backporter won't always have as much context about the bug as the original fixer, and may not be able to ensure that it is fixed properly. But my point is it is pretty standard behaviour to have to backport fixes to all actively maintained branches. I'm actually arguing against calling it backporting at all: the point is that it is *more* urgent to fix the bug on a release branch than to do so on the trunk, so we should refer to the process as forward-porting. Pragmatically, it is typically *easier* to forward-port a bugfix than to backport it, because the common ancestry in the merge is more likely to be helpful. Of course, some kinds janitorial practices (e.g., tidying up whitespace, imports, etc.) can make this harder if done only on the trunk. That sort of friction is one of the reasons why change velocity drops off on successful projects. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFBYYJ+gerLs4ltQ4RAl/fAJ474wC5H+0i15e/YPgmDqXb5h4GzQCgw9x0 IZ44jkt1FOtuHMV+3v6AUF4= =+SWn -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: The bug fixing problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick Gerken wrote: On 7/16/06, Jim Fulton [EMAIL PROTECTED] wrote: On Jul 11, 2006, at 8:05 AM, Patrick Gerken wrote: On 7/7/06, Julien Anguenot [EMAIL PROTECTED] wrote: ... I marked the bug as bug + bugfix but nobody cares. That is much more discouraging than what I can not do nice wiki links to in my bugreport other bugtracker items or svn sources like it is possible in trac itself. What is the issue number you are referring to? I don't see any bug+solution issues that seem to be from you. Perhaps you submitted 572? Or perhaps your issue was resolved. Sorry for the very late answer, but our employee put us into a tourist place with no internet access, and before I sent the link I wanted to ensure that the tests still work. This is the issue: http://www.zope.org/Collectors/Zope/1944 But the original issue is just, that it turns one off, to see no response, of course I'm giving a bad example in responding so late. I'll note that one developer (Andreas) did try to merge the patch, and then ended up backing it out because it broke tests. I'm also not quite sure I understood the rationale for the patch, when reading it, which makes it harder for me to just jump in and merge it. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFBYac+gerLs4ltQ4RAkS4AKCf1BMG2VlNwuu0jyUUKYhWEMkAuwCdFsjS /elBt9ucMltYtr2w7PvKL8c= =uW61 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3.2 maintenance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Friday 08 September 2006 04:12, yuppie wrote: Are there good reasons why these changes were not backported? I volunteer to backport some fixes I'm missing in Zope 3.2, but that's no general solution for keeping the current stable branch maintained. The short answer is: We are a bit sloppy. I always develop against the trunk, so when I fix an issue, I do not event think about porting it back to another release, other when one is imminent, like Zope 3.3 now. I think most other Zope 3 developers are the same. I consider this practice unacceptable for work on an allegedly ready-for-production package. The Zope Development Process document [1] states: When you check in a bug fix, you almost always need to: * Check in the fix on the current release branch * Note the fix in the /doc/CHANGES.txt on the current release branch * Merge the fix to the trunk to be sure its fixed for the next feature release Only feature work should be done primarily on the trunk. [1] http://www.zope.org/DevHome/Subversion/ZopeDevelopmentProcess Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFAbKx+gerLs4ltQ4RAt6SAJ9fYC0322cIzW0NeHMe+EGT+RSqsgCdHH7T t2Um2o27+28g6mMLDZiI5XU= =l+RS -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 as a reliable platform?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dieter Maurer wrote: Philipp von Weitershausen wrote at 2006-9-4 16:49 +0200: ... I for one prefer exceptions over manual error handling. And I prefer straight-forward APIs over unnecessarily complicated constructs. But you probably would not prefer if these straight-forward APIs were continously changing. I prefer a slightly suboptimal stable API over one that is optimized in each version in a non backward compatible way. I do not want to say that this is happening in Zope3 land. I do not yet use Zope3 in earnest and see what is happening more from the mailing list than from my own experience. So, for me, it would be great if developers would take more time to weigh up the what does this new feature or refactoring bring against the how much of a PITA is it going to be for everyone else to relearn this... I like new features but often could not see the gain of refactorings. Many refactorings in Zope 2 land were just silly, e.g. whitespace refactoring such as: from X.Y.Z import a, b, c refactored to from X.Y.Z import a from X.Y.Z import b from X.Y.Z import c I might be the perpetrator, but surely such a change has no impact on code which imports the module. Does this affect you because it breaks patches you maintain? I do see the gain of moving out general purpose functions from zope.app into zope. But, I would do it in a backward compatible way -- even when zope.app then contains quite a few trivial packages redirecting to the relocated packages. As I said earlier, I actually *like* the insulation provided by a façade package: it leaves the internal location free to change wildly, without propagating the churn from that change out to those who are clients of the code. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE/HSr+gerLs4ltQ4RAiLGAJ490R2aiQAAeuVELa90QzjLNYszxwCfa4Bq ccve4CXAHlKBRgoTl+FVYuY= =BPQx -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 as a reliable platform?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: Hi, this is a rant. I don't want to be destructive or disruptive, but I feel like I need to turn this up right now. Let's start with something positive: I love Zope 3. I do. I know it almost since the beginning and I see how it works out. But to be honest, I too often get the feeling that something in the process is wrong and we are failing to acknowledge it or work on it. I think we make it way to hard for people who want to use Zope 3 as developers making applications with Zope 3. Why? Because we keep changing stuff and don't tell people in VERY LARGE LETTERS about it. What worries me most is that I, although I'm contributing to Zope 3 every now and then, even fall into this quite often and I'm getting tired of it. I can't read every proposal or every commit message or every post on the mailing list. I try to, but I can't. And I think that normal developers shouldn't have to try to. When Philipp explained the zope.component thing in an earlier post I got annoyed again because I was relying on information that obviously was false. That's probably my fault because I didn't digg deep enough to verify the truth whether zope.component.provideUtility works against the thread local component registry or not. When I saw that zope.*app*.component does that I got scared because it's so similar and maybe hard to distinguish. What I'm worried about is that we have to come up with a *MUCH* better way to tell people What is *the single* way to do this or that? and Hey, we used to do it *this* way, but HEADSUP, now it's *that* way!. Again, maybe I'm only hitting this all the time because I'm living most of my live on pre-release-branches or the trunk, but still. I think if Zope 3 shall be used by many people, this is a major obstacle. I hope I don't annoy anybody, but I had to get that off my mind. Insulating non-core developers from this kind of churn is what the façade module 'zapi' was orignally for. Folks who were writing application code would have a reliable location in which to find the public API, and would not be exposed to the deprecation dance caused by tree refactorings: instead, the person who did the tree refactoring would just adjust the 'zapi' imports, and everyone else's code would Just Work (tm). That module would also be the logical place for lots of the BBB code now scattered around the tree. I'm OK with having in-tree code not use zapi, but I don't see a win in propagating all the mess out to the rest of the world. I'll also note that janitorial deprecation is way too common in the tree today: people decide they don't like the name a method was given, and deprecate it in favor of the better name. The ongoing cost of that deprecation is then borne by everyone else. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE+blG+gerLs4ltQ4RAhEEAJ9/CLYNqlrPFWh+3UnPwaraMMLs7QCfVYYp 1fiertpiMU2/pFhAe6ovbQk= =esi5 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: proposal: error reporting unification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Martijn Faassen wrote: Hi there, See the following proposal: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ErrorReportingUnification +1, as posted in a comment already. To be determined is whether we want to keep the rules currently in place for the SiteError log and apply them to the error reporting utility as well, or remove them for the SiteError log as well. I'd propose the latter - it's evidently not an issue that all errors are reported in the utility, so why suppress them in the logging? I'd be fine with that, but we'd still need to filter UserErrors, NotFound, etc. logged. UserError is thrown by a piece of software when it wants to know the user of the application about it (e.g. invalid container names). Such errors aren't of interest for the system error log, at least not normally. Zope2's experience argues otherwise. Having a log of the error allows the developer to investigate an error reported by the user, even though the user can't give enough information to allow reproduction. *I* want to be able to push such errors to the log; *you* might never need to. Ergo, it is policy, and needs to be managed as such. NotFound errors would occur every time IE tries to find favicon.ico, so again, not very useful... That is more policy, though, and should be settable on the error log. Sometimes getting the log of the NotFound is *important* in some cases, even though it is useless most of the time. This is an anti-case for emergent behavior configured by adapters, IMHO; better to configure the service (the error log object, or its global equivalent) to handle such choices. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE7dVS+gerLs4ltQ4RAuWnAKCzV+mBwgsxgR6xNPruVpGSqlmnzwCcDZGP EBUNFtmy60W2C67jK3oBFgI= =Rtwg -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 2 clock server for Zope 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: Florian Lindner wrote: Am Sonntag, 20. August 2006 06:11 schrieb Christian Theune: Hi, you might try a look at the recently released zc.async which allows you to leverage twisted asynchronous handling together with persistent objects (as far as I know right now, haven't looked at it personally yet). I've overflown the readme and it looks rather complicated compared with the Zope2 clock server which is pretty straightforward. Well, it's not exactly the same use case and it's more generic AFAIU. *And* more complex, *and* it requires that you run Twisted. ClockServer is dirt simple, robuts, and runs inside ZServer. It doesn't try to be anything more than a way to trigger periodic requests. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE6ciA+gerLs4ltQ4RAi47AJ4k9dlT7r1pFzt39BsksKSMLOjB1QCfRY+E xj7ylKpyTHfBfaIFgpx3Djc= =5OaD -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Testbrowser failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Jung wrote: --On 19. August 2006 17:25:39 +0530 Baiju M [EMAIL PROTECTED] wrote: This is already fixed according to: http://www.zope.org/Collectors/Zope3-dev/645 The fix is in 'ClientForm.py', this file is *not* set as an svn:external in Zope 2. Just setting this as svn:external to Zope 3.3 will fix this problem, otherwise update this module. Thanks, I copied over the file. Unfortunately svn:externals don't work on files but only on directories. Maybe make it a package, 'lib/pythong/ClientForm', with the current module code in its '__init__.py'. 'lib/python' shoulc not carry around such forks, if we can help it; better svn:externals today, eggs tomorrow! Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE5zEQ+gerLs4ltQ4RAsx9AKCD/Fh992o5V26tutPc2ul6+vl0JwCgig6V fOQgEYX4PVHVUFmTXx7PSy8= =RPIT -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Checkins] SVN: lovely.rating/ Initial import from Lovely Systems repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Jung wrote: --On 17. August 2006 01:11:44 -0400 Tres Seaver [EMAIL PROTECTED] wrote: The appropriate thing here would be to remove the code which depends on the GPL, and then ask the foundation's permission before readding it. In the meanwhile, codespeak.net might provide a reasonable place from which to continue development of said code. That's extremly odd. Consider the following case: I am writing a ZPLed Zope product but include some migration shell scripts that call some common GPLed unix programs for a particular task...I wouldn't be allowed to checkin this software on svn.zope.org? The advice to move the code out of the repository is not really legitimate. Neither rules as given through the contributor agreement nor unspoken rules were violated. Once again: using GPLed software does not make your own ZPLed software automatically GPLed. Some folks (many of those who release Python software under the GPL) believe that 'from foo import bar' triggers the provisions of the GPL, arguing by similarity with the somewhat-equivalent operation which occurs when including / linking code in a C / C++ application. These same folks would *not* argue that invoking a separately-compiled GPL application, and then consuming its output (or relying on its side effects) triggers the GPL on the invoking application. In the realm of copyright law, such authors' intent about the use of their code might actually be pertinent if the issue is ever tried in court. In the meanwhile, the code in question exposes others beyond the author (those who incorporate the ZPL-but-dependent-on-a-GPL-module code in their own applications) to a risk of being the guinea pig who gets to pay to prove the point in court. I consider such needle^h^h^h^h^h^hrisk sharing to be inappropriate within the Zope repository. I say this as a Zope developer / ZF member, who is *not* a ZF board member; the foundation's IP policy is more easily construed to support such a position, as well. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE5Abx+gerLs4ltQ4RAu28AJ43Z0E7Qmu5fAEoebtY/tvcx0S0fgCgitCf l8H27Qu3bxh6gMuuxn5RDy8= =0cMb -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: SVN: Zope3/branches/3.3/ Fix issue 383.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florent Xicluna wrote: Log message for revision 69521: Fix issue 383. Patch on zope.app.server was missing on zope.app.twisted (see rev.30448). Thanks very much for carrying this forward! Changed: U Zope3/branches/3.3/doc/CHANGES.txt U Zope3/branches/3.3/src/zope/app/twisted/schema.xml U Zope3/branches/3.3/zopeskel/etc/zope.conf.in -=- Modified: Zope3/branches/3.3/doc/CHANGES.txt === --- Zope3/branches/3.3/doc/CHANGES.txt2006-08-15 20:02:00 UTC (rev 69520) +++ Zope3/branches/3.3/doc/CHANGES.txt2006-08-15 20:02:22 UTC (rev 69521) @@ -10,11 +10,10 @@ Bugfixes - - Fixed issue 383: Change default configuration in zope.conf to -bind explicitely HTTP server to 127.0.0.1 and give information -how to bind to any network interfaces. -Note: if you omit to specify host or ip address, there's still -a discrepancy between Windows and other platforms. + - Fixed issue 383: Twisted and ZServer work the same on any platform. +Default configuration is to bind servers to all interfaces. +You find additional information in 'zope.conf' to know +how to bind to a specific address. - Fixed issue 574: Page template traversal adapters were not correctly proxied. Modified: Zope3/branches/3.3/src/zope/app/twisted/schema.xml === --- Zope3/branches/3.3/src/zope/app/twisted/schema.xml2006-08-15 20:02:00 UTC (rev 69520) +++ Zope3/branches/3.3/src/zope/app/twisted/schema.xml2006-08-15 20:02:22 UTC (rev 69521) @@ -4,7 +4,7 @@ sectiontype name=server datatype=zope.app.twisted.server.ServerFactory key name=type required=yes / -key name=address datatype=inet-address / +key name=address datatype=inet-binding-address / key name=backlog datatype=integer default=50 / /sectiontype Modified: Zope3/branches/3.3/zopeskel/etc/zope.conf.in === --- Zope3/branches/3.3/zopeskel/etc/zope.conf.in 2006-08-15 20:02:00 UTC (rev 69520) +++ Zope3/branches/3.3/zopeskel/etc/zope.conf.in 2006-08-15 20:02:22 UTC (rev 69521) @@ -17,16 +17,14 @@ # Standard HTTP server for Zope 3. # -# HTTP server is explicitely bound to local loopback. -# You can keep this configuration if your server -# stays behind a dedicated web server. -# Alternatively, you can change address to 0.0.0.0:8080, -# if you need to bind to all network interfaces. -# +# HTTP server is bound to all interfaces. +# You can bind to any IP address or hostname, +# or use 127.0.0.1:8080 for local loopback. # Server: All Servers +# server type HTTP - address 127.0.0.1:8080 + address 8080 /server # Ready to go HTTPS server. You just need to make sure OpenSSL is installed. @@ -69,7 +67,7 @@ path $DATADIR/Data.fs /filestorage -# uncomment this if you want to connect to a local ZEO server +# Uncomment this if you want to connect to a local ZEO server # instead: # zeoclient #server localhost:8100 Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE4/vY+gerLs4ltQ4RAv85AKCFOnFtce9aMIdIdFtCtl14ngyMzgCfaJbv EIBuX6RSu9XaL2/YuECeRas= =asJ7 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: SVN weirdness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: Benji York wrote: [craziness] That'll teach me to reply to email before coffee. Philipp explained the observed behavior. And another argument for usning tags instead of 'branch + revision' for externals: if SVN doesn't remember that the external should be frozen to the revision it was checked out with, then SVN is broken here. /me *still* wants a 'svn ln' command which creates a read-only tag from the combination of branch and revision, but the SVN team is uninterested in supporting release managers' use cases, it seems. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE2z8e+gerLs4ltQ4RAo2aAKC0/zB6diIGdL3zYnH8aMsRLDQtOwCbBGvj HUzLmtA/Jf4NVr2jDa51ETo= =JIgW -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Through-the-web reStructuredText
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: So forking docutils inside Zope is *not* evil, even when considering packaged versions, as long as the packagers know about the fork, right? The unforked docutils provides the necessary safety when used correctly. It is our careless use of the feature that was the cause of the problem. As Florent pointed out, long experience with text processing systems on Unix (Tex, postscript, etc.) says that enabling file inclusion by default is a security hole. Leaving it enabled by default makes docutils at least partly to blame for such holes (under a doctricne of attractive nuisance). If, OTOH, the downstream programmer had to explicitly enable the risky behavior, then any breach would be *that programmer's* fault. Relevant history: - SVN says that the knobs to disable the dangerous features, along with the docs for the why teh features are dangerous, were added fifteen months ago: http://svn.berlios.de/viewcvs/docutils?rev=3071view=rev - Those knobs were made available in the 0.3.9 release of docutils (per the HISTORY.txt file). - Andreas upgraded Zope to that release last October, just before initial hotfix (from the timing, on 2005/10/09, it looks as though the hotfix have been the motivation for the upgrade). - Because of the way we ship docutils (there was a lot of wrangle about this, as well, with Andreas moving stuff around to suit the course of the wrangle) we don't even ship the documents which label those directives as 'dangeroous' (they are off in the 'test' subtree). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEsf7j+gerLs4ltQ4RAgUiAJ4kntQ8aOogx6gC+r3TmlEO+Bhs5QCgssm6 co2YkpdSgWiv+pWfEPkyo9w= =nvkT -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Version control of ZOPE3 objects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pjotr Prins wrote: Hi, I need to build a versioning module for the xParrot project (http://xparrot.thebird.nl/). I have some questions and wondered who would be inclined to help with the architecture phase. The idea is to save objects that implement IVersioning on a modification event to either ZODB, or to an external version control system like subversion. The latter would be nice as it could handle for example diffs through Websvn (a reverse proxy may be needed to handle access control through ZOPE). Using an existing version system saves a lot of code and would allow for functionality like branching etc. On the other hand commits have to be run on a separate thread (which I can model on the current mailqueue implementation). Also deployment would require extra system administrator skills. Before I go down this route I would like to ask if anyone has a better idea? And who would take an interest in this little project, and doesn't mind bouncing off a few ideas? Integration with a non-transactional backend (such as Subversion)is going to be tricky: the mailqueue, for instance, manages to avoid re-sending mails for requests which are repeated due to ConflictErrors, but it can't cope with failure in the actual mail handoff. In the case of a subversion sandbox, you are going to need some kind of notification mechanism, at least if each appserver has its own sandbox, so that you know when to do 'svn up' due to a modification in another appserver. You are also going to have to serialize access to the sanbox between threads in a single appserver. If a commit fails (e.g., due to a conflict error), it is going to be tricky for your application to handle: assuming that you have delayed doing the actual 'svn commit' to the end of the request (in 'tpc_finish', most likely), then you won't be able to abort the Zope transaction. You will also have to come up with UI to allow the user whose commit failed to resolve the SVN-level conflicts. I don't know what kind of format xparrot uses for its documents. Is it going to be diff-friendly? If not, then most of the win for SVN is going to go away. At that point, I would be considering some kind of ZODB-based solution, either a content repository (I've done this for large media sites) or else making the documents themselves into containers for revisions and drafts (I've done that as well for systems with fewer, but more complex, documents). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEsXA2+gerLs4ltQ4RAibxAJ45d4FazCsr30X4qUHDveANoT992ACfU5/w Vj8UWQYq+KvC0Yeh+80rd40= =KaYo -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Through-the-web reStructuredText
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Haubenwallner wrote: Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Haubenwallner wrote: Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Zope 3, as releases is not affected by the security hole that has plagued Zope 2, however, Michael Haubenwallner has pointed out that some add-on-products, such as zwiki and bugtracker, may provide TTW reST. They appear to be safe for the moment, but not because they intentionally disable file inclusion: rather, they have a bug (they set the 'encoding' to 'unicode', which then causes an exception). Both restructuredText directives 'include' and 'raw' have an 'encoding' option to set the name of text encoding of the external data file/raw data (file or URL), it defaults to the document's encoding (if specified). .. include:: filename.ext :encoding: utf-8 .. raw:: html :file: filename.ext :encoding: utf-8 should work as expected Michael Verified. Both wikis and bugtracker issues are capable of including arbitrary files using that spelling (in an instance created from today's Zope3 trunk, anyway). Zope3 accesses docutils in a single point atm: zope.app.renderer.rest.ReStructuredTextToHTMLRenderer.render() All objects created from the factory zope.source.rest are rendered here. It should be possible to configure the docutils parser (and its directives) by adjusting the 'settings_overrides' values. I think the same can be done (and is done already) for Zope2.x in lib.python.reStructuredText.render() with the 'settings' dictionary. That way it would be possible to make the parser usage configurable and no need to use a patched docutils. In Zope2 land, the module is still available, and can be used by other code (which may not know of that issue). I'm *not* in favor of shipping an un-patched docutils until we work this out. For instance, perhaps we should be patching docutils to make the *default* settings disable file inclusion and 'raw'; then the trusted code which wanted to render reST which legitimately needed those features could enable them explicitly. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEr6pm+gerLs4ltQ4RAhquAJ4yotGOLN5778NdQ5Fh2oO7wCRNIACfcZ3N //xqhLuWYrUAGEU5j8B214c= =CHum -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Through-the-web reStructuredText
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Zope 3, as releases is not affected by the security hole that has plagued Zope 2, however, Michael Haubenwallner has pointed out that some add-on-products, such as zwiki and bugtracker, may provide TTW reST. They appear to be safe for the moment, but not because they intentionally disable file inclusion: rather, they have a bug (they set the 'encoding' to 'unicode', which then causes an exception). DTML Page was another possible culprit: it too is safe for the moment, because Z3's DTML does not have a handler for 'fmt=restructured-text'. That is not really a comfort, because someday somebody is going to harmonize Zope2's DTML features into Zope3's DTML; at that point we are hosed again. There are 2 issues here: 1. That we need to warn anyone using these that there is an issue, including anyone who might be using a Zope 3 checkout in production. 2. I want to move these out of the main subversion tree. For those of you on this list, consider yourself warned. We should probably send out a warning more broadly though. Thoughts? I think the benefit of leaving file inclusion lying around in the main python path's version of docutils (for benefit of notional filesystem ResT users) is far outweighed by the risks associated with it. TTW ReST is *valuable* to people: it gets used by content authors, among others. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFErsYB+gerLs4ltQ4RAjeCAKC20y9dt1CLJNzYH/QC3suafMdeoACfV1O7 C/2DHO5D+8hwacuMcvw8w5U= =qCze -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Through-the-web reStructuredText
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Haubenwallner wrote: Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Zope 3, as releases is not affected by the security hole that has plagued Zope 2, however, Michael Haubenwallner has pointed out that some add-on-products, such as zwiki and bugtracker, may provide TTW reST. They appear to be safe for the moment, but not because they intentionally disable file inclusion: rather, they have a bug (they set the 'encoding' to 'unicode', which then causes an exception). Both restructuredText directives 'include' and 'raw' have an 'encoding' option to set the name of text encoding of the external data file/raw data (file or URL), it defaults to the document's encoding (if specified). .. include:: filename.ext :encoding: utf-8 .. raw:: html :file: filename.ext :encoding: utf-8 should work as expected Michael Verified. Both wikis and bugtracker issues are capable of including arbitrary files using that spelling (in an instance created from today's Zope3 trunk, anyway). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFErzS3+gerLs4ltQ4RAhboAKC0oxRwqZKBOiZxYEEPXoPi1NE0tACbBepr f5qWSi/OFDafP05XGXaOqxI= =x4ny -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: What are zope.generic, z3c, ldapauth, et.al.?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: no problem, I agree to have a place for such infos. The README.txt files are not good enough for give a overview because you have to checkout first or browse the really slow repos with a browser. Tell me where is somewhere and I can write something ;-) snip Maybe there should be a top-level README (a peer of the 'src' directory) which outlines the overall architecture and points to the individual sub-packages as they fit into that concept. Then, anybody who checks out the trunk, or a tag, or a branch, will get that overview in the top of their checkout. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFErcF/+gerLs4ltQ4RAh5gAKCD9ybcmAExAfrKFEYQu8qft8SwvQCfZWDc QvSFKo7PF7XXgP0fODhhgvw= =nqOe -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: The bug fixing problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: Hi, Marius Gedminas wrote: I do not think that the requirements to 4. Write unit tests 5. Merge bugfixes from trunk to the release branch 6. Wait for the incredibly slow updates on the collector discourage me all that much. Right. They don't discourage me either, but there is a special case in 4) which I hit several times lately, where the unit tests need very special effort. I think that if more bug reports had a solution outlined in English, I'd be more likely to go fix them every now and them. Indeed! I would say that there are two bugs in the case you are describing: the one you meant to fix and the one which is the lack of any tests for the module / class / whatever. I would bet that spending your thirty minutes adding minimal tests to such a module is a *higher* value activity than fixing most bugs, because it makes it easier for you (or someone else) to fix that bug and others in that module. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFErcLD+gerLs4ltQ4RAhSxAJ9xmfzyQILaq0/aVZr/ELlQOGu4dgCfQog8 YK2w5mPjtW7mAfpzFDYqS0Y= =m9Cv -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Unify the Zope 2 and Zope 3 repositories!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: A small question/idea. When making svn:externals in Nuxeo, we always use https. That way trees can still be checked out anonymously, but still modified. in Zope, threes are checked out with svn+ssh, but externals use svn. That means that when you want to modify for example Five, you need to delete the svn checkout and do an svn+ssh checkout instead. Also, if you start changing things without remembering that you have to make a fresh checkout, you have to svn diff it and them manually merge it into the fresh checkout, and if you later do an svn up, your changes will be moved into a dead *.OLD directory (where you can't do svn diff to extract your changes) and so on. The benefit of that is that you don't by mistake check in on a tag... My question is: Is there a good way of not having to check out a fresh copy before you do changes? If not how would people feel about switching to https or something instead? Especially if we merge the trees, in which case both Zope2 and Zope3 will be made up mainly of svn:externals... - -1. The externals are just that, external to the Zope project. Modifying them should require extra thought, and a little extra effort, because the possibility exists that the change might break something outside the Zope tree. When we get to an egg-based Zope install, I think such a gesture would map onto check out the source egg and force it into the path.' Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEoB5L+gerLs4ltQ4RAqfRAKDUrcW7NYg4ljtHvYZto3H5hARV1gCglHWv 2pqpEsGwE1h6rckFpJgcmTo= =/cbq -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Unify the Zope 2 and Zope 3 repositories!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: On 6/26/06, Tres Seaver [EMAIL PROTECTED] wrote: - -1. The externals are just that, external to the Zope project. Uhm. I have a hard time seeing Five and lib/python/zope as external to Zope. They are managed as separate projects, with their own priorities and releases. ZODB is the longest-running example of this externality. When we get to an egg-based Zope install, I think such a gesture would map onto check out the source egg and force it into the path.' Yeah, with eggs this issue might go away... Right. The 'svn:externals' will morph into dependencies, which will still be managed exterally to the dependent package. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEoCer+gerLs4ltQ4RAqnwAKCVr5TeOU0XyLG/6drpaTJ65lGgiwCfbD74 V6ArZP8baL0Vo2fafxJQYOg= =fcxE -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: SVN: Zope3/branches/3.3/ Fixed issue 525: DateWidget ru-format
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dmitry Vasiliev wrote: Benji York wrote: Philipp von Weitershausen wrote: Dmitry Vasiliev wrote: Log message for revision 68818: Fixed issue 525: DateWidget ru-format - type=text value=2002-12-02 12:30:00 / + type=text value=2002 12 2 12:30:00 / Note that a EditForm can't make use of a get_rendered method. The get_rendered method does only set initial values. Why does the display of the default DateTime widget change? DatetimeWidget now use zope.i18n for parse and format values so the display is the same as for DatetimeDisplayWidget (note the line 1529 of the form.txt). ...and in such a strange way? It's the datetime format for the default locale, see the specification in zope/i18n/locales/data/root.xml. That breaks a test: File /home/tseaver/projects/Zope-CVS/tseaver-retire_zpkg-2.10/lib/python/zope/formlib/form.txt, line 1547, in form.txt Failed example: print MyAddForm(None, request)() # doctest: +NORMALIZE_WHITESPACE Expected: input class=textType id=form.identifier name=form.identifier size=10 type=text value= / input class=textType id=form.name name=form.name size=20 type=text value= / input class=textType id=form.min_size name=form.min_size size=10 type=text value= / input class=textType id=form.max_size name=form.max_size size=10 type=text value= / input class=textType id=form.now name=form.now size=20 type=text value=2002-12-02 12:30:00 / Got: input class=textType id=form.identifier name=form.identifier size=10 type=text value= / input class=textType id=form.name name=form.name size=20 type=text value= / input class=textType id=form.min_size name=form.min_size size=10 type=text value= / input class=textType id=form.max_size name=form.max_size size=10 type=text value= / input class=textType id=form.now name=form.now size=20 type=text value=2002 12 2 12:30:00 / not onlyt that, but I don't believe that '2002 12 2 12:30:00' is a valid date representation in *any* standard locale. The dashes-with-leading-zeros should be the default (it is the stock ISO date format). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEoE23+gerLs4ltQ4RAj8JAJ0WzmZFOqNm1Fi2wRuOiGSIR3DwiACfXvEB BeY9EW5FqiOAAiRpXJlmWwo= =KV4D -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.testbrowser too trigger-happy with urlencodes?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
Hi,
I've got a situation where a form submit will eventually end up in an
action that does (in Zope 2):
context.REQUEST.RESPONSE.redirect('/path/to/foo/#bar')
This works fine through the web, but using zope.testbrowser, the # gets
converted to %23 (which is the correct urlencoding of #). The url
/pat/to/foo/%23bar is not valid, and I get a 404.
I couldn't work out where this was being handled in zope.testbrowser, so
and I guess it may be mechanize or some other library's fault, but I'd
like to know if (a) it's a bug and (b) how I may work around it; save
for that, I have one monster of a functional test now exercising a
pretty complex set of forms and views - and a tutorial on how I did it :)
Note that the fragment identifier is *never* going to be passed to the
server by a real browser: instead, the browser strips of the fragment
part, submits the remainder of the URL to the server, and then does a
search for the appropriate 'a name=bar' element *on the client side*.
I'm not sure how this is pertinent to the problem you have found, but
Zope will never traverse '#bar' or '%23bar' in the real world.
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEoHYj+gerLs4ltQ4RAmVbAJ0dvGvRS6/ayBbVyTXcJvR5ir0G5wCbBMEt
LyhGnkFCTbSztdHEGTF1dKM=
=iOB4
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: SVN: Zope3/trunk/src/zope/exceptions/ Cosmetic bugfix for the exception formatter: it used to double the newlines
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marius Gedminas wrote: Log message for revision 68413: Cosmetic bugfix for the exception formatter: it used to double the newlines in exception messages (e.g. SyntaxError exceptions). Could this tiny little change be snuck into the upcoming 3.3 release? Pretty pretty please with sugar on top? +1. I'm not even sure why you're asking. ;) Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEfd1y+gerLs4ltQ4RAoJZAKC9965Ee7i5KdKN1w7LhTKzpyzZ1gCeMFIt OQuS/2/IgZBGkExIx9NSlHw= =lRav -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: time schema field?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Rocky Burt wrote: Hi all, I was just curious why zope.schema has fields for datetime.datetime, datetime.date, and datetime.timedelta but no field for datetime.time. I have a need for such a field right now and I think it'd be useful to be core to zope.schema rather than me create my own field. Would anyone mind if I added this to the zope3.3 branch and trunk? It'd be a very small thing. +1 to the trunk Or perhaps I'm too late (feature-freeze) to add it to the zope3.3 branch? -1 to 3.3 branch. Since we already have had a beta release, 3.3 should be considered in feature-freeze. You could easily construe the omission of the 'time' field type as a bug; adding it is near zero-risk, as well. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEcdk2+gerLs4ltQ4RAu7wAJ9FIe41wF9Eyl8Mxwf1F1y9tq2bXQCdFfvk qAQOleo+ah5XRbSYk+5V1KY= =o5tC -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Google SoC Project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: snip The second approach is to reduce the ZCML processing time, which could be integrated into the reload mechanism for Zope 2. This can be accomplished by storing some binary representation of the ZCML, similarly to ``*.pyc`` files in Python. Again there are several choices to consider and they should probably all be tried. The first solution would be to store a pickle of each parsed directive, namely the action and its arguments. There would be one pickle file fore each ZCML file. When the ZCML file changed, the pickle would be updated. Pickle loading would be much faster than pure ZCML loading, since no XML-parsing, value conversion and schema validation would be necessary. Note that this will require a refactoring of ZCML handlers to define picklable actions. This will also require refactoring so that work now done by handlers be defered to action execution. As I explained to Jim on IRC, I am not proposing pickling the configuration actions, but the configuration handler callable and its arguments. For functions, this is trivial to do. For complex directives that use classes this is a little bit harder, but not much. We will still have the benefit of saving value conversion and validation, as well as XML parsing (though I am not sure whether pickle parsing is faster). The approach is also much safer, since it does not depend on the subtleties of directives, which is good. Not only are actions often unpickable, but some directives also do not generate actions, but do their work directly; this is due to some bootstrap issues. An approach pickling actions would miss those registrations. The more I think about this, the more I believe this is the right approach. - -1. This fact is a wart on the current system: it means that it is currently impossible to *parse* the ZCML file without allowing any directive make arbitrary changes to the interpreter state. Directives should *never* do more than register actions. We can remove all these issues that I know of if we make the dotted-name checker less eager: rather than performing the check inline, during parsing, it should record the name, plus file and line number, for checking only after the actions have been run. At that point, all actions should be trivially picklable, and we get the bonus of being able to introspect the ZCML without actually executing it. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEZKJn+gerLs4ltQ4RAsq1AKCTKxCxvY2pGpMoDAOi5hVr3tz50QCeLyow kZneakUDzgu9jmo8IZXkME8= =UGZM -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Google SoC Project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: whit wrote: Adam Groszer wrote: I personally am tired of restarting z3 each time I made an error even if it is just one char mistype. I'm doing now a wx based app, and the problem is the same... made an error, restart, click 10 times... It would be also a way to have a developer version which might run slower. amen... In the plone community, we have several influential developers who don't use z3 tech I suspect because developing with pythonscript is *still faster* than writing views and adapters because one doesn't have to reload to see minor code changes. also, in z2 land, refreshing a product loses all the related z3 registrations. being able to dynamically reload without restart would be a huge fricking win. I guess we need to make this a priority for the next release. Python simply does not support a general robust reload, other than restart. I think that there are 2 ways we can make progress in this area: - Speed up restart. I think there are a lot of ways that restarts can be made faster: o Optimizae what we're doing now. I suspect that there are some opportunuties here. o Load less. A Zope 3 application that only loads what it actually uses will load much more quickly than a full Zope 3 checkout. The Zope 3 checkout has as much as it does to provide a way to test a range of applications when we modify Zope 3. We need to have a better way of solving this problem without such a bloated checkout configuration. Also, we need to make progress with packaging, to make it easier for people to get just the components they need. I wanted to switch to eggs for the 3.3 release, but, sadly, there wasn't enough time. I think switching to package-based distributions and installation should be a top priority for 3.4. Finally, there's a lot of interest in generating configuration actions in Python, rather than ZCML. I suspect that avoiding XML processing, conversion, and validation might speed startup quite a bit. If we modified the validation to defer checking things like dotted name resolution until *after* all files have been parsed, then we could make it a requirement that configuration handlers have *no* side effects; at that point, we could save a pickle of the actions list, and restart by loading the pickle instead of parsing. We would need to remember things like file name and line number for the dotted name references, so that we could report them property in the deferred check (after all actions have run). - Look at opprtunities for limited robust reload. Perhaps we could define reloadable modules, especially for defining adapters, with restrictions on their definitions and exports in a way that allows robust reload. This would probably be based on the persistent-module experiments. This is a fair bit of deep work though and I'm not sure who has the interest and ability to make it happen. I'm really not interested in a reload faclity, like the one commonly used in Zope 2, that is not robust. I've wasted too many hours helping people debug problems that were caused by reload misshaps. Amen. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEYLZ9+gerLs4ltQ4RApytAJ0fi8XBcnlt3aR5mM1L9MgdGSZ3DACgtGSj igZb17loQ69PYA8be5KR3jg= =CGBI -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope-3.2.1.tgz Zope version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yoshito Komatsu wrote: Hello, Zope-3.2.1.tgz does not have the version.txt in src/zope/app, so Zope version is set to Development/Unknown in zopeversion.py. Though I think that it is not so serious problem, we should update the tar ball or leave it? Leave it. If need be, we could release a 3.2.1.1 with the fix. If we replace it, people have no way of knowing whether the version they got has the fix or not, without peeking inside the tarball itself. This is a general release management principle: we have been guilty of violating it several times in tha past. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEUkbJ+gerLs4ltQ4RAtHfAJ4jsQ7fkuBtcyhc7fHuAqmGKnNHmwCfQItd nyXvyLvuQslx88GhhudHm/I= =neWA -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: ClientStorage vs DemoStorage broken in Zope 3.2?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: Hi, I'm preparing a presentation and marketing campaign for Zope 3 for the next weeks linux fair in here in Germany. I'm demonstrating a couple of things and was trying to use DemoStorage with ClientStorage on a Zope 3.2 server today. However, it didn't work and crashed with this message and traceback (partially given): File /home/ctheune/Development/Zope-3.2/src/ZODB/DemoStorage.py, line 94, in __init__ BaseStorage.__init__(self, name, base) File /home/ctheune/Development/Zope-3.2/src/ZODB/BaseStorage.py, line 108, in __init__ self._oid = base._oid AttributeError: 'ClientStorage' object has no attribute '_oid' Is this something that - should not be broken - should be fixed - is known ? I'd fix it if someone gave me a quick hint on what is wrong. Smells like a fix didn't get forward-ported somehow -- that looks like the same error I helped Tim find and fix for Zope 2. CC'ing the ZODB list just in case anyone there has a better memory. Here is the NEWS.txt entry for that fix: DemoStorage --- - (3.4a4) Appropriate implementations of the storage API's ``registerDB()`` and ``new_oid()`` methods were added, delegating to the base storage. This was needed to support wrapping a ZEO client storage as a ``DemoStorage`` base storage, as some new Zope tests want to do. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFETu39+gerLs4ltQ4RAtGBAJ0Thb6eJPegItQr9HDHvtskfXsIJwCfSgRM 0V1ma6vIS67f/Osxko7wkNc= =9S/w -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Update: The browser:page compromise
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
Florent Guillaume wrote:
Philipp von Weitershausen wrote:
If people don't like the 'browser2' prefix, I'm open to other
suggestions. For all I care, the three directives I suggested could
be on the 'browser' namespace, only browser2:page and browser:page
clash. So perhaps browser2:page should be named something else. I
can't seem to come up with good alternatives, though.
I haven't looked closely, but can't we have one browser:page whose
behaviour changes according to what attributes it has? If old
attributes are provided, a deprecation message is sent but the old
code is used. Otherwise the new behaviour is in effect.
Heh, of course. In fact, that was my original idea, but Tres Co.
objected to it (changing browser:page in-place instead of creating a new
directive).
There is no particular reason to have the new directives in the same
namespace as the old ones, but note that the convenience prefix
('browser' vs. 'browser2') is strictly up to the author of the ZCML
file, and not up to the directive author.
Changing the namespace declration at the top of that file would be a
sign that one had adopted the new semantics, which seems like a good
gesture to me.
If we don't adopt a new namespace, perhaps 'browser:published'would
serve as a 'nominalized adjective noun form of 'browser:publish'.
In any case, I would argue for having the new directives deployed as
alternatives for at least a release *before* we talk about deprecating
the old ones.
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFETPPr+gerLs4ltQ4RAlVrAJ9oc7be5KfBUJE18IkHd02kwDM3rQCgssxu
IMcJnwDkvchb7Wj13Fft84M=
=CX7u
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [z3-five] Re: Patch for testbrowser.py
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Winkler wrote: On Fri, Apr 21, 2006 at 04:07:43PM +0200, Daniel Nouri wrote: The relevant code in Zope2's ZPublisher.HTTPResponse.__str__: # ... we just built a headersl list using self.heders if self.cookies: headersl = headersl+self._cookie_list() headersl[len(headersl):] = [self.accumulated_headers, body] return '\n'.join(headersl) Maybe this can shed some light on whether we want to include that patch. As an aside: What's with assigning to headersl[len(headersl):] instead of calling headersl.extend(...)? I've seen this idiom a couple of times and I always wonder why, it's much less readable IMO. I doubt it's supposed to be an optimization, since this code runs only once per request; anyway, the two idioms are about equivalent in speed AFAICT. If it were in a performance-sensitive loop, a bit faster and still quite readable would be: headersl += [self.accumulated_headers, body] timeit confirms this, here on python 2.4.2: I think this may be a fossil from a much earlier version of Python, in which 'list.extend' had undesirable performance (the new one is O(1)-amortized, I think). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFESVJ5+gerLs4ltQ4RAlseAKDVL5ABbRYGSzNtaLUVeu37WPTBCwCfW9pp c1gst1YN+xssxW2ZFhHWt88= =bcvP -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
http://dev.zope.org/Zope3/TheBrowserPageCompromise
I've long been thinking about how to make browser:page / simpler and
less magical. Some radical ideas weren't received well and I couldn't
convince even myself 100% that they were the way to go. Other
brainstormings were dead ends.
I therefore call this proposal a compromise. It simplifies, but it
shouldn't annoy (Tres...). Note that I'm specifically only addressing
browser:page /, not browser:view /; nor am I coming up with a
framework for dealing with forms and their handlers (Jeff...).
'Nuff said. Your turn :)
- -1 on breaking ZCML in the wild. Propose *new* directives which have
new semantics, but for existing directives, we should clean up the
implementation rather than modifying semantics. E.g., we should be able
to rip out the gunk which synthesizes new classes in 'browser:page': I
think it derives from a period before we could assign a
'__Security_checker__' attribute to instances, and so *had* to have a
class in order to make the checker stuff work.
Here is an example from my 'pushpage' product, which has a directive for
registering pages using filesystem templates::
class PushPageFactory:
def __init__(self, template, mapper, checker=None):
if getattr(template, 'read', None) is not None:
template = template.read()
self.template = PushPageTemplate()
self.template.write(template)
self.mapper = mapper
self.checker = checker
def __call__(self, context, request):
page = PushPage(context, request, self.template, self.mapper)
if self.checker is not None:
page.__Security_checker__ = self.checker
return page
The directive handler instantiates the factory::
def pushpageViewDirective(_context,
for_,
name,
permission,
template,
mapping,
layer=IDefaultBrowserLayer,
):
Create and register factory for pushpage-driven views.
if for_ is not None:
_context.action(
discriminator = None,
callable = provideInterface,
args = ('', for_)
)
if permission == 'zope.Public':
permission = CheckerPublic
template = os.path.abspath(str(_context.path(template)))
if not os.path.isfile(template):
raise ConfigurationError(No such file, template)
required = {'__call__': permission,
'__getitem__': permission,
'browserDefault': permission,
'publishTraverse': permission,
}
checker = Checker(required)
factory = PushPageFactory(open(template, 'r'), mapping, checker)
_context.action(
discriminator = ('view', for_, name, IBrowserRequest, layer),
callable = handler,
args = ('provideAdapter',
(for_, layer), Interface, name, factory,
_context.info),
)
Note this implementation does not require majyk classes -- the factory
instances here function in place of the synthesize classes.
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFER8KA+gerLs4ltQ4RAh0kAJ9vvKtqAcPfZh0+2ujqpJefWGgsFQCeNzhi
r8E8Ewhpv/aJdP0t20vpZok=
=Z27s
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
Tres Seaver wrote:
- Introducing new deprecation warnings in third-dot releases is
probably inappropriate:
When we have we done this?
2.9.1 just did it (see below).
- Deprecating an API without cleaning up *all* core uses is a *lie*;
In some of the few cases where this happened was oversight and not
intentional. When you deprecate something, none of the core should still
use it. I think that's pretty clear.
Zope 2.9.0 shipped deprecating the OFS.content_types module without
removing all uses (I cleaned that up back in January).
Zope 2.9.1 deprecated zLOG without removing all uses: testrunner output
is *still* littered with deprecation warnings for zLOG. As far as I'm
concerned, that means 'zLOG' is *not* deprecated in the 2.9.x release
line, and may not therefore be ripped out unitl the appropriate interval
*after* 2.10 (i.e., in 2.12, not 2.11).
- Deprectaion of an older, stable alternative, *no matter how grotty,*
should go hand in hand with *lots* of confidence that the new favored
alternative really is superior, and by enough margin to make the
switch worthwhile. In my mind, this means that the new
implementation needs to be rolled out *in production* and tested in
the wild *before* we can deprecate the older alternative.
I think that's a big burden for refactorings. Under such a rule, Jim
wouldn't be allowed to roll out neither his adapter registry
improvements nor his Component Architecture simplification.
Refactorings *need* a bigger burden than we have recently been imposing:
- Doing a refactoring right means adding BBB code, which itself
increases the maintenance burden for core developers.
- As an example, the twisted server became the *default* in Zope 3.2
in spite of the fact that it broke ZEO because the developer who
landed the change doesn't use ZEO, and hence missed seeing the
damage.
- The packaging changes introduced in the 2.9 release cycle broke
usecases which many developers care about ('make inplace' is broken,
instance home testing broke, etc.) Worse, and ironically, the
breakage was incurred on behalf of 'zpkg', which is itself slated
(now) to be deprecated.
- Jim's current changes will most likely land for 2.10. If we don't
spend enough time in the beta cycle with them, we may be seeing
similar effects, or may need to be prepared to un-deprecate some
of the stuff currently on the doomed list.
We're not refactoring mercilessly. We're thinking about problems,
writing proposals, measuring risks, providing BBB and writing tests.
We'll have to trust our tests to a certain degree. If we don't then
perhaps we need more tests. We surely could use more functional tests.
I'll be fine with creating new directives instead of changing the old
ones, if that's what the majority prefers. But then I'd very much like
to see a Death Certificate for the old directives made out for some time
in the future (doesn't have to be 2 releases, could be more).
I don't think we are going to come to consensus about the appropirate
standard set of directives anytime soon: the current state of the
debate reminds me eerily of the lumbers vs splitters rift in the
world of paleoanthropology[1], which has been unresolved for more than a
generation now.
I stand by my claim that the reductionist strain in our current debate
is backed by developers who *also* admin the systems they have deployed,
and that this sample is not representative of the audience to whome Zope
is pitched.
[1] http://www.mos.org/evolution/downloads/desilva.html
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFER/Gj+gerLs4ltQ4RAu16AKDBkOGl3aoBIAVBQwUciAMwxRsUeQCfXv8u
7/D6eKGh5DO0uqJyvC5U1hU=
=tS58
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
Tres Seaver wrote:
- Deprectaion of an older, stable alternative, *no matter how grotty,*
should go hand in hand with *lots* of confidence that the new favored
alternative really is superior, and by enough margin to make the
switch worthwhile. In my mind, this means that the new
implementation needs to be rolled out *in production* and tested in
the wild *before* we can deprecate the older alternative.
I think that's a big burden for refactorings. Under such a rule, Jim
wouldn't be allowed to roll out neither his adapter registry
improvements nor his Component Architecture simplification.
Refactorings *need* a bigger burden than we have recently been imposing:
- Doing a refactoring right means adding BBB code, which itself
increases the maintenance burden for core developers.
- As an example, the twisted server became the *default* in Zope 3.2
in spite of the fact that it broke ZEO because the developer who
landed the change doesn't use ZEO, and hence missed seeing the
damage.
I guess we didn't have enough tests. Now we have a test that exercises
ZEO. Plus, we dealt with this problem before any final release (perhaps
even before the beta?). That's what alpha and beta phases are for...
My point here is that the 'refactor mercilessly meme has left people
feeling free to make chnages of debatable value (Twisted is *still* not
accepted in the Zope community as a superiour choice for publishing
HTTP), without full weight being given to the needs of folks who aren't
up to their elbows in the code every day.
- The packaging changes introduced in the 2.9 release cycle broke
usecases which many developers care about ('make inplace' is broken,
instance home testing broke, etc.) Worse, and ironically, the
breakage was incurred on behalf of 'zpkg', which is itself slated
(now) to be deprecated.
Forgive me if I'm a little rough on this subject, but here it goes:
I've had it with this whining about make inplace etc. It's been nearly
half a year since 2.9 is out and nobody has even made the attempt to fix
this so I guess nobody really needed it. Yet there's still whining. Yes,
I'm to blame for bringing zpkg to Zope 2 because the Zope 3.2 build
process strongly suggested it. If there were alternatives to zpkg,
nobody has suggested them and nobody seems to have explored them so far.
All I know is that everyone wanted Zope 3.2 in Zope 2.9 which is what
they got.
Zope 3 is a *library* for Zope 2 -- I don't see any necessary reason to
have Zope 3's packaging model drive Zope 2's. What I recall about this
discussion was the following:
- There was distaste in the Zope 3 world for the carefully
hand-maintained code which made Zope 2's 'configure make make
install/inplace' dance work
- Jim proposed ripping it out in Zope 3 in favor of the generate
everything via zpkg' dance.
- In order to move toward the Zope 3 way, you proposed doing the
same for Zope 2.9.
- Immediately after you landed the change, folks began to point out
issues with it
o in-place builds were broken (the 'bin' directory was not created)
o out-of-tree builds broken (e.g.:
$ sudo mkdir /opt/zope29
$ sudo chown tseaver:root /opt/zope29
$ cd /opt/zope29
$ /path/to/zope29/checkout/configure make make inplace
o 'make instance' and 'mkzopeinstance' producing borked instances,
(since fixed for 2.9, but still broken in Zope 3)
- We stayed the course, and *today* are still stuck with a 2.9 branch
which *cannot be used* as the 2.8 branch was in a checkout. The
problem appears to be intractable, as the changes needed to make
'zpkg' work completely invalidated all our former experience and
knowledge of how to use a checkout tree.
Effectively, the only folks who can maintain the 'zpkg'-centric
build don't care about these usecases, and so we are stuck.
- Not only that, but we did it to support 'zpkg', which has proved to
be a failed experiment, even for packaging Zope 3. For instance,
at this point, a Zope 3.2 checkout tree can be uesd to do only:
o Run the unit tests.
o Generate a release distribution.
It cannot be used as the basis for running developer sandboxes, at
least not without major hacking of the generated instances. Here is
a sample:
$ svn co $ZSVN/Zope3/branches/3.2 Zope-3_2-branch
...
$ cd Zope-3_2-branch
$ /path/to/python setup.py build_ext -i
...
$ /path/to/python utiltiies/mkzopeinstance.py -d /tmp/z32
...
$ cd /tmp/z32
$ bin/zopectl fg
...
ConfigurationError: ('Unknown directive',\
u'http://namespaces.zope.org/zope', u'role')
I don't think this is a useful place for us to be in Zope 3, and I
*don't* want to emulate Zope 3 in this direction in Zope 2. I would
in fact
Re: [Zope3-dev] Re: 64-bit BTrees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: Previously Chris Withers wrote: The implicit change to make them all 64-bits which results in some unknown slowdown for all I BTree users seems a bit too scary to bite off... Has anyone done any benchmarks to prove that 64-bits is slower or faster? It would be interesting to see benchmarks on modern 32bit and a 64bit systems. Until then it's all hand-waiving. Sure, but the burden of proof needs to be on the party proposing the cnange. First, do no harm is a good principle in such cases. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFERpCv+gerLs4ltQ4RAuoIAJ9fKveUfI54DtYWnD9pWDudhqf5LACgmZu1 GFD9FgvQDR9BdvIyTpIm2tI= =QgmO -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: 64-bit BTrees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Drake wrote: I have a need for 64-bit BTrees (at least for IOBTree and OIBTree), and I'm not the first. I've created a feature development branch for this, and checked in my initial implementation. I've modified the existing code to use PY_LONG_LONG instead of int for the key and/or value type; there's no longer a 32-bit version in the modified code. Any Python int or long that can fit in 64 bits is accepted; ValueError is raised for values that require 65 bits (or more). Keys and values that can be reported as Python ints are, and longs are only returned when the value cannot be converted to a Python int. This can have a substantial effect on memory consumption, since keys and/or values now take twice the space. There may be performance issues as well, but those have not been tested. There are new unit tests, but more are likely needed. If you're interested in getting the code from Subversion, it's available at: svn://svn.zope.org/repos/main/ZODB/branches/fdrake-64bits/ Ideally, this or some variation on this could be folded back into the main development for ZODB. If this is objectionable, making 64-bit btrees available would require introducing new versions of the btrees (possibly named LLBTree, LOBTree, and OLBTree). I think coming up with new types is the only reasonable thing to do, given the prevalence of persistent BTrees out in the wild. Changing the runtime behavior (footprint, performance) of those objects is probably not something which most users are going to want, at least not without carefully considering the implications. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEPpyu+gerLs4ltQ4RAmh1AJ9/dLigNMrQgIFNASKWbpvboapywwCePV22 /3d8kFGTjipAVCsy5fnuLa4= =xe6v -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Insufficient Privileges when adding a patch in the collector
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bjorn Tillenius wrote: I tried to add a patch to a bug in the collector, but I was presented with a page saying that I don't have sufficient privileges to view this page. Do I need some special privileges to attach a file to an issue? For issues created by others, you need either to ba a supporter for the collector, or else have the Owner local role granted. I just made you an Owner of the Z3-dev issue 448; if you would prefer to be a suppoerter (you will get e-mail about all issue traffic in the collector, in that case), please let me know. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEPQxr+gerLs4ltQ4RAkGUAJ9W0v86oT8C7Wz3X10xOgwTCUUWvACffne2 OzvDuVV0gsL7/9BXHXSr1wQ= =Bug1 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: eggifying zc.resourcelibrary, zc.table and others
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Gary Poster wrote: [snip] Apologies for the confusion, Martijn. I checked with Jim. The procedure that Tres described is only for people who have direct access to the machine. The intended use is similar to the following: $ touch gary_test.txt $ scp gary_test.txt [EMAIL PROTECTED]:/distribution/ gary_test.txt 100%0 0.0KB/s 00:00 That appears to have worked! Thanks! Now somebody needs to remove the martijn_test.txt again, unless scp has file removal capabilities I don't know about. :) Done. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFENPbA+gerLs4ltQ4RAjR2AKDBGRc2b2Rkv5sI+EmPeTMZbecqiQCglq2r IwFGz0GQ2IszgDI6MGHZHG4= =rCZs -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: eggifying zc.resourcelibrary, zc.table and others
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
* the setup.py I'll create will only work with setuptools installed;
is this a problem?
Not from us. You'd maybe get even more warm fuzzies from people by
making it not require setuptools, but that limitation doesn't bother us.
Okay, good. Warm fuzzies are nice, but I won't worry too much about that.
There is some support for kickstarting an eggifying project. E.g.:
$ export ZSVN=svn+ssh://svn.zope.org/repos/main
$ svn cp -m Eggify $ZSVN/productsupport/trunk/project-template \
$ZSVN/zope.foopackage
The top-level 'zope.foopackage' will have a skeleton 'trunk', plus empty
'branches' and 'tags':
$ svn co $ZSVN/zope.foopackage/trunk zope.foopackage-trunk
$ cd zope.foopackage-trunk
$ ls -1
CHANGES.txt
develop.py
INSTALL.txt
README.txt
setup.cfg.in
setup.py
src
test.py
workspace
The text files are templates, and should be edited to fit.
The 'develop.py' script will set up a local 'bin' and 'lib' directory
inside your checkout, and try to install dependencies as specified in
'setup.py' and 'setup.cfg' (which it copies from 'setup.cfg.in'). It
also jams the Zope egg URL into 'setup.cfg'.
I usually run 'setup.py develop' afterwards, as it is better at
finding all the dependencies:
$ PYTHONPATH=lib /path/to/your/python setup.py develop
The 'zope.testing' package is supposed to be pulled in during that
bootstrapping, but often seems missed (I haven't yet figured out
why). Running the local 'easy_install' does the trick:
$ PYTHONPATH=lib /path/to/your/python bin/easy_install \
zope.testing
The 'src/zope' directory is intended to contain a 'svn:externals'
pointer to the canonical location of the source (we may eventually
reverse this, and make the main Zope tree point out at the top-level
package directories). E.g.
$ svn propedit svn:externals src/zope
#... add your external here
$ svn up
# ... fetches your external.
That 'src/zope' directory also contains setuptools / pkgutil
boilerplat namespace __init__.py:
$ cat src/zope/__init__.py
# namespace package boilerplate
try:
__import__('pkg_resources').declare_namespace(__name__)
except ImportError, e:
from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)
The 'test.py' needs to be edited to point to your package. At that
point, you should have all your package's dependencies installed
(assuming that you named them in 'setup.py'), and should be able to run
the tests using your local eggs:
$ PYTHONPATH=lib /path/to/your/python test.py
Nathan, Jim, please correct any mistakes you see.
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFEM7tX+gerLs4ltQ4RArrjAJ9GAW9klbLC9n4ZUdcmbvvsrSDQCgCgsz+l
SojySIyJZEGgMVercdKH8Uk=
=FdIS
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Checkins] SVN: Zope3/trunk/src/zope/app/form/browser/itemswidgets.py The label for the list items widgets could not point to the field, because
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Poster wrote: On Apr 5, 2006, at 4:14 PM, Kamal Gill wrote: Hmm, I'm inclined to doubt whether IE expects the id and name attributes to be identical. Distinct values for id and name shouldn't be a problem, afaik Wait, someone used shouldn't be a problem in reference to IE? :-) As Benji said, this isn't idle: we've encountered some pain that makes me bring this up. A quick Google search didn't come up with any confirmation, though, so, without further backup, I'm happy to let this lie. I'm pretty sure that at least some flavors of IE were fussy about 'id' attributes which were not valid according the HTML DTD's; I therefore quit giving form fields an 'id' attribute long ago, just because I couldn't keep it straight. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFENFJc+gerLs4ltQ4RApmfAKCFRB3tvLCbNXRarJ96hoxeGTCvagCeOHTc /GpIl9O6n4uAbJ7r5HDMeLo= =jcyG -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: eggifying zc.resourcelibrary, zc.table and others
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Poster wrote: On Apr 4, 2006, at 12:38 PM, Martijn Faassen wrote: Hi there, * does anyone have any objections if I make eggs for various zc.* packages? In svn, this involves adding a setup.py to these packages, and to add a __init__.py to the zc package that they contain (which contains some egg-specific stuff). Sounds great! (I assume the __init__ changes won't cause problems without setuptools around). There is supposed to be a dance in Python itself for declaring a namespace package. Framkly, anybody who wants to play along *without* setuptools installed has rocks in their heads: distutils is too wanky to use by itself for complicated cases, and setuptools makes it just barely tolerable. Jim points out that Nathan Yergler has a script that can generate eggs from zpkg data; you might or might not find that to be easier. It's less of an obvious win with these packages that have little or no zpkg metadata already, but it might still be quicker in some cases (no idea myself). * the setup.py I'll create will only work with setuptools installed; is this a problem? Not from us. You'd maybe get even more warm fuzzies from people by making it not require setuptools, but that limitation doesn't bother us. * what email address should I list for the author of some zc package? this is information that will appear in the cheeseshop. zope3-dev@zope.org * to get the full egg experience, I'd like to have them uploaded to the cheeseshop. I could do this myself, but they're not my packages. Can I? or does someone else want to do this? I'll of course gladly give admin rights for these packages to the real creators. Jim also suggests the new, as-of-this-moment-no-longer-secret http:// download.zope.org/distribution/ as a possible location instead. All Zope committers have the appropriate privileges to scp to this directory. That's where he will be doing his egg work, at least until he thinks we have figured out the best way to make Zope eggs. It can be used a setuptools source. Note that I am actively working in that directory on eggifying a number of the top-level zope packages in released verisons (typically in the flavors which shipped with ZopeX3.0.0 and Zope3.2). If you want to use the cheeseshop anyway, that's ok too. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEMsG5+gerLs4ltQ4RAq4rAKDCwrsDs/nmkJVv7ASzuhLsa81LOQCeIt6/ mBewTTCRqCgcK5EjiAO039U= =GITX -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope-CMF] Fighting the Zope 2.9 testrunner
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Chris Withers wrote: Jens Vagelpohl wrote: From the old testrunner, which I miss *a lot*, I could ensure I am indeed running a specific module by doing... Yup, this is one of the things I like least from the Zope 3 world. What happened to proposals and community agreement before inflicting big changes on other people who're trying to help out? Oh cut the crap. The new test runner tries very hard to be backward compatible. The old test runner was increasingly unmaintaiable and had a host of bugs of it's own. I can't tell what you snipped, but I'm guessing that it was the breakage of supplying a module name as a positional argument. This breakage was not intentional. It was a bug. There is an easy work around: just use the -m option. I particularly hate the fact that no real effort was put into backwards compatibility, not to mention those silly weird sort-of-fifty-dots-per-line thing that doesn't actually work. I'm not sure what Chris meant, but the change to the visual output of the testrunner when running with dots seems gratuitous to me, as well - -- I don't see any benefit to the indented, narrower output, especially because it's prettiness gets fouled up anyway by deprecation warnings, etc. I objected to the change enough to file collector issues: http://www.zope.org/Collectors/Zope/1958 http://www.zope.org/Collectors/Zope3-dev/493 What the heck are you talking about? What doesn't work? Zope 2.9 broke the 'confiugre-make' dance in several ways, due (I think) to the choice to bolt on^H^H^H^H^H^H^Hretrofit zpkg. E.g.: $ cd /tmp $ svn co svn+ssh://svn.zope.org/repos/main/Zope/trunk zt $ cd zt $ ./configure --prefix=/tmp/zt-sw make make install ... running install_scripts error: cannot copy tree 'build/scripts-2.4': not a directory make: *** [install] Error 1 $ make clobber inplace ... $ ls -laF bin ls: bin: No such file or directory (The 'bin' directory was, in Zope 2.7, 2.8, the location for the scripts, created during an inplace build). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEH/jP+gerLs4ltQ4RAhlOAKDBNhLZNaLvUn9bHOTBiIjBz2CYLQCeI6gp WD21iz7SSHQfCTOd0PxT22s= =k4TY -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: a plan for widgets?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Shell wrote: On 3/20/06, Tres Seaver [EMAIL PROTECTED] wrote: So *don't use ZCML*; use Python: there is literally nothing which can be done in ZCML which cannot be done in Python. I wish that folks who don't like / need ZCML would quit trying to dictate how the rest of us use ZCML. Literally nothing? Try literally everything. I'm sorry. But that was the experience I had that set me in such a bad temperament. I had no idea what half of these directives were doing, and when trying to duplicate them in a test environment I nearly threw the laptop to the ground and swore of programming forever. I was *INCREDIBLY* frustrated. There is a lot of potentially valuable functionality *hidden behind ZCML*. If a ZCML directive were a one line wrapper/adapter around a common function, I'd feel different. If a directive is too magical for you, and you don't mind writing Python, then *don't use it*. Consider the following: browser:page name=myview.html for=ISomeInterface permission=zope.Public template=templates/myview.pt / If you consider what it does (register a view which uses a filesystem-based template) rather than how it does it (i.e., synthesize a new class for use as a view factory and bind a template to it). If you don't like the implementation, and don't mind the boilerplate, then why not write: class MyView(object): index = zope.pagetemplate.pagetemplatefile.PageTemplateFile( 'templates/myview.pt') def __init__(self, context, request): self.context, self.request = context, request def __call__(self, *args, **kw): return self.index(*args, **kw) zope.security.checker.defineChecker(MyView, zope.security.checker.CheckerPublic) zope.component.provideAdapter( (ISomeInterface, zope.publisher.interfaces.browser.IBrowserRequest), MyView, 'myview.html') Note that I am *not* arguing in favor if the current implementation of browser:view / browser:page; in fact, I think it is needlessly complex. But I am strongly against the idea of tossing the directive on that account, and thereby breaking deployed applications. My argument and wish has been only this: simplify ZCML. Make it more transparent what it is doing. There is a classic tension here between convenience and purity. Please recall the many of the directives in ZCML were *added* because people got tired of typing repetitious boilerplate (imagine the Python code above repeated *dozens* of times in a given application). Or, if you like ZCML but don't like the current directive set, feel free to propose a new set of directives you think are better, and implment them in *your* namespace: if enough other people like them, we can talk about making people who are already using the current set change. But let's quit tearing up what people have alredy learned in favor of a it-must-be-better-because-its-new variant which doesn't yet exist, and whose improved usability we have to take on faith. My set of directives is adapter, utility, class, and maybe interface. Inside of class, requires, allows, implements, and factory (because I do believe that 'factory' there is a nice shortcut). So just use those. But *don't* argue that the rest of us mustn't define or use more convenient directives. Nothing new. Only less. Less concepts to have to remember. Less concepts to have to look up. Less code to have to try to follow when it's 10:30 at night and I've been working six hours too long and I still can't figure out why my field adapter on an IChoice isn't getting its value set properly and I can't get a vocabulary bootstrapped up to write a test to debug and then verify the fix of it. Make ZCML do whatever you want. But if you're going to share it, it needs a HELLUVA lot better documentation. I'm glad for what's there now. But I've been surprised by ZCML one time too many, and have lost too many hours trying to figure out the surprise. Too many similar directives, too many possible attribute combinations, and too little information about what certain choices will actually do or what they're good for. And the source is not a readable, reliable backup point to look at. I'll note that the Refactor mercilessly meme from XP is *not* particularly well-suited to frameworks / libraries: it is best suited when applied to *applications*, where the impacts of such changes are borne entirely by the people who make them. When you tear up the API of a framework / library, you force *other* people to make changes, often without any particular benefit to them. What is well suited to frameworks and libraries is to provide maximum playability with a minimum number of concepts. When the component architecture was simplified (Zope 3.0 - Zope 3.1), the whole thing suddenly made a whole lot more sense to me. Utilities and Adapters. Nice
[Zope3-dev] Re: Reducing the Amount of ZCML Directives ready for review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Dominik Huber wrote: I really appreciate your effort in all other cases, but in this case I think its not a simplification. At least in case of class/implements it is. I'm merging two directives, class/implements and five:implements into one. The case of class/factory is arguable, I admit. However, there I'm just following the rule of a) defining things in Python and registering them in ZCML and b) use more basic ZCML directives, less special ones. That rule is somewhat debatable (the debate seems ongoing). I think we could argue the following equally well: if you find a directive unuseful, *just don't use it*. Register *new* directives (perhaps in a new namespace, if you want to reuse the names) which do your simpler / cleaner thing. Deprecation is not always a reasonable model, given disagreement about the value of the simplification. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEHrCD+gerLs4ltQ4RAnb7AJ9NyTYi9roHh6IrcyoxqbEeNpuBRgCeLhm3 f6Abhf0JvAOYKZ645Ev7tCQ= =fvkA -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: httpgz in zope.conf?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Washington wrote:
I announced release of httpgz, http://zif.hill-street.net/httpgz on
Zope3-Users this past weekend.
It does very nice things to bandwidth. One particular page (tabular and
very repetitious) went from around 400K to 25K for the client.
MochiKit.js went from 94254 bytes to 24854 bytes. This makes web pages
seem much faster, particularly on slower connections.
I am wondering what the best mechanism for turning this on and off would
be. I suppose it is simple enough to insert and remove the
httpgz-configure.zcml file in etc/package-includes, but is there a place
for third-party hooks in zope.conf? Or would that be a bad idea?
There is a mechanism for registering third party schemas in ZConfig.
Zope2 leverages this support, declaring an abstract section type
('product-config'), which allows products to register custom section
types (they can also just add simple key value pairs). The SVN checkins
which enabled this:
$ svndiff -r 39634:39652 \
svn+ssh://svn.zope.org/repos/main/Zope/branches/2.9
Products define custom section types in a 'component.xml', which must
then be imported into the zope.conf (via '%import') before a section of
that type may be used.
Zope3 could add a similar abstract section type to its top-level schema,
for use by third-party extensions. Such a change would *not* require
settling the config-file-format debate.
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFEHsIA+gerLs4ltQ4RAi3jAKCGCGQjISAsIKgvI9QiyyIHRN2FUQCeM+cZ
wgVKeFv3uwpAF47PYW4D/z8=
=B4lJ
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: a plan for widgets?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Shell wrote: On 3/17/06, Tres Seaver [EMAIL PROTECTED] wrote: Jeff Shell wrote: By the way, isn't it pretty easy to provide straight up values anyways for those quick drop-down situations? snip Python example You're missing the point -- the vocabulary is *not* software, and Python is *completely* the wrong place to define it: it is *pure* policy. THe fact that you are administering all the sites you build blinds you to this fact. My examples move the definition of the vocabulary out into integrator / administrator land, which is where they belong. No. I think they are software. Or can be as much software as anything else. Sometimes I don't care what the values I get for a Choice field are. Sometimes I care very very very much. With the interfaces, vocabularies can come from a lot of sources. Personally, if I were giving someone an editable vocabulary list in text because they were an 'integrator/administrator', I'd write a Vocabulary object that used something like YAML. Or CSV if that's what the user that's meant to maintain it is. But I'm not going to turn over site.zcml or overrides.zcml with all of its other crap just to let a secretary add an airport code to a preferred destinations vocabulary. There's nothing in the Zope 3 implementation stopping you from having the definition come in from outside. But don't restrict me from using Python just to make a bone stupid simple list of values when I have 100% or even 80% surety that it's *not* something that needs to be an editable policy. It's a waste of time, it's another layer of confusion, and as I said above: this is another policy thing that may not even be maintained by any 'administrator/integrator'. So if there was just one concept of a registered Vocabulary: that of a named utility providing the IVocabulary (or a derivative) interface, then it's easy: write one for your integrators/administrators that sources itself from ZCML, OPML, RDF, whatever. I don't need it. For me, it becomes a maintenance nightmare, or just a roadblock early on. So maybe I am blind. But I **absolutely do not need to worry about integrators/administrators**. And I absolutely hate wasting time writing something that hurts me to write and maintain for a role that I, nor my colleagues, nor my customers, really have to play. Maybe you do. But then, you should do like I do and build yourself some frameworks on top of Zope that suit your world, your customers needs, etc, and work through those. Don't make me have to jump through hoops and XML pain just to make a yes/no/maybe option list just because there's this theoretical person out there that might want to add a maybe not after they find it buried deep within the trenches of XML files buried in an Egg. So *don't use ZCML*; use Python: there is literally nothing which can be done in ZCML which cannot be done in Python. I wish that folks who don't like / need ZCML would quit trying to dictate how the rest of us use ZCML. Or, if you like ZCML but don't like the current directive set, feel free to propose a new set of directives you think are better, and implment them in *your* namespace: if enough other people like them, we can talk about making people who are already using the current set change. But let's quit tearing up what people have alredy learned in favor of a it-must-be-better-because-its-new variant which doesn't yet exist, and whose improved usability we have to take on faith. I'll note that the Refactor mercilessly meme from XP is *not* particularly well-suited to frameworks / libraries: it is best suited when applied to *applications*, where the impacts of such changes are borne entirely by the people who make them. When you tear up the API of a framework / library, you force *other* people to make changes, often without any particular benefit to them. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEHvlc+gerLs4ltQ4RAkGoAJwMlUixk+yOo1wLjag8vX394zPRbgCfX8A3 9xtrj5J+Vc4Qcut51Arx3DM= =JGRT -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope Eggs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan R. Yergler wrote: So right now we scribble the development dependencies as well as path (lib, script, etc) information into setup.cfg. The develop.py script reads the dependency information and attempts to install them into the specified lib directories. So it seems to make sense to put things like egg parameters, etc (settings independent of user workspace location) into setup.cfg.in, and then have develop.py populate a setup.cfg at runtime. I think we really do want a setup.cfg that isn't under version control -- storing the path information there makes the easy_install commands somewhat less verbose as you don't have to specify the script and lib locations each time you run. I just committed changes to develop.py that make it examine setup.cfg.in if setup.cfg doesn't exist. So setup.cfg.in can contain any project-specific egg settings and the development time dependencies, and develop.py will use that as a template for setup.cfg. See the zope.interface project for an example of using setup.cfg.in. README.txt in projectsupport has also been updated with some new details of the develop.py process. Great! I just fixed the other eggification packages I had checked out accordingly, including adding setup.cfg to the svn:ignore list. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEHie9+gerLs4ltQ4RAo1NAKC4ksh6q0Mu9daWZv7KkQLB0amstgCgqXgp YCuug6tS1gpFb/1jAm/7wwU= =8lx4 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Internal architecture or ZopeX3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinhold Strobl wrote: Further I'd like to know, what happens to ZPT at runtime. Are they compiled into Python modules? No, they are compiled into bytecodes exceuted by the TAL interpreter, which is invoked when the template is rendered. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEGXYZ+gerLs4ltQ4RAn+7AJ93hl5bvHkgwi4IZdzZQGoemuqMvQCfXsDF xj4Cw0mt6zN+oQQKCbQCEEA= =QEM0 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: a plan for widgets?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: snip * sources and terms are nice, but we should at least provide some basic sources and register some basic terms for them; that bit is completely missing in Zope 3 right now. People should be able to at make a simple drop-down widget happen without having to figure out how to tie all these components together - they should just import and use the right source, perhaps import, use, and register the right term, and there they go. zcml:ktupema_necro_halogo Hmm, another case where high-level ZCML support would be useful: defining simple terms for a vocabulary. Why should somebody who wants to tweak a vocabulary have to edit software? E.g.: vocabulary name=philosophers term id=platoPlato/term term id=aristotleAristotle/term term id=kantImmanuel Kant/term /vocabulary Of course, we could also keep the vocabularies in another data file, and merely have the high-level directive source it: zope:vocabulary name=philosophers file=philosophers.csv / /zcml:ktupema_necro_halogo Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEGZRq+gerLs4ltQ4RAqfjAKCVsLoGMDkvqbZVu7r+lPQzqvu3zwCeKYbS 7TZXr/3VwH64Z/w9jbH20sY= =ZUki -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: a plan for widgets?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Winkler wrote: On Thu, Mar 16, 2006 at 11:38:02AM -0500, Tres Seaver wrote: zcml:ktupema_necro_halogo eh? http://www.google.com/search?hl=enlr=q=ktupema+necro+halogobtnG=Search Your search - ktupema necro halogo - did not match any documents. It is pseudo-Greek from the roots for beating dead horse. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEGZ0k+gerLs4ltQ4RAtVZAKDacf6/4HCAOnZdLMWZavElzXtiKwCdEJqB xFnW72g4IFLA5AGrNZLSI8I= =UQeT -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: what is ZCML?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Martijn Faassen wrote: Shane Hathaway wrote: Jim Fulton wrote: Shane Hathaway wrote: +1. When I learn a skill, it is at first completely explicit, and as the skill becomes predictable and reliable, it gradually becomes implicit. If I kept everything explicit, I would hinder myself from building higher level skills. So explicit is better than implicit until a sufficiently tight abstraction comes about. Take memory management: yesterday it was explicit (malloc/free); today it's mostly implicit (garbage collection). Garbage collection is both an abstraction, since programmers no longer manage memory directly, and an indirection, since programmers now use APIs that call malloc and free. We all agree GC is good, so explicit is definitely not always better than implicit. Thanks for explaining Explicit is better than implicit, except when it's not. Admittedly, I should have posted that in my blog, not here. :-) I appreciated you making it explicit, Shane, even though I already knew and fully agree. :) I sometimes express this principle as magic is bad unless it's perfect magic. Do post it on your blog. Yes, it is a good thing to know, except that it is incomplete and obscures an important point. Magic always has the downside that it hides things. Often, as in the case of garbage collection, the benefit outweighs the cost. Too often though, people introduce magic (aka abstraction, indirection, automation) when the benefit doesn't justify the hiding. One should always approach magic with skepticism. This is an important design principle. The explicit is better than implicit is a guide, not a rule never to be broken. It's something we should start with. Does that mean we never provide automation? Of course not. I wonder if there isn't a sore spot which is driving a lot of the discussion here, but isn't being mentioned: the experiment in form definition (browser:addform / browser:editform). The interesting thing about that experiment is that it *almost* worked, as magic; its failure was not in what it made easier (generating a view from a schema *and* a policy), but in what it made harder (changing the behavior of the generated view). Developers who are the only admins for the sites they deploy are *not* representative of the intended audience for ZCML; they are much more comfortable with back to Python as a solution than more traditional admins / integrators would be. Big directives, with clearly documented knobs for specifying policies, are likely to appeal more to folks sho are *not* inclined to write Python. The fact that such developer-admins are the primary users of ZCML so far is due to the small size of the Zope3 market to date. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEGD5f+gerLs4ltQ4RAnCjAKDb/6AM4phxLZhHnSPH554Ysv8CIwCfRIUo 8+DrkkvhQFQDB8WGCSC70j4= =X/7J -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope Eggs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan R. Yergler wrote: During the Zope3 sprint following PyCon, Paul and I, with Jim's guidance, began work on exploring how Zope can utilize eggs and be packaged using eggs. Since we're still experimenting with how eggs will be used, I wrote a script, zpkgegg, which reads the zpkg configuration information for a package and generates a standard setup.py from which an egg and vanilla sdist can be generated. You can find the script in subversion in the projectsupport project. For a brief overview of how the script is used, see README.txt (in http://svn.zope.org/projectsupport/trunk/src/zpkgegg/). The eggs generated by zpkgegg do not attempt to distinguish between runtime, testing or development dependencies, so almost all packages will want zope.testing. README.txt contains a brief example of how to point easy_install at the appropriate folders so that easy_install can resolve the dependencies. Note that at this point we're still experimenting with how we'll use eggs, so suggestions, feedback and comments are welcome. I've been playing around a lot, trying to get at least the eggs together to make ZPT usable outside of Zope (one of the original sprint goals). I have a couple of observations: 1. Putting 'setup.cfg' under version control sucks, because the 'develop' framework scribbles on it. I think we should do two things: - Move any special settings to a 'setup.cfg.in', and modify the workspace stuff to read that first when creating setup.cfg. - Make 'setup.cfg' a 'svn:ignore' file (at lest on the trunk). Agreed. IMO, we should either not scrible on setuop.cfg or not check it in. I vote for not scribbling on it. I'd rather not check it in, myself. Even if the 'develop.py' helper doesn't scribble, it is a natural place for the developer to scribble. Generating it when needed, and ignoring it for version control, seems healthier to me. Perhaps we should use a different strategy for released packages than trunk ones? 2. Getting the development dependencies installed was harder than it seemed. Some packages (perhaps with help from a stanza in 'setup.cfg') could do that when running 'develop.py'; others needed me to run 'setup.py develop'. Maybe we should just kick off 'setup.py develop' at the end of the 'develop.py' dance? I suspect these are just lingering bugs. One thing I noticed, when I tried a few days ago was that zope.testing had a bogus dependency that made it's installation fail. ... 4. We need to begin creatinng released versions of the eggs (maybe numbering them according to the Z3 release they point into), and reorganizing the download page a bit (maybe development builds need to go on one page, and release builds on another). Why do you say this? I agree that we need this eventually, but it feels a bit early to me. I think that getting the eggs usable outside of Zope is a goal, and one which makes getting the packages released more urgent than simply changing Zope to use them (which won't happen until November at the earliest). Many of the packages are actually very stable, and could easily be released now, assuming some elbow grease is applied. Also, I expect and hope that many packages will have release cycles independent of Zope. That will require that they get maintainers who actively manage them. One sign of such a package is that it has its own CHANGES.txt file, and that its bugfix / feature entries end up there, rather than in Zope's changelog. For the time being, I'll be content with packages which merely point into the release tag area of Zope. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEGEBg+gerLs4ltQ4RArzYAKDNkq4C4JTPaloz3qu/C1p8s3A0BwCgw9f/ r+ZGtDI1V5Zv9KkjcSOY5+0= =FZXB -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope Eggs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan R. Yergler wrote: During the Zope3 sprint following PyCon, Paul and I, with Jim's guidance, began work on exploring how Zope can utilize eggs and be packaged using eggs. Since we're still experimenting with how eggs will be used, I wrote a script, zpkgegg, which reads the zpkg configuration information for a package and generates a standard setup.py from which an egg and vanilla sdist can be generated. You can find the script in subversion in the projectsupport project. For a brief overview of how the script is used, see README.txt (in http://svn.zope.org/projectsupport/trunk/src/zpkgegg/). The eggs generated by zpkgegg do not attempt to distinguish between runtime, testing or development dependencies, so almost all packages will want zope.testing. README.txt contains a brief example of how to point easy_install at the appropriate folders so that easy_install can resolve the dependencies. Note that at this point we're still experimenting with how we'll use eggs, so suggestions, feedback and comments are welcome. I've been playing around a lot, trying to get at least the eggs together to make ZPT usable outside of Zope (one of the original sprint goals). I have a couple of observations: 1. Putting 'setup.cfg' under version control sucks, because the 'develop' framework scribbles on it. I think we should do two things: - Move any special settings to a 'setup.cfg.in', and modify the workspace stuff to read that first when creating setup.cfg. - Make 'setup.cfg' a 'svn:ignore' file (at lest on the trunk). 2. Getting the development dependencies installed was harder than it seemed. Some packages (perhaps with help from a stanza in 'setup.cfg') could do that when running 'develop.py'; others needed me to run 'setup.py develop'. Maybe we should just kick off 'setup.py develop' at the end of the 'develop.py' dance? 3. I was hoping to get 'setup.py test' working, but that command in setuptools doesn't honor the command-line arguments for egg handling. 4. We need to begin creatinng released versions of the eggs (maybe numbering them according to the Z3 release they point into), and reorganizing the download page a bit (maybe development builds need to go on one page, and release builds on another). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEF0fm+gerLs4ltQ4RAmrpAJoDoHdjtKphZJPy9tXG5tGjde0+hgCfaFZo tmvntIJnqEyc4tMS3UrLrXI= =G//3 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: what is ZCML?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Shell wrote: On 3/13/06, Dieter Maurer [EMAIL PROTECTED] wrote: Martijn Faassen wrote at 2006-3-13 17:15 +0100: ... A newer interpretation of ZCML is: ZCML is a configuration language that configures a number of basic directives for configuring the component architecture and security: adapters, utilities, security requirements, and little else. Everything else should be done in Python code, as configuration in Python code is more flexible and packages can form a more self-contained whole. ZCML should reflect the underlying universality of the component architecture. If two directives work with, say, adapters underneath, they should really be one directive. ZCML should be simple and minimal so it is easy to grasp. ZCML is not readable standalone. ZCML is simply used to turn on various adapters and such, hooking them into the system, but we do not get a clue what the adapters are doing by just looking at the ZCML - Python code needs to be consulted. I believe that this interpretation is the up-and-coming interpretation of ZCML. I hope not... Note, that configuration files should be understand and adaptable by administrators. Therefore, they should be readable and understandable -- without an understanding of the implementation (but with reading of the component documentation). I think differently. ZCML is primarily for programmers. ZConfig style configuration is what administrators deal with more, isn't it? Maybe ZConfig and the things in the root $INSTANCE_HOME/etc/ ZCML files. I don't think of ZCML as administrative configuration. It spells out lots of site policy which must *not* creep back into the software. I'd rather have Python files that I can read and understand what's going on without having to consult ZCML files, directives, documentation, and so on, just to understand why a certain class whose code I'm looking at is getting its behavior when I can see no superclass. I'd like to know that a class I'm looking at is an adapter and what it provides and what it adapts without having to dig through a large ZCML file. An administrator is not likely to override my 'inplace_editor' view. Really? You have no options which an admin might want to change, either on a site-wide basis or within a single folder? How about choices like whether to accept HTML 4.0 versus XHTML 1.0? What about tag blacklists? He may want to configure global services (if my application is written that way) such as RDB connection parameters and mail services. But beyond that, just loading it up in package-includes or in a specific file is likely to be the bulk of 'administrative' effort. Did administrators go into your ``initialize(context)`` functions in your Zope 2 Product's __init__.py files and change things? That's what I view ZCML as being - a better version of that. (Better in only that configuration and initialization can be executed separately from Python imports) We need to get beyond the idea that Python is the ideal place to spell everything. It is particularly bad to have to modify the software shipped by the developer in order to change policy, which is where we are going if we continue down this road. Having to accept choices made by a component developer is a barrier to reuse; we won't win brownie points for all our cool components if we make it hard to use a comoponent without accepting either *all* or *none* of its configured policy choices. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEFhdD+gerLs4ltQ4RAptSAJ4lvBZ2f7iwodYUP8l9J4j+nqoYcQCgr5qb c4HIIpb1Kkm/KuQ7yMYiGdU= =F/SR -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: traceback when running tests for zope.app.component
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 j.kartnaller wrote: Benji York wrote: jürgen Kartnaller wrote: Benji York wrote: I emailed the committer Friday about this, but no fix has been forthcoming, so I reverted the offending revisions. Hopefully a revised version can be reapplied soon. Still the same problem after your revert ! The tests pass on my box and on all the buildbot machines (and they didn't before). Perhaps you're seeing a different problem. I didn't compare the tracebacks to be sure. The traceback only occurs when running the test for zope.app.component : python test.py --package=zope.app.component A full test runs without problems. A trunk checkout fails for me with the same traceback when run with that command line. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEDFP2+gerLs4ltQ4RAkyOAJ9kIr6yWO7iK9sAkDOA8LxOTmHhdACfV+FU bt9FlEcGL/TCSBWQYzXT3kU= =w0Hz -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Notice: zope.interface is now a separate project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Winkler wrote: On Sat, Mar 04, 2006 at 12:38:38AM +0100, Thomas Lotze wrote: What was the reason for choosing these and not choosing others? Minimal dependencies. We thought we should start with easier packages. Right. The selected packages tend to be dependencies for the others, as well. The eventual plan is to have *all* the non-app Python packages distributable as eggs, as well as moving out large chunks of stuff currently under zope.app. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFECPgC+gerLs4ltQ4RAvajAJ479R8ytjILUGWdSOcQnQ+20s2OuwCgsycR dgzEfQzDKugojSjbfZxC3Sg= =mfxA -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Two visions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Max M wrote: Jim Fulton wrote: 2) In an alternate vision, Zope 2 evolves to Zope 5. Zope 2 is complicated! It has too many layers of everything. The reason for Zope 3 is to make it simpler for developers. Therefore I believe that any succesfull strategy would require Zope 3 to be usable completely without all the Zope 2 layers. If Zope 3 becomes just another layer on top of Zope 2 - CMF - Plone it will not reduce complexity, as any developer would still need to learn the entire stack. Wherever practical, Zope 2 technologies should be rewritten to Zope 3 technologies to remove layers from the stack. I think these are good points. Five runs the risk of being yet another layer on a stack like Plone, but Five also gives the chance of us stripping off these layers and replacing it with something cleaner, and at the same time Five is giving an impulse to Zope 3 development as things slowly get ported to Zope 3 or written in a Zope 3 style. The Five project has the right attitude to deal with such integration issues. We have been quite successful: In Zope 2.9 it's possible to build modern Zope 3-style apps, using formlib and sqlos and so on (we've done it). In this vision, the Zope 3 project should stay where it is and push things forward. That doesn't mean Five should be ignored by Zope 3 developers, but it should be compartmentalized in people's minds. Zope 3 does innovation, Five does integration, and then the big codebases can move forward using both. I think the other major point is the door #2 proposal takes pressure off of Zope3: under that regime, Zope3 does not need to grow all the features present in Zope2, which door #1 *does* imply. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEBHBA+gerLs4ltQ4RAs22AJ44rNQIZB9HCt1S6fp7s36Hq68MNgCgv37w PHiyspa7XahkllCJmueEU5w= =ZyJQ -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 web root
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shane Hathaway wrote: Jeff Shell wrote: I agree that better integration with external data should be a priority for Zope. But what does that mean? In theory, if something's a Python object it should work with Zope 3 with relative ease... If that's not the case, perhaps we need to look at how much work is required to take some random Python object that may be created by some random data access library and get it into a Zope 3 published web page. If it kicks and screams and resists security and interfaces, or what not, maybe we need to take a look at all of that. Let me focus the discussion: I think it's nearly always a bad idea for anyone, newbie or expert, to put a template or script in ZODB. Do we have any agreement on that point? I wish we did. I enjoy ZODB for many purposes, but not for storing templates and scripts. I have a real client application where the templates themselves *are* the content being managed: they are *not* software. They *must* be stored in the ZODB. You could think of these things as active content components, or somthing, and they are not logically the same thing as stock templates used for software, but they do include ZPT. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD9Jni+gerLs4ltQ4RAmrjAKCiwoNHJd8ZTKqnJ+8FemITlPuQtwCfZ3nC QxO8Etxh2cyrUIMb7tcvzE4= =KLiU -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: One namespace for ZCML
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: snip Just note that I'm explicitly not addressing automation as a use case for custom ZCML directives. I believe automation is best done in Python. If you're trying to invent a new ZCML directive that does something else to an adapter/view/utility before registering it (e.g. putting an interface on it, adding attributes, wrapping it in a factory etc.), then that should be done in Python. zope.formlib is a good example of how browser:page is enough for registering a form as it isn't ZCML's concern *what* kind of page we're registering. All that is in Python. I'll aggree to an extent: where this pactice breaks down is when the argumentes to the automation need to be supplied as configuration. At that point, a wrapper argument which allows the user to specify those values without writing / modifying PYthon can be a win. In the case of Shane's webroot proposal, for instance, the filesystem path to the root would be best specified as an attribute to a custom directive, even if the directive did nothing more than configure a single global utility. snip Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD8cKj+gerLs4ltQ4RAvo3AKCs0XzL07Yo6TYUGjtR9TwVHsWkSQCgvSul z/pSuIU/iBLm3x3ad1IR2G4= =fyuR -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Reducing the amount of ZCML directives
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: On 2/14/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: utility component=.alias.sydneyFactory name=alias.SydneyBristow / The naming of the component already gives it away as a factory. To me that's enough naming. I think I agree. This to me makes sense. If it were nameless (are there nameless utilities) you could then get off with just utility component=.alias.sydneyFactory / which is then the on/off switch we mentioned earlier. And an adapter should be registered the same way adapter component=.alias.FidgetAdapter / and what it adapts between should be a part of the python-code with an adapts(ISomething) declaration, just like implements(ISomethingelse), which I think you suggested in your ZCML does doo much blog, right? The use case here is for registering components (in particular, factories) which don't / can't have the CA metadata hard-wired into them: e.g., they are functions, not objects, or they are in read-only library code. It is also conceivable that the metadata they declare is overharsh, and that the component might work well with an equiavlent interface to the one it was written for. In this case, ideally one would update the software with a more generic interface; but allowing the configuration file to override the metadata is a workaround. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD8clC+gerLs4ltQ4RAqj+AKCuEuRhN9OONBq05FaLGTiW9AJqtACguXqE ijXt6KrV346wnho6TIKd8m8= =nYS9 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: One namespace for ZCML
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Monday 13 February 2006 08:36, Philipp von Weitershausen wrote: As we have learned that we can reduce nearly all component tasks to adapters and utilities, many tasks revolving around registration and configuration of policy also only involve adapters and utilities. By using those elementary directives we can stimulate the learning process for developers (there should only be one way of doing things). Yes, you might have to use two or three directives instead of just one new one, but you'll know what you're doing... And you'll remember it in 2 months. I think that's more valuable than saving a couple of lines today. I think this is the wrong thread. :-) We are discussing the one namespace here. If I would be against replacing one special directive with a couple fundamental directives, I would have voted -1 on the other proposal, which I did not. That said, there might still be a small percentage of cases where custom directives are a valid tool. I can accept their being on the same namespace as others. In fact, I would like it to be that way, reducing the amount of dead chickens (namespace declarations). I do not think namespace declarations are dead chickens. For me declaring a namespace in ZCML is the same as importing a package or module in Python. You would not want all functions and classes in Python live in one namespace, would you? +1 to Stephan's comment; -1 to the proposal. - The opposition to namespace declarations is whiny, as they are the standard way to make XML extensible. Unless we are going to quit using XML, outlawing namespaces would be equivalent to saying, you may not extend ZCML; I don't think we are smart enough to make that ukase. I think the Last Law of Python according to the Prophet Peters obtains here as well. - Note that the non-XML language also used by Zope (ZConfig) has its own extensibility mechanism: in fact, Fred and I made it possible in November for Zope2 products to register their own schemas for those extensions, which was a blocker for moving some configuration out of software. - I don't want to encourage people to do configuration in Python: we have moved away from that *on purpose* in Zope, and I don't see a reason to go back. Directives which make it possible to change policy decisions without touching software are a Good Thing. I think that letting people who spend their days up to the elbows in the software make choices here skews the picture: we *want* people to be able to change the behavior of the system in controlled ways without having to modify software; I would prefer to hear feedback from non-core-developers before going further with the ZCML delenda est thread. - The application vs plugin discussion is probably germane to this issue, as well: a user who is deploying a single application is acutally *more* likely to define and use convenience directives which reduce the amount of effort required to change policy than the generic appserver-with-plugins configuraiton. Removing the ability to create such convenience declarations makes it harder for those developers. - Many of the objected-to directives exist precisely because people did not want to type the much more verbose equivalents which were the original, cleaner spellings. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD8KAe+gerLs4ltQ4RAtREAJwMf91w4eEGbvp0Llz0SKg7bkoTpwCgyDce rEhfptDFqlhXZjSAZ5FZXxw= =aIxe -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: tal:define=... considered harmful?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: On 2/13/06, Tonico Strasser [EMAIL PROTECTED] wrote: Looking forward to see explicit ZPTs soon :) Me too. I'd also like the macros to be called rather than expanded, so that any error messages report the error in the macro rather than in an expanded main template. This should be possible if we have explicit macro parameters. In fact, this would not only solve the two biggest problems with macros, it would make the macros functions, which is much better. If we don't want to break backwards compatibility, calling them functions would be a good idea. That's a non-goal for me: macros are *not* functions, and aren't supposed to be called: the point of them is that they operate in the context of the caller. In addition to the loss of functionality (slots, as you note), calls are much more expensive than macros. Slots are however highly useful, and I'm not sure what to do about them. I'd also like to remove the python: prefix completely. No tal:define, no python:, no macros, but functions. Then I'd be happy. Question is: Is it still ZPTs? ;-) No. I would prefer to make it easier to avoid lots of 'tal:defines' and Python expressions (e.g., by making it easier to define new top-level names without deriving a subclass). I don't want to force everyon to adopt the practices which your world would require (trivial boolean methods on the view to call from 'tal:condition', for instance). It should be possible to tweak the template as it sits today, including making it messy, and then clean it up by extending the view class later. Tres/ - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD8KId+gerLs4ltQ4RAgLLAJ4pnaF2IKPzu0I4WvOURRqXXFaJngCfcRRC rf+trhMVjOg57Tyu29zv3wE= =rsU0 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: tal:define=... considered harmful?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tonico Strasser wrote: I'm interested in your opinion about parameters for macros. Do you think this is explicit enough?: ul tal:define=list main_navigation li metal:use-macro=macros/li_repeat/ /ul Or do you think explicit parameters would make things clearer?: ul li metal:use-macro=macros/li_repeat metal:with-params=list main_navigation/ /ul I don't favor explict arguments for macros, becaued I don't think they are functions. I normally document the expected names in a comment in the supplying template (outside the macro itself). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD8LC9+gerLs4ltQ4RArPaAJ9zzlHSc2LXkvFS9I4avXoiaMof6ACfaak4 TA7szsDbdsxKIF3R0t+K6Pc= =73f6 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: One namespace for ZCML
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Tres Seaver wrote: - The opposition to namespace declarations is whiny, as they are the standard way to make XML extensible. Unless we are going to quit using XML, outlawing namespaces would be equivalent to saying, you may not extend ZCML; I don't think we are smart enough to make that ukase. I think the Last Law of Python according to the Prophet Peters obtains here as well. I'm neither trying to follow the whiny people who detest XML and therefore ZCML nor am I trying to make ZCML not extensible. That said, I think that ZCML's usage of namespace is quite arbitrary. Why is browser and mail-related stuff on its own namespace but security-related stuff not? I'm not arguing (here) against refactoring the namespaces in which core directives are declared. I'm arguing against the idea that namespaces are bad in general. Why is it then recommended that third-party packages use their own namespaces, even though they might only have browser-related directives to register...? Third-party packages which don't define new directives don't need their own namespaces. If, for instance, Plone adds a plone:view directive which is nothing more than a no-op wrapper around 'browser:view', that would be a Bad Thing (TM). If, however, they add a 'plone:frobnatz' directive which does something magical and outside the scope of the Zope core, and document how to use it when setting up Plone, that would be a Good Thing, especially if it kept people from changing site policy by customizing software. I don't really see the point in ZCML's using namespaces. What good do they provide? Seriously, is it just the prefix? Well, we don't need the namespaces for that. ZCML *must* support extensibility, and therefore must continue to allow packages to register their own namespaces (unless we abandon XML altogether). Otherwise, we give up the ability to check that a given directive can actually be interpreted at all, which would be a Bad Thing. - Note that the non-XML language also used by Zope (ZConfig) has its own extensibility mechanism: in fact, Fred and I made it possible in November for Zope2 products to register their own schemas for those extensions, which was a blocker for moving some configuration out of software. I'm not sure what to do with this info... Just note that being able to extend the configuration language from non-core code is an important use case. - I don't want to encourage people to do configuration in Python: Rest assured neither do I. we have moved away from that *on purpose* in Zope, and I don't see a reason to go back. Directives which make it possible to change policy decisions without touching software are a Good Thing. I think that letting people who spend their days up to the elbows in the software make choices here skews the picture: we *want* people to be able to change the behavior of the system in controlled ways without having to modify software; I would prefer to hear feedback from non-core-developers before going further with the ZCML delenda est thread. I have heard such feedback, otherwise I wouldn't have taken the time to write the proposal. I've also heard positive feedback on this particular matter (reducing ZCML namespaces to one). Again, I wouldn't have brought it up otherwise. A lot of the feedback seemed to be along the lines of: - ZCML sux -- I won't use Zope3 until it is gone! They weren't gonna use it anyway. - Why do I have to declare the namespaces? (XML haters, for the most part; note that I am not an XML fanboy myself). - Why does the core use more than one namespace? This question seems legitimate to me: I think we wanted to allow non-mangled names for otherwise conflicting directives, e.g. 'browser:view' and 'xmlrpc:view'. - The application vs plugin discussion is probably germane to this issue, as well: a user who is deploying a single application is acutally *more* likely to define and use convenience directives which reduce the amount of effort required to change policy than the generic appserver-with-plugins configuraiton. Removing the ability to create such convenience declarations makes it harder for those developers. This belongs in the other thread, really. But here it goes anyway: I'm not convinced that people who deploy apps will actually go as deep as editing package ZCML, or even overrides for that matter. I would rather imagine they turn ZCML features on or off (which would then turn on or off ZCML directives via zcml:condition) Nope. You are ignoring the cases which are currently done TTW in Zope2: mailhost configuration, for instance, or caching policies, etc. If an application wants to add a diretive which makes it possible to configure such policies in ZCML, why should we prevent that? - Many
[Zope3-dev] Re: One namespace for ZCML
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Tres Seaver wrote: snip I'm not arguing (here) against refactoring the namespaces in which core directives are declared. I'm arguing against the idea that namespaces are bad in general. I'm not arguing that either. I'm just saying that one namespace is sufficient. Not if you need to mangle names to avoid clashes. snip I don't really see the point in ZCML's using namespaces. What good do they provide? Seriously, is it just the prefix? Well, we don't need the namespaces for that. ZCML *must* support extensibility, and therefore must continue to allow packages to register their own namespaces (unless we abandon XML altogether). I don't see how that conclusion works. It seems like you think namespaces are needed for extensibility. They are not. We can add directives to existing namespaces just fine. I don't want to encourage third-party applications to inject their names into stock namespaces, because then I can't safely mix unrelated third-party packages without chasing down conflicts. XML Namespaces are useful for extending existing XML dialects with stuff from others. E.g. embedding SVG into HTML, adding TAL/METAL to HTML, and the like. The way ZCML uses namespaces isn't even half-way compatible with that. For example, I couldn't add inline-documentation to ZCML unless I configured no-op directives for my particular documentation elements, just so that the ZCML machinery wouldn't complain it encountered unknown directives. Why would it think that they are directives? I can add inline-documentation to XSL or, heck, OpenDocument just fine. ZCML wants to be XML but it's weird about it. I don't want DocBook in my ZCML, personally. De gustibus again. At the moment, ZCML does assume that all elements in a ZCML file belong to it. If you wanted to add DocBook to your ZCML, then you could add a meta.zcml file which registered faux handlers for the docbook elements; you might also add a directive to ZCML which instructed it to ignore all nodes from a given namespace. Otherwise, we give up the ability to check that a given directive can actually be interpreted at all, which would be a Bad Thing. Huh? Right now, ZCML does a syntax check on the files it processes, and barfs on elements it doesn't understand. I don't want to lose that check if the only benefit is the ability to inline foreign elements. Again, I wouldn't mind some syntax which told ZCML to ignore names from particular foreign namespaces. snip A lot of the feedback seemed to be along the lines of: - ZCML sux -- I won't use Zope3 until it is gone! They weren't gonna use it anyway. ... - Why do I have to declare the namespaces? (XML haters, for the most part; note that I am not an XML fanboy myself). I am *for* declaring XML namespaces. I'm against declaring too many pointless namespaces. Now we are getting close to 'de gustibus' territory. Your proposal seems to make a claim that we don't / won't need more than one namespace, while the ones we have are there because people were trying to avoid name clashes. There may be some which could be refactored away, but I don't think that is the same point the proposl si trying to make. - Why does the core use more than one namespace? This question seems legitimate to me: I think we wanted to allow non-mangled names for otherwise conflicting directives, e.g. 'browser:view' and 'xmlrpc:view'. Yes. Using namespaces for this is arbitrary, though. We could just as well have chosen different names, e.g. browserView and xmlRpcView. I don't think that was arbitrary all: we use namespaces *as they are designed* here, to allow people to use natural names for things without worrying whethere they clash with names which are equally natural in another domain. This is why Python has namespaces, too: import this ... Namespaces are one honking great idea -- let's do more of those! - The application vs plugin discussion is probably germane to this issue, as well: a user who is deploying a single application is acutally *more* likely to define and use convenience directives which reduce the amount of effort required to change policy than the generic appserver-with-plugins configuraiton. Removing the ability to create such convenience declarations makes it harder for those developers. This belongs in the other thread, really. But here it goes anyway: I'm not convinced that people who deploy apps will actually go as deep as editing package ZCML, or even overrides for that matter. I would rather imagine they turn ZCML features on or off (which would then turn on or off ZCML directives via zcml:condition) Nope. You are ignoring the cases which are currently done TTW in Zope2: mailhost configuration, for instance, or caching policies, etc. If an application wants to add a diretive which makes it possible to configure such policies
[Zope3-dev] Re: Correction to RFC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: On Fri, 2006-01-27 at 16:38 -0700, Shane Hathaway wrote: It's checked in, but perhaps there is some other code that also needs to use the custom traceback formatter. The conversion is trivial. Replace this: from traceback import print_exception print_exception(...) with this: from zope.exceptions.exceptionformatter import print_exception print_exception(...) Thought so! I'm just not sure whether this is intended behaviour. What's the current policy about displaying tracebacks to the end-user in Zope 3? The policy seems to be that the end user should *never* see the traceback, unless she selects the '++skin++Debug' skin *and* the admin configures inclusion of the 'zope.app.debug' package. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD2/lF+gerLs4ltQ4RAqVpAJ408lAfr/qAgr8RXHQufyCleNTZiQCeKWgX OrpMsZSxywRiYDMGh77WjXM= =EGCT -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Deploying WSGI Apps with Zope 3.2+
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Shane Hathaway wrote: Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sidnei da Silva wrote: On Thu, Jan 26, 2006 at 02:02:19PM +, Chris Withers wrote: | Sidnei da Silva wrote: | | My original intention was to put the config file location in the | ZConfig schema, but that's *wy* too painful right now. | | What's the specific problem here? I find adding to ZConfig schemas | pretty easy... Yet you find ZCML declaring namespaces in ZCML files annoying *wink*. Sometimes I don't understand you :) +1 to that. I think Chris doesn't really believe in the Second Law of Python (according to the prophet Peters). No, Chris just doesn't like XML namespaces. You can still have explicitness without XML namespaces. I think I'm starting to grasp the XML division among Zope developers. ZConfig schema definitions use a conventional style of XML with deeply nested elements, text nodes, and no namespaces, while ZCML uses its own style with minimal nesting, many attributes, and many namespaces. This style is hardly unique to ZCML. Many XML languages work this way, including, for example, XML Schema Definitions. The XML folk talk about document-centric versus data-centric applications as having essentially incompatible semantics for their XML; I think we are staring at a similar split. Using elements instead of attiributes has the downside that constraining the type of the element is much trickier when spelling pattern-based schema-validation templates. Elements also tend to introduce spurious whitespace problems when used for semanticall simple values. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD2/q6+gerLs4ltQ4RAqydAJ93fnitXiwqEvNDChEIrphI8cAUugCfbJ/0 ZgNgLaJd5DdDw40GG2nYkqs= =vfly -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: SVN: zope.paste/trunk/README.txt - More explicit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sidnei da Silva wrote: Log message for revision 41447: - More explicit Changed: U zope.paste/trunk/README.txt -=- Modified: zope.paste/trunk/README.txt === --- zope.paste/trunk/README.txt 2006-01-25 18:41:51 UTC (rev 41446) +++ zope.paste/trunk/README.txt 2006-01-25 20:12:39 UTC (rev 41447) @@ -19,16 +19,16 @@ Configuration is very simple. There are three steps that need to be performed: -1. Configure a named IServerType utility +1. Configure a named IServerType utility (by default, we already + define a utility named `Paste.Main`). 2. Change the server directive on INSTANCE_HOME/etc/zope.conf to - use the newly-created IServerType utility + use the newly-created 'IServerType' utility (out of the box, you + can just swap out 'HTTP' or 'WSGI-HTTP' by 'Paste.Main'). 3. Configure a WSGI application using `paste.deploy`_ syntax in INSTANCE_HOME/etc/paste.ini -By default, we already define a utility named `Paste.Main`. - Here's an example of how to configure the `Paste.Main` application using paste.deploy to use the Zope 3 publisher as a WSGI app: Interesting. Can you extend the README to show a sample of configuring it end-to-end (e.g., how to set up a simple WSGI server and configure it to use the WSGI application)? WSGI-river-take-my-mind'ly, Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD1/gP+gerLs4ltQ4RAlE5AJ4prS+Hze9nAmpIq938tC2M8yiIpwCgwOj8 KWL9246Pe3IBq1x64s7iOxQ= =aOkl -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Question about re-authentication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Wednesday 25 January 2006 05:40, Christian Theune wrote: I'm quite sure that part b) isn't written yet, but I'm not sure what the state of part a) is. (a) is done. It is indeed the default Zope behavior. Hmm, I thought that Zope3's security machinery set the response code to 403 (forbidden) rather than a 401 (Unauthorized) if the user is already authenticated. but then tries to do something not allowed. Browsers (rightfully) don't treat a 403 as a prompt to reauthenticate. The configureed authentication service *may* override that to raise Unauthorized, but that is not mandated. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD1/rk+gerLs4ltQ4RAiVtAJ0ce2+V9zw7KwQsalTXlk9/KeRz0ACeMnpF e5xVjsnEpHEqrAp4rEHUN/E= =RAuP -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Zope 3 startup message
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: Tres Seaver wrote: Heh, only with Plone, where PTS spews tons of useless gunk at INFO level. Let's fix the spew in PTS instead (which should be at BLATHER or DEBUG level). Note, that I fixed this in PTS svn, releases after Plone 2.1.2 will be quiet ;) ...and there was much rejoicing. Thanks for stepping up and hammering that out. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD1/wg+gerLs4ltQ4RAgqhAJ9AoiBIPcnvkMnzdJA7IoDEBCMvggCfT0Th KT6No/Wjn1gqDl0u6w1JDhY= =93wq -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Zope 3 startup message
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander Limi wrote: On Wed, 18 Jan 2006 14:48:42 -0800, Marius Gedminas [EMAIL PROTECTED] wrote: This is what Zope 3 prints on startup: 2006-01-19 00:47:32,059 zope.server.http (HTTP) started. Hostname: pitonas Port: 8080 This is what Roundup prints on startup: Server running - connect to: http://localhost:8917/demo/ Another related fix that probably applies to both Zope 2 and Zope 3 (although I'm not sure about the latter) - this gets printed at the *beginning* of the output from the process, which means that it quickly scrolls out of view if there are any messages from the server process at all (which there always are, at least on Zope 2). Heh, only with Plone, where PTS spews tons of useless gunk at INFO level. Instead of printing: 2006-01-17 14:59:09 INFO Zope Ready to handle requests at the end, could we have something like: 2006-01-17 14:59:09 INFO Zope Ready to handle requests on the following ports: and then a list of the ports it is running on? One of the classic newbie gotchas (especially on Linux or other platforms not using the Plone installer) is Oh, it's running - but where? How do I connect to it?. Zope tells you where to connect, but way too early in the output. Let's fix the spew in PTS instead (which should be at BLATHER or DEBUG level). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD0FX9+gerLs4ltQ4RApcbAKC5kFgaFGv8pFbEfoqNwjP+HZ7JNgCgklyf 82CroLO+olUPDrDudYRBJVg= =GY8g -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Fwd: mail.zope.org listed in SORBES
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim Peters wrote: [Stephan Richter, re: http://www.us.sorbs.net/lookup.shtml?63.240.213.173 ] can someone at Zope Corp. get us delisted? Frankly, I doubt it -- who has time to wrestle with SORBS? It's time-consuming just to find out from them why it's listed. At the end, I'd like to be a fly on the wall when someone suggests to Rob that Zope Corp open a PayPal account to send $50 to The Joey McNicol Legal Defense Fund 0.1 wink. They claim that cvs.zope.org sent mail to one of their spamtrap addresses (I had to try twice to get an image whose text *I* could read). Their procedure for getting support (i.e., to get delisted) is invasive and ugly; I wouldn't bother, myself, either. If they allow DoS by having malicious folks sign up mailing addresses to their spamtrap stuff, nothing we can do will preent the same jerk from doing it again. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDy8yK+gerLs4ltQ4RAukyAJ9EoQrF/TbxEz3hAOARO3+dALktzgCdErSN VaKHgholY1lfMlqVYGtojI4= =mTDb -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: URGENT RFC: Is anyone using response.write in Zope 3?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: When we refactored the Zope 3 pubisher to work more closely with WSGI, we decided to remove the response.write method. We should have written a proposal for this, but we failed to do so. Over the last few weeks there has been much discussion of this in which I asserted many times that I didn't think any applications outside of Zope 3 itself used this method. No one has disagreed with me. I want to double check this. Does anyone have any Zope 3 applications that are using response.write? Assuming that the answer is no (or that no one answers today), I'm going to more clearly document how to return long output and I'm going to add a method that generates a hopefully helpful error. Note that we may add this method (or something like it) back in the future to support chunked streaming output, IIRC, Christian Theune wrote that he had been using 'response.write'; I think the note was in the Twisted Publisher thread about a week and a half back. CC'ing him to ensure he knows to respond today. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDptN9+gerLs4ltQ4RAnhiAJ9TvhSSBDPj6HmbNkL/otDduioBFACdF0VP m5iJH+iy7meJBSrlXyPLQZI= =94K7 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: URGENT RFC: Is anyone using response.write in Zope 3?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Shell wrote: Yes, it's hurry.file. What's Tramline? We're using hurry.file for small images, generally, and it's been working fine. We've recently written a cache manager that writes the images out to the file system where Apache can serve them. Heh, that would be tramline, or half of it, anyway. ;) http://faassen.n--tree.net/blog/view/weblog/2005/11/11/0 Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDpv5Z+gerLs4ltQ4RAtK4AJ9wnZuLJjyH/Ahfhpi5Sk4AN1Qi9gCeNSgo MsRgJsQRrAhsnmFWUwPPUHs= =wrZ2 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Certification: SupportingResidual InformationProtection in Zope 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Roger Ineichen wrote: [Martijn goes into why this might be slow] Yes you are right. Do you have another idea? A fairly drastic one, unfortunately -- catalog all role and permission assignments and run a query as soon a user is removed. CMF does this for local roles, and Jim is already on record as disliking it. I am pleased with the *result*, which also allows the catalog to filter normal content results efficiently based on the user's roles (the original eason for the index). OTOH, the *implementation* is grotty. Hm, perhaps another idea would involve the timestamp of creation in the userid somewhere, to make the ids unique. Unfortunately I don't see how that would work with external authentication systems such as LDAP, as we don't know when userids are created and removed there. The actual ID used by LDAP is a DSN. Perhaps the authorization system could map the DSNs to internally-generated integer ID, which would be the only value actually stored in grant records. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDotJc+gerLs4ltQ4RAscQAJ9pNpD2Dce+3vxbOKOu3jeyi4OcZgCg08Ss uLAalHjZ6RTaj32kmTnJLrw= =J37w -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Twisted issues (Re: Re: Twisted Publisher and Zope 2)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Jim Fulton wrote: Tres Seaver wrote: ... Ob. note: the performance characteristics of such servers (including twisted) are not well understood in the context of Zope, until some brave soul actually rolls out a high-volume production site and reports success or failure. Good point! It would be good to investigate this issue further. I did some investigation and found the thread-management strategy currently provided to be unsatisfactory. Given the twisted team's general attitude toward threaded programming, I don't find that terribly surprising. Kind of like what you get when you elect government officials whose sincere program and belief is that government can't work. ;) I've posted a note to the Twisted list. I don't know if this can be fixed before the next Zope 3.2 beta this weekend. I think I'm going to look into adding an option to makezopeinstance to select which server is used. I haven't decided yet which one will be the default. I'm leaning toward making twisted the default to try to increase the amount of testing it gets, but recommend that people use ZServer for now in production sites. - -0. I would restate my belief that the twisted integration is yet-to-be-proved in production use, and needs some care-and-feeding from people whose pagers go off (or the equivalent) if it breaks. I can live with the default being twisted, but it is a bit like leaving 'debug-mode on' in the default config file for now. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDoewB+gerLs4ltQ4RAuXaAKDPXKDmAMgQpOAKWDJ+zF2rGov4DQCfboYX sByBXXJYqeJKFcgVgSYKvL4= =z7XT -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: rdb: Disappearing Connection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florent Guillaume wrote: Jim Washington wrote: Spelunking a bit in the code, zope.app.rdb.ZopeDatabaseAdapter.isConnected() looks at whether _v_connection is present, not whether the connection is actually alive. If we fix this here, isConnected() perhaps should handle the case where the connection might be reaped by the back end db. Frankly anything that uses _v_ attributes is asking for trouble because it relies on low level behaviour of the ZODB and persistence mechanisms. They can disappear at unpredictable times. Avoid them. There *is* a reasonable pattern for using them, with the following caveat: the value you are caching must depend *only* on other attribtues of the *same* persistent object *or* its non-persistent subobjects (i.e., the values are pickled / ghostified as part of the same ZODB record). In this case, the following works entirely as expected: class Foo(SomePersistentBaseClass): _v_cache_an_expensive_operation = None def getExpensiveResult(self): if self._v_cache_an_expensive_operation is None: self._v_cache_an_expensive_operation = _expensive() return self._v_cache_an_expensive_operation This pattern is reliable because the volatile will be wiped if *any* of the attributes of its object are modified, at the point that the transaction (or subtransaction) commits / reaches a savepoint. If '_expensive' depends on *any other persistent object*, you lose (eventually, anyway). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDn3gV+gerLs4ltQ4RAmekAKCf8ByFHX9beo51HUYOYyIoAm6eswCfRkLi czMxyJZPhaKMgq6K1lJup6g= =gkrJ -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Twisted Publisher and Zope 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sidnei da Silva wrote: On Mon, Dec 12, 2005 at 07:18:05AM -0500, Jim Fulton wrote: | We should proceed by getting Z2 and Z3 to use a common | publisher, presumingly based on the Z3 publisher. This common | publisher should: | | - Be well documented and tested. | | - Use WSGI for HTTP | | - Be backward compatible with Both Z2 and Z3 | | - Should be highly customizable through components. This will | hopefully allow z2-stype and z3-style publication to coexist in | a single app server. | | Again, I expect that the Z3 publisher will be the best starting point. | | Note that the Z3 publication framework splits functionality | currently provided by the Z2 publisher into a publisher and a | publication object. An initial step might be top come up with | a Z2 publication object that works with the Z3 publisher. You haven't said anything about the server. I assume this Z3/Z2 publication object hybrid would run with with the Z3 server instead of the Z2 ZServer. If WSGI lives up to its promise, then the WSGI-compliant Z2-Z3 hybrid would be publishable as a WSGI application from any WSGI server, including perhaps mod_python-based servers. Ob. note: the performance characteristics of such servers (including twisted) are not well understood in the context of Zope, until some brave soul actually rolls out a high-volume production site and reports success or failure. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDnXQh+gerLs4ltQ4RAjzbAJ4+5SAPXcxnbo3IY7tWODabMuLajgCgyNFK mW6JmvMV9vcc0xq/xKOyOdM= =flX1 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: The default ZEO port
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Yoshito Komatsu wrote: Hello, I'm Yoshito Komatsu. I have some question about the default ZEO port. In mkzeoinst.py, the default ZEO port is 8100. http://svn.zope.org/*checkout*/ZODB/trunk/src/ZEO/mkzeoinst.py?rev=38309 But in zope.conf.in, the default ZEO port is . http://svn.zope.org/*checkout*/Zope3/trunk/zopeskel/etc/zope.conf.in?rev=39582 Yes, I noticed this too. They should be the same. I think that the default ZEO port in zope.conf.in should be changed to 8100. Are there any problems with changing it? Fixed on the 3.2 branch and the Zope3 trunk (Zope2 was already consistent). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDnIk3+gerLs4ltQ4RAkOEAKCwU7SjifZ40uJ2TNnTYf0YE8g5HgCfTcq0 yMwVsrjvUQNvnze0CUrehm0= =omel -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Twisted Publisher and Zope 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Thursday 08 December 2005 08:29, Sidnei da Silva wrote: On Thu, Dec 08, 2005 at 08:18:49AM -0500, Stephan Richter wrote: | On Thursday 08 December 2005 07:06, Sidnei da Silva wrote: | Just one thing that struck me right now. ZServer uses medusa/asyncore | and twisted has it's own 'main loop'. How do they play together in | Zope 3? Or they dont? | | They don't. Either you use ZServer or you use Twisted, but not both. So | if you want to use Twisted-specific packages, like the scheduler, you | have to use twisted, otherwise you are out of luck. I think this is | totally fine. What's the situation with ZEO then? The ZEO 'zrpc.client' uses ThreadedAsync.register_loop_callback(), which is a evil monkeypatch to asyncore. I haven't seen that change recently, so I assume this has been ignored? Yep. Nobody has complained to us about this yet. I personally do not use ZEO, so I could not fix the issue anyways. If twisted and ZEO are incompatible, then twisted needs *never* to be the default; ZEO is an essential part of Zope's real world story. I can't imagine even *developing* without ZEO, much less deploying applications in production. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDmGOO+gerLs4ltQ4RAh5WAKDKV/3O77THXAFJZWK6ePEXxyMo8wCeL9O7 +fK7fCbh6uMXE2NgrRCRAFU= =5WMQ -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
