Re: [Zope-dev] Location of RelStorage
On 04/12/2013 11:59 AM, Chris Withers wrote: On 14/03/2013 08:01, Marius Gedminas wrote: What's the official location of RelStorage? I see two source trees: * http://zope3.pov.lt/trac/browser/relstorage/trunk * https://github.com/zodb/relstorage They have the same commits (~1 year old). ..and one more just for good measure: https://github.com/cjw296/relstorage Would be good to have an official git repo under Shane's care. Shane, where are you maintaining relstorage nowadays? https://github.com/zodb/relstorage See also: http://zope3.pov.lt/trac/browser/relstorage/trunk/MOVED_TO_GITHUB Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On 07/06/2011 10:59 AM, Hanno Schlichting wrote: The ZMI is a highly insecure, completely outdated and user-unfriendly interface. As I read this, I got an idea for a possible way forward. I haven't been reading zope-dev much lately, so forgive me if something like this has been mentioned already. What if we had decorators that let us disable old code by default, yet allowed users to enable the old code with configuration? Something like this: import zope.oldcode class SomeClass(SimpleObject): @zope.oldcode.zmi def manage_edit(self, REQUEST): # ... The idea here is we'll create a zope.oldcode egg and fill it with decorators for pervasive features of Zope that need to be removed over time, such as the current ZMI. We'll also create a configuration switch for each of those old features so that people can keep using them for a reasonable period of time. When the zmi feature is disabled, the code above will replace the manage_edit method with a zope.oldcode.Disabled object that raises a helpful exception if anyone tries to call it. It would also be good to make these decorators implement __nonzero__ to allow conditional attribute definition: if zope.oldcode.zmi: manage_properties = (...) I would want to make sure conditional tests are possible as well: @zope.oldcode.zmi def test_manage_edit(self): # ... (The zope.oldcode package probably ought to enable all old features by default when running tests.) What do you think? Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CSRF protection for z3c.form
On 04/04/2011 10:22 AM, Roger wrote: Just because you can write login forms with z3c.form this package has nothing to do with authentication. That's just a form framework! Authentication is defently not a part of our z3c.form framework and should not become one. Why do you think authentication has something to do with the z3c.form library? Did I miss something? This thread is using the word authenticate differently than most other Zope-related discussions. Here, we are authenticating the *form*, not the user. We need to be sure that submitted form data was produced by an authentic form. Otherwise, a crafty site could cause the user's browser to invoke some action in the background. BTW, the CSRF issue has existed as long as HTML forms have existed, but for some reason it has only drawn attention in the past year or two. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On 03/21/2011 10:59 AM, Chris McDonough wrote: On Mon, 2011-03-21 at 15:53 +0100, Lennart Regebro wrote: It's easy and clear, but has the drawback of encouraging that registration is done on import time, while scanning separates the registration from the definition. I'm not sure how important that is. It's important to me, at least. Registration-on-import effectively requires that there only be a single component registry for all applications in a process. This is often fine for a given deployment, but as a framework strategy it seems very limiting. +1. Pyramid has proven (IMHO) that a component registry can be friendly to developers without being global. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] my take on ZCML's includeOverrides
On 12/07/2010 12:27 PM, Chris McDonough wrote: I *think* I'm of the opinion that libraries (or even reusable applications) probably shouldn't need to use includeOverrides. +1, I would be very suspicious of any library that uses includeOverrides. Any use of it ought to be highly visible to developers. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.i18messageid
On 07/02/2010 11:49 AM, Tres Seaver wrote: Jim has asserted (but not really explained) that the C extension closes some kind of security hole. I don't see any credible attack vector myself, but then I no longer believe it worthwhile to devote my own energy to defending against malicious TTW programmers. FWIW, I imagine the problem is that zope.security treats zope.i18nmessageid as a rock, so if the implementation is in Python, it probably allows untrusted code to do this: msg.__setattr__.im_func.func_globals['__builtins__']['__import__'] built-in function __import__ I suggest the bug is in zope.security, which should never allow a type written in Python to be a rock. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] vyshakh krishnan wants to chat
Christian Theune wrote: This is a mailinglist and you probably have dumped your address book to the invitation system. I've seen a couple of those talk to Zope mailinglists recently. Can you *please* avoid putting mailing list addresses into those systems? Better yet, I wonder if there is some equivalent of robots.txt for email. Domain owners should be able to create and host a file that specifies policies for automated email. Does anyone know of such a standard? Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] New Zope 3 name: BlueBream
Jan Ulrich Hasecke wrote: On 04.01.10 19:23, Baiju M wrote: Hi All, I am proposing to call Zope 3 - the web frame work as BlueBream. The main use for name is documentation. Coming from marketing I strongly suggest to think twice or better thrice before inventing the next new name in Zope world. There are already too many of them. Well, the name Zope 3 is effectively dead, yet there are still a number of developers who want to work on it and improve it. Those developers need to rename and regroup. BlueBream is a clever name and I think it's a great idea. Once it's released, BlueBream will probably be on my short list of preferred platforms. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Toolkit - packages with zope.app dependencies
Lennart Regebro wrote: On Tue, Dec 29, 2009 at 22:54, Martijn Faassen faas...@startifact.com wrote: Because we have a ton of installed base out there Do we? I think the debate is somewhat confused here, or possibly it's only me. :) I agree that the debate is confused. No one intends to declare that zope.app is dead. However, dropping zope.app from ZTK is a declaration that newcomers to ZTK will not have to learn anything in zope.app in order to become productive, which is a big win IMHO. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Toolkit - packages with zope.app dependencies
Hanno Schlichting wrote: It has a dependency on zope.app.publication. Given the central role of zope.traversing I allowed it and zope.app.publication to stay in the ZTK, but moved it to the under-review option. On the zope.traversing trunk, I have removed the zope.app.publication dependency. It was only a testing dependency. We have talked about refactoring the traversal and publication story in the past, without seeing any consensus on how to move forward with it. My feeling tells me, that a pure renaming of zope.app.publication to zope.publication or similar code reshuffling into other packages isn't really helpful in this case. ACTION: Until we see further progress on clarifying the semantics of traversal and publication, I'd leave zope.app.publication in the ZTK. What other ZTK packages depend on zope.app.publication? zope.app.publication is an extra layer of complexity that most sites could probably do without. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCA proposal
Martin Aspeli wrote: Gary Poster wrote: I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) Thinking about it a bit, it strikes me that IFoo.adapt(context) may not be right. This reads IFoo adapt context, which doesn't make sense. What I really want to hear is context adapted to IFoo. So maybe it's IFoo.adapting(context)? IFoo.adapterFor(context)? IFoo.adapter(context)? Just thinking out loud. To me, myobj.get(x) reads as myobj, please get x and give me the result, so IFoo.adapt(y) reads as IFoo, please adapt y and give me the result. That statement makes perfect sense to me. Thinking out loud further, I think I may actually prefer IFoo.instance() instead of .utility(), but maybe that debate is already passed. .utility() is OK too. To me, generic names like instance and singleton suggest we're trying to solve some grand problem that would make our brains hurt. I find it more satisfying to solve a more specific problem. I am participating in this thread because I believe the current zope.component API is unnecessarily verbose, hindering readability and adoption by Python projects that would benefit. I think adding adapt() and utility() to zope.interface.Interface might improve the situation. We could instead add adapt() and utility() functions to the zope.component package, but I haven't seen any function signature that would turn out as simple as IFoo.adapt(x). Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Adapter for class with slots
Wolfgang Schnerring wrote:
The minimal reproduction recipe to see the error is this:
class Slotted(object):
__slots__ = ('__provides__')
zope.component.provideAdapter(
lambda x: True, (Slotted,), zope.interface.Interface)
Which will raise
File
/home/wosc/.python-eggs/zope.component-3.7.1-py2.6.egg/zope/component/registry.py,
line 419, in _getAdapterRequired
elif not ISpecification.providedBy(r):
TypeError: 'member_descriptor' object is not callable
Why is this? Can this be made to work? How would I go about
investigating that?
It looks to me like a possible bug in zope.interface. Try deleting
_zope_interface_coptimizations.so to hopefully expand that traceback.
Shane
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the ZCA API decision
Godefroid Chapelle wrote: I tried to follow this discussion closely: however, I cannot say that I understand if doing multi-adaptation with IFoo(bar, baz, boo) has been rejected or postponed. AFAICT, the decision to reject or postpone that has been postponed. :-) Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the ZCA API decision
Martin Aspeli wrote: Can we all get back to our lives now? :-) FWIW, I try to participate in discussions like these by reading and writing only short emails. I find that I don't miss much that way. Life is more enjoyable without essay-mails. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
Martijn Faassen wrote: Given some feedback about backwards compatibility, I'm leaning to the following adjusted scenario: * allow IFoo((a, b)) for multi adaptation. This breaks tuple adaptation. It's not as pretty as IFoo(a, b), but it's pretty tolerable and it *is* actually symmetric with registration. * deprecate a non-explicit default such as IFoo(a, default), require IFoo(a, default=default) While this short spelling of component lookup is attractive and sensible for Zopistas, I wonder if it ever really was the best idea. When a developer encounters the IFoo() pattern for the first time, what is he/she going to type into a search engine to find out what it means? I can't think of any search phrase that is likely to give a good answer. JQuery has a similar issue, but because JQuery is a smaller framework, the JQuery folks simply put that info right near the top of their documentation. I'm not sure we can do that quite as effectively. For an alternate spelling, consider what happens when component lookup fails: you get a ComponentLookupError. Lookup is interesting. It doesn't yet have any meaning in zope.interface, so I think using a method named lookup() would make code more comprehensible. You would use it like this: IFoo.lookup(a) SomeAdapter instance at ... IFoo.lookup(a, b) SomeMultiAdapter instance at ... IFoo.lookup(c) Traceback... ComponentLookupError(...) IFoo.lookup(c, default='missing') 'missing' IMyUtility.lookup() MyUtility instance at ... When developers encounter this for the first time, they might type zope.interface lookup in a search engine. That phrase has a reasonable chance of hitting good documentation. What do you think? If adding lookup() is a good idea, then all we need to do is add lookup() to zope.interface 3.x and deprecate the 2nd parameter of IFoo(). After that, we can let multi-year evolution dictate whether IFoo() should be deprecated altogether. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
Lennart Regebro wrote: On Mon, Nov 30, 2009 at 19:16, Shane Hathaway sh...@hathawaymix.org wrote: If adding lookup() is a good idea Possibly, but it sound like you are looking up (a), when in fact you are adapting it. :) Maye IFoo.adapt(a) ? +1, IFoo.adapt() is better, along with IFoo.utility(). Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
Gary Poster wrote: Then to the multiadapter concern I raised, all my real-world examples of adapters are to adapt one object so it can be used in a certain way (to integrate with another kind of object). Power adapters, for instance, adapt a plug (required interface) so it can plugged in to the wall (output interface). Is there a common real-world example of this for multiadapters? I have a Roku player (great device, BTW). It streams video from Netflix and other sources. It takes two inputs (network and power) and produces one output (a video signal). I could call the device a multi-adapter, but the power input is so simple and reliable that I forget about it. Most of the time I think of the Roku player as a simple adapter from Internet packets to a video signal, but electrically, it's definitely a multi-adapter. Note that the network signal for a Roku player varies wildly, while the power is either ~110VAC or ~220VAC. Multi-adaptation works best when it has similar characteristics, I think. It's safe to allow one of the inputs to multi-adaptation to vary a lot, but to keep developers sane, the rest of the inputs should be more predictable. I think getMultiAdapter((context, request)) is OK because most web sites have only one or two request types. Turned around, people know the term singleton and they do not know the terms adapters and utilities. singletons describe the huge majority of how we use these things. It's something less to explain. Making comprehension quicker is very valuable to me. Do you intend to change the API names in zope.component, then? For example, getUtility - getSingleton? That might be possible, but no one has suggested it before (AFAIK), and I think it's implied by your suggestion. ``IFoo.new(a, b)`` is equivalent to getMultiAdapter((a, b), IFoo) Using new for a name could be a problem for Jython and IronPython users, since new is a keyword in other languages. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
Martijn Faassen wrote: But someone needs to think of a feasible upgrade scenario. We could instrument all calls to IFoo and see whether a default argument is in use, but what then? I'd be hard to distinguish a default argument from one we're meant to adapt. I'd also be non-trivial to scan code. Here is an interface decorator I intend to try out soon. It adds convenient component lookup methods to a particular interface without requiring any changes to zope.interface. --- (snip) --- from zope.interface.interfaces import IInterface from zope.component import getAdapter from zope.component import getMultiAdapter from zope.component import getUtility from zope.component import queryAdapter from zope.component import queryMultiAdapter from zope.component import queryUtility def componentlookup(iface): Decorator: adds zope.component lookup methods to an interface. Adds utility([default], [name]) and adapt(*args, [default], [name]). assert IInterface.providedBy(iface) def utility(**kw): if 'default' in kw: return queryUtility(iface, **kw) else: return getUtility(iface, **kw) iface.utility = utility def adapt(*args, **kw): if len(args) == 1: # simple adapter lookup arg = args[0] if not 'name' in kw and iface.providedBy(arg): # The object passed in already provides this interface, # and no adapter name was provided, so return the object # unchanged. return arg if 'default' in kw: return queryAdapter(arg, iface, **kw) else: return getAdapter(arg, iface, **kw) # multi-adapter lookup if 'default' in kw: return queryMultiAdapter(args, iface, **kw) else: return getMultiAdapter(args, iface, **kw) iface.adapt = adapt return iface --- (snip) --- Example usage: @componentlookup class IFoo(Interface): pass class Foo(object): implements(IFoo) IFoo.adapt(Foo()) IFoo.adapt(Foo(), HTTPRequest(), name='edit') IFoo.adapt(Foo(), name='x') IFoo.adapt(Foo(), default=None) IFoo.utility(default=None) I think class decorators were added in Python 2.6, but in earlier Pythons you can do this instead: class IFoo(Interface): pass componentlookup(IFoo) Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZODB Competing read/writes: How to find out which attribute?
Hermann Himmelbauer wrote: That's exactly the problem - it's a read operation and there should not be any write operation involved. However, it's hard to find out where the write operation in my code occurs, I can't find it in the view, maybe there's something in the authentication code, but I'd have to dig deep through my source. So It would be extremely helpful to know a faster way to find out what code triggered this warning. The code that modifies something will indirectly call the register() method of the ZODB.Connection class. If you arrange for Connection.register() to raise an exception when the transaction is not supposed to modify anything, you should get a traceback that pinpoints what is doing the modification. Unfortunately, there is no API for that, so the easiest thing to do is modify the source code of the register() method in ZODB.Connection. Fortunately, this is Python, so modifying someone else's code is usually quite easy. :-) Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZODB Competing read/writes: How to find out which attribute?
Hermann Himmelbauer wrote: Hi, I once in the while get the following warning in my Zope 3 log, which I'd like to resolve: 2009-10-07T14:35:41 WARNING ZopePublication Competing writes/reads at /BSPSite/act/++vh++http:zis.act.at:80/bankneu/++/c/acc/booklist/index.html: database conflict error (oid 0x7a5d, class BTrees.OOBTree.OOBTree, serial this txn started with 0x0381388ca6804966 2009-10-07 12:28:39.023700, serial currently committed 0x03813893b087d0cc 2009-10-07 12:35:41.374343) That URL looks like it should only be reading the database, but the fact that you get a conflict error suggests that the code behind that URL is writing to the database. If I were you, I would first ensure that read operations never write to the database. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2 WebDAV and acquisition
Martin Aspeli wrote: Can anyone explain why that condition is there? Otherwise, I'll rip it out. ;-) As I recall, this code is convoluted because it's hard to tell whether an HTTP request is a WebDAV request. If there is now a way to clearly distinguish WebDAV requests, then I imagine this code can be greatly simplified. This code had to deal with Windows 95 and such. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: zope.app.publisher refactoring
Hi Dan, I'll provide feedback for a few parts of your proposal. Dan Korostelev wrote: xmlprc - move the IXMLRPCView interface and XMLRPCView base class to zope.publisher as a counterpart to zope.publisher.browser.BrowserView. Move MethodPublisher, MethodTraverser, xmlrpc:view ZCML directive to new zope.xmlrpcview package. Also I'd merge MethodTraverser with MethodPublisher to make it easier to understand and to decrease number of entities :) Few developers care about XML-RPC these days. Most web developers are now working with REST, JSON, and other similar stuff. It's probably best to move all XML-RPC artifacts, including those in zope.publisher, to a single package, so that most developers can safely ignore the XML-RPC code. IXMLRPCPublisher adapters for zope.container - move them to zope.container. The IBrowserPublisher adapters that are already there, so it won't make things worser. The zope.container package may be refactored later to break dependency on zope.publisher though. You need Jim Fulton's input on this. I think his latest opinion is that zope.container should have nothing to do with publishing. IHTTPView and IFTPView interfaces - move that into zope.publisher as a counterpart to IBrowserView. (BTW, shouldn't IBrowserView be a subclass of IHTTPView?) In zope.app land, sometimes IHTTP* really means INonBrowser*. In other words, sometimes people want to define views just for HTTP ports not intended for web browsers. IFTPDirectoryPublisher interface - not sure what's this and where is it used. Probably should be moved to zope.publisher.interfaces.ftp as well. FTP is in the same boat as XML-RPC. Today, very few developers care to provide a dynamic FTP view of anything. WebDAV usually wins over FTP because adding SSL to WebDAV is easy. All FTP artifacts should move to a separate package. That's all for now. I'd like to see some comments/propositions/objections before I start. Also, maybe there are more beautiful names for new packages? The names you proposed seem ok. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Simplifying dependencies of zope.app.publisher
Fabio Tranchitella wrote: My knowledge of the zope.publisher is too limited to do any change in this area, but to me it looks like these configurations (both of them) should be perfomed by zope.app.publisher (removing the dependency zope.container - zope.publisher), but conditionally (zcml:condition) only if zope.container is installed, (removing the dependency zope.app.publisher - zope.container). I'm hoping Jim will soon take charge of zope.publisher, zope.traversing, zope.container, and zope.app.publisher, because he seems to be the only one who knows how they are supposed to be related. For example, which packages should be aware of XML-RPC? I would guess that none of them should have any notion of XML-RPC, and that there should be a zope.xmlrpc package, but my confidence in that guess is very low. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Why does zope.tales explicitly pin versions in buildout.cfg?
Fabio Tranchitella wrote: Is there a specific reason for having the version pinning? Automatic testing of zope.tales obviously fails using the KGS, because zope.traversing there is 3.7.1. Is it possible to remove the versions stanza? Sure. Pinned versions are OK for a maintenance branch, but not the trunk. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.index 3.5.2 broken
Marius Gedminas wrote: On Sun, Aug 02, 2009 at 08:48:24PM +0200, Andreas Jung wrote: Hi, the doctests for zope.index 3.5.2 - as used in Zope 2.12 - fail badly: File /home/ajung/.buildout/eggs/zope.index-3.5.2-py2.6-linux-x86_64.egg/zope/index/text/tests/../textindex.txt, line 143, in textindex.txt Failed example: [(k, %.4f % v) for (k, v) in index2.apply(Zorro).items()] == result I'm assuming items() returns a plain Python dictionary with string keys. Python's string hashes return different valuesfor half of all the strings on 64-bit machines. This influences the ordering of dictionary keys and some other things too (such as the sequence of random numbers you get if you use a string as the seed). Add a sorted() on both sides and the test should pass. Actually, those tests were plain insane and I've fixed them on the trunk. I intend to make a new zope.index release today. How insane were these tests? Well, the author of the tests noticed that the C optimization produces different scores than the Python version, and compensated for that in a way that dramatically reduced readability. Furthermore, the C code was producing incorrect results due to an unsafe optimization that accidentally took 32 bits of a Python float and pretended it was an integer. The breakage only became obvious when we started taking 64 bits instead, leading to completely different results. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.index 3.5.2 broken
Chris McDonough wrote: On 8/3/09 1:07 PM, Shane Hathaway wrote: How insane were these tests? Well, the author of the tests noticed that the C optimization produces different scores than the Python version, and compensated for that in a way that dramatically reduced readability. /me hangs head in shame. That was you? Well, it could have been worse. :-) Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Linux x86_64 [Was: Zope Tests: 3 OK, 5 Failed]
Hanno Schlichting wrote: I kind of suspect that we are seeing the results of http://www.python.org/dev/peps/pep-0353 though. That is very likely. BTW, that PEP links to a handy tool that reveals most 64 bit portability issues in Python-oriented C code. From what I understand we need to change code in C extension modules following the instructions in that PEP, to be able to run code reliably on 64-bit platforms. To my knowledge nobody changed any C code in Zope yet to do so. We fixed the C portability problems in Zope 3 a while back, but it seems we didn't fix the extensions that are specific to Zope 2. The other interesting bit to this is, that it seems doable but hard to do these changes while preserving compatibility with Python 2.4. These changes along with the definition of Py_ssize_t were introduced into Python 2.5. Preprocessor macros solve that fairly cleanly, actually: #ifndef Py_ssize_t #define Py_ssize_t int #endif At this point I think we need to declare 64-bit platforms as unsupported. Hopefully people with the right kind of knowledge would like to step up and start working on these issues. I just checked in some code that solves the portability problem in zope.index, although I haven't created a release. It looks like the Acquisition module needs some 64 bit TLC. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: Zope/trunk/versions.cfg Revert r101557 and put back version pins for zodbcode and zope.app.interface. These are actual dependencies of zope.app.zcmlfiles, which in turn is a test d
Tres Seaver wrote: Hanno Schlichting wrote: Log message for revision 101616: Revert r101557 and put back version pins for zodbcode and zope.app.interface. These are actual dependencies of zope.app.zcmlfiles, which in turn is a test dependency of numerous packages we use. Having a consistent known set of packages for tests is as important as having one for production. Shouldn't we just rip zodbcode et al out of a new version of zcmlfiles? +1 Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: ZTK custom publications, zope.app.publication, and zope.traversing
Jim Fulton wrote: They wouldn't. They don't use the URL traversal code. Non-URL traversal code would move to zope.tales. zope.container would depend on zope.tales rather than on zope.traversing. For my own education, I would like to understand why it makes sense for zope.container to depend on zope.tales. This dependency suggests people need to understand ZPT in order to understand container relationships, which seems wrong to me. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: ZTK custom publications, zope.app.publication, and zope.traversing
Jim Fulton wrote: On Jun 23, 2009, at 2:36 PM, Shane Hathaway wrote: Jim Fulton wrote: They wouldn't. They don't use the URL traversal code. Non-URL traversal code would move to zope.tales. zope.container would depend on zope.tales rather than on zope.traversing. For my own education, I would like to understand why it makes sense for zope.container to depend on zope.tales. This dependency suggests people need to understand ZPT in order to understand container relationships, which seems wrong to me. Because it provides traversal adapters needed soley by zope.tales. Sorry, you lost me on the first sentence (and the rest doesn't make sense yet to me as a result). You first said that zope.container is going to depend on zope.tales. Now you're saying zope.tales is going to depend on zope.container. If you meant the latter, then I understand. :-) Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.traversing/trunk/src/zope/traversing/ Moved the publicationtraverse module from zope.app.publication and added tests.
Jim Fulton wrote: Why? traverseName is part of zope.app.publication's implementation. Now it's oddly split off in a very separate package. The publisher traversal code is very similar to the code in zope.traversing, so I thought the best thing to do is put it in the same package as zope.traversing, so that traversal would be maintained in one place. Or, better yet, traverseRelativeURL and traversePath should be moved to the browser module and should get traverseName from request.publication. I'll go ahead and do this. That's fine. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] HA storage for zope
Chris Withers wrote: It's a shame that the 2 or 3 times I've tried to organise purchase of ZRS for customers, the Zope Corp sales process hasn't succeeded in delivering anything :-( (I'm not 100% on the details, but it may just have been that the prices were extortionate...) I disagree. The kind of fault tolerance ZRS provides is hard to achieve without a lot of either time or money. I suspect ZRS is less expensive than a new replicated Oracle setup, or paying a developer to invent something new. (I only recommend Oracle + RelStorage to people who have already invested deeply in Oracle.) Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] HA storage for zope
Hanno Schlichting wrote: Wichert Akkerman wrote: [lots of great info about RelStorage] I couldn't have said it better. :-) Thanks guys. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] package dependency refactoring progress report
Martijn Faassen wrote: It's interesting to see zope.deprecation is a new dependency. We could consider changing these deprecations to simple imports if this is possible... Certainly, but what is the right way to deprecate code, then? I'm not very happy about including zope.deprecation either, since it uses the sys.modules trick just like zope.deferredimport, but those deprecation warnings are important, aren't they? Knowing there are no cycles besides the zope.container one, this graph starts to look comprehensible, that's good. :) It's still really big though. Hmph. Thanks for the new graphs! Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] package dependency refactoring progress report
Martijn Faassen wrote: I'm not sure about zope.rest; there's already a z3c.rest which likely does something quite different, and I think a zope.rest package should actually *talk* about REST. What about zope.httpview instead? Well, no, I don't think it's generic enough to call that. zope.app.http is almost a webdav implementation, except I'm not sure it implements enough to actually work with most webdav clients. Another note, I think we should consider splitting off zope.app.publisher.xmlrpc, which looks quite independent from the rest, into its own package. So: zope.app.publisher - zope.view, zope.xmlrpcview I've pondered this split before, but AFAICT it would only increase the number of dependencies, so I've been waiting for the graph to shrink before talking about it. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] package dependency refactoring progress report
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shane Hathaway wrote: Martijn Faassen wrote: It's interesting to see zope.deprecation is a new dependency. We could consider changing these deprecations to simple imports if this is possible... Certainly, but what is the right way to deprecate code, then? I'm not very happy about including zope.deprecation either, since it uses the sys.modules trick just like zope.deferredimport, but those deprecation warnings are important, aren't they? Not so much, IMO. I think we can leave simple BBB imports in place, warning-free, forever (with a '#BBB' comment so that people don't delete them as unused imports). Ok, I've replaced all the zope.deprecation imports I added with BBB. What does BBB stand for anyway? Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] package dependency refactoring progress report
Martijn Faassen wrote: So, the only dependency cycles left in zope.app.publisher are these: zope.app.publisher -- zope.app.publication -- zope.app.http I fixed those tonight. On the trunk, there are no longer any dependencies between zope.app.publisher, zope.app.publication, and zope.app.http, except testing dependencies. Here is a summary of what I did: - Moved the publication traversal code to zope.traversing and simplified it from 3 classes to 1. This did not increase the dependencies of zope.traversing at all, since publication traversal is only slightly different from the traversal logic already in zope.traversing. It also opens the doors for someday moving the gnarly traversal code in zope.publisher to something saner in zope.traversing. - Moved an XML-RPC view registration from zope.app.publisher to zope.app.publication. - Moved IHTTPException, IMethodNotAllowed, and the MethodNotAllowed exception class to zope.publisher.interfaces.http. This move decoupled zope.app.http from zope.app.publication. - Moved getDefaultViewName() and queryDefaultViewName() to zope.publisher.defaultview. If you look at the commit messages, you'll see that I first attempted a different move that included the browser:defaultView handler, but that move turned out wrong for other packages and I reverted it. - I used zope.deferred to deprecate things I moved from zope.app.publication, zope.app.publisher, and zope.app.http. Are there any objections to using zope.deferred in those packages? In all, I changed 6 packages. Should I release them now, or should I look for other dependencies we might clean up at the same time? The changed packages are: zope.traversing (3.7.0) zope.publisher (3.8.0) zope.app.publisher (3.8.0) zope.app.publication (3.7.0) zope.app.http (3.6.0) zope.app.zcmlfiles (3.5.5; bugfix only) Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] package dependency refactoring progress report
Shane Hathaway wrote: Martijn Faassen wrote: So, the only dependency cycles left in zope.app.publisher are these: zope.app.publisher -- zope.app.publication -- zope.app.http I fixed those tonight. On the trunk, there are no longer any dependencies between zope.app.publisher, zope.app.publication, and zope.app.http, except testing dependencies. I should take a moment to describe the different purposes of these packages as I see them now. Conceptually, they are really quite independent. - zope.app.publisher: A library of ZCML directives for configuring views. Also provides generic view classes. A better name for this package might be zope.basicviews. A lot of packages depend on this. - zope.app.publication: Provides IPublication implementations and a mechanism/registry for choosing a different publication class for each request. Most packages should not depend on this. A better name might be zope.publicationregistry. - zope.app.http: Provides generic views that translate HTTP verbs like PUT, DELETE, and OPTIONS into map operations. The idea is clever, but not everyone needs a REST-style API. A better name might be zope.httpverbs. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] package dependency refactoring progress report
Martijn Faassen wrote: Shane Hathaway wrote: - I used zope.deferred to deprecate things I moved from zope.app.publication, zope.app.publisher, and zope.app.http. Are there any objections to using zope.deferred in those packages? No objection, but what's the reason to use zope.deferred instead of straight imports or zope.deprecation? To break the dependencies? I had forgotten about zope.deprecation. :-) I'll switch to that. In all, I changed 6 packages. Should I release them now, or should I look for other dependencies we might clean up at the same time? I'm +1 on releasing now. (and thanks for making them feature releases) Getting these things out there gives everybody who plays with this nicer dependency graphs and this tends to help improvement. Ok, I intend to release them today. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] package dependency refactoring progress report
Shane Hathaway wrote: Martijn Faassen wrote: Shane Hathaway wrote: In all, I changed 6 packages. Should I release them now, or should I look for other dependencies we might clean up at the same time? I'm +1 on releasing now. (and thanks for making them feature releases) Getting these things out there gives everybody who plays with this nicer dependency graphs and this tends to help improvement. Ok, I intend to release them today. Done. I look forward to seeing the changes in the dependency graph. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] package dependency refactoring progress report
Martijn Faassen wrote: Shane Hathaway wrote: - zope.app.publisher: A library of ZCML directives for configuring views. Also provides generic view classes. A better name for this package might be zope.basicviews. A lot of packages depend on this. I'm not sure 'basic' needs to be in there. Do we have anything less basic? What about simply calling it zope.view? (I don't like the plural in package names either generally) Sounds good to me. - zope.app.publication: Provides IPublication implementations and a mechanism/registry for choosing a different publication class for each request. Most packages should not depend on this. A better name might be zope.publicationregistry. I'm fine with this. I was considering 'zope.publication', but we already have 'zope.publisher' so that'd get very confusing again, something we should avoid. Right. - zope.app.http: Provides generic views that translate HTTP verbs like PUT, DELETE, and OPTIONS into map operations. The idea is clever, but not everyone needs a REST-style API. A better name might be zope.httpverbs. Even though I don't really like the plural, I think 'zope.http' would promise a bit too much, so 'zope.httpverbs' sound better. Another option is zope.rest, because a simple REST interface is what the package tries to accomplish. So if we get some consensus about this, we need volunteers that can help move the code over to these new packages and leave backwards compatible imports in the old places. Is there anything in these packages we can safely leave behind do you think? (ZMI related, perhaps?) I haven't come across anything we'd want to leave behind. Summarizing: zope.app.publisher - zope.view zope.app.publication - zope.publicationregistry zope.app.http - zope.rest Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] package dependency refactoring progress report
Marius Gedminas wrote: On Sat, May 23, 2009 at 08:59:34PM +0200, Martijn Faassen wrote: What about simply calling it zope.view? (I don't like the plural in package names either generally) FWIW at some point I decided that singular is appropriate when a package defines a concept, and plural is appropriate when a package provides multiple implementations of that concept. Thus you have zope.interface but zope.$anything.interfaces. In this case it's a plural of metaconfiguration. Maybe zope.viewzcml? I think that would express the intent even better. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] package dependency refactoring progress report
Chris McDonough wrote: On 5/22/09 1:11 PM, Martijn Faassen wrote: After some work we'd gotten it down to this: http://startifact.com/depgraphs/zope_app_publisher_cycles2.svg And by now the main cycles left are these: http://startifact.com/depgraphs/zope_app_publisher_cycles3.svg So, the only dependency cycles left in zope.app.publisher are these: zope.app.publisher-- zope.app.publication-- zope.app.http In isolation, it sort of looks like we should just collapse zope.app.publication and zope.app.http *into* zope.app.publisher, given that the relationships between the packages are all cyclical. Well, zope.app.publication and zope.app.publisher are really completely different, despite their similar names. zope.app.publication is a publisher implementation, while zope.app.publisher contains publishable resources. IMHO, zope.app.publisher is more broadly useful than zope.app.publication. So I'm working on removing the dependency from zope.app.publisher to zope.app.publication. It's mostly done, but I'm writing tests for the code I'm moving, since it never had any tests... I'm thinking about also removing the reverse dependency (zope.app.publication - zope.app.publisher). I think the default view name logic might belong in publication, not publisher. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.app.publication dependencies (volunteersneeded!)
Martijn Faassen wrote: It might actually be the best to move these ZCML directives *down* into zope.component. That won't affect the dependencies of zope.component at all in fact; the [zcml] dependencies of zope.component already need all the dependencies that zope.app.component's view and resource directives implement. I see that zope.component now relies fairly heavily on the setuptools extras_require, which makes the proposed move possible. At what point did we decide extras_require is good? Just curious. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12.0 beta 1 released
Andreas Jung wrote: I will cut a beta 2 release by tomorrow. Objections? A couple of bugs have been fixed in ZODB, so it might be useful to get another ZODB release out first. http://svn.zope.org/ZODB/trunk/src/CHANGES.txt?view=markup Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope2.12.a04 / relstorage / zodbconvert.py errors
Jürgen Herrmann wrote: ZConfig.SchemaResourceError: import name does not refer to a package Package name: 'relstorage' File name: 'component.xml' Package path: None I need to make a new release of RelStorage before this will work. RelStorage 1.1.3 does not work with ZODB 3.9, but the current RelStorage trunk does. I intend to package and release a compatible version today or tomorrow. FWIW, I suspect ZConfig is attempting to import relstorage and getting an ImportError due to the incompatibility, but then ZConfig is converting the ImportError into a strange SchemaResourceError. It would be much better if ZConfig just propagated the ImportError. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
zopyxfil...@gmail.com wrote: On 27.04.2009 22:56 Uhr, Shane Hathaway wrote: Lennart Regebro wrote: Or, we could release 2.12 soon, and then start working on 2.13, a +1. We need an eggified, Buildout-friendly Zope 2 that's fully compatible with Zope 2.11. Zope 2.11??? In other words, let's not discuss any more sweeping changes for Zope 2.12. I want an eggified Zope 2 release soon so that RelStorage is easier to support. :-) Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Defining Zope 3.
Albertas Agejevas wrote: On Sat, Apr 18, 2009 at 08:32:52AM -0600, Shane Hathaway wrote: Given that definition, Zope Toolkit will start relatively small, since much of Zope 3 does not yet qualify. However, as people refine packages, the packages will be reconsidered for inclusion in the Zope Toolkit, and the Zope Toolkit will hopefully grow into something similar to what we currently know as Zope 3. Zope 3 can't die; people are relying on it and maintaining it. The maintainers are doing a rather good job too, IMHO. The checkins list has been active lately. We don't have to create any more Zope 3 tarballs, but we should keep up the KGS. The Zope Toolkit will be the subset that's good for building applications, web sites, and frameworks. Zope 3 will be designed only for building applications and web sites. +1, this sounds like a good way forward. Thanks. It occurred to me that one simple test of a Zope naming scheme is to consider what employers will write in job descriptions. Consider these alternatives: 1. Candidate must be have Zope 3 experience. 2. Candidate must be experienced with the Zope Toolkit. #1 is ambiguous. If I'm highly experienced with Grok or Repoze, doesn't that count? What if I'm a modern Plone developer? If the HR department does the hiring, they are likely to disqualify good candidates. #2 should allow developers experienced with Grok, Repoze, modern Plone, and possibly even Twisted, but does not allow old-school Zope 2 or inexperienced Python developers. This seems much more like what typical employers want to express. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Defining Zope 3.
Shane Hathaway wrote: 1. Candidate must be have Zope 3 experience. 2. Candidate must be experienced with the Zope Toolkit. Of course I meant... 1. Candidate must have Zope 3 experience. 2. Candidate must have Zope Toolkit experience. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Defining Zope 3.
Lennart Regebro wrote: On Mon, Apr 20, 2009 at 18:42, Shane Hathaway sh...@hathawaymix.org wrote: It occurred to me that one simple test of a Zope naming scheme is to consider what employers will write in job descriptions. That's a bloody good point. Thanks. I take it this point reinforces your proposal that we should both create Zope Toolkit as a subset of Zope 3, *and* rename Zope 3 to something else. We could rename Zope 3 to Zope Toolkit Reference Application for the InterNet, or ZTRAIN. This name expresses several intents: - Zope 3 is the reference application for building something for the Internet on top of Zope Toolkit. - Not all of the Zope community is using it. If everyone were using it, we would call it simply Zope. However, someone is using it, otherwise we wouldn't bother naming it. - Zope 3 was derailed (pun, ha ha) a bit and now we're trying to put it back on track. - People who like Ruby on Rails might like this too. Also, it follows the open source tradition of slightly whimsical names. The logo could be a train engine driven by a Zope fish. :-) Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Defining Zope 3.
Lennart Regebro wrote: On Mon, Apr 20, 2009 at 23:32, Shane Hathaway sh...@hathawaymix.org wrote: Also, it follows the open source tradition of slightly whimsical names. The logo could be a train engine driven by a Zope fish. :-) Done. Does this mailing list accept attachements? Wowsers. LOL! Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Defining Zope 3.
Martijn Faassen wrote: You're right of course, I apologize for going that way. I have little excuse for that. You've taken a lot of heat in this thread. I hope that doesn't bother you too much, because I think you're an extremely valuable team member. This kind of discussion is hard, but it is an important part of any mature project. I find it rather encouraging that so many people are participating in this thread. Clearly, the Zope project has many dedicated contributors. I don't know how valuable my opinion about all of this is, but I'll suggest it in case it's useful. In my mind, I've been thinking of Zope Toolkit as the subset of Zope 3 that has well-managed dependencies. Zope 3 already has good code and excellent test coverage, but what's controversial about it is the mad package dependency graph as you reach inside zope.app. Given that definition, Zope Toolkit will start relatively small, since much of Zope 3 does not yet qualify. However, as people refine packages, the packages will be reconsidered for inclusion in the Zope Toolkit, and the Zope Toolkit will hopefully grow into something similar to what we currently know as Zope 3. Zope 3 can't die; people are relying on it and maintaining it. The maintainers are doing a rather good job too, IMHO. The checkins list has been active lately. We don't have to create any more Zope 3 tarballs, but we should keep up the KGS. The Zope Toolkit will be the subset that's good for building applications, web sites, and frameworks. Zope 3 will be designed only for building applications and web sites. I'll be able to recommend Zope Toolkit to friends without hesitation. They will be able to learn the ZTK in small steps because the dependency graph will be comprehensible. It will never be necessary to learn all of ZTK to be productive. Many will start with the ZTK and eventually realize they only need a small subset of ZTK. They will be happy when they discover how easy it is to use a subset of ZTK. Zope 3 is the thing I'll still recommend to people who decide they want to drink all of Zope in at once. Some people have good reasons to want that, after all. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
Martijn Faassen wrote: Stephan Richter wrote: On Friday 10 April 2009, Jim Fulton wrote: Unfortunately these are ZC's use cases. They are not just ZC's use cases. Keas is relying on that safety heavily too. Anyone who wants to build a secure DSL based on Python really wants zope.security. Okay, second case of such usage noticed. One thing that worries me is that PyPy folks keep saying it probably isn't really secure, though they refuse to specify why not when Chris Withers tried to find out last year at EuroPython. I suspect that's because Python allows anything by default; zope.security and RestrictedPython only provide a way to close known holes. The security model of Javascript running in a browser is very similar, though, and that seems to be good enough for most people. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] naming Zope
Martijn Faassen wrote: If nobody volunteers to do this (feel free to organize more volunteers), we'll stick with Zope Framework. Let me know if you're going to do this and when you're done. FWIW, I think this particular pile of libraries is in fact best described by the name framework, because the code we're discussing often calls user code rather than the other way around. For example, looking up and using an adapter is deep in framework territory. The name framework has earned a bad name just because there are so many bad frameworks out there, but there are plenty of good ones too. Good frameworks use library-like patterns where possible, falling back to carefully designed framework-like patterns. Zope Framework will be one of the best frameworks. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] naming Zope
Martijn Faassen wrote: If we don't call Zope Framework 4.0, we'll be fine. We should call its first release 1.0 and there's no implication of a progression. +1 on calling it Zope Framework 1.0. We need the people who have been burned by past Zope releases to take another look, because we believe Zope is finally getting simpler. Those people would assume Zope-anything 4.0 is just piling on more complexity, while a version 1.0 release would invalidate that assumption and suggest they take another look. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] naming Zope
discussion type=bikeshed Tres Seaver wrote: WRT the Framework name: framework is a misleading name for the collection of packages salvaged from the new Coke effort: it is actually a *bunch* of frameworks, in the classic software engineering sense, along with some pure libraries. Zope Toolkit, perhaps? (No relationship to Portal Toolkit. :-] ) /discussion Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Constant values defined in interfaces
Chris McDonough wrote: FTR, I do often put constants in an interfaces.py module at module scope (if there are more than one related, sometimes in a dictionary or within a non-interface class statement) in order to not feel I need to create some constants.py module. Maybe we could just agree that doing so isn't some sort of violation of intent? +1 Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.password
Christian Theune wrote: I remember that at the sprint we used to identify packages which are always good. E.g. zope.interface is a declared no-brainer to add to your dependencies. The other two that keep popping up that we *might* wanna white-list are zope.schema and zope.component. To whitelist zope.component would be quite interesting. As I recall, there was a time when all packages that depended on zope.component were required to be in the zope.app namespace. I don't object to the idea, though. We're using zope.schema and zope.component almost like language features. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] setting missing minimum version in setup.py
Roger Ineichen wrote: What do you do if version x.y works with d.e.d but not with d.e.e (because it's borken) and fixed in d.e.f. This means you could use d.e.d or d.e.f. but not d.e.e What's your solution then? Fix the version to d.e.d or d.e.f or skip fixing versions? The version requirements in setup.py should specify only API compatibility. They have nothing to do with bug fixes; that's the domain of the KGS. How about an example. Let's say we have zope.schema version 5.2, which requires zope.interface version 4.1 because zope.interface version 4.0 has a different API. Let's also say that zope.interface version 4.1.5 has a bug that breaks zope.schema, but versions 4.1.4 and 4.1.6 are OK. Since that level of detail is burdensome and unnecessary for setup.py files, zope.schema should require zope.interface = 4.1 and let the KGS provide the finer detail. People who don't use a KGS will be fine because they'll get 4.1.6+ as soon as it's released. Note; Not that fixing versions in a package is a bad thing in general. But such fixed versions will mess up the KGS that's the bad part. And since the KGS solves any kind of version conflict problems, there is no way to do it in a package anymore. The KGS is too fine grained for many uses. I, for example, would like to use the latest z3c.form, but I really can't, because it relies on a bunch of other packages with revised APIs and the API requirements are not written anywhere. I don't care about bugs; I can fix bugs. What I can't do is read other developer's minds to discover API version requirements. Note that if I could use the current z3c.form, I would also be able to help develop it. Surely many other developers face similar circumstances. Thus I believe the Zope project is quietly missing opportunities for developers to get involved due to the lack of coarse-grained version requirements. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Extras (was zope.password)
Stephan Richter wrote: On Tuesday 10 March 2009, Dan Korostelev wrote: Either you have a dependency and declare it or you don't have a dependency. Since we don't want to use extras anymore, I think this calls for another package which depends on zope.password and zope.schema. I still don't like/get the idea of creating and maintaining extra package that merely contains a vocabulary factory for another package. Whatever, I reverted that change. Roger, just exclude zope.app.authentication's password.zcml file, include zope.password explicitly and define your own vocabulary. I think we have become dependency paranoid. And we embrace package proliferation instead, which in my opinion is equally bad. If you really hate the dependency, make it an extra requires. I know that goes against the latest guidelines as well...*sigh* My big problem here is that we dismiss all solutions but new packages. We want to minimize dependencies and not have extra includes. The only choice left is a separate package. We should, however try to make the number of packages a parameter too. It seems to me that extras are a lot like Gentoo USE flags, except that the infrastructure for USE flags is much more complete. USE flags are an essential feature of Gentoo. Perhaps if the Python packaging chain had similar infrastructure, there would no longer be a reason to avoid extras and we could solve packaging and dependency problems a lot more easily. Here are a few things you can do with USE flags that you can't yet do with extras: - You can enable or disable a USE flag globally (yet override it per-package). If you don't need X-Windows on your server, just add -X to /etc/make.conf, and nothing will be built with optional X support. If we had this feature, we would just add -zope.component to buildout.cfg and nothing would be installed with optional component architecture support. - Packagers can specify whether a USE flag should be enabled by default. - USE flags can cause whole chunks of code to not be compiled or installed. I would love to be able to specify -coptimizations to build a Zope app without any optional C optimizations. (That way, tracebacks would often be more informative.) These days I run both a Gentoo and an Ubuntu box. The Gentoo box has more features, but fewer packages, because Gentoo doesn't have to divide packages to avoid dependencies. My $0.02. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
Jim Fulton wrote: I'd rather leave zope.publsiher more or less alone, but develop a new thing that has the basic/core functionality we need and refactor zope.publisher to use that. I'd also like to use or be compatible with WebOb on that. I'd prefer to do this at PyCon where I'll have time to pay attention and where there will be higher bandwidth communication. I look forward to PyCon! :-) Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
Martijn Faassen wrote: Jim Fulton wrote: [snip] I'd rather leave zope.publsiher more or less alone, but develop a new thing that has the basic/core functionality we need and refactor zope.publisher to use that. I had the impression Shane was doing that; i.e. building zope.pipeline factoring bits out of the publisher but not really changing the publisher very much itself, creating a new structure instead. Shane, is that correct? Yes. I think Jim and I are saying the same thing there. The current code in zope.pipeline doesn't reflect that thinking, though, because we really need to divide zope.publisher somehow before a project like this makes sense. +1 on the WebOb compatibility. I imagine it should be possible to reconstruct our request and response interfaces on top of WebOb's. We should also think of ways so that code can get the WebOb request directly instead of having to go through these adapters. I'd also be much in favor of reusing WebOb's implementation, not just the APIs. I think it could help us replace part of the publisher. That should be a great thing to work on in a sprint. Thanks. I'm very much in favor of you guys talking at PyCon if that's the best way to make progress. I'm also looking forward to seeing Shane again at PyCon after meeting him so briefly all these years ago when I was still young and nimble. So I'm glad to hear he's going to make it! I'm also happy I'll get to see you again as well! I'll be the one who arrives Monday afternoon without much hair on top. :-) Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
Jim Fulton wrote: - It's not well enough documented. While I think there's merit in doing some things at the WSGI level, I remain pretty happy with the publication interface for separatating generic publisher functions from application policies. I which the use of this API was better communicated and understood. I hope you're not asking me to write documentation for zope.publisher :-), because I only understand the mechanics. The overall scope and purpose is cloudy to me. In particular, I don't understand how the publication interface is actually generic. Does it fit the needs of anything other than Zope? A less major complaint is some baggage from the past. There are a number of request features that I never use and tend to forget about. The biggest of these is the special form data unmarshalling and url manipulation support. (I was amused to read in your introduction to your pipeline proposal that people wanted to know the answer to the question: When does Zope respect the :method form variable?. :) FWIW, that particular functionality has been pulled out twice now, both in repoze.monty and zope.httpform. As a baby step, we could make zope.publisher depend on zope.httpform. (I made zope.httpform without knowing repoze.monty already existed, but zope.httpform has more tests and interfaces and it's hosted on svn.zope.org, so I think zope.httpform is worth keeping.) Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher
Roger Ineichen wrote: Shane, Can you review and merge this changes into your zope.pipeline branch? I'm going to put zope.pipeline on hold until the PyCon sprints. Jim and I need to discuss it in person; hopefully then I can understand his opposition and the group can decide on the best direction for zope.publisher and zope.app.publication. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope.pipeline proposal
Hi all, I've put up a draft of a zope.pipeline proposal: http://wiki.zope.org/zope3/ZopePipeline The proposal is intended to explain my thoughts on the subject more thoroughly. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope.pipeline proposal
Dan Korostelev wrote: Also, how easy is to integrate existing non-zopeish WSGI middlewares into the zope.pipeline? Like some resource injectors or XHTML slimmers and so on. It would be really great to be able to do that with single ZCML directive. You can do that with two ZCML directives. I probably need to elaborate on the directives in the proposal. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope.pipeline proposal
Roger Ineichen wrote: Do you know something about the performance of WSGI? I whould be happy to see some perfomance tests comparing WSGI with other server concepts. WSGI is extremely lightweight, so WSGI itself isn't going to affect performance. The WSGI servers I know about are reasonably fast. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope.pipeline proposal
Martin Aspeli wrote: I'm used to using Paste Deploy ini files to configure a WSGI pipeline. Is this simply an alternative to that? If so, do we really need our own alternative, or could we try to use the Paste Deploy stuff directly? Yes, you can just use Paste Deploy instead of the ZCML-based pipeline builder. However, the pipeline you get with Paste Deploy will not vary according to the request type, so you won't get the publisher's special handling for non-browser methods like PUT and DELETE, nor XML-RPC support, etc. OTOH, I'm sure people can find creative ways to make Paste Deploy vary the pipeline according to the request type. I am a little worried about the conceptual overhead of having both the ZCA and the WSGI pipeline provide swappability services to application builders. It feels like those two things overlap somewhat in scope. They do overlap, but the ZCA-configured pipeline can easily vary according to the request type. I need to add more info about this to the proposal. Also, looking at your endware, there are some that seem to overlap with Repoze stuff. Is this on purpose? I think the relationship with Repoze should be made more clear in the proposal. I don't know what the relationship is yet because I've chosen to only get code from Zope, for now, since I'm trying to maintain compatibility. virtual_host -- is this the same as repoze.vhm? Could be. Not sure. retry -- is this the same as repoze.retry? I think it might be different, because this version of retry resets the environment rather than the request. It has to be in the pipeline before the create_request application. This design makes it possible to eliminate the complex retry code from Zope requests. create_request -- should this maybe have some compatibility with WebOb requests? I've looked at WebOb, and my impression is that Zope requests and WebOb requests serve completely different purposes. A Zope request is essentially an input decoder and information holder. A WebOb request is a whole framework, AFAICT. That said, I expect zope.pipeline to give people a greater opportunity to prove I'm wrong about things like that. switch_pipeline -- could this be made non-Zope specific? It sounds useful. I need to understand better what you mean by non-Zope specific. How would you use it? log -- both repoze and paste have logging middleware, IIRC Sure. I haven't bothered to write this app at all since I know lots of people have written such things. open_root -- I thought repoze had something similar, but I may be wrong I think this one is significantly different from Repoze. It would be good to communicate about stuff like this at a sprint. clean_transaction -- is this not the same as repoze.tm2? No. To mimic the current Zope publisher, we need to commit the transaction shortly after the call application is finished, but then a lot of things can still happen before the response leaves the server, so we need to make sure any open transaction is aborted before letting the open_root application close the database. This application is very small. It might make sense to have the open_root application do its job instead. handle_error -- again, I thought Repoze had something like this This error handling is very different from Repoze, I think. It's going to handle errors the Zope way, by looking up error handlers in the database. I imagine a lot of people will want to remove or customize it. end_transaction -- sounds like the other end of repoze.tm2 This is like repoze.tm2, but it will also annotate the transaction. Note that the code in my sandbox does not yet reflect this thinking. authenticate -- sounds like repoze.who? I doubt it. This does the IAuthentication dance, allowing authentication to be added during traversal. fix_relative_links -- sounds generally useful outside Zope as well I wish, but this application depends on Zope's traversal logic to determine the canonical URL of an object. I don't think the same traversal information will be present in most frameworks. OTOH, I imagine fix_relative_links could be rewritten as a more broadly useful thing, if someone can figure out how without breaking performance. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope.pipeline proposal
Hanno Schlichting wrote: What's the overhead of a WSGI middleware? Is the overhead cost in the same order of magnitude as a simple function call with a return value or is there something inherently more complex going on? A WSGI middleware app is simply a callable thing that calls the next app, so the overhead is literally the same as a simple function call. There won't be security proxies or any other such thing getting in the way. From my current experience I usually classify things into the groups of: 1. attribute access 2. function calls 3. adapter lookups Going from one of these groups into the next one has a very noticeable performance cost involved, if used on the critical path of the application. The current publisher is chock full of function calls and adapter lookups along the critical path. I expect the zope.pipeline project to open everyone's eyes about just how much we're already doing in the critical path. I think much of it is frequently not needed at all. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope.pipeline proposal
Martin Aspeli wrote: Shane Hathaway wrote: Martin Aspeli wrote: clean_transaction -- is this not the same as repoze.tm2? No. To mimic the current Zope publisher, we need to commit the transaction shortly after the call application is finished, but then a lot of things can still happen before the response leaves the server, so we need to make sure any open transaction is aborted before letting the open_root application close the database. Why is it desirable to do things in this way? I do find it kind of confusing/error prone that we have two pieces of middleware: one that opens the transaction and another that closes it, with ordering dependencies between the two. I'm trying to express something different, actually. The first app, clean_transaction, only exists to cancel accidental writes. The Zope publisher does this today. The actual transaction management is in the second application, which I now realize is misnamed as end_transaction because it both begins and ends transactions. repoze.who seems to be turning into something of a widely used standard. I think it'd be worth looking into whether it can be used 'upstream' and something else could do the IAuthentication stuff based on what repoze.who does. Ok, that changes my perspective a bit. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
Jim Fulton wrote:
On Feb 24, 2009, at 3:08 AM, Shane Hathaway wrote:
I've been working on the dependencies to and from zope.publisher.
Refining the dependencies should make it easier to integrate
zope.pipeline when it's ready.
Can you elaborate on this a bit?
I've been discussing zope.pipeline on my blog. I am attempting to
rebuild the publisher to make it easier to understand and customize. I
think it's working out pretty well. zope.pipeline is intended to
replace most of the implementation code in zope.publisher and
zope.app.publication.
To accomplish that, it looks like I ought to separate the
implementations in zope.publisher from the specifications. Separating
the zope.publisher.interfaces package would mostly accomplish that.
After thinking this over last night, I realize that the idea to move
BrowserView, BrowserPage, and TestRequest is driven by the desire to
clarify the dependency graph. That's more complex than what I'm trying
to do and I don't think I need to do that for zope.pipeline, so I'm
going to withdraw from that part of the discussion for now.
I've noticed that nearly all packages that depend on zope.publisher
depend only on a few pieces of it:
- zope.publisher.interfaces
- zope.publisher.browser.Browser{View|Page}
- zope.publisher.browser.TestRequest
I'd like to turn this around a little bit. Only browser-based code
should depend on zope.publisher. This seems like a very reasonable
dependency. It's like wxwindows UI code depending on wxwindows.
Maybe the browser code should be factored out of the packages that
depend on zoep.publisher so that only *that* code has the dependency
and non-browser code doesn't.
I think things are already pretty well factored in that sense. Take
zope.formlib, for example. It wouldn't make sense to separate
zope.formlib into an abstract package and a browser package, because
zope.formlib only makes sense for browsers.
Shane
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
Jim Fulton wrote: I disagree strongly with many of the assertions made in these articles. (I can't judge the pipeline proposal, since it is only fleshed out in code.) While I do think zope.publisher has some problems, they aren't the same problems that shane sees. What are the problems with zope.publisher as you see it? Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
Martijn Faassen wrote: The main problem I have with the zope publication machinery is that after all these years of using it I *still* get lost in it regularly. A more regular architecture that can be traced more easily would not only allow better understanding on my part, but might also allow us to more easily selectively replace or remove bits of it. +1. As I recall, we tried to build a regular architecture in zope.publisher using the IPublication interface, but the publisher machinery is still painfully difficult to understand without extensive study. I think a pipeline design will make the publisher a lot easier for everyone to understand because the pipeline design seems to keep concerns closer together. For example, I've made a traversal module in zope.pipeline which has nearly all of the traversal logic in one place and almost nothing else. Its code came from at least 4 scattered modules. Now, in theory, when people want to understand traversal, they will usually only need to understand one module. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3
Jim Fulton wrote: I agree that it shouldn't go in zope.app. I believe I suggested putting this in zc.openid, although I'm fine with zope.openid. I'll rename it to zc.openid. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3
Dan Korostelev wrote: 2009/2/24 Jim Fulton j...@zope.com: I agree that it shouldn't go in zope.app. I believe I suggested putting this in zc.openid, although I'm fine with zope.openid. Why zc? I thought it's only for packages coming from the zope corporation. Or does Shane works for ZC? :) This is for a ZC contract. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
Martijn Faassen wrote: Hey, On Tue, Feb 24, 2009 at 11:26 PM, Jim Fulton j...@zope.com wrote: [snip] The graph only shows direct dependencies on zope.i18n and zope.security, but there are many other direct dependencies. Ah, agreed, yes, I think this is because of the transitive dependency functionality removal somehow, even though it seems to remove more than just these. Hanno's now also generating the real graphs, though: http://hannosch.eu/dependencies/zope/zope.publisher-full.svg I see in that graph a number of dependencies that are pulled in just for specifications. For instance, zope.publisher doesn't really need the Location class, it only needs ILocation. Just brainstorming, but I wonder if we shouldn't split at least the following packages into specification and implementation packages: - zope.location - zope.security - zope.i18n - zope.publisher - zope.component That way various packages could use i18n interfaces without pulling in pytz, or could use location interfaces without pulling in zope.proxy, and so on. Brainstorming deeper: we could apply a naming convention where the specification package is named with the suffix spec, so zope.location would be split into zope.location and zope.locationspec. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher dependencies
Stephan Richter wrote: On Tuesday 24 February 2009, Shane Hathaway wrote: Brainstorming deeper: we could apply a naming convention where the specification package is named with the suffix spec, so zope.location would be split into zope.location and zope.locationspec. what about zope.ilocation? Maybe. I'd lean toward zope.locationspec because it would appear right after zope.location in a sorted list, making it more apparent that they are related. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3
Dan Korostelev wrote: 2009/2/24 Shane Hathaway sh...@hathawaymix.org: Log message for revision 97183: New library for OpenID auth in Zope 3 Changed: A zope.app.openidconsumer/ Wow, that's great! Finally an OpenID auth plugin is being developed! Thank you :) I thought about publishing this myself many times, but now, as you are doing that, I'll be happy to help developing and testing this package. Thanks, though I should warn you that it's not at all ready to try out yet. I imagine it has broken imports and the like. I'll let you and the zope-dev list know when it's in a testable state. BTW, this is what I'm getting paid to do at the moment. :-) Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Coding style clarifications
Fred Drake wrote: On Thu, Feb 19, 2009 at 11:03 AM, Jim Fulton j...@zope.com wrote: BTW, I strongly discourage from imports. (I didn't always have this opinion, but have seen the error of my ways. Thanks to Fred Drake for nudging me in this direction.) IMO, this is wildly more important than any of the issues raised in this thread. You're welcome. :-) You're saying that: import zope.interface.Interface class IFoo(zope.interface.Interface): ... is better than: from zope.interface import Interface class IFoo(Interface): ... ? Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Single Sign On
Gary Poster wrote: We use the OpenID 2.0 identifier select URL. This is a special OpenID url that basically means: identity using whatever ID you have on that server. The OpenID response will contain the actual OpenID identifier of the user at the end of the request. So sites that we integrate in our SSO simply sends you to Launchpad for authentication and then uses the returned identifier to link with their local account representation. We also use sreg (Simple Registration) to transfer information about the account to the integrated sites, so that they can update their local account representation with the central data. I see now! Thanks, Francis and Gary. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Single Sign On
Reinout van Rees wrote: So: easiest way is to let some trusted apache plugin handle the hard part and then laugh all the way to the bank with some 100-line authentication plugin. That would usually work, but in this case, customers will be doing their own installation, so we need to keep the number of installation steps down. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Proposed Patch for zope.site
Today I ran into an exception masked by Zope 3. I found the code that was masking the exception and fixed it locally, but since this small bit of code has no docs or tests, I can't be sure I won't break stuff if I check in my change. What do y'all think I should do? Here is the patch: Index: src/zope/site/hooks.py === --- src/zope/site/hooks.py (revision 96718) +++ src/zope/site/hooks.py (working copy) @@ -91,10 +91,7 @@ def adapter_hook(interface, object, name='', default=None): -try: -return siteinfo.adapter_hook(interface, object, name, default) -except zope.component.interfaces.ComponentLookupError: -return default +return siteinfo.adapter_hook(interface, object, name, default) def setHooks(): Catching ComponentLookupError is a problem when an adapter factory looks up another adapter. If the first adapter lookup succeeds but the second fails with a ComponentLookupError, the current code makes it look like the first adapter is not registered at all. Very confusing. This patch exposes the correct traceback. I think my patch is correct because the 'default' parameter implies to me that if 'siteinfo.adapter_hook' can't find an adapter, it will return None, not raise ComponentLookupError. If 'siteinfo.adapter_hook' does in fact raise ComponentLookupError, then something else must be wrong and we should report the exception. BTW, until recently, this module lived in zope.app.component. It looks like this exception masking originated in Subversion revision 26391. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Single Sign On
Marius Gedminas wrote: It's my impression that launchpad.net is an OpenID provider only, while Shane is trying to figure out how to use the OpenID consumer API in AuthKit. No. I am going after the more conventional single sign on use case where many consumers depend on only one centralized identity provider, and I'd like to use a restricted form of OpenID to accomplish it. It turns out that Launchpad's internal authentication system is pretty much exactly what I was planning to do, so Gary's info pointed me in the right direction. Launchpad also happens to provide public OpenID services, but I don't need to do that. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Single Sign On
I'm working with a customer on a single sign on (SSO) system for Zope. We haven't yet chosen which SSO system we want to use. I would like to hear from anyone who has set up SSO with Zope. We have some definite requirements: * We can't accept arbitrary identities like OpenID normally does. We need to set up our own identity provider (IDP) and force our servers to accept only identities provided by our own IDP. * The SSO process should be very similar to an ordinary cookie-based login process. I don't want the user to have to enter their username on one form and their password on another, but that's the standard OpenID process. * This will be implemented in Zope 3. We are considering OpenID, Shibboleth, CAS, and any other mature system that others might suggest. Shibboleth seems like the most obvious fit, but it's nowhere near as popular as OpenID. I haven't yet looked at CAS in detail. Alternatively, I have wondered if we actually need full-blown SSO; perhaps a carefully constructed domain-wide cookie would do the trick. Any experiences with that? Thanks to anyone who participates. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCML implementations: where should they go
Hanno Schlichting wrote: Wichert Akkerman wrote: I'ld rather not see a whole slew of extra packagse appear. I also wonder how the extra number of packages and increasing size of sys.path influence performance and restrictions on environments like GAE. For environments like GAE you don't want setuptools and its magic to be part of your application. This is were repackaging your entire app into one zipped egg or some other flat structure comes in handy. Setuptools and eggs are a distribution format from my point of view. They are certainly not the best way to deploy your applications. The growing sys.path is affecting performance to some degree in all deployment environments. Well, zc.buildout ought to be able to eliminate this concern for GAE deployment. I haven't tried the recipe below, but it certainly seems like the right idea. http://pypi.python.org/pypi/rod.recipe.appengine Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 3.4.0 Released!
Stephan Richter wrote: It is finally here! Thanks goes to everyone who involved! January 29, 2009 - The Zope 3 development team announces the Zope 3.4.0 release. Excellent! I have to say, though, that the download process is quite confusing. Let's say I'm a Pythonista who wants to try out Zope 3. Google sends me here: http://download.zope.org/zope3.4/ After the release overview, the document tells me Zope is now distributed as eggs. I'm familiar with eggs and I like them. Then it talks about the KGS and my buildout. It tells me how to modify my buildout configuration. Wait, what's a buildout and how do I configure it? Hmm, none of the links about the KGS tell me much about this buildout thing. I can already tell it's gonna be hard to learn about Zope... Well, I'll skip over the KGS stuff and see what I can figure out anyway. Ok, I can follow the easy_install directions. I'm really savvy and I'll even use virtualenv to do it, even though the document doesn't mention that. I already have the habit of using virtualenv whenever I use easy_install. So, following the directions, I create a project called HelloWorld. I try to fire it up. Uh-oh... zope.configuration.config.ConfigurationExecutionError: class 'zope.configuration.exceptions.ConfigurationError': Help Topic definition [...]/transaction-1.0a1-py2.5.egg/transaction/README.txt does not exist So it breaks before even starting the server. This is really trying my patience, but I study a lot of web pages and discuss the problem with other developers over a few days. Following a friend's recommendation, I add the following two lines to the [buildout] section of buildout.cfg generated by zopeproject: extends = http://download.zope.org/zope3.4/3.4.0/versions.cfg versions = versions After running bin/buildout again, the server finally starts! Of course, what I see when the server starts is opaque and uninviting, but I'll leave that for another discussion. :-) So, my question is: what should the download page *really* say? Consider that existing developers of Zope 3 don't actually need this page at all since they already use zc.buildout. This page's audience, then, is people who know little about zc.buildout, let alone the KGS. Newbies need straightforward directions to follow. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.publisher/trunk/ Fixed LP #322486: setStatus() now allows any int()-able status value.
Tres Seaver wrote: Is there any reason to hide the KeyError behind a 500, rather than letting it propagate to the application? In this implementation, we lose the information about the bad 'status' value. I agree, but I hit a legacy design snag. The handleException() method still calls setStatus(exception_type_name), where we could be handling any kind of exception, similar to what Zope has always done. IMHO, we should change the contract of setStatus() to not do any lookup at all and make handleException() do the lookup instead, or something along those lines. But I'm trying to make conservative changes ATM. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: relstorage/trunk/ Corporation - Foundation
Benji York wrote: On Sat, Jan 24, 2009 at 9:43 PM, Shane Hathaway sh...@hathawaymix.org wrote: Log message for revision 94997: Corporation - Foundation AFAIK, the IP hasn't been transfered yet. I'm not sure what the implications of using Foundation are at this point. Even so, I have no doubt that assigning the copyright to the foundation is better than assigning to a corporation. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Remove 'Add Product' in Control_Panel
Hanno Schlichting wrote: I just checked in another little change that allows you to disable the persistent product registry and have Zope still work. Just specify enable-product-installation off in your zope.conf before starting Zope the first time and watch Zope, CMF and Plone run without any entry in that list :) /me claps! Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Plans for Zope 2.12
Chris Withers wrote: I don't think this is such a huge change, it's a change in the style of what RP does already, not a complete re-implementation... OTOH, with Python 3 now released, it seems unlikely that we'll see any new syntax added to Python 2.x. So RP doesn't really need any sort of overhaul until we start switching to Python 3. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Salt-weakness in zope.app.authentication passwordmanagers?
Uli Fouquet wrote: Ok. I'll put something into the zope.app.authentication branches for review. Great! Two remaining questions: I would like to use `os.urandom` instead of `random.randint` to create the salt, because this is recommended in cryptographic contexts. There was, however, a problem with this module in former times: sometimes it stopped until enough entropy was available, which could make threads and processes hang. Is this still an issue? Well, the Linux man page for urandom says that /dev/urandom never blocks, while /dev/random can block if the entropy pool runs out. I assume os.urandom uses /dev/urandom. Last question: How should we handle lack of SHA-2 hashes in the Python standard lib of 2.4? Self-implementing sounds too error-prone to me while existing Python ports of the reference implementation in PyCryto etc. are implemented in C which would make `zope.app.authentication` a binary package. Something I would like to avoid. Or is support for Python 2.4 running out anyway? Let's not implement the SHA-2 version yet. SSHA, based on SHA-1, is sufficient for now. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Salt-weakness in zope.app.authentication passwordmanagers?
Uli Fouquet wrote: Do we need a SMD5-manager as well (same as SSHA, only with MD5 instead of SHA1 as hash algorithm)? I doubt it. Any reviews by the more competent gurus in the list are highly appreciated. Your implementation and docs look fine to me. The only comment I have is I wonder why this is zope.app.authentication instead of zope.authentication, but that's a different discussion for another day. Shae ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Salt-weakness in zope.app.authentication passwordmanagers?
Martijn Faassen wrote:
Shane Hathaway wrote:
We should really be using the SSHA standard (as defined by LDAP) as a
minimum. SSHA was the default in Zope 2, but someone forgot to bring
this code over to Zope 3.
http://svn.zope.org/Zope/trunk/lib/python/AccessControl/AuthEncoding.py?rev=94737view=markup
So perhaps this should be ported over and we should do an announcement
that we ask people to use that instead?
Yes. The first volunteer to change we should do it into I have done
it will earn recognition, glory, and a permanent place in Zope's
Subversion history!
Also, every encrypted password should have a scheme name prefix in curly
braces, such as {SSHA}, as discussed earlier in this thread. That
makes it possible to support multiple schemes in a single database,
which is essential for migration to new schemes.
Shane
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Salt-weakness in zope.app.authentication passwordmanagers?
Uli Fouquet wrote: Shane Hathaway wrote: http://svn.zope.org/Zope/trunk/lib/python/AccessControl/AuthEncoding.py?rev=94737view=markup Is there some recent documentation about SSHA available? The netscape links seems to be down. I'm not sure where to find that documentation now (Mozilla keeps breaking URLs, grrr), but the slapd package in Ubuntu (probably Debian also) provides the simple slappasswd utility. slappasswd hashes passwords using SSHA by default. In theory, the SSHA algorithm in AuthEncoding.py matches the SSHA algorithm in slappasswd. If it doesn't, we need an implementation that perfectly matches slappasswd. The code looks quite similar to what is done in the current SHA1 password manager, but if there is a standard we could follow, we might should do that and recommend people to switch. SSHA is much more secure than plain SHA-1 because SSHA is not vulnerable to a trivial dictionary attack. Let's say I'm an attacker and I manage to steal a bunch of SHA-1 encrypted passwords. Now I want to expose some of those passwords so I can attack related sites. I would build a database of SHA-1 hashes of dictionary words and common names with some variations, then I would see if any of those hashes are in the list I stole. Assuming some of the users are naive, chances are pretty good that I'll expose a few passwords in seconds. This is an O(m * log(n)) problem, where m is the number of password hashes I stole and n is the number of words in my dictionary. It might even be O(m) if I first apply a perfect hash algorithm to the dictionary. With SSHA, my work is much more difficult. Instead of running the encrypted passwords through a trivial reverse mapping, now I have to encrypt every word in my dictionary using the salt provided for each password. This is an O(m * n) problem, so it could take hours to find a common password and years to decipher a well chosen password. Note that SSHA is in fact more secure than SHA-256 when applied to passwords, since a dictionary attack on a scheme with no salt is approximately O(m * log(n)) regardless of the hashing algorithm. SSHA seems cryptography-wise to be as strong or weak as the used hash algorithm (which here was SHA-1), so I wonder whether you would like to replace the standard SHA1 manager by an SSHA manager or vote for providing a new one. We can't take away existing password schemes, but we can allow multiple schemes to coexist using a curly brace prefix, then change the default to the most secure available. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Salt-weakness in zope.app.authentication passwordmanagers?
Uli Fouquet wrote: Is there some recent documentation about SSHA available? The netscape links seems to be down. I finally found a good source. Look at the Python code at the bottom of this page: http://www.openldap.org/faq/data/cache/347.html Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Salt-weakness in zope.app.authentication passwordmanagers?
Uli Fouquet wrote: while working on a password manager tool (commandline) for Grok I stumbled over the usage of salts in the password managers of `zope.app.authentication`. In short, they seem to generate (and store) a salt number but do not make any use of it when it comes to creating the hashes (SHA1, MD5, whatever). As a result, same passwords lead always to same hashes, only the leading salt number is different. This could be exploited by dictionary attacks. We should really be using the SSHA standard (as defined by LDAP) as a minimum. SSHA was the default in Zope 2, but someone forgot to bring this code over to Zope 3. http://svn.zope.org/Zope/trunk/lib/python/AccessControl/AuthEncoding.py?rev=94737view=markup A SHA-256 version of the algorithm would also be useful since cryptography experts expect SHA-1 to be vulnerable soon. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope3-Users] Next Step to Bug Resolution???
Dan Korostelev wrote: I just committed a fix for zope.schema's ValidationError that makes its repr output more sensible. I'd like community to review those changes and say if they're okay, because changing exception formatting syntax will affect doctest so they should be adapted to new style. +1. The output I see in the checkin is much more readable to my eyes. http://mail.zope.org/pipermail/checkins/2009-January/028856.html Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Next Step to Bug Resolution???
Tim Cook wrote: I DID submit a patch suggestion in the Launchpad bug report. I think you're talking about this: https://bugs.launchpad.net/zope3/+bug/301226 Sorry, but the patch doesn't make any sense. Your version of _validate_fields quietly skips validation entirely by default. Why would the function be called _validate_fields if it doesn't actually validate unless the caller passes some special parameter? The function needs to validate the fields regardless of the parameters. I would also like for you to explain just what it is about my attitude that you find so offensive/problematic? Please ignore comments like that. They are not worth dealing with. I traced down and described the problem to the function level. I suggested a fix and asked for experts to review and apply it. I do not have (and am not qualified to have) commit access to ZCA source. So again, referring to the subject line. What are the next steps? Here's a tip: for a programmer, good error messages are like gold. The right error message will save you countless hours (or months) of frustration. Therefore, making error messages readable is one of your top priorities. You have been presented with a very poor error message. Fixing that error message doesn't look very difficult on the surface, so your first priority should be to make that error message readable. Marius was on the right track: http://mail.zope.org/pipermail/zope3-users/2008-October/008218.html Look at the __repr__ method of the ValidationError class in the _bootstrapinterfaces.py module of the zope.schema package. This method was designed to generate short error messages, but in your case it appears to be truncating the error messages altogether. I would start by changing that particular __repr__() method to: def __repr__(self): return '%s(%s)' % (self.__class__.__name__, repr(self.args)) This version prefers verbosity. At a minimum, I hope this version of __repr__ will change the bizarre message zope.schema.interfaces.WrongContainedType: [, []] into something legible. Still, I don't know if my version of __repr__() is appropriate for everyone else, so I am not going to touch SVN yet. For now, this is just something that might help you find the real cause of the bug. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Subclassing an Interface Doesn't Work?
Chris Withers wrote: This is all interesting discussion, but I'd *really* like to know why subclassing an interface when the C-based implentation is in use doesn't work. Does *anyone* actually know the answer to this? (rather than avoiding it by trying to make the problem something else ;-) ) This is a completely different question, so I've changed the subject line for you. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
Martijn Faassen wrote: Besides an import checker you'd need a system that would be able to thrawl through a ZODB and report deprecated classes. The drawback is that it'd need to thrawl through a ZODB, so that's rather costly. Thrawl = thrashing crawl? Never heard that word before, but it's apt. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
