Re: [Zope-dev] Re: TALES idea: tuple unpacking
On Wed, 30 Jul 2003 12:13:41 -0500 Evan Simpson [EMAIL PROTECTED] wrote: Jim Penny wrote: Well, that is exactly why it will be more confusing to everyone. A python programmer is not expecting them to be different, and a non-programmer has no idea of what keys and indices are, much less how they differ. The explanation isn't that hard, at least for a user with a basic knowledge of data structures -- you usually use key: with a dictionary, and item: with a sequence. The exception is when you have an integer key in a dictionary. It is in fact not only hard to teach, it is impossible to use. Look, the ZPT programmer has no way of discovering whether the python programmer has returned a dictionary, a sequence, a Set, or anything else, much less what the key type is. Introspection is not available to a ZPT programmer. So, you are back to asking the python programmer, who just as well do the work. And why would I expect a ZPT person to have a basic knowledge of data structures? Eeep, gad no. The python is horrible. The prefix syntax is equally horrible, unfamiliar, and ambiguous! For example, why does call: not have an argument Because I'm not passing an argument to the SQL statement. In my implementation, the syntax is call:arg1,arg2,..., where each argument is required to be a variable name. Every prefixed path element operates upon the current traversal object, using the argument (if any) to the prefix. Here's a list that demonstrates: x/key:foo -- x['foo'] x/item:0 -- x[0] x/attr:foo -- x.foo x/call:foo -- x(foo) x/var:foo -- getattr(x, foo) or x[foo] (path traversal semantics) x/fmt:%.2f -- '%.2f' % x x/fmt:thousands_commas -- thousands_commas(x) Doesn't it strike you as odd that sometimes the prefix denotes parameterization, and sometimes it denotes application? I hope that the list above makes the consistency clearer. No, it actually makes it clearer, and worse. It is an interesting notation, kind of, but hugely irregular, and that you and Chris are talking about two quite different semantics on top of a similar syntax does not help things in the least. One by one: key: and item: need to be combined, as they cannot be practically used by the ZPT programmer as separate entities, due to lack of introspection. var: is semantically clear, but I suspect will confuse the hell out of non-programmers. Frankly, and I freely admit that I have not a clue to the implementational details, I would prefer that key:, item:, and var: all be a single entity, say index: x/index:'foo' -- x['foo'] x/index:span_of_int -x[span_of_int] x/index:foo-- x[foo] call: well, you have said that arguments are allowed, and must be only variable names. What is the reason for this? I assume that only positional parameters are permitted. With named parameters, this is the part I have fewest reservations about. Is there any reason to avoid parentheses however? Does using call: explicitly erase all magic name bindings (I hope so)? Why not x/call:(parameter_list)? There are several reasons to consider this. The primary one is that niladic calls are explicitly marked. Another reason, again with niladic calls is that x/call:()/foo makes is more clear that the foo attribute of x() is being requested, rather than that /foo is an argument to x. The final one is that it would probably permit much more general parameter lists, possibly including constants and/or named parameters. attr: looks clean enough. Combinations of attr: and call: made me think for a while, but, I don't see any obvious problems. fmt: is most irregular. First, it reverses the pattern of all the others and makes the stuff to the left the parameter. This may be OK for your intended audience. It may also confuse them totally. Why x/fmt:%.2f and not x/fmt:'%.2f'? As it stands, it takes either expression fragments starting with % or function names. Can I define my own functions, if so, how/where? Finally, can we come up with a better term than prefix. In conventional terminology, most of these are infix operations, except call, which may be a purely postfix. Jim Penny Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
On Wed, 30 Jul 2003 15:59:47 -0500 Evan Simpson [EMAIL PROTECTED] wrote: Several of your objections/suggestions involve the distinction between a string and a name, as in: x/index:'foo' -- x['foo'] x/index:span_of_int -x[span_of_int] x/index:foo-- x[foo] I'd rather not introduce additional punctuation (quotes or parens) But you've already crossed the Rubicon, :, ',', and % have been introduced as punctuation (yes, not matched, which does make a difference)! I am not opposed to this idea, per se, I am worried about the fact that it is so slippery slopish, and that it is so non-standard notationally. As a add-on product, I would say, go for it! As core functionality, it worries me. Further, this is an engineering trade-off. You are trading parsing simplicity by requiring extra programmer awareness - things which a python programmer is often not consciously aware of. I am trying to strongly point this out, so that you are prepared for the inevitable confusion later. if I can help it -- TAL and TALES both have a tradition of minimalist syntax, and it keeps parsing simple. Also, as soon as you add delimiters, you add quoting issues, and TALES has enough of those already. call: well, you have said that arguments are allowed, and must be only variable names. What is the reason for this? To keep things simple. There's a clearly visible slippery slope here, Yes, but named parameters can be very nice, especially working with databases, they let you match between form names, which are often very specific and database column names which are often more generic. And permitting constants keeps the programmer from an artificial requirement to define bind a constant to a name just to use it in a conditional section. I do understand the parsing issues, and can accept them, although I really would prefer named parameters be available, even if I have to give up constants. I strongly would urge you to use parentheses to denote functional application. Yes, I know there are alternative traditions, but they are much less common in practice. And the strongest one, RPN, was widely hated by 'the masses'. Does using call: explicitly erase all magic name bindings (I hope so)? I don't know what you mean, here. Well, grabbing missing parameters from request, and possibly (zope2) other places. fmt: is most irregular. First, it reverses the pattern of all the others and makes the stuff to the left the parameter. This may be OK for your intended audience. It may also confuse them totally. Why x/fmt:%.2f and not x/fmt:'%.2f'? As it stands, it takes either expression fragments starting with % or function names. Can I define my own functions, if so, how/where? 'fmt' is a quick-and-dirty implementation, and most likely to change. It was almost certainly a mistake to conflate the standard formatting functions with Python string formatting. I don't agree that it reverses the pattern, though -- to me, it's apply *this* formatting operation to the current object, much like 'key' is fetch *this* key from the current object. well, even if you persist in the mistaken ;-) notion that it is written key: x/key:y -- x[y] x/call:y -- x(y) x/fmt:y -- y(x) 'one of these things is not like the others...' Finally, can we come up with a better term than prefix. In conventional terminology, most of these are infix operations, except call, which may be a purely postfix. 'prefix' refers to the syntax, not the operations. In my source code comments, I refer to prefixed path elements. A better name would be welcome :-) Hmm, maybe 'decorated path'. I am worried that prefix, postfix, and infix already have meaning, and this is more an infix language than a prefix language. But, I lost on 'snake thingy', so I will lose here to :-( Jim Penny ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
On Tue, 29 Jul 2003 14:27:34 -0400 Paul Winkler [EMAIL PROTECTED] wrote: On Tue, Jul 29, 2003 at 06:22:38PM +0100, Chris Withers wrote: Paul Winkler wrote: On Wed, Jul 23, 2003 at 11:07:20AM -0500, Evan Simpson wrote: ... This would allow options/a_mapping/key:items/index:0 rather than python:options['a_mapping']['items'][0]. Why is that an improvement? Personally, I find it much easier to read... I find the opposite: Neither is easy to read. Go to your nearest non-programmer unit, spousal, parental, whatever. Watch the My Eyes Glaze Over, (MEGO) phenomenon take immediate effect. Assuming that the reader does NOT understand any python, it doesn't make much sense. The immediate questions arise: What's a key? What's an index? What's the difference between them? How do I know when to use one or the other? And, how do you answer those questions without talking about python data structures? I agree with Paul here. I hated the int: because it had nothing to do with indexing. I could reluctantly accept index: -- but it will not help the intended audience. Only programmers understand things like indices, keys, etc. What is worse, is that it builds a bunch on un-pythonic syntax, which will get in the way of learning python later. Let ZPT handle the simplest things, and escape to python as needed. Lo, ZPT has not even a proper expression syntax. All that is going on here is creating a syntax for some extremely limited special cases, a really non-standard syntax. And, the syntax depends on having some python programmer create the dictionaries or sequences that are being referenced. That to me, is the fatal flaw. It is hard to argue, on one hand, that a python programmer is available to you whenever you need a sequence created, and on the other hand, that he is no longer there to consult/hand work off to when a simple expression is needed. Jim Penny ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
On Tue, 29 Jul 2003 16:43:21 -0400 Shane Hathaway [EMAIL PROTECTED] wrote: [Paul Winkler] I guess I don't understand the goal. Are we trying to make it so that zpt authors don't have to know any python? [Chris Withers] For me, that would be ideal... [Paul Winkler] I really think that's a mistake. Guys, that line of thinking is a distraction. ZPT authors ought to learn Python. The issue is deeper than that. I'll explain below. [Paul Winkler] Assuming that TALES python expressions are banned/discouraged/whatever, [...] Python expressions won't be banned. I will never consider them discouraged for all cases, either. There will always be a need for constructs like: div tal:condition=python: a == b.../div div tal:condition=python: (a and b) or c.../div However, the following is quite bad: tal:x define=ss nocall:modules/Products/PythonScripts/standard a tal:attributes=href python: ss.url_quote(some_url) / /tal:x Frankly, would not even have occurred to me - I would probably create a tiny Script (Python) en passant, and called it directly, as: a tal:attributes=href python: here.url_quote(some_url) /. I did not realize that this is deprecated in Zope3. This is un-Pythonic in numerous ways. snip a tal:attributes=href here/format:url_quote / To me, that's a vast improvment, and it's only one example. But, what does all of this have to do with index:, key:, int:, etc.? index: and key: are particularly interesting, in that they use different syntax for something that python conflates syntactically. That is, an integer indexed reference looks exactly like a string indexed reference, both have form structure[key]. Jim Penny ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
On Tue, 29 Jul 2003 17:04:46 -0500 Evan Simpson [EMAIL PROTECTED] wrote: Jim Penny wrote: But, what does all of this have to do with index:, key:, int:, etc.? index: and key: are particularly interesting, in that they use different syntax for something that python conflates syntactically. That is, an integer indexed reference looks exactly like a string indexed reference, both have form structure[key]. Well, that is exactly why it will be more confusing to everyone. A python programmer is not expecting them to be different, and a non-programmer has no idea of what keys and indices are, much less how they differ. I proposed distinct key: and item: in order to kill some implicit magic before it was born: x/key:0 is the same as python:x['0'], while x/item:0 is the same as python:x[0]. It seems clear to me that subpath prefixes are going to be part of Zope 3, no matter how opinion on this thread goes. It wasn't hard to implement them for Zope 2, and I find them useful. While I agree that someone who can deal well with x/item:0 will have no problem with python:x[0], I also assert that many such people would join me in prefering options/lib/data/my.sql/call:/item:0/state to options['lib'].data['my.sql']()[0].state if only because the former allows me to specify access methods *only* for the exceptions to the norm, not for every path step. If that isn't valuable, what about path expressions is? Eeep, gad no. The python is horrible. The prefix syntax is equally horrible, unfamiliar, and ambiguous! For example, why does call: not have an argument, is it because my.sql is niladic, or is it that '/item:0/state' is the argument? Is options/lib/data/call:my.sql/item:0/state equivalent? Are parameters magic? If not, how are they discovered? I also offer for general consideration the following: options/foo/item:0 | request/foo/item:0 | default data/stat/fmt:thousands_commas | string:No data. Python expression equivalents, please? Yes, alternative is very nice. Yes, it can be done with python:path(), or by refactoring the expression to an script. Yes, the alternatives are harder to read, or more work. Nu? The syntax has kind of odd denotation, on top of everything else. The item:0 applies the integer indexing operator to the options['foo'] which must be a sequence type with parameter 0? (I thought that was index: ) The fmt:thousands_commas construct applies the thousands_commas operator with parameter data['stat']? Doesn't it strike you as odd that sometimes the prefix denotes parameterization, and sometimes it denotes application? Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
On Tue, 29 Jul 2003 17:51:56 -0400 Shane Hathaway [EMAIL PROTECTED] wrote: Jim Penny wrote: Frankly, would not even have occurred to me - I would probably create a tiny Script (Python) en passant, and called it directly, as:a tal:attributes=href python: here.url_quote(some_url) /. I did not realize that this is deprecated in Zope3. Ahh, OK. The damned here/context semantic trap again. It is too late to revisit, it is a done deed, it was a really good idea to call the concept context, self, and here, depending on what kind of object you are using, etc. But here suggests container more strongly to my mind than container does! So, I try never to use it. Jim Penny ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
On Wed, 23 Jul 2003 10:00:37 -0400 Shane Hathaway [EMAIL PROTECTED] wrote: We've come up with a number of generally useful prefixes, BTW. Off the top of my head: call: -- Call a named method int:-- Look up an item by index Hate this. Looks like a typecast of some kind, int is way to overused for this. If you must, why not index: ? Jim Penny format: -- Perform simple formatting operations like format:money zope: -- Access a big Zope API It sure would be nice to have these prefixes, both in Zope 2 and Zope 3. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope RPMs/debs and Linux FHS
On Sat, Oct 12, 2002 at 06:28:37PM -0400, Chris McDonough wrote: Hi all, I am working towards a unified Zope configuration and installation system on a branch of Zope named the 'chrism-install-branch'. I have given the buildout process on that branch the ability to create an RPM distribution of Zope. I intend later to give the buildout process the ability to create Debian .debs as well and maybe Solaris packages... I am doing this with the expectation that we might be able to provide RPM and .deb distros of Zope from zope.org instead of our current generic Linux as tarball distro. I haven't looked yet at the Debian packaging of Zope (by Gregor Hoffleit), but I intend to do that next to get some more ideas. I will be honest here. I don't care a lot about how the debian files are packaged, or where. But I do not want to see two sets of debs with differing layouts. I would rather that either Chris become an official debian maintainer and take over zope (and thereby upload it to the normal repositories), or that he leave debian packaging to Gregor, or whoever succeeds him. There is no reason that zope.org cannot have a short paragraph or two on installing zope under debian, which points people to the normal repositories; or alternatively, there is no reason that zope.org cannot mirror debian's zope and related packages. Jim Penny ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Some Zope distributions are missing Data.fs.in
On Wed, Sep 11, 2002 at 03:49:25PM +0200, Stefan H. Holek wrote: Same thing on Debian. 'Data.fs.in' is missing there as well. This is a problem for me as the ZopeTestCase relies on a working Testing package and error reports start to trickle in... This is not correct. Data.fs.in is in /var/lib/zope/Data.fs.in. As part of the postinst, it is copied to /var/lib/zope/var. Jim Penny ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] A Modest Proposal Concerning Monkey Patches
On Wed, Aug 14, 2002 at 08:46:41AM +0100, Adrian Hungate wrote: Again, monkey patching doesn't modify source code, so I don't know what would be getting written into tmp. Comments? Didn't someone else make a proposal (with code) to handle this? Was it PatchKit? Yup, and it is more than a proposal, it is a full blown product ( http://www.zope.org/Members/haqa/PatchKit ) with some patches already in it (They can be removed if you wish). Nope... we have been down this path before. Note this what I need (see below on why) requires modification, and not simple replacement, of whatever code is currently running. As far as I can see, Patchkit does nothing to make this possible. The problem is that A) monkey patches may or may not have been applied before a given product sees anything, and B) there is no reasonable way to discover what (or even if) patches have been applied by other products. If you are going to go down the monkeypatch path, then there needs to be some way for other monkeypatchers to discover what you have done, so that they can decide if they can 1) extend your code to be compatible with theirs, 2) refuse to install their code, or 3) blow your pre-existing code away. Current monkeypatch code always does 3. Patchkit has, as far as I can tell no way to make 1 or 2 easier. It just makes it easier to blow other people's work away! Background: I am debian maintainer for zope-zshell. The debian release is currently a version behind. I have been holding off updating it because I would like the ZMI box. I cannot modify manage_main.py directly, because it belongs to the zope package and the changes would be blown away on any upgrade of zope. I was starting to turn it into a python product, but zope-externaleditor has been packaged, and it monkeypatches manage_main. The naive thing to do would be to install it as a monkeypatch. But then, either I blow away externaleditor, or externaleditor blows away zshell, depending on the order in which zope installs products on startup. There are several other products that monkeypatch manage_main as well, building a nice mutual destruction club. Jim Penny PS: I would also like to hear general responses to Jerome's proposal. Clearly this was not an API, no arguments have been specified. But is there a general consensus that this is a reasonable thing to do? Please, if it isn't to late, could we make it a 2.6 thing? There is a fledgling API, though I probably need to document it better, make some unit tests etc, but it is there, and it works (For me... YMMV). But yes, some standard would be helpful, possibly with supporting utilities, to allow multiple monkeypatches coexist, I think. On the other hand, in Zope3 you just change the zcml files...although I think there was a discusion of an analogous issue there (coexistence of multiple modifications to the same area) and I'm not sure a conclusion was reached (but I can't remember for sure). Adrian... -- Adrian Hungate EMail: [EMAIL PROTECTED] Web: http://www.haqa.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] A Modest Proposal Concerning Monkey Patches
There is a large problem looming with Moneky Patches. The problem is that monkey patches are so Highlander. There can be Only One. For example, there are at least five or six products that monkey patch manage_main. Each simply replaces whatever manage_main exists at the time of instantation, and blows away any previous monkey patch. Some coordinated way of dealing with this problem needs to be arrived at. Proposal: for concreteness sake, suppose manage_main is being patched. A monkey patch author does the following: 1) checks to see if the file being patched is in $(INSTANCE_HOME)/tmp A) If not, he proceeds directly with the patch B) If so, he makes whatever checks he can to determine if he can update the file in $(INSTANCE_HOME)/tmp. i) If he cannot, it is his decision whether to follow current practice and simply blow away the current monkey patch (Boo! Hiss!) or, ii) fail (sigh, curse!). 2) If the monkey patch is installed, then the installed file is written in $(INSTANCE_HOME)/tmp. I.e., the new manage_main.py is written to $(INSTANCE_HOME)/tmp. This assumes that z2.py is modified so that it clears out $(INSTANCE_HOME)/tmp on each start. It might be also be a good idea to keep a section of comments at the top of the monkeypatch file showing the history of monkeypatch application. Comments? Jim Penny ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] multiple monkeypatches
On Wed, Jun 05, 2002 at 10:51:45PM +0100, Adrian Hungate wrote: PatchKit handles this for you (If you ask it to). :) Adrian... I am not sure that I understand. I need to be able to do a cumulative monkey patch. Suppose that there were two independent products which both modified manage_main (without loss of generality, say ExternalEditor and ZShell). Most people use neither, some people use one, some use the other, and some use both. It is the case of people using both that I am interested in. To do this appears to me to require that I have access to the DTML form of any previous monkey patches to manage_main so that I can decide if I can safely patch the running version to meet the needs of both products. Is this possible? If both products were using PatchKit would it be possible? How about if only one used PatchKit? Thanks Jim -- ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] multiple monkeypatches
Is there a safe way to handle multiple monkeypatches? Here is the problem. External editor monkeypatches ObjectManager.manage_main. There are some other products that also need to monkeypatch this object. For example, if Jerome Alet's Zshell were turned into a python product, it would be natural for it to monkeypatch this same object. But, if it does so, whichever monkeypatch is applied last will destroy the previous. Any ideas on a reasonably simple way to solve this problem. Thanks Jim Penny ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [ZPT] Order of attribute execution Feature Request
On Sat, May 11, 2002 at 02:55:23PM +, Florent Guillaume wrote: Jim Penny [EMAIL PROTECTED] wrote: I also have not found a convention that I am comfortable with on handling check-boxes and radio buttons in error processing. But I expect to! Are you referring to what I call magic boolean attributes ? http://lists.zope.org/pipermail/zpt/2002-March/003013.html Yes, thanks very much, this is very helpful. I see that you could find no documentation on this, and got no reply. Is this intended to be a permanent feature, or is is experimental? Jim Penny Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [ZPT] Order of attribute execution Feature Request
On Mon, May 13, 2002 at 03:32:21PM -0400, Shane Hathaway wrote: Florent Guillaume wrote: Jim Penny [EMAIL PROTECTED] wrote: Are you referring to what I call magic boolean attributes ? http://lists.zope.org/pipermail/zpt/2002-March/003013.html Yes, thanks very much, this is very helpful. I see that you could find no documentation on this, and got no reply. Is this intended to be a permanent feature, or is is experimental? I'm pretty sure it's permanent, only undocumented. Florent, do you have committer privileges? You can certainly check in documentation of this behavior. You can also add a comment to the Zope book. http://www.zope.org/Documentation/ZopeBook/AdvZPT.stx I will write up something and do the feedback thing in the Zope book. It seems to me it should be in both the advanced section and the ZPTRef section. Would like a bit of guidance on the Ref writeup, i.e., what does ZC want to call it (presumably not magic boolean attributes)? Jim Penny Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [ZPT] Order of attribute execution Feature Request
On Fri, May 10, 2002 at 11:53:47AM +0100, Chris Withers wrote: Jim Penny wrote: on the surface, to be pretty ugly. I have said that there are three specific things I dislike about ZPT -- 0) lots of things have changed spelling again -- request v. REQUEST, here v. context v. container v. this v. ? Yeah, there was absolutely no need for this and I did find it extremely frustrating. That said, the whole area has always been a mess, particularly in DTML. I do, however, wish that Script (Python)'s and ZPT could have been consistent :-(( 1) infix notation that makes program scansion hard, You don't HAVE to use infix ;-) tr tal:repeat=x xes td tal:content=x/idan ID/td /tr ...can also be written as: tal:x repeat=x xes tr tdtal:x replace=x/id//td /tr /tal:x Interesting. I seem to remember this from the Wiki's, is it documented anywhere else? This really seems like Chapter 5 material. 2) the order of operations, which I think is baroque. Six levels of precendence for eight statements is pretty amazing. And it is certainly harder to explain/remember than things happen in the order you specify. *shrugs* I've done a u-turn on this. Tim's comments make it perfectly obvious why this needs to be the case, and at least it is very well defined what order things happen in (as Ken pointed out). My only beef is that define sometimes happens in an order that is less helpful than it could be ;-) tal:x repeat=fish fishes define=species fish/species Actually, the first time I got bit was on repeat v. condition. I wanted the condition to test each row, not to guard the entire iteration process. ...doesn't do what I'd like it to ;-) I now agree with this, as well, on the basis that XML says no order, and that some XML tools may reorder. Yuck. OK, off to add following comments to Zope Book ZPT Reference -- Since the on-error statement is invoked ... +If multiple statements appearing within an element have the same +precedence level, the order of execution of those statements +within the precedence group is undefined. The reasoning behind these precedences begins with the fact that TAL statements are being writtten as XML attributes. By definition, XML attributes are un-ordered, and XML tools may, and do, rewrite attributes in any order they wish. But, for TAL to be useful as a programming language, there has to be a predictable order of operations. This order was chosen by the following rationale: ... Any objection to that wording? I will add a fourth nit -- I cannot see why attributes should be plural when every other command is singular. Certainly it feels like attribute ought to be an acceptable spelling of the atttributes command! *shrugs* this is pretty minor to be honest ;-) Hey, nits are by definition small. A foolish consistency is the hobgoblin of small minds but Make things as simple as possible, but no simpler! My most-missed DTML feature has not been mentioned at all -- it is not loop batching -- it is the dtml-else option of dtml-in -- which made it much easier to handle the nothing found case. tal:x define=pigs here/gimmeSomePigs tal:x repeat=pig pigs This little piggie went to tal:x replace=pig/location. /tal:x tal:else condition=not:pigs Waaagh! No bacon! /tal:else /tal:x Thanks... I also have not found a convention that I am comfortable with on handling check-boxes and radio buttons in error processing. But I expect to! Not sure what you mean, can you explain the problem a bit more? OK, consider a form like: pError Message (may be replaced)/p form action=. Name: input type=text name=namebr/ Type: input type=checkbox name=social_skills value=nerd checkednerd input type=checkbox name=social_skills value=geekgeek input type=checkbox name=social_skills value=mundanemundane ... /form On entry I would like a default to be checked. On call with an error message I would like the item that was most recently checked to remain checked. For example, suppose I needed to prevent multiple definitions of the same name. my validation routine could set error_message and then my tal would look like: p tal:replace=structure contents | nothingError Message/p form action=. Name: input type=text name=name tal:attributes=name request/name|nothingbr/ But how do I elegantly handle checked element? If checked were a true attribute (i.e. took form checked=1 or checked=0), it would be clear! But they aren't. cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman
Re: Support for X-HTTPD-FORWARDED-FOR Re: [Zope-dev] Speaking of 2.6...
On Wed, Apr 10, 2002 at 06:59:38PM +0200, Oliver Bleutgen wrote: Jim Washington wrote: 2. If we want to get fancy about allowing authentication using that ip address like naked ZServers can do, In lib/python/AccessControl/User.py, around line 1116, change if request.has_key('REMOTE_ADDR'): addr=request['REMOTE_ADDR'] to if request.has_key('HTTP_X_FORWARDED_FOR'): addr=request['HTTP_X_FORWARDED_FOR'] elif request.has_key('REMOTE_ADDR'): addr=request['REMOTE_ADDR'] I do not believe this does anything to authentication that is not possible now regarding spoofed ip addresses, so probably not a major security headache. Correct me if I'm wrong, but this IMO makes spoofing against a naked ZServer a childs play. It's just adding a custom header to the request. I also doubt that every reverse proxy overwrites this header, so zservers behind a proxy might also be hit. Note: this is using another web server to front for zope. It turns out to be fairly safe -- I have used a variant for quite a while and did quite a bit of testing. For short hand, I am going to call the other web server apache. Apache presumably uses something like getpeername to fill in its idea of HTTP_X_FORWARDED_FOR or REMOTE_ADDR. If the remote user attempts to spoof it (by using hidden variables, or other HTTP based techniques), the Zope server interprets this is a list, rather than the expected string. This is easy to detect, and in fact, if you fail to handle it, you will probably simply error out. If the attacker is using TCP spoofing, there is really not much you can do at an application level. On the other hand, I am now conviced that this is not an intelligent thing to do, not even for presentation. You already have Apache in front, so why not use rewriting rules to make the URL distinguishable. In this way, you can use one of the BASE or URL variables to determine how the person got in. This gives you pretty much the same level of control (especially if you are worried only about internal/external) as using IP addresses, without modifying either Zope or Apache. Jim Penny TCP spoofing OTOH is far more complicated, if (does it?) zope turns off the source routing option when replying, if present. IMO something like cracking a router or predicting sequence numbers is another level from adding a custom http-header. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Moving forward on Zope 2.6
On Wed, Mar 20, 2002 at 07:01:13PM +0100, Lennart Regebro wrote: From: Jim Penny [EMAIL PROTECTED] I now have two kinds of administrators, and two kinds of users. An interesting case. If I understand it correctly, with our workgroups scheme,the restricted administrators would have administration rights on a workgroup. They would then be able to create users and add them to the workgroup they manage, but they wouldn't be able to give the users any priviligies outside the workgroup, and hence the new users priviligies would be limited to whatever priviligies they can get through the workgroup. Right, although they may have adminstration priveleges on a set of workgroups. To give a motivation, consider a large company that has parallel design groups. The groups are intentionally kept in the dark about the other groups' work. Some companies do this to get a variety of choices to base the final decision on. Just to label them, call them Green, Blue, and Red teams. In this case, I might delegate an administrator who has authority over all of these teams, i.e, the administrator can (partially) control users or other administrators who have a subset of (Green, Red, and Blue) in their group list. The administrator, being a busy fellow himself, might create a Red administrator, who can (partially) control users or other adminstrators that have Red in their group list. Now, I am not really deep into modifying Zope core code at this point. The list of acceptable groups is available for any given user. The application programmer handles authorization and presentation. We have to have this for both reasons of scale and delegation of authority. Some, even many, of the design teams themselves use sub-contractors. We have no way of knowing the contractor's day-to-day relationships with the groups, and prefer not to know. Also, we are in a somewhat incestuous industry, and people move from company to company. While they obviously have what is in their head at the time of the move, we do not wish to give them knowledge of future plans. There are interesting policy decisions to make. Should an administrator be allowed to grant workgroup access to a pre-existing user? Can an administrator change a pre-existing user into an administrator? What does delete mean if the use has workgroups that the administrator does not control? Can the administrator see what workgroups the user has? Jim ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Moving forward on Zope 2.6
On Tue, Mar 19, 2002 at 04:11:05PM +0100, Lennart Regebro wrote: I also want groups! But I want a different kind of groups, that I call workgroups just to distinguish them from all other types of groups. :-) I don't know if it's possible implement this compatibly in 2.x, and I can't judge if there is any problems in implementing one type of groups in 2.x and then switching in 3.x. And of course, I'm worried that implementation of groups in 2.6 will lessen the possibilities of getting workgroups into 3.x. :-) A workgroup is a set of users, just like I understand that NuxUserGroups are. But you set up a workgroup just like you would set up the local roles for a folder, ie, you do not only assign users to the workgroup, *you also assign roles to them within this workgroup*. When setting up a workgroup you don't get access to anything but the workgroup itself. But, you can then add any number of workgroups to a Zope folder, and the users in that workgroup would get the roles they were assigned in the workgroup to that folder. That way you still get the grouping and indirection that you get from otehr grousp, but you also get a greater automatic granularity in that grouping. So, in technical terms a workgroup is macro of role definitions. When you add a user to the workgroup and give him a Reviewer role, he will get the Reviewer role at all the folders where the workgroup is added to the workgroup list. The workgroup Boss will get the Boss role in all the places where this workgroup is added. With normal grouping, you typically have one group per department, and give that department access to a couple of parts of the database. Then you have a group of the Bosses that have more access. But usually this means that all the Bosses have Boss access everywhere, which is not necessarily what you want. So, even if it is very tempting to let Florent implement the local roles blacklist instead of doing it ourselves :-), I'd rather wait for workgroups than standard groups. In any case Johan and me would be very happy to help Florent and the others at Nuxeo implement it groups and blacklists. I needed a generalization of this scheme (and so ended up writing my own User Folder). We manufacture parts which are controlled by second parties, but bought primarily by third parties. I will call these parties Manufacturer, Brand Owners, and Contractors. I now have two kinds of administrators, and two kinds of users. There are unrestricted administrators and users. Since this really is enforced only at the user folder level (normal zope machinery is used elsewhere), a quick description is that an unrestricted administrator may create, modify or destroy any user or Brand Owner Name, and may associate any list of Brand owner names with any user. Any unrestricted user has a flag designating him as such and it is expected that application code check the flag and permit access to the contents held for Brand Owners. Restricted Administrators may create new users, modify users, or delete (some) users. However, any user they create may have only a subset of their brand owner name list (and their normal zope permissions). They may remove any of their brand names from a user that has one or more of the brand names under their control. They may delete users that have brand names only under their control. They may also create other administrators, subject to the subset restictions. Restricted Users have a brand list associated with them. Application logic can use this brand list to filter content. The restricted administrator is a big deal to us. If this takes off, we will not be able to properly control the set of Restricted Users (at Brand Owners and Contractors). Failure to do so could lead to legal exposure, so by creating Restricted Administrators who are Brand Owners, the contrl (and thus most of the legal exposure) can be shifted back to the Brand Owner. Jim Penny Best Regards Lennart Regebro Torped Strategi och Kommunikation AB ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Benchmarks: DTML vs. ZPT?
On Fri, Feb 08, 2002 at 11:29:39AM +, seb bacon wrote: Well, I just ran a very naive test and it suggests that zpt may be about twice as slow as dtml. I made a DTML Method, and a ZPT, identical to each other, containing only HTML: html Test /html Then I ran the ab benchmarking tool against each method, thus: # ab -n 500 http://localhost:8005/zpt_test/dtml The results are reproduced below, along with the profiling information (sorry if it wraps badly) seb snip - snip. This is indeed very interesting. I also had an impression that ZPT was sometimes evaluating things that it did not need to in the presence of conditional tags. How does the timing compare with a Script Python and with an external method on your machine? (Yes, I understand they are very different from ZPT and dtml, but I think this might be useful information for a Zope architect. And this would give a common baseline.) Jim Penny ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Vulnerability: attacking can get file list and directory
On Mon, Sep 24, 2001 at 10:59:11AM -0400, Shane Hathaway wrote: Oliver Bleutgen wrote: From a non-technical, PR-wise point of view let me add that this type of vulnerability easily gets zope mentioned on lists like bugtraq. The perception is that these thing really are vulnerabilities. You're right, a quick search on google for path disclosure vulnerability yields a lot of hits for lots of applications. It troubles me that people consider PDV to be important at all when the client-side trojan bug is still fully exploitable on all browsers including IE and Mozilla! (AFAIK) Client-side trojans, which can cause your browser to invisibly post a comment on a weblog, execute a financial transaction, or break into servers you maintain, are a major risk. PDV just yields information you might give out anyway. But maybe we could deal with it anyway by writing an error.log instead of sending the traceback to the browser. What do you think? Yes, the error log approach is far preferable. But, it would be nice if the browser got a message something like: An error has occurred : (stuff above traceback information is printed). Refer your administrator to the error log key and then prepend each line of the error log for this item with . Then a simple grep would be enough to find the particular error in question. [And it might be really nice if errors were emailed to an administrator, as well as logged. If this is done, it would probably be desirable to have some sort of per folder property in which the proper contact(s) could be listed.] Jim Penny Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] removal of User Folders
Is there some function that is called when a User Folder is removed? If so, what is it? If not, is there a recommended way to delete users, any information stored about the User Folder's configuration, etc.? Thanks. Jim Penny ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPL and GPL licensing issues
On Thu, Jun 21, 2001 at 12:28:01PM +0200, Nils Kassube wrote: * Jim Penny [EMAIL PROTECTED] [2001-06-20 19:12]: As far as I can tell you are wrong, but there are certainly gray areas. The last time this came up I wrote such a scenario up and tried to get FSF clarification. Nothing ever came back. I got a clarification from the FSF. It's in the mailing list archives at http://lists.zope.org/pipermail/zope/2000-September/118024.html Some topics never die :-) I went and reread the clarification. OK, consider this from another point of view. If I have an operating system may I install a piece of GPL software on the operating system? May I redistribute the operating system? With the GPL software? May I invoke/run the GPL software? My understanding is that the answer to every one of these is yes. May I modify the GPL software and distribute it without giving downstream the same opportunity. Clearly no. Now, s/operating system/zope/g Do the answers to the questions change? And, if so, why? From my perspective, and I think from fog's the answer is that it should not change the answers. Maybe the easy way out of this is to simply declare zope an operating system rather than an application. Snippy thoughts cut here. Cheers, Nils ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPL and GPL licensing issues
On Thu, Jun 21, 2001 at 05:18:40PM +0200, Federico Di Gregorio wrote: On 21 Jun 2001 11:08:30 -0400, Jim Penny wrote: [snip] OK, consider this from another point of view. If I have an operating system may I install a piece of GPL software on the operating system? May I redistribute the operating system? With the GPL software? May I invoke/run the GPL software? My understanding is that the answer to every one of these is yes. yes. only if it is free. only if it is free. yes, but only because gpl allows for gpl code linking with the major components of the os even if they are proprietary. Uh, you might want to reconsider the only if it is free parts. After all Interix had a business of selling GPL software for a non-free OS. Now Microsoft has that business (NT Services for Unix Pack). IBM distributes gcc and perl. Cygwin sells GPL software for non-free OS's. May I modify the GPL software and distribute it without giving downstream the same opportunity. Clearly no. Now, s/operating system/zope/g Do the answers to the questions change? And, if so, why? From my perspective, and I think from fog's the answer is that it should not change the answers. err, no. if you write an external module using only python code, as long as you use a gpl-compatible python to run zope, you can call your external code from zope. if you write a product suclassing dc code, you're effectively 'linking' and gpl limitations apply. GPL limitations apply to whom: To you, the developer? To a downstream user invoking the product via dtml-call or dtml-var or their pythonish equivalents? To a downstream developer who modifies your product and redistibutes the modified product? To a downstream developer who writes a component that invokes the GPL component? In my mind the only sensible answers are developer - no, user - no (but see Jerome Alet's codacil), downstream modifier - yes, downstream developer who uses - no. The only other sensible option is that, indeed, no one may distribute GPL components for Zope, including the original developer. Maybe the easy way out of this is to simply declare zope an operating system rather than an application. Snippy thoughts cut here. eheh. nice try... :) -- Federico Di Gregorio MIXAD LIVE Chief of Research Technology [EMAIL PROTECTED] Debian GNU/Linux Developer Italian Press Contact[EMAIL PROTECTED] Don't dream it. Be it. -- Dr. Frank'n'further ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPL and GPL licensing issues
err, no. if you write an external module using only python code, as long as you use a gpl-compatible python to run zope, you can call your external code from zope. if you write a product suclassing dc code, you're effectively 'linking' and gpl limitations apply. GPL limitations apply to whom: To you, the developer? To a downstream user invoking the product via dtml-call or dtml-var or their pythonish equivalents? To a downstream developer who modifies your product and redistibutes the modified product? To a downstream developer who writes a component that invokes the GPL component? In my mind the only sensible answers are developer - no, user - no (but see Jerome Alet's codacil), downstream modifier - yes, downstream developer who uses - no. The only other sensible option is that, indeed, no one may distribute GPL components for Zope, including the original developer. as i said before, writing gpl code subclassing zope is a non-sense. even the author cannot, imho, redistribute its work with a plain gpl attached to it. the gpl says that if you link with gpl code *all* the code should be gpl or gpl-compatible (major os components like clibs, compilers, etc are an exception). so even the author cannot do that without licensing under gpl plus some exception (as a special exception you're allowed to link this code with zope or any other zope product distributed under the zpl.) see the (in)famous gpl vs. qt thread in the debian mailing lists for an in-depth analisys of this problem. ciao, federico OK, this is essentially what I wanted. Now the problem is completely distilled. DC and FSF somehow have to come to some understandings of the following questions. Can a GPL (unmodified) component be distributed for Zope (at all)? Can a GPL (modified per fog) component be distributed for Zope? If yes to either, may the component be invoked (dtml-var, dtml-call, or equivalent) from a non-GPL component? If yes to either, may the component be subclassed by a non-GPL component? Jim -- Federico Di Gregorio MIXAD LIVE Chief of Research Technology [EMAIL PROTECTED] Debian GNU/Linux Developer Italian Press Contact[EMAIL PROTECTED] The number of the beast: vi vi vi. -- Delexa Jones ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Using db_connections from Zope products
On Wed, Jun 20, 2001 at 08:54:41AM -0700, Tom Brown wrote: I would like to make an SQL query directly from python code. Do I have to make a ZSQL Method dynamically, or is there another way without making the class database dependent (i.e. Gadfly, PoPy, etc), utilizing an existing db_con? Suppose I am using the ZPoPy DA and have established a database connection externally. How can I access this database and submit a query from my own class? You can use an established connection. If it is ZSQL based, you will have to deal with the results object. A good overview of the results object is http://www.zope.org/Members/spinwing/ZSQL_Results You might also look at the somewhat dated http://www.zope.org/Members/jpenny/Accessing_a_ZSQL_Method_from_an_External_Method This would work from Script (Python), as well. Jim Penny Thanks, Tom Brown [EMAIL PROTECTED] __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPL and GPL licensing issues
On Wed, Jun 20, 2001 at 08:05:43PM +0200, Gregor Hoffleit wrote: On Wed, Jun 20, 2001 at 01:12:20PM -0400, Jim Penny wrote: It appears to me, that, if you want to play it safe, you would not distribute the code under license G and license T on the same medium. It is certainly acceptable to call code released under license G from code released under license T; but it is not clear that you can do subclassing and such. I think this is wrong. Providing things on the same media is mere aggregation and therefore not a problem on its own. BTW, I was responding to a question implicit in the original message, but not explicitly asked. The question is How do I minimize risk of inadvertant 'GPL Contamination'?. In this view, if you never distribute GPL and non-GPL code on the same medium, you have made a small step in making sure that they are considered as separate entities. After all, one of the more ambiguous part of the GPL is what is mere aggregation and what is a combined work. It is somewhat easier to consider something a combined work if it is always distributed with GPL code. Jim It's not acceptable, though, to distribute a proprietary program that has to be linked with a GPL component by the customer--even if you distribute this on separate medias! If you're interested in this, feel free to come over to debian-legal and read the ongoing discussion. Gregor ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RDBM Connections per User
On Tue, Jun 05, 2001 at 11:47:18PM +0200, Christian Theune wrote: Hello out there. I had following problem: In a software, using zope as appserver, we needed to have every user a single connection to the database (postgres 7.1) to have access- checks on database level. I think that this is not a very good idea. Consider, you are moving from a realm where there is one object (The database adapter) that needs to be tightly controlled to one that has many objects that must be tightly controlled (the database adapters, the database user ids, their passwords and ACL's). What happens when a db is accessed by someone with insufficient authority? A Zope error is raised and (unless you have caught it), a nasty looking traceback is triggered. It is just as much work to catch the tracebacks as it is to prevent them from occurring. So, you are not saving any application development time. Given the propensity of people to reuse passwords, and the general ease of finding user level passwords, you probably have a situation with many weak passwords rather than one strong one. No, in general, I recommend that you prevent people who have insufficient authority from accessing the database in the first place, and that you log CRUD events so that you know who is responsible for database damage. [Yes, this is a classic tradeoff. There is one position stated as defense in depth. Check the user at the Zope stage, check him again at db access time, etc. There is another that can be summarized as put all your eggs in one basket - and watch that basket carefully. In general, I support defense in depth, but my experience with users is that they simply do not help you with security. For the same reason, I will not give any users accounts on my firewall.] Jim Penny I hacked into the Connection code and found, that the interfaces are really hard to be used for this feature. The thing is, that many people are accessing the database connection handle directly whether I am using now a wrapper function getConnection() to get the current connection or open one. I am reading the current user out of the REQUEST[AUTHENTICATED_USER] and am storing the handles in an _v_connections Dictionary, which is explicitly not stored in database, but lets every user have exactly one connection. Any comments on this? -- Christian Theune - [EMAIL PROTECTED] gocept gmbh co.kg - schalaunische strasse 6 - 06366 koethen/anhalt tel.+49 3496 3099112 - fax.+49 3496 3099118 mob. - 0178 48 33 981 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b'))) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] usability bug concerning database connections?
regarding Zope 2.3.0: I removed a database connection from a top level (there is a second one). All my ZSQL methods were connected to the first one. The user interface now looks like if the second one is connected (it is shown as Connection Id). This is confusing. It would be better to have some indicator for the broken status of the ZSQL methods. Just a small bug report :-) Jan Seconded, and it would be really nice to be able to search by connection ID! Then if you were changing DA's, you could find the ones that needed to be changed rather than waiting for breakage. Jim Penny ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )