Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-30 Thread Jim Penny
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

2003-07-30 Thread Jim Penny
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

2003-07-29 Thread Jim Penny
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

2003-07-29 Thread Jim Penny
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

2003-07-29 Thread Jim Penny
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

2003-07-29 Thread Jim Penny
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

2003-07-23 Thread Jim Penny
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

2002-10-14 Thread Jim Penny

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

2002-09-11 Thread Jim Penny

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

2002-08-14 Thread Jim Penny

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

2002-08-13 Thread Jim Penny

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

2002-06-05 Thread Jim Penny

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

2002-06-04 Thread Jim Penny

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

2002-05-13 Thread Jim Penny

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

2002-05-13 Thread Jim Penny

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

2002-05-10 Thread Jim Penny

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...

2002-04-10 Thread Jim Penny

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

2002-03-20 Thread Jim Penny

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

2002-03-19 Thread Jim Penny

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?

2002-02-08 Thread Jim Penny

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

2001-09-24 Thread Jim Penny

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

2001-09-24 Thread Jim Penny

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

2001-06-21 Thread Jim Penny

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

2001-06-21 Thread Jim Penny

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

2001-06-21 Thread Jim Penny

   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

2001-06-20 Thread Jim Penny

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

2001-06-20 Thread Jim Penny

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

2001-06-05 Thread Jim Penny

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?

2001-02-22 Thread Jim Penny

 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 )