Re: [Zope-dev] Location of RelStorage

2013-04-12 Thread Shane Hathaway

On 04/12/2013 11:59 AM, Chris Withers wrote:

On 14/03/2013 08:01, Marius Gedminas wrote:

What's the official location of RelStorage?  I see two source trees:

   * http://zope3.pov.lt/trac/browser/relstorage/trunk
   * https://github.com/zodb/relstorage

They have the same commits (~1 year old).


..and one more just for good measure:

https://github.com/cjw296/relstorage

Would be good to have an official git repo under Shane's care.

Shane, where are you maintaining relstorage nowadays?


https://github.com/zodb/relstorage

See also: http://zope3.pov.lt/trac/browser/relstorage/trunk/MOVED_TO_GITHUB

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] CookieCrumbler, any new versions or replacement?

2012-02-02 Thread Shane Hathaway

On 02/02/2012 10:46 AM, Hugo Ramos wrote:

I need to reuse a web application I developed around 2005/2006. This
App was using CookieCrumbler as it's only authentication method but it
seems that after zope 2.11.x the product is broken as it has a few
imports from deprecated classes.

Anyone knows about CookieCrumbler versions above 1.2 or some other
replacement for this product?


Zope's pluggable authentication service replaces it.

Shane
___
Zope maillist  -  Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope-dev] direction

2011-07-07 Thread Shane Hathaway
On 07/06/2011 10:59 AM, Hanno Schlichting wrote:
 The ZMI is a highly insecure, completely outdated and user-unfriendly 
 interface.

As I read this, I got an idea for a possible way forward.  I haven't 
been reading zope-dev much lately, so forgive me if something like this 
has been mentioned already.

What if we had decorators that let us disable old code by default, yet 
allowed users to enable the old code with configuration?  Something like 
this:


import zope.oldcode

class SomeClass(SimpleObject):

 @zope.oldcode.zmi
 def manage_edit(self, REQUEST):
 # ...


The idea here is we'll create a zope.oldcode egg and fill it with 
decorators for pervasive features of Zope that need to be removed over 
time, such as the current ZMI.  We'll also create a configuration switch 
for each of those old features so that people can keep using them for a 
reasonable period of time.  When the zmi feature is disabled, the code 
above will replace the manage_edit method with a zope.oldcode.Disabled 
object that raises a helpful exception if anyone tries to call it.

It would also be good to make these decorators implement __nonzero__ to 
allow conditional attribute definition:

 if zope.oldcode.zmi:
 manage_properties = (...)

I would want to make sure conditional tests are possible as well:

 @zope.oldcode.zmi
 def test_manage_edit(self):
 # ...

(The zope.oldcode package probably ought to enable all old features by 
default when running tests.)

What do you think?

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] CSRF protection for z3c.form

2011-04-04 Thread Shane Hathaway
On 04/04/2011 10:22 AM, Roger wrote:
 Just because you can write login forms with
 z3c.form this package has nothing to do with
 authentication. That's just a form framework!

 Authentication is defently not a part
 of our z3c.form framework and should not
 become one.

 Why do you think authentication has something
 to do with the z3c.form library? Did I miss
 something?

This thread is using the word authenticate differently than most other 
Zope-related discussions.  Here, we are authenticating the *form*, not 
the user.  We need to be sure that submitted form data was produced by 
an authentic form.  Otherwise, a crafty site could cause the user's 
browser to invoke some action in the background.

BTW, the CSRF issue has existed as long as HTML forms have existed, but 
for some reason it has only drawn attention in the past year or two.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)

2011-03-21 Thread Shane Hathaway
On 03/21/2011 10:59 AM, Chris McDonough wrote:
 On Mon, 2011-03-21 at 15:53 +0100, Lennart Regebro wrote:
 It's easy and clear, but has the drawback of encouraging that
 registration is done on import time, while scanning separates the
 registration from the definition. I'm not sure how important that is.

 It's important to me, at least.  Registration-on-import effectively
 requires that there only be a single component registry for all
 applications in a process.  This is often fine for a given deployment,
 but as a framework strategy it seems very limiting.

+1.  Pyramid has proven (IMHO) that a component registry can be friendly 
to developers without being global.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] my take on ZCML's includeOverrides

2010-12-07 Thread Shane Hathaway
On 12/07/2010 12:27 PM, Chris McDonough wrote:
 I *think* I'm of the opinion that libraries (or even reusable
 applications) probably shouldn't need to use includeOverrides.

+1, I would be very suspicious of any library that uses 
includeOverrides.  Any use of it ought to be highly visible to developers.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-DB] ZSQL Question - Insert multiple rows in one statement?

2010-08-24 Thread Shane Hathaway
On 08/24/2010 04:04 PM, Jaroslav Lukesh wrote:
 ZPT is more academic platform, than for everyday usage.

Wow, I have never heard that opinion before.  I have had quite the 
opposite experience: I find ZPT more productive and less error-prone 
than all other web templating languages.  I have a project that pulls in 
several templating languages, due to dependencies, and ZPT is easily the 
best and most practical of them all.

I should clarify that I use Chameleon and BFG, so expressions in 
templates are in Python, and BFG's view machinery lets me put all 
non-trivial template code in normal Python modules.

I suppose I would agree with the statement Zope 2 page templates are 
academic, since the full practical value of ZPT was not realized until 
it was reimplemented a few times.  (See Kid, Genshi, Chameleon, and 
possibly others.)

Anyway, sorry for posting this to the wrong list.

Shane
___
Zope-DB mailing list
Zope-DB@zope.org
https://mail.zope.org/mailman/listinfo/zope-db


Re: [Zope-dev] zope.i18messageid

2010-07-05 Thread Shane Hathaway
On 07/02/2010 11:49 AM, Tres Seaver wrote:
 Jim has asserted (but not really explained) that the C extension closes
 some kind of security hole.  I don't see any credible attack vector
 myself, but then I no longer believe it worthwhile to devote my own
 energy to defending against malicious TTW programmers.

FWIW, I imagine the problem is that zope.security treats 
zope.i18nmessageid as a rock, so if the implementation is in Python, it 
probably allows untrusted code to do this:

  msg.__setattr__.im_func.func_globals['__builtins__']['__import__']
built-in function __import__

I suggest the bug is in zope.security, which should never allow a type 
written in Python to be a rock.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] long running methods

2010-05-20 Thread Shane Hathaway
On 05/20/2010 06:18 AM, Jürgen Herrmann wrote:
 def myLongRunningMethod(self):

BATCH_SIZE = 10
MAX_CONFLICTS = 3

work_items = [some, work, to , do, ...]
# list of persistent objects to be modified in this method

idx = 0
while idx  len(work_items):
  conflicts = 0
  try:
my_batch = work_items[idx, idx+BATCH_SIZE]
for work_item in my_batch:
  do_some_work(work_item)
transaction.commit()
  except ConflicError:
conflicts += 1
if conflicts  MAX_CONFLICTS:
  raise
  else:
idx += BATCH_SIZE

 does this sound like a reasonable approach?

More than that, it looks nearly finished. ;-)  The transaction machinery 
does all the heavy lifting, so you don't need to do much.  Issues to fix:

- Your code resets the conflicts counter in every iteration.  You 
obviously didn't intend that.

- You should start each loop with transaction.begin() to avoid any 
side effects of transactions started before the long running method was 
called.

- Writing thorough tests for this kind of code is very important.  If 
you don't, it might be a while before you discover that ConflictError 
was misspelled.

Shane
___
Zope maillist  -  Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope-dev] vyshakh krishnan wants to chat

2010-03-08 Thread Shane Hathaway
Christian Theune wrote:
 This is a mailinglist and you probably have dumped your address book to
 the invitation system. I've seen a couple of those talk to Zope
 mailinglists recently. Can you *please* avoid putting mailing list
 addresses into those systems?

Better yet, I wonder if there is some equivalent of robots.txt for 
email.  Domain owners should be able to create and host a file that 
specifies policies for automated email.  Does anyone know of such a 
standard?

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] preventing form submission

2010-02-02 Thread Shane Hathaway
Tres Seaver wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Garry Saddington wrote:
 Has anyone any suggestions as to how to prevent form submission by the 
 using pressing the refresh or back buttons?
 
 Issue a redirect from the POST handler:  the browser won't land again
 on the original POST target URL, but only only on the redirected page,
 or the original form.

+1, I've been happy with this technique.

Shane
___
Zope maillist  -  Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope-dev] New Zope 3 name: BlueBream

2010-01-04 Thread Shane Hathaway
Jan Ulrich Hasecke wrote:
 On 04.01.10 19:23, Baiju M wrote:
 Hi All,
  I am proposing to call Zope 3 - the web frame work
 as BlueBream.  The main use for name is documentation.
 
 Coming from marketing I strongly suggest to think twice or better thrice
 before inventing the next new name in Zope world. There are already too
 many of them.

Well, the name Zope 3 is effectively dead, yet there are still a 
number of developers who want to work on it and improve it.  Those 
developers need to rename and regroup.  BlueBream is a clever name and I 
think it's a great idea.  Once it's released, BlueBream will probably be 
on my short list of preferred platforms.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope Toolkit - packages with zope.app dependencies

2009-12-29 Thread Shane Hathaway
Lennart Regebro wrote:
 On Tue, Dec 29, 2009 at 22:54, Martijn Faassen faas...@startifact.com wrote:
 Because we have a ton of installed base out there
 
 Do we? I think the debate is somewhat confused here, or possibly it's
 only me. :)

I agree that the debate is confused.  No one intends to declare that 
zope.app is dead.  However, dropping zope.app from ZTK is a declaration 
that newcomers to ZTK will not have to learn anything in zope.app in 
order to become productive, which is a big win IMHO.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope Toolkit - packages with zope.app dependencies

2009-12-26 Thread Shane Hathaway
Hanno Schlichting wrote:
 It has a dependency on zope.app.publication. Given the central role of
 zope.traversing I allowed it and zope.app.publication to stay in the
 ZTK, but moved it to the under-review option.

On the zope.traversing trunk, I have removed the zope.app.publication 
dependency.  It was only a testing dependency.

 We have talked about refactoring the traversal and publication story
 in the past, without seeing any consensus on how to move forward with
 it. My feeling tells me, that a pure renaming of zope.app.publication
 to zope.publication or similar code reshuffling into other packages
 isn't really helpful in this case.
 
 ACTION: Until we see further progress on clarifying the semantics of
 traversal and publication, I'd leave zope.app.publication in the ZTK.

What other ZTK packages depend on zope.app.publication? 
zope.app.publication is an extra layer of complexity that most sites 
could probably do without.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZCA proposal

2009-12-03 Thread Shane Hathaway
Martin Aspeli wrote:
 Gary Poster wrote:
 I think I could get fully behind the following proposal that others have 
 made (Shane I think was one of several?).

 IFoo.adapt(...)

 IFoo.utility(...)
 
 Thinking about it a bit, it strikes me that IFoo.adapt(context) may not 
 be right. This reads IFoo adapt context, which doesn't make sense. 
 What I really want to hear is context adapted to IFoo. So maybe it's
 
IFoo.adapting(context)?
IFoo.adapterFor(context)?
IFoo.adapter(context)?
 
 Just thinking out loud.

To me, myobj.get(x) reads as myobj, please get x and give me the 
result, so IFoo.adapt(y) reads as IFoo, please adapt y and give me 
the result.  That statement makes perfect sense to me.

 Thinking out loud further, I think I may actually prefer IFoo.instance() 
 instead of .utility(), but maybe that debate is already passed. 
 .utility() is OK too.

To me, generic names like instance and singleton suggest we're 
trying to solve some grand problem that would make our brains hurt.  I 
find it more satisfying to solve a more specific problem.

I am participating in this thread because I believe the current 
zope.component API is unnecessarily verbose, hindering readability and 
adoption by Python projects that would benefit.  I think adding adapt() 
and utility() to zope.interface.Interface might improve the situation. 
We could instead add adapt() and utility() functions to the 
zope.component package, but I haven't seen any function signature that 
would turn out as simple as IFoo.adapt(x).

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Adapter for class with slots

2009-12-03 Thread Shane Hathaway
Wolfgang Schnerring wrote:
 The minimal reproduction recipe to see the error is this:
 
 class Slotted(object):
 __slots__ = ('__provides__')
 
 zope.component.provideAdapter(
 lambda x: True, (Slotted,), zope.interface.Interface)
 
 Which will raise
   File 
 /home/wosc/.python-eggs/zope.component-3.7.1-py2.6.egg/zope/component/registry.py,
   line 419, in _getAdapterRequired
   elif not ISpecification.providedBy(r):
   TypeError: 'member_descriptor' object is not callable
 
 Why is this? Can this be made to work? How would I go about
 investigating that?

It looks to me like a possible bug in zope.interface.  Try deleting 
_zope_interface_coptimizations.so to hopefully expand that traceback.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the ZCA API decision

2009-12-03 Thread Shane Hathaway
Godefroid Chapelle wrote:
 I tried to follow this discussion closely: however, I cannot say that I 
 understand if doing multi-adaptation with IFoo(bar, baz, boo) has been 
 rejected or postponed.

AFAICT, the decision to reject or postpone that has been postponed. :-)

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the ZCA API decision

2009-12-03 Thread Shane Hathaway
Martin Aspeli wrote:
 Can we all get back to our lives now? :-)

FWIW, I try to participate in discussions like these by reading and 
writing only short emails.  I find that I don't miss much that way. 
Life is more enjoyable without essay-mails.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Shane Hathaway
Martijn Faassen wrote:
 Given some feedback about backwards compatibility, I'm leaning to the 
 following adjusted scenario:
 
 * allow IFoo((a, b)) for multi adaptation. This breaks tuple adaptation. 
 It's not as pretty as IFoo(a, b), but it's pretty tolerable and it *is* 
 actually symmetric with registration.
 
 * deprecate a non-explicit default such as IFoo(a, default), require 
 IFoo(a, default=default)

While this short spelling of component lookup is attractive and sensible 
for Zopistas, I wonder if it ever really was the best idea.  When a 
developer encounters the IFoo() pattern for the first time, what is 
he/she going to type into a search engine to find out what it means?  I 
can't think of any search phrase that is likely to give a good answer.

JQuery has a similar issue, but because JQuery is a smaller framework, 
the JQuery folks simply put that info right near the top of their 
documentation.  I'm not sure we can do that quite as effectively.

For an alternate spelling, consider what happens when component lookup 
fails: you get a ComponentLookupError.  Lookup is interesting.  It 
doesn't yet have any meaning in zope.interface, so I think using a 
method named lookup() would make code more comprehensible.  You would 
use it like this:

  IFoo.lookup(a)
SomeAdapter instance at ...
  IFoo.lookup(a, b)
SomeMultiAdapter instance at ...
  IFoo.lookup(c)
Traceback...
ComponentLookupError(...)
  IFoo.lookup(c, default='missing')
'missing'
  IMyUtility.lookup()
MyUtility instance at ...

When developers encounter this for the first time, they might type 
zope.interface lookup in a search engine.  That phrase has a 
reasonable chance of hitting good documentation.

What do you think?

If adding lookup() is a good idea, then all we need to do is add 
lookup() to zope.interface 3.x and deprecate the 2nd parameter of 
IFoo().  After that, we can let multi-year evolution dictate whether 
IFoo() should be deprecated altogether.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Shane Hathaway
Lennart Regebro wrote:
 On Mon, Nov 30, 2009 at 19:16, Shane Hathaway sh...@hathawaymix.org wrote:
 If adding lookup() is a good idea
 
 Possibly, but it sound like you are looking up (a), when in fact you
 are adapting it. :) Maye IFoo.adapt(a) ?

+1, IFoo.adapt() is better, along with IFoo.utility().

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Shane Hathaway
Gary Poster wrote:
 Then to the multiadapter concern I raised, all my real-world examples
 of adapters are to adapt one object so it can be used in a certain
 way (to integrate with another kind of object).  Power adapters, for
 instance, adapt a plug (required interface) so it can plugged in to
 the wall (output interface).  Is there a common real-world example of
 this for multiadapters?

I have a Roku player (great device, BTW).  It streams video from Netflix 
and other sources.  It takes two inputs (network and power) and produces 
one output (a video signal).  I could call the device a multi-adapter, 
but the power input is so simple and reliable that I forget about it. 
Most of the time I think of the Roku player as a simple adapter from 
Internet packets to a video signal, but electrically, it's definitely a 
multi-adapter.

Note that the network signal for a Roku player varies wildly, while the 
power is either ~110VAC or ~220VAC.  Multi-adaptation works best when it 
has similar characteristics, I think.  It's safe to allow one of the 
inputs to multi-adaptation to vary a lot, but to keep developers sane, 
the rest of the inputs should be more predictable.  I think 
getMultiAdapter((context, request)) is OK because most web sites have 
only one or two request types.

 Turned around, people know the term singleton and they do not know
 the terms adapters and utilities.  singletons describe the huge
 majority of how we use these things.  It's something less to explain.
 Making comprehension quicker is very valuable to me.

Do you intend to change the API names in zope.component, then?  For 
example, getUtility - getSingleton?  That might be possible, but no one 
has suggested it before (AFAIK), and I think it's implied by your 
suggestion.

 ``IFoo.new(a, b)`` is equivalent to getMultiAdapter((a, b), IFoo)

Using new for a name could be a problem for Jython and IronPython 
users, since new is a keyword in other languages.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] improving the utility and adapter lookup APIs

2009-11-26 Thread Shane Hathaway
Martijn Faassen wrote:
 But someone needs to think of a feasible upgrade scenario. We could 
 instrument all calls to IFoo and see whether a default argument is in 
 use, but what then? I'd be hard to distinguish a default argument from 
 one we're meant to adapt. I'd also be non-trivial to scan code.

Here is an interface decorator I intend to try out soon.  It adds 
convenient component lookup methods to a particular interface without 
requiring any changes to zope.interface.

--- (snip) ---

from zope.interface.interfaces import IInterface
from zope.component import getAdapter
from zope.component import getMultiAdapter
from zope.component import getUtility
from zope.component import queryAdapter
from zope.component import queryMultiAdapter
from zope.component import queryUtility

def componentlookup(iface):
 Decorator: adds zope.component lookup methods to an interface.

 Adds utility([default], [name]) and adapt(*args, [default], [name]).
 
 assert IInterface.providedBy(iface)

 def utility(**kw):
 if 'default' in kw:
 return queryUtility(iface, **kw)
 else:
 return getUtility(iface, **kw)
 iface.utility = utility

 def adapt(*args, **kw):
 if len(args) == 1:
 # simple adapter lookup
 arg = args[0]
 if not 'name' in kw and iface.providedBy(arg):
 # The object passed in already provides this interface,
 # and no adapter name was provided, so return the object
 # unchanged.
 return arg
 if 'default' in kw:
 return queryAdapter(arg, iface, **kw)
 else:
 return getAdapter(arg, iface, **kw)

 # multi-adapter lookup
 if 'default' in kw:
 return queryMultiAdapter(args, iface, **kw)
 else:
 return getMultiAdapter(args, iface, **kw)
 iface.adapt = adapt

 return iface


--- (snip) ---

Example usage:

 @componentlookup
 class IFoo(Interface):
 pass

 class Foo(object):
 implements(IFoo)

 IFoo.adapt(Foo())
 IFoo.adapt(Foo(), HTTPRequest(), name='edit')
 IFoo.adapt(Foo(), name='x')
 IFoo.adapt(Foo(), default=None)
 IFoo.utility(default=None)

I think class decorators were added in Python 2.6, but in earlier 
Pythons you can do this instead:

 class IFoo(Interface):
 pass
 componentlookup(IFoo)

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZODB Competing read/writes: How to find out which attribute?

2009-10-10 Thread Shane Hathaway
Hermann Himmelbauer wrote:
 That's exactly the problem - it's a read operation and there should not be 
 any 
 write operation involved. However, it's hard to find out where the write 
 operation in my code occurs, I can't find it in the view, maybe there's 
 something in the authentication code, but I'd have to dig deep through my 
 source. So It would be extremely helpful to know a faster way to find out 
 what code triggered this warning.

The code that modifies something will indirectly call the register() 
method of the ZODB.Connection class.  If you arrange for 
Connection.register() to raise an exception when the transaction is not 
supposed to modify anything, you should get a traceback that pinpoints 
what is doing the modification.  Unfortunately, there is no API for 
that, so the easiest thing to do is modify the source code of the 
register() method in ZODB.Connection.  Fortunately, this is Python, so 
modifying someone else's code is usually quite easy. :-)

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZODB Competing read/writes: How to find out which attribute?

2009-10-09 Thread Shane Hathaway
Hermann Himmelbauer wrote:
 Hi,
 I once in the while get the following warning in my Zope 3 log, which I'd 
 like 
 to resolve:
 
 2009-10-07T14:35:41 WARNING ZopePublication Competing writes/reads 
 at 
 /BSPSite/act/++vh++http:zis.act.at:80/bankneu/++/c/acc/booklist/index.html: 
 database conflict error (oid 0x7a5d, class BTrees.OOBTree.OOBTree, serial 
 this txn started with 0x0381388ca6804966 2009-10-07 12:28:39.023700, serial 
 currently committed 0x03813893b087d0cc 2009-10-07 12:35:41.374343)

That URL looks like it should only be reading the database, but the fact 
that you get a conflict error suggests that the code behind that URL is 
writing to the database.  If I were you, I would first ensure that read 
operations never write to the database.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope 2 WebDAV and acquisition

2009-10-05 Thread Shane Hathaway
Martin Aspeli wrote:
 Can anyone explain why that condition is there? Otherwise, I'll rip it 
 out. ;-)

As I recall, this code is convoluted because it's hard to tell whether 
an HTTP request is a WebDAV request.  If there is now a way to clearly 
distinguish WebDAV requests, then I imagine this code can be greatly 
simplified.  This code had to deal with Windows 95 and such.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] Error when trying pack database

2009-09-24 Thread Shane Hathaway
iarly selbir | ski0s wrote:
 Error Type: IntegrityError
 
 Error Value: (1062, Duplicate entry '251983055306698820-6697-172041' 
 for key 1)

Could you look in your Zope log, get the full traceback, and post it? 
Otherwise, there isn't much information to go on.  Also, please post the 
basics: operating system, MySQL version, Zope version, RelStorage version.

Shane
___
Zope maillist  -  Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] How to disable transaction log feature in zope

2009-09-02 Thread Shane Hathaway
Kedar Dash wrote:
 It seems that lot of system resources are getting consumed in zope 
 because of its transaction log feature. Ff course it has got its utility 
 in undoing some mistakes.
 
 How this feature can be disabled in zope. 

The standard FileStorage backend for ZODB and Zope is an append-only 
database.  It would not be possible to remove the append-only nature 
without a complete redesign of FileStorage.  I doubt anyone wants to 
take that on.

There are alternatives to FileStorage, however.  For example, I've 
tinkered with a version of RelStorage that does not save any history. 
It seems to work well, but I haven't released any history-free version yet.

Shane

___
Zope maillist  -  Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope-dev] Proposal: zope.app.publisher refactoring

2009-08-21 Thread Shane Hathaway
Hi Dan,

I'll provide feedback for a few parts of your proposal.

Dan Korostelev wrote:
 xmlprc - move the IXMLRPCView interface and XMLRPCView base class to
 zope.publisher as a counterpart to zope.publisher.browser.BrowserView.
 Move MethodPublisher, MethodTraverser, xmlrpc:view ZCML directive to
 new zope.xmlrpcview package. Also I'd merge MethodTraverser with
 MethodPublisher to make it easier to understand and to decrease number
 of entities :)

Few developers care about XML-RPC these days.  Most web developers are 
now working with REST, JSON, and other similar stuff.  It's probably 
best to move all XML-RPC artifacts, including those in zope.publisher, 
to a single package, so that most developers can safely ignore the 
XML-RPC code.

 IXMLRPCPublisher adapters for zope.container - move them to
 zope.container. The IBrowserPublisher adapters that are already there,
 so it won't make things worser. The zope.container package may be
 refactored later to break dependency on zope.publisher though.

You need Jim Fulton's input on this.  I think his latest opinion is that 
zope.container should have nothing to do with publishing.

 IHTTPView and IFTPView interfaces - move that into zope.publisher as a
 counterpart to IBrowserView. (BTW, shouldn't IBrowserView be a
 subclass of IHTTPView?)

In zope.app land, sometimes IHTTP* really means INonBrowser*.  In other 
words, sometimes people want to define views just for HTTP ports not 
intended for web browsers.

 IFTPDirectoryPublisher interface - not sure what's this and where is
 it used. Probably should be moved to zope.publisher.interfaces.ftp as
 well.

FTP is in the same boat as XML-RPC.  Today, very few developers care to 
provide a dynamic FTP view of anything.  WebDAV usually wins over FTP 
because adding SSL to WebDAV is easy.  All FTP artifacts should move to 
a separate package.

 That's all for now. I'd like to see some
 comments/propositions/objections before I start. Also, maybe there are
 more beautiful names for new packages?

The names you proposed seem ok.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Simplifying dependencies of zope.app.publisher

2009-08-06 Thread Shane Hathaway
Fabio Tranchitella wrote:
 My knowledge of the zope.publisher is too limited to do any change in this
 area, but to me it looks like these configurations (both of them) should be
 perfomed by zope.app.publisher (removing the dependency zope.container -
 zope.publisher), but conditionally (zcml:condition) only if zope.container
 is installed, (removing the dependency zope.app.publisher -
 zope.container).

I'm hoping Jim will soon take charge of zope.publisher, zope.traversing, 
zope.container, and zope.app.publisher, because he seems to be the only 
one who knows how they are supposed to be related.  For example, which 
packages should be aware of XML-RPC?  I would guess that none of them 
should have any notion of XML-RPC, and that there should be a 
zope.xmlrpc package, but my confidence in that guess is very low.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Why does zope.tales explicitly pin versions in buildout.cfg?

2009-08-05 Thread Shane Hathaway
Fabio Tranchitella wrote:
 Is there a specific reason for having the version pinning? Automatic testing 
 of
 zope.tales obviously fails using the KGS, because zope.traversing there is
 3.7.1.
 
 Is it possible to remove the versions stanza?

Sure.  Pinned versions are OK for a maintenance branch, but not the trunk.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.index 3.5.2 broken

2009-08-03 Thread Shane Hathaway
Marius Gedminas wrote:
 On Sun, Aug 02, 2009 at 08:48:24PM +0200, Andreas Jung wrote:
 Hi,

 the doctests for zope.index 3.5.2 - as used in Zope 2.12  - fail badly:

 File
 /home/ajung/.buildout/eggs/zope.index-3.5.2-py2.6-linux-x86_64.egg/zope/index/text/tests/../textindex.txt,
 line 143, in textindex.txt
 Failed example:
 [(k, %.4f % v) for (k, v) in index2.apply(Zorro).items()] == result
 
 I'm assuming items() returns a plain Python dictionary with string keys.
 
 Python's string hashes return different valuesfor half of all the strings
 on 64-bit machines.  This influences the ordering of dictionary keys and
 some other things too (such as the sequence of random numbers you get if
 you use a string as the seed).
 
 Add a sorted() on both sides and the test should pass.

Actually, those tests were plain insane and I've fixed them on the 
trunk.  I intend to make a new zope.index release today.

How insane were these tests?  Well, the author of the tests noticed that 
the C optimization produces different scores than the Python version, 
and compensated for that in a way that dramatically reduced readability. 
  Furthermore, the C code was producing incorrect results due to an 
unsafe optimization that accidentally took 32 bits of a Python float and 
pretended it was an integer.  The breakage only became obvious when we 
started taking 64 bits instead, leading to completely different results.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.index 3.5.2 broken

2009-08-03 Thread Shane Hathaway
Chris McDonough wrote:
 On 8/3/09 1:07 PM, Shane Hathaway wrote:
 How insane were these tests?  Well, the author of the tests noticed that
 the C optimization produces different scores than the Python version,
 and compensated for that in a way that dramatically reduced readability.
 
 /me hangs head in shame.

That was you?  Well, it could have been worse. :-)

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Linux x86_64 [Was: Zope Tests: 3 OK, 5 Failed]

2009-07-25 Thread Shane Hathaway
Hanno Schlichting wrote:
 I kind of suspect that we are seeing the results of
 http://www.python.org/dev/peps/pep-0353 though.

That is very likely.  BTW, that PEP links to a handy tool that reveals 
most 64 bit portability issues in Python-oriented C code.

From what I understand we need to change code in C extension modules
 following the instructions in that PEP, to be able to run code
 reliably on 64-bit platforms. To my knowledge nobody changed any C
 code in Zope yet to do so.

We fixed the C portability problems in Zope 3 a while back, but it seems 
we didn't fix the extensions that are specific to Zope 2.

 The other interesting bit to this is, that it seems doable but hard to
 do these changes while preserving compatibility with Python 2.4. These
 changes along with the definition of Py_ssize_t were introduced into
 Python 2.5.

Preprocessor macros solve that fairly cleanly, actually:

#ifndef Py_ssize_t
#define Py_ssize_t int
#endif

 At this point I think we need to declare 64-bit platforms as
 unsupported. Hopefully people with the right kind of knowledge would
 like to step up and start working on these issues.

I just checked in some code that solves the portability problem in 
zope.index, although I haven't created a release.  It looks like the 
Acquisition module needs some 64 bit TLC.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] SVN: Zope/trunk/versions.cfg Revert r101557 and put back version pins for zodbcode and zope.app.interface. These are actual dependencies of zope.app.zcmlfiles, which in turn is a test d

2009-07-06 Thread Shane Hathaway
Tres Seaver wrote:
 Hanno Schlichting wrote:
 Log message for revision 101616: Revert r101557 and put back
 version pins for zodbcode and zope.app.interface. These are actual
 dependencies of zope.app.zcmlfiles, which in turn is a test
 dependency of numerous packages we use. Having a consistent known
 set of packages for tests is as important as having one for
 production.
 
 Shouldn't we just rip zodbcode et al out of a new version of
 zcmlfiles?

+1

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] RFC: ZTK custom publications, zope.app.publication, and zope.traversing

2009-06-23 Thread Shane Hathaway
Jim Fulton wrote:
 They wouldn't. They don't use the URL traversal code. Non-URL  
 traversal code would move to zope.tales. zope.container would depend  
 on zope.tales rather than on zope.traversing.

For my own education, I would like to understand why it makes sense for 
zope.container to depend on zope.tales.  This dependency suggests people 
need to understand ZPT in order to understand container relationships, 
which seems wrong to me.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] RFC: ZTK custom publications, zope.app.publication, and zope.traversing

2009-06-23 Thread Shane Hathaway
Jim Fulton wrote:
 
 On Jun 23, 2009, at 2:36 PM, Shane Hathaway wrote:
 
 Jim Fulton wrote:
 They wouldn't. They don't use the URL traversal code. Non-URL  
 traversal code would move to zope.tales. zope.container would depend  
 on zope.tales rather than on zope.traversing.

 For my own education, I would like to understand why it makes sense 
 for zope.container to depend on zope.tales.  This dependency suggests 
 people need to understand ZPT in order to understand container 
 relationships, which seems wrong to me.
 
 
 Because it provides traversal adapters needed soley by zope.tales.

Sorry, you lost me on the first sentence (and the rest doesn't make 
sense yet to me as a result).  You first said that zope.container is 
going to depend on zope.tales.  Now you're saying zope.tales is going to 
depend on zope.container.  If you meant the latter, then I understand. :-)

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] [Checkins] SVN: zope.traversing/trunk/src/zope/traversing/ Moved the publicationtraverse module from zope.app.publication and added tests.

2009-06-20 Thread Shane Hathaway
Jim Fulton wrote:
 Why?  traverseName is part of zope.app.publication's implementation.   
 Now it's oddly split off in a very separate package.

The publisher traversal code is very similar to the code in
zope.traversing, so I thought the best thing to do is put it in the same
package as zope.traversing, so that traversal would be maintained in one
place.

 Or, better yet, traverseRelativeURL and traversePath should be moved  
 to the browser module and should get traverseName from  
 request.publication.
 
 I'll go ahead and do this.

That's fine.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] HA storage for zope

2009-06-12 Thread Shane Hathaway
Chris Withers wrote:
 It's a shame that the 2 or 3 times I've tried to organise purchase of 
 ZRS for customers, the Zope Corp sales process hasn't succeeded in 
 delivering anything :-(
 
 (I'm not 100% on the details, but it may just have been that the prices 
 were extortionate...)

I disagree.  The kind of fault tolerance ZRS provides is hard to achieve 
without a lot of either time or money.  I suspect ZRS is less expensive 
than a new replicated Oracle setup, or paying a developer to invent 
something new.

(I only recommend Oracle + RelStorage to people who have already 
invested deeply in Oracle.)

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] HA storage for zope

2009-06-03 Thread Shane Hathaway
Hanno Schlichting wrote:
 Wichert Akkerman wrote:
 [lots of great info about RelStorage]

I couldn't have said it better. :-)  Thanks guys.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] package dependency refactoring progress report

2009-05-25 Thread Shane Hathaway
Martijn Faassen wrote:
 It's interesting to see zope.deprecation is a new dependency. We could 
 consider changing these deprecations to simple imports if this is 
 possible...

Certainly, but what is the right way to deprecate code, then?  I'm not 
very happy about including zope.deprecation either, since it uses the 
sys.modules trick just like zope.deferredimport, but those deprecation 
warnings are important, aren't they?

 Knowing there are no cycles besides the zope.container one, this graph 
 starts to look comprehensible, that's good. :)

It's still really big though.  Hmph.

Thanks for the new graphs!

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] package dependency refactoring progress report

2009-05-25 Thread Shane Hathaway
Martijn Faassen wrote:
 I'm not sure about zope.rest; there's already a z3c.rest which likely 
 does something quite different, and I think a zope.rest package should 
 actually *talk* about REST. What about zope.httpview instead?

Well, no, I don't think it's generic enough to call that.  zope.app.http 
is almost a webdav implementation, except I'm not sure it implements 
enough to actually work with most webdav clients.

 Another note, I think we should consider splitting off 
 zope.app.publisher.xmlrpc, which looks quite independent from the rest, 
 into its own package. So:
 
 zope.app.publisher - zope.view, zope.xmlrpcview

I've pondered this split before, but AFAICT it would only increase the 
number of dependencies, so I've been waiting for the graph to shrink 
before talking about it.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] package dependency refactoring progress report

2009-05-25 Thread Shane Hathaway
Tres Seaver wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Shane Hathaway wrote:
 Martijn Faassen wrote:
 It's interesting to see zope.deprecation is a new dependency. We could 
 consider changing these deprecations to simple imports if this is 
 possible...
 Certainly, but what is the right way to deprecate code, then?  I'm not 
 very happy about including zope.deprecation either, since it uses the 
 sys.modules trick just like zope.deferredimport, but those deprecation 
 warnings are important, aren't they?
 
 Not so much, IMO.  I think we can leave simple BBB imports in place,
 warning-free, forever (with a '#BBB' comment so that people don't delete
 them as unused imports).

Ok, I've replaced all the zope.deprecation imports I added with BBB. 
What does BBB stand for anyway?

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] package dependency refactoring progress report

2009-05-23 Thread Shane Hathaway
Martijn Faassen wrote:
 So, the only dependency cycles left in zope.app.publisher are these:
 
 zope.app.publisher -- zope.app.publication -- zope.app.http

I fixed those tonight.  On the trunk, there are no longer any 
dependencies between zope.app.publisher, zope.app.publication, and 
zope.app.http, except testing dependencies.

Here is a summary of what I did:

- Moved the publication traversal code to zope.traversing and simplified 
it from 3 classes to 1.  This did not increase the dependencies of 
zope.traversing at all, since publication traversal is only slightly 
different from the traversal logic already in zope.traversing.  It also 
opens the doors for someday moving the gnarly traversal code in 
zope.publisher to something saner in zope.traversing.

- Moved an XML-RPC view registration from zope.app.publisher to 
zope.app.publication.

- Moved IHTTPException, IMethodNotAllowed, and the MethodNotAllowed 
exception class to zope.publisher.interfaces.http.  This move decoupled 
zope.app.http from zope.app.publication.

- Moved getDefaultViewName() and queryDefaultViewName() to 
zope.publisher.defaultview.  If you look at the commit messages, you'll 
see that I first attempted a different move that included the 
browser:defaultView handler, but that move turned out wrong for other 
packages and I reverted it.

- I used zope.deferred to deprecate things I moved from 
zope.app.publication, zope.app.publisher, and zope.app.http.  Are there 
any objections to using zope.deferred in those packages?

In all, I changed 6 packages.  Should I release them now, or should I 
look for other dependencies we might clean up at the same time?  The 
changed packages are:

zope.traversing (3.7.0)
zope.publisher (3.8.0)
zope.app.publisher (3.8.0)
zope.app.publication (3.7.0)
zope.app.http (3.6.0)
zope.app.zcmlfiles (3.5.5; bugfix only)

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] package dependency refactoring progress report

2009-05-23 Thread Shane Hathaway
Shane Hathaway wrote:
 Martijn Faassen wrote:
 So, the only dependency cycles left in zope.app.publisher are these:

 zope.app.publisher -- zope.app.publication -- zope.app.http
 
 I fixed those tonight.  On the trunk, there are no longer any 
 dependencies between zope.app.publisher, zope.app.publication, and 
 zope.app.http, except testing dependencies.

I should take a moment to describe the different purposes of these 
packages as I see them now.  Conceptually, they are really quite 
independent.

- zope.app.publisher: A library of ZCML directives for configuring 
views.  Also provides generic view classes.  A better name for this 
package might be zope.basicviews.  A lot of packages depend on this.

- zope.app.publication: Provides IPublication implementations and a 
mechanism/registry for choosing a different publication class for each 
request.  Most packages should not depend on this.  A better name might 
be zope.publicationregistry.

- zope.app.http: Provides generic views that translate HTTP verbs like 
PUT, DELETE, and OPTIONS into map operations.  The idea is clever, but 
not everyone needs a REST-style API.  A better name might be 
zope.httpverbs.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] package dependency refactoring progress report

2009-05-23 Thread Shane Hathaway
Martijn Faassen wrote:
 Shane Hathaway wrote:
 - I used zope.deferred to deprecate things I moved from 
 zope.app.publication, zope.app.publisher, and zope.app.http.  Are there 
 any objections to using zope.deferred in those packages?
 
 No objection, but what's the reason to use zope.deferred instead of 
 straight imports or zope.deprecation? To break the dependencies?

I had forgotten about zope.deprecation. :-)  I'll switch to that.

 
 In all, I changed 6 packages.  Should I release them now, or should I 
 look for other dependencies we might clean up at the same time?  
 
 I'm +1 on releasing now. (and thanks for making them feature releases) 
 Getting these things out there gives everybody who plays with this nicer 
 dependency graphs and this tends to help improvement.

Ok, I intend to release them today.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] package dependency refactoring progress report

2009-05-23 Thread Shane Hathaway
Shane Hathaway wrote:
 Martijn Faassen wrote:
 Shane Hathaway wrote:
 In all, I changed 6 packages.  Should I release them now, or should I 
 look for other dependencies we might clean up at the same time?  
 I'm +1 on releasing now. (and thanks for making them feature releases) 
 Getting these things out there gives everybody who plays with this nicer 
 dependency graphs and this tends to help improvement.
 
 Ok, I intend to release them today.

Done.  I look forward to seeing the changes in the dependency graph.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] package dependency refactoring progress report

2009-05-23 Thread Shane Hathaway
Martijn Faassen wrote:
 Shane Hathaway wrote:
 - zope.app.publisher: A library of ZCML directives for configuring 
 views.  Also provides generic view classes.  A better name for this 
 package might be zope.basicviews.  A lot of packages depend on this.
 
 I'm not sure 'basic' needs to be in there. Do we have anything less basic?
 
 What about simply calling it zope.view? (I don't like the plural in 
 package names either generally)

Sounds good to me.

 - zope.app.publication: Provides IPublication implementations and a 
 mechanism/registry for choosing a different publication class for each 
 request.  Most packages should not depend on this.  A better name might 
 be zope.publicationregistry.
 
 I'm fine with this. I was considering 'zope.publication', but we already 
 have 'zope.publisher' so that'd get very confusing again, something we 
 should avoid.

Right.

 - zope.app.http: Provides generic views that translate HTTP verbs like 
 PUT, DELETE, and OPTIONS into map operations.  The idea is clever, but 
 not everyone needs a REST-style API.  A better name might be 
 zope.httpverbs.
 
 Even though I don't really like the plural, I think 'zope.http' would 
 promise a bit too much, so 'zope.httpverbs' sound better.

Another option is zope.rest, because a simple REST interface is what 
the package tries to accomplish.

 So if we get some consensus about this, we need volunteers that can help 
 move the code over to these new packages and leave backwards compatible 
 imports in the old places. Is there anything in these packages we can 
 safely leave behind do you think? (ZMI related, perhaps?)

I haven't come across anything we'd want to leave behind.

Summarizing:

zope.app.publisher - zope.view
zope.app.publication - zope.publicationregistry
zope.app.http - zope.rest

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] package dependency refactoring progress report

2009-05-23 Thread Shane Hathaway
Marius Gedminas wrote:
 On Sat, May 23, 2009 at 08:59:34PM +0200, Martijn Faassen wrote:
 What about simply calling it zope.view? (I don't like the plural in 
 package names either generally)
 
 FWIW at some point I decided that singular is appropriate when a package
 defines a concept, and plural is appropriate when a package provides
 multiple implementations of that concept.
 
 Thus you have zope.interface but zope.$anything.interfaces.

In this case it's a plural of metaconfiguration.  Maybe zope.viewzcml? 
  I think that would express the intent even better.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] package dependency refactoring progress report

2009-05-22 Thread Shane Hathaway
Chris McDonough wrote:
 On 5/22/09 1:11 PM, Martijn Faassen wrote:
 After some work we'd gotten it down to this:

 http://startifact.com/depgraphs/zope_app_publisher_cycles2.svg

 And by now the main cycles left are these:

 http://startifact.com/depgraphs/zope_app_publisher_cycles3.svg

 So, the only dependency cycles left in zope.app.publisher are these:

 zope.app.publisher--  zope.app.publication--  zope.app.http
 
 In isolation, it sort of looks like we should just collapse 
 zope.app.publication 
 and zope.app.http *into* zope.app.publisher, given that the relationships 
 between the packages are all cyclical.

Well, zope.app.publication and zope.app.publisher are really completely 
different, despite their similar names.  zope.app.publication is a 
publisher implementation, while zope.app.publisher contains publishable 
resources.  IMHO, zope.app.publisher is more broadly useful than 
zope.app.publication.

So I'm working on removing the dependency from zope.app.publisher to 
zope.app.publication.  It's mostly done, but I'm writing tests for the 
code I'm moving, since it never had any tests...

I'm thinking about also removing the reverse dependency 
(zope.app.publication - zope.app.publisher).  I think the default view 
name logic might belong in publication, not publisher.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.app.publication dependencies (volunteersneeded!)

2009-05-20 Thread Shane Hathaway
Martijn Faassen wrote:
 It might actually be the best to move these ZCML directives *down* into 
 zope.component. That won't affect the dependencies of zope.component at 
 all in fact; the [zcml] dependencies of zope.component already need all 
 the dependencies that zope.app.component's view and resource directives 
 implement.

I see that zope.component now relies fairly heavily on the setuptools 
extras_require, which makes the proposed move possible.  At what point 
did we decide extras_require is good?  Just curious.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope 2.12.0 beta 1 released

2009-05-20 Thread Shane Hathaway
Andreas Jung wrote:
 I will cut a beta 2 release by tomorrow.
 
 Objections?

A couple of bugs have been fixed in ZODB, so it might be useful to get 
another ZODB release out first.

http://svn.zope.org/ZODB/trunk/src/CHANGES.txt?view=markup

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope2.12.a04 / relstorage / zodbconvert.py errors

2009-05-04 Thread Shane Hathaway
Jürgen Herrmann wrote:
 ZConfig.SchemaResourceError: import name does not refer to a package
   Package name: 'relstorage'
   File name: 'component.xml'
   Package path: None

I need to make a new release of RelStorage before this will work. 
RelStorage 1.1.3 does not work with ZODB 3.9, but the current RelStorage 
trunk does.  I intend to package and release a compatible version today 
or tomorrow.

FWIW, I suspect ZConfig is attempting to import relstorage and getting 
an ImportError due to the incompatibility, but then ZConfig is 
converting the ImportError into a strange SchemaResourceError.  It would 
be much better if ZConfig just propagated the ImportError.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Proposal: set __parent__ and __name__ in Zope 2.12 OFS

2009-04-27 Thread Shane Hathaway
zopyxfil...@gmail.com wrote:
 On 27.04.2009 22:56 Uhr, Shane Hathaway wrote:
 Lennart Regebro wrote:
   
 Or, we could release 2.12 soon, and then start working on 2.13, a
 
 +1.  We need an eggified, Buildout-friendly Zope 2 that's fully 
 compatible with Zope 2.11.  
 
 Zope 2.11???

In other words, let's not discuss any more sweeping changes for Zope 
2.12.  I want an eggified Zope 2 release soon so that RelStorage is 
easier to support. :-)

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope] relstorage on zope 2.10.5

2009-04-27 Thread Shane Hathaway
Jürgen Herrmann wrote:
 the version of zopdb shipped with zope 2.10.5 is 3.7.1, so why
 does the command above try to pull an alpha release of zodb?
 can in pin the version of zodb to 3.7.1?

Zope includes ZODB.  You need a buildout that does not try to replace 
the version of ZODB that comes with Zope.  Furthermore, the version of 
ZODB that comes with Zope must be patched to support RelStorage.  Newer 
Zope releases will solve this problem, but Zope 2.10 users are stuck 
with this.

If you are installing Plone, you should follow the instructions here:

http://shane.willowrise.com/archives/how-to-install-plone-with-relstorage-and-mysql/

Those instructions make use of a handy fake eggs mechanism provided by 
the Plone recipe.  The fake eggs solution seems like the best way to use 
Buildout with Zope releases before 2.12.

Shane

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] Backing up a Zope instance with Relstorage / Mysql

2009-04-23 Thread Shane Hathaway
Anthony Gerrard wrote:
 We're setting a new Zope instance (2.10.7) using Relstorage (1.1.3)
 and MySql (5.0.77).  We have 3 different mount points (main, Plone
 and temp) all pointing to different mysql databases.
 
 I can't find any instructions about backing up this type of
 environment.  Can just we back databases up sequentially?

Your main database probably changes very infrequently.  No Plone user 
action should change the main database, so I suspect the backup order 
doesn't matter much.

If both databases changed often, we'd have to think harder.  For 
example, if you put your catalog in a different database, you would want 
to either back them up at the same instant (by shutting down, using a 
volume snapshot, or holding a lock on both databases for a short time) 
or back up the catalog first and plan to rebuild the catalog whenever 
you restore.

Shane
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope-dev] Defining Zope 3.

2009-04-20 Thread Shane Hathaway
Albertas Agejevas wrote:
 On Sat, Apr 18, 2009 at 08:32:52AM -0600, Shane Hathaway wrote:
 Given that definition, Zope Toolkit will start relatively small, since
 much of Zope 3 does not yet qualify.  However, as people refine
 packages, the packages will be reconsidered for inclusion in the Zope
 Toolkit, and the Zope Toolkit will hopefully grow into something similar
 to what we currently know as Zope 3.

 Zope 3 can't die; people are relying on it and maintaining it.  The
 maintainers are doing a rather good job too, IMHO.  The checkins list
 has been active lately.  We don't have to create any more Zope 3
 tarballs, but we should keep up the KGS.

 The Zope Toolkit will be the subset that's good for building
 applications, web sites, and frameworks.  Zope 3 will be designed only
 for building applications and web sites.
 
 +1, this sounds like a good way forward.

Thanks.

It occurred to me that one simple test of a Zope naming scheme is to 
consider what employers will write in job descriptions.  Consider these 
alternatives:

1. Candidate must be have Zope 3 experience.

2. Candidate must be experienced with the Zope Toolkit.

#1 is ambiguous.  If I'm highly experienced with Grok or Repoze, doesn't 
that count?  What if I'm a modern Plone developer?  If the HR department 
does the hiring, they are likely to disqualify good candidates.

#2 should allow developers experienced with Grok, Repoze, modern Plone, 
and possibly even Twisted, but does not allow old-school Zope 2 or 
inexperienced Python developers.  This seems much more like what typical 
employers want to express.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Defining Zope 3.

2009-04-20 Thread Shane Hathaway
Shane Hathaway wrote:
 1. Candidate must be have Zope 3 experience.
 
 2. Candidate must be experienced with the Zope Toolkit.

Of course I meant...

1. Candidate must have Zope 3 experience.

2. Candidate must have Zope Toolkit experience.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Defining Zope 3.

2009-04-20 Thread Shane Hathaway
Lennart Regebro wrote:
 On Mon, Apr 20, 2009 at 18:42, Shane Hathaway sh...@hathawaymix.org wrote:
 It occurred to me that one simple test of a Zope naming scheme is to
 consider what employers will write in job descriptions.
 
 That's a bloody good point.

Thanks.  I take it this point reinforces your proposal that we should 
both create Zope Toolkit as a subset of Zope 3, *and* rename Zope 3 to 
something else.

We could rename Zope 3 to Zope Toolkit Reference Application for the 
InterNet, or ZTRAIN.  This name expresses several intents:

- Zope 3 is the reference application for building something for the 
Internet on top of Zope Toolkit.

- Not all of the Zope community is using it.  If everyone were using it, 
we would call it simply Zope.  However, someone is using it, otherwise 
we wouldn't bother naming it.

- Zope 3 was derailed (pun, ha ha) a bit and now we're trying to put it 
back on track.

- People who like Ruby on Rails might like this too.

Also, it follows the open source tradition of slightly whimsical names. 
  The logo could be a train engine driven by a Zope fish. :-)

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Defining Zope 3.

2009-04-20 Thread Shane Hathaway
Lennart Regebro wrote:
 On Mon, Apr 20, 2009 at 23:32, Shane Hathaway sh...@hathawaymix.org wrote:
 Also, it follows the open source tradition of slightly whimsical names.  The
 logo could be a train engine driven by a Zope fish. :-)
 
 Done. Does this mailing list accept attachements?

Wowsers.  LOL!

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Defining Zope 3.

2009-04-18 Thread Shane Hathaway
Martijn Faassen wrote:
 You're right of course, I apologize for going that way. I have little 
 excuse for that.

You've taken a lot of heat in this thread.  I hope that doesn't bother
you too much, because I think you're an extremely valuable team member.
 This kind of discussion is hard, but it is an important part of any
mature project.

I find it rather encouraging that so many people are participating in
this thread.  Clearly, the Zope project has many dedicated contributors.

I don't know how valuable my opinion about all of this is, but I'll
suggest it in case it's useful.

In my mind, I've been thinking of Zope Toolkit as the subset of Zope 3
that has well-managed dependencies.  Zope 3 already has good code and
excellent test coverage, but what's controversial about it is the mad
package dependency graph as you reach inside zope.app.

Given that definition, Zope Toolkit will start relatively small, since
much of Zope 3 does not yet qualify.  However, as people refine
packages, the packages will be reconsidered for inclusion in the Zope
Toolkit, and the Zope Toolkit will hopefully grow into something similar
to what we currently know as Zope 3.

Zope 3 can't die; people are relying on it and maintaining it.  The
maintainers are doing a rather good job too, IMHO.  The checkins list
has been active lately.  We don't have to create any more Zope 3
tarballs, but we should keep up the KGS.

The Zope Toolkit will be the subset that's good for building
applications, web sites, and frameworks.  Zope 3 will be designed only
for building applications and web sites.

I'll be able to recommend Zope Toolkit to friends without hesitation.
They will be able to learn the ZTK in small steps because the dependency
graph will be comprehensible.  It will never be necessary to learn all
of ZTK to be productive.  Many will start with the ZTK and eventually
realize they only need a small subset of ZTK.  They will be happy when
they discover how easy it is to use a subset of ZTK.

Zope 3 is the thing I'll still recommend to people who decide they want
to drink all of Zope in at once.  Some people have good reasons to want
that, after all.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] uuid.UUID as a rock in zope.security

2009-04-10 Thread Shane Hathaway
Martijn Faassen wrote:
 Stephan Richter wrote:
 On Friday 10 April 2009, Jim Fulton wrote:
 Unfortunately these are ZC's use cases.
 They are not just ZC's use cases.
 Keas is relying on that safety heavily too. Anyone who wants to build a 
 secure 
 DSL based on Python really wants zope.security.
 
 Okay, second case of such usage noticed.
 
 One thing that worries me is that PyPy folks keep saying it probably 
 isn't really secure, though they refuse to specify why not when Chris 
 Withers tried to find out last year at EuroPython.

I suspect that's because Python allows anything by default; 
zope.security and RestrictedPython only provide a way to close known 
holes.  The security model of Javascript running in a browser is very 
similar, though, and that seems to be good enough for most people.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] naming Zope

2009-04-09 Thread Shane Hathaway
Martijn Faassen wrote:
 If nobody volunteers to do this (feel free to organize more volunteers), 
 we'll stick with Zope Framework.
 
 Let me know if you're going to do this and when you're done.

FWIW, I think this particular pile of libraries is in fact best 
described by the name framework, because the code we're discussing 
often calls user code rather than the other way around.  For example, 
looking up and using an adapter is deep in framework territory.

The name framework has earned a bad name just because there are so many 
bad frameworks out there, but there are plenty of good ones too.  Good 
frameworks use library-like patterns where possible, falling back to 
carefully designed framework-like patterns.  Zope Framework will be one 
of the best frameworks.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] naming Zope

2009-04-08 Thread Shane Hathaway
Martijn Faassen wrote:
 If we don't call Zope Framework 4.0, we'll be fine. We should call its 
 first release 1.0 and there's no implication of a progression.

+1 on calling it Zope Framework 1.0.  We need the people who have been 
burned by past Zope releases to take another look, because we believe 
Zope is finally getting simpler.  Those people would assume 
Zope-anything 4.0 is just piling on more complexity, while a version 1.0 
release would invalidate that assumption and suggest they take another look.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] naming Zope

2009-04-08 Thread Shane Hathaway
discussion type=bikeshed

Tres Seaver wrote:
 WRT the Framework name: framework is a misleading name for the
 collection of packages salvaged from the new Coke effort:  it is
 actually a *bunch* of frameworks, in the classic software engineering
 sense, along with some pure libraries.

Zope Toolkit, perhaps?  (No relationship to Portal Toolkit. :-] )

/discussion

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Constant values defined in interfaces

2009-04-04 Thread Shane Hathaway
Chris McDonough wrote:
 FTR, I do often put
 constants in an interfaces.py module at module scope (if there are more than
 one related, sometimes in a dictionary or within a non-interface class
 statement) in order to not feel I need to create some constants.py module.
 Maybe we could just agree that doing so isn't some sort of violation of 
 intent?

+1

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.password

2009-03-18 Thread Shane Hathaway
Christian Theune wrote:
 I remember that at the sprint we used to identify packages which are
 always good. E.g. zope.interface is a declared no-brainer to add to
 your dependencies. The other two that keep popping up that we *might*
 wanna white-list are zope.schema and zope.component.

To whitelist zope.component would be quite interesting.  As I recall, 
there was a time when all packages that depended on zope.component were 
required to be in the zope.app namespace.

I don't object to the idea, though.  We're using zope.schema and 
zope.component almost like language features.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] setting missing minimum version in setup.py

2009-03-17 Thread Shane Hathaway
Roger Ineichen wrote:
 What do you do if version x.y works with d.e.d but not with
 d.e.e (because it's borken) and fixed in d.e.f.
 
 This means you could use d.e.d or d.e.f. but not d.e.e
 
 What's your solution then?
 Fix the version to d.e.d or d.e.f or skip fixing versions?

The version requirements in setup.py should specify only API 
compatibility.  They have nothing to do with bug fixes; that's the 
domain of the KGS.  How about an example.

Let's say we have zope.schema version 5.2, which requires zope.interface 
version 4.1 because zope.interface version 4.0 has a different API. 
Let's also say that zope.interface version 4.1.5 has a bug that breaks 
zope.schema, but versions 4.1.4 and 4.1.6 are OK.  Since that level of 
detail is burdensome and unnecessary for setup.py files, zope.schema 
should require zope.interface = 4.1 and let the KGS provide the finer 
detail.  People who don't use a KGS will be fine because they'll get 
4.1.6+ as soon as it's released.

 Note; Not that fixing versions in a package is a bad thing
 in general. But such fixed versions will mess up the KGS
 that's the bad part. And since the KGS solves any kind of
 version conflict problems, there is no way to do it in a
 package anymore.

The KGS is too fine grained for many uses.  I, for example, would like 
to use the latest z3c.form, but I really can't, because it relies on a 
bunch of other packages with revised APIs and the API requirements are 
not written anywhere.  I don't care about bugs; I can fix bugs.  What I 
can't do is read other developer's minds to discover API version 
requirements.

Note that if I could use the current z3c.form, I would also be able to 
help develop it.  Surely many other developers face similar 
circumstances.  Thus I believe the Zope project is quietly missing 
opportunities for developers to get involved due to the lack of 
coarse-grained version requirements.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Namespace declaration using pkgutil vs pkg_resources

2009-03-11 Thread Shane Hathaway
Martijn Faassen wrote:
Since ``setuptools`` is a dependency of our packages anyway, we
can instead do the following::
 
__import__('pkg_resources').declare_namespace(__name__)
 
Feel free to use that and also feel free to simplify existing
``__init__.py`` modules. Just make sure ``setuptools`` is a declared
dependency of the package.

Nit: In this case, two lines are better than one.

   import pkg_resources
   pkg_resources.declare_namespace(__name__)

There's no need to use the lesser known __import__ function when an 
ordinary import statement will do.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Extras (was zope.password)

2009-03-10 Thread Shane Hathaway
Stephan Richter wrote:
 On Tuesday 10 March 2009, Dan Korostelev wrote:
 Either you have a dependency and declare it or you don't have a
 dependency. Since we don't want to use extras anymore, I think this
 calls for another package which depends on zope.password and zope.schema.
 I still don't like/get the idea of creating and maintaining extra
 package that merely contains a vocabulary factory for another package.
 Whatever, I reverted that change. Roger, just exclude
 zope.app.authentication's password.zcml file, include
 zope.password explicitly and define your own vocabulary.
 
 I think we have become dependency paranoid. And we embrace package 
 proliferation instead, which in my opinion is equally bad. If you really hate 
 the dependency, make it an extra requires. I know that goes against the 
 latest guidelines as well...*sigh*
 
 My big problem here is that we dismiss all solutions but new packages. We 
 want 
 to minimize dependencies and not have extra includes. The only choice left is 
 a separate package. We should, however try to make the number of packages a 
 parameter too.

It seems to me that extras are a lot like Gentoo USE flags, except 
that the infrastructure for USE flags is much more complete.  USE flags 
are an essential feature of Gentoo.  Perhaps if the Python packaging 
chain had similar infrastructure, there would no longer be a reason to 
avoid extras and we could solve packaging and dependency problems a lot 
more easily.

Here are a few things you can do with USE flags that you can't yet do 
with extras:

- You can enable or disable a USE flag globally (yet override it 
per-package).  If you don't need X-Windows on your server, just add -X 
to /etc/make.conf, and nothing will be built with optional X support. 
If we had this feature, we would just add -zope.component to 
buildout.cfg and nothing would be installed with optional component 
architecture support.

- Packagers can specify whether a USE flag should be enabled by default.

- USE flags can cause whole chunks of code to not be compiled or 
installed.  I would love to be able to specify -coptimizations to 
build a Zope app without any optional C optimizations.  (That way, 
tracebacks would often be more informative.)

These days I run both a Gentoo and an Ubuntu box.  The Gentoo box has 
more features, but fewer packages, because Gentoo doesn't have to divide 
packages to avoid dependencies.

My $0.02.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.publisher dependencies

2009-03-06 Thread Shane Hathaway
Jim Fulton wrote:
 I'd rather leave zope.publsiher more or less alone, but develop a new 
 thing that has the basic/core functionality we need and refactor 
 zope.publisher to use that.  I'd also like to use or be compatible with 
 WebOb on that. I'd prefer to do this at PyCon where I'll have time to 
 pay attention and where there will be higher bandwidth communication.

I look forward to PyCon! :-)

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.publisher dependencies

2009-03-06 Thread Shane Hathaway
Martijn Faassen wrote:
 Jim Fulton wrote:
 [snip]
 I'd rather leave zope.publsiher more or less alone, but develop a new  
 thing that has the basic/core functionality we need and refactor  
 zope.publisher to use that. 
 
 I had the impression Shane was doing that; i.e. building zope.pipeline 
 factoring bits out of the publisher but not really changing the 
 publisher very much itself, creating a new structure instead. Shane, is 
 that correct?

Yes.  I think Jim and I are saying the same thing there.  The current 
code in zope.pipeline doesn't reflect that thinking, though, because we 
really need to divide zope.publisher somehow before a project like this 
makes sense.

 +1 on the WebOb compatibility. I imagine it should be possible to 
 reconstruct our request and response interfaces on top of WebOb's. We 
 should also think of ways so that code can get the WebOb request 
 directly instead of having to go through these adapters. I'd also be 
 much in favor of reusing WebOb's implementation, not just the APIs. I 
 think it could help us replace part of the publisher.

That should be a great thing to work on in a sprint.

 Thanks. I'm very much in favor of you guys talking at PyCon if that's 
 the best way to make progress. I'm also looking forward to seeing Shane 
 again at PyCon after meeting him so briefly all these years ago when I 
 was still young and nimble. So I'm glad to hear he's going to make it! 
 I'm also happy I'll get to see you again as well!

I'll be the one who arrives Monday afternoon without much hair on top. :-)

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-DB] RelStorage and Zope 2.9.8

2009-03-06 Thread Shane Hathaway
JeanMichel FRANCOIS wrote:
 I have tested RelStorage with Zope3.4 and i m happy with it. I would 
 like to know if it's usable with Zope 2.9. I'm not sure, but Zope2.9 is 
 release with a ZODB==3.6 and RelStorage need ZODB==3.7, isn't it ?

I think RelStorage could work with ZODB 3.6, but the combination hasn't 
been tested yet.  Would it be possible for you to upgrade to Zope 2.10?

Shane
___
Zope-DB mailing list
Zope-DB@zope.org
http://mail.zope.org/mailman/listinfo/zope-db


Re: [Zope-dev] zope.publisher dependencies

2009-03-05 Thread Shane Hathaway
Jim Fulton wrote:
 - It's not well enough documented.  While I think there's merit in doing 
 some things at the WSGI level, I remain pretty happy with the 
 publication interface for separatating generic publisher functions from 
 application policies.  I which the use of this API was better 
 communicated and understood.

I hope you're not asking me to write documentation for zope.publisher 
:-), because I only understand the mechanics.  The overall scope and 
purpose is cloudy to me.  In particular, I don't understand how the 
publication interface is actually generic.  Does it fit the needs of 
anything other than Zope?

 A less major complaint is some baggage from the past. There are a number 
 of request features that I never use and tend to forget about. The 
 biggest of these is the special form data unmarshalling and url 
 manipulation support. (I was amused to read in your introduction to your 
 pipeline proposal that people wanted to know the answer to the question: 
 When does Zope respect the :method form variable?. :)

FWIW, that particular functionality has been pulled out twice now, both 
in repoze.monty and zope.httpform.  As a baby step, we could make 
zope.publisher depend on zope.httpform.  (I made zope.httpform without 
knowing repoze.monty already existed, but zope.httpform has more tests 
and interfaces and it's hosted on svn.zope.org, so I think zope.httpform 
is worth keeping.)

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.publisher

2009-03-04 Thread Shane Hathaway
Roger Ineichen wrote:
 Shane,
 Can you review and merge this changes into your 
 zope.pipeline branch?

I'm going to put zope.pipeline on hold until the PyCon sprints.  Jim and 
I need to discuss it in person; hopefully then I can understand his 
opposition and the group can decide on the best direction for 
zope.publisher and zope.app.publication.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Zope.pipeline proposal

2009-02-25 Thread Shane Hathaway
Hi all,

I've put up a draft of a zope.pipeline proposal:

http://wiki.zope.org/zope3/ZopePipeline

The proposal is intended to explain my thoughts on the subject more 
thoroughly.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope.pipeline proposal

2009-02-25 Thread Shane Hathaway
Dan Korostelev wrote:
 Also, how easy is to integrate existing non-zopeish WSGI middlewares
 into the zope.pipeline? Like some resource injectors or XHTML slimmers
 and so on. It would be really great to be able to do that with single
 ZCML directive.

You can do that with two ZCML directives.  I probably need to elaborate 
on the directives in the proposal.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope.pipeline proposal

2009-02-25 Thread Shane Hathaway
Roger Ineichen wrote:
 Do you know something about the performance of WSGI?
 
 I whould be happy to see some perfomance tests comparing
 WSGI with other server concepts.

WSGI is extremely lightweight, so WSGI itself isn't going to affect 
performance.  The WSGI servers I know about are reasonably fast.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope.pipeline proposal

2009-02-25 Thread Shane Hathaway
Martin Aspeli wrote:
 I'm used to using Paste Deploy ini files to configure a WSGI pipeline. 
 Is this simply an alternative to that? If so, do we really need our own 
 alternative, or could we try to use the Paste Deploy stuff directly?

Yes, you can just use Paste Deploy instead of the ZCML-based pipeline 
builder.  However, the pipeline you get with Paste Deploy will not vary 
according to the request type, so you won't get the publisher's special 
handling for non-browser methods like PUT and DELETE, nor XML-RPC 
support, etc.

OTOH, I'm sure people can find creative ways to make Paste Deploy vary 
the pipeline according to the request type.

 I am a little worried about the conceptual overhead of having both the 
 ZCA and the WSGI pipeline provide swappability services to application 
 builders. It feels like those two things overlap somewhat in scope.

They do overlap, but the ZCA-configured pipeline can easily vary 
according to the request type.  I need to add more info about this to 
the proposal.

 Also, looking at your endware, there are some that seem to overlap with 
 Repoze stuff. Is this on purpose? I think the relationship with Repoze 
 should be made more clear in the proposal.

I don't know what the relationship is yet because I've chosen to only 
get code from Zope, for now, since I'm trying to maintain compatibility.

 virtual_host -- is this the same as repoze.vhm?

Could be.  Not sure.

 retry -- is this the same as repoze.retry?

I think it might be different, because this version of retry resets the 
environment rather than the request.  It has to be in the pipeline 
before the create_request application.  This design makes it possible to 
eliminate the complex retry code from Zope requests.

 create_request -- should this maybe have some compatibility with WebOb 
 requests?

I've looked at WebOb, and my impression is that Zope requests and WebOb 
requests serve completely different purposes.  A Zope request is 
essentially an input decoder and information holder.  A WebOb request is 
a whole framework, AFAICT.

That said, I expect zope.pipeline to give people a greater opportunity 
to prove I'm wrong about things like that.

 switch_pipeline -- could this be made non-Zope specific? It sounds useful.

I need to understand better what you mean by non-Zope specific.  How 
would you use it?

 log -- both repoze and paste have logging middleware, IIRC

Sure.  I haven't bothered to write this app at all since I know lots of 
people have written such things.

 open_root -- I thought repoze had something similar, but I may be wrong

I think this one is significantly different from Repoze.  It would be 
good to communicate about stuff like this at a sprint.

 clean_transaction -- is this not the same as repoze.tm2?

No.  To mimic the current Zope publisher, we need to commit the 
transaction shortly after the call application is finished, but then a 
lot of things can still happen before the response leaves the server, so 
we need to make sure any open transaction is aborted before letting the 
open_root application close the database.

This application is very small.  It might make sense to have the 
open_root application do its job instead.

 handle_error -- again, I thought Repoze had something like this

This error handling is very different from Repoze, I think.  It's going 
to handle errors the Zope way, by looking up error handlers in the 
database.  I imagine a lot of people will want to remove or customize it.

 end_transaction -- sounds like the other end of repoze.tm2

This is like repoze.tm2, but it will also annotate the transaction. 
Note that the code in my sandbox does not yet reflect this thinking.

 authenticate -- sounds like repoze.who?

I doubt it.  This does the IAuthentication dance, allowing 
authentication to be added during traversal.

 fix_relative_links -- sounds generally useful outside Zope as well

I wish, but this application depends on Zope's traversal logic to 
determine the canonical URL of an object.  I don't think the same 
traversal information will be present in most frameworks.

OTOH, I imagine fix_relative_links could be rewritten as a more broadly 
useful thing, if someone can figure out how without breaking performance.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope.pipeline proposal

2009-02-25 Thread Shane Hathaway
Hanno Schlichting wrote:
 What's the overhead of a WSGI middleware? Is the overhead cost in the
 same order of magnitude as a simple function call with a return value or
 is there something inherently more complex going on?

A WSGI middleware app is simply a callable thing that calls the next 
app, so the overhead is literally the same as a simple function call. 
There won't be security proxies or any other such thing getting in the way.

From my current experience I usually classify things into the groups of:
 
 1. attribute access
 2. function calls
 3. adapter lookups
 
 Going from one of these groups into the next one has a very noticeable
 performance cost involved, if used on the critical path of the application.

The current publisher is chock full of function calls and adapter 
lookups along the critical path.  I expect the zope.pipeline project to 
open everyone's eyes about just how much we're already doing in the 
critical path.  I think much of it is frequently not needed at all.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope.pipeline proposal

2009-02-25 Thread Shane Hathaway
Martin Aspeli wrote:
 Shane Hathaway wrote:
 Martin Aspeli wrote:
 clean_transaction -- is this not the same as repoze.tm2?
 No.  To mimic the current Zope publisher, we need to commit the 
 transaction shortly after the call application is finished, but then a 
 lot of things can still happen before the response leaves the server, so 
 we need to make sure any open transaction is aborted before letting the 
 open_root application close the database.
 
 Why is it desirable to do things in this way? I do find it kind of 
 confusing/error prone that we have two pieces of middleware: one that 
 opens the transaction and another that closes it, with ordering 
 dependencies between the two.

I'm trying to express something different, actually.  The first app, 
clean_transaction, only exists to cancel accidental writes.  The Zope 
publisher does this today.  The actual transaction management is in the 
second application, which I now realize is misnamed as end_transaction 
because it both begins and ends transactions.

 repoze.who seems to be turning into something of a widely used standard. 
 I think it'd be worth looking into whether it can be used 'upstream' and 
 something else could do the IAuthentication stuff based on what 
 repoze.who does.

Ok, that changes my perspective a bit.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Shane Hathaway
Jim Fulton wrote:
 On Feb 24, 2009, at 3:08 AM, Shane Hathaway wrote:
 
 I've been working on the dependencies to and from zope.publisher.
 Refining the dependencies should make it easier to integrate
 zope.pipeline when it's ready.
 
 Can you elaborate on this a bit?

I've been discussing zope.pipeline on my blog.  I am attempting to 
rebuild the publisher to make it easier to understand and customize.  I 
think it's working out pretty well.  zope.pipeline is intended to 
replace most of the implementation code in zope.publisher and 
zope.app.publication.

To accomplish that, it looks like I ought to separate the 
implementations in zope.publisher from the specifications.  Separating 
the zope.publisher.interfaces package would mostly accomplish that.

After thinking this over last night, I realize that the idea to move
BrowserView, BrowserPage, and TestRequest is driven by the desire to 
clarify the dependency graph.  That's more complex than what I'm trying 
to do and I don't think I need to do that for zope.pipeline, so I'm 
going to withdraw from that part of the discussion for now.

 I've noticed that nearly all packages that depend on zope.publisher
 depend only on a few pieces of it:

   - zope.publisher.interfaces

   - zope.publisher.browser.Browser{View|Page}

   - zope.publisher.browser.TestRequest
 
 
 I'd like to turn this around a little bit.  Only browser-based code  
 should depend on zope.publisher.  This seems like a very reasonable  
 dependency.  It's like wxwindows UI code depending on wxwindows.   
 Maybe the browser code should be factored out of the packages that  
 depend on zoep.publisher so that only *that* code has the dependency  
 and non-browser code doesn't.

I think things are already pretty well factored in that sense.  Take 
zope.formlib, for example.  It wouldn't make sense to separate 
zope.formlib into an abstract package and a browser package, because 
zope.formlib only makes sense for browsers.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Shane Hathaway
Jim Fulton wrote:
 I disagree strongly with many of the assertions made in these  
 articles. (I can't judge the pipeline proposal, since it is only  
 fleshed out in code.)  While I do think zope.publisher has some  
 problems, they aren't the same problems that shane sees.

What are the problems with zope.publisher as you see it?

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Shane Hathaway
Martijn Faassen wrote:
 The main problem I have with the zope publication machinery is that
 after all these years of using it I *still* get lost in it regularly.
 A more regular architecture that can be traced more easily would not
 only allow better understanding on my part, but might also allow us to
 more easily selectively replace or remove bits of it.

+1.  As I recall, we tried to build a regular architecture in 
zope.publisher using the IPublication interface, but the publisher 
machinery is still painfully difficult to understand without extensive 
study.

I think a pipeline design will make the publisher a lot easier for 
everyone to understand because the pipeline design seems to keep 
concerns closer together.  For example, I've made a traversal module 
in zope.pipeline which has nearly all of the traversal logic in one 
place and almost nothing else.  Its code came from at least 4 scattered 
modules.  Now, in theory, when people want to understand traversal, they 
will usually only need to understand one module.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Shane Hathaway
Jim Fulton wrote:
 Maybe, but I find that people confuse the machinery in zope.publisher  
 with a bunch of additional and very confusing machinery in various  
 zope.app packages.  The publisher itself is pretty simple.  I think  
 this is illustrated by paste.txt in the zope.publisher package.  That  
 isn't to say there might not be better models.

I see what you're saying and I agree that the zope.publisher package by 
itself is fairly simple.  However, zope.publisher by itself isn't very 
useful (except in tests), yet zope.publisher doesn't provide all the 
kinds of extension facilities that other packages require.  This has led 
to messy code, starting with zope.app.publication.

Furthermore, I'm not sure anyone can foresee all the ways people need to 
extend zope.publisher.  I think we need a more powerful abstraction.

  Hopefully, I'll find  
 time to study your pipeline ideas. I wish there was a proposal I could  
 read rather than reading code.

I am close to being able to formulate a proposal.  The concept is 
simple: move most publisher functionality into WSGI pipeline stages, 
similar to Repoze.  WSGI pipeline stages are very simple and powerful. 
I had to work out a way to build pipelines with replaceable stages, but 
I think I've almost solved that.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3

2009-02-24 Thread Shane Hathaway
Jim Fulton wrote:
 I agree that it shouldn't go in zope.app.  I believe I suggested  
 putting this in zc.openid, although I'm fine with zope.openid.

I'll rename it to zc.openid.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3

2009-02-24 Thread Shane Hathaway
Dan Korostelev wrote:
 2009/2/24 Jim Fulton j...@zope.com:
 I agree that it shouldn't go in zope.app.  I believe I suggested
 putting this in zc.openid, although I'm fine with zope.openid.
 
 Why zc? I thought it's only for packages coming from the zope
 corporation. Or does Shane works for ZC? :)

This is for a ZC contract.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Shane Hathaway
Martijn Faassen wrote:
 Hey,
 
 On Tue, Feb 24, 2009 at 11:26 PM, Jim Fulton j...@zope.com wrote:
 [snip]
 The graph only shows direct dependencies on zope.i18n and zope.security, but
 there are many other direct dependencies.
 
 Ah, agreed, yes, I think this is because of the transitive dependency
 functionality removal somehow, even though it seems to remove more
 than just these. Hanno's now also generating the real graphs, though:
 
 http://hannosch.eu/dependencies/zope/zope.publisher-full.svg

I see in that graph a number of dependencies that are pulled in just for 
specifications.  For instance, zope.publisher doesn't really need the 
Location class, it only needs ILocation.

Just brainstorming, but I wonder if we shouldn't split at least the 
following packages into specification and implementation packages:

   - zope.location
   - zope.security
   - zope.i18n
   - zope.publisher
   - zope.component

That way various packages could use i18n interfaces without pulling in 
pytz, or could use location interfaces without pulling in zope.proxy, 
and so on.

Brainstorming deeper: we could apply a naming convention where the 
specification package is named with the suffix spec, so zope.location 
would be split into zope.location and zope.locationspec.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.publisher dependencies

2009-02-24 Thread Shane Hathaway
Stephan Richter wrote:
 On Tuesday 24 February 2009, Shane Hathaway wrote:
 Brainstorming deeper: we could apply a naming convention where the
 specification package is named with the suffix spec, so zope.location
 would be split into zope.location and zope.locationspec.
 
 what about zope.ilocation?

Maybe.  I'd lean toward zope.locationspec because it would appear 
right after zope.location in a sorted list, making it more apparent that 
they are related.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] [Checkins] SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3

2009-02-23 Thread Shane Hathaway
Dan Korostelev wrote:
 2009/2/24 Shane Hathaway sh...@hathawaymix.org:
 Log message for revision 97183:
  New library for OpenID auth in Zope 3


 Changed:
  A   zope.app.openidconsumer/
 
 Wow, that's great! Finally an OpenID auth plugin is being developed!
 Thank you :) I thought about publishing this myself many times, but
 now, as you are doing that, I'll be happy to help developing and
 testing this package.

Thanks, though I should warn you that it's not at all ready to try out 
yet.  I imagine it has broken imports and the like.  I'll let you and 
the zope-dev list know when it's in a testable state.

BTW, this is what I'm getting paid to do at the moment. :-)

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Coding style clarifications

2009-02-19 Thread Shane Hathaway
Fred Drake wrote:
 On Thu, Feb 19, 2009 at 11:03 AM, Jim Fulton j...@zope.com wrote:
 BTW, I strongly discourage from imports. (I didn't always have this
 opinion, but have seen the error of my ways. Thanks to Fred Drake for
 nudging me in this direction.) IMO, this is wildly more important than
 any of the issues raised in this thread.
 
 You're welcome.  :-)

You're saying that:

 import zope.interface.Interface

 class IFoo(zope.interface.Interface):
 ...

is better than:

 from zope.interface import Interface

 class IFoo(Interface):
 ...

?

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Single Sign On

2009-02-18 Thread Shane Hathaway
Gary Poster wrote:
 We use the OpenID 2.0 identifier select URL. This is a special OpenID  
 url that
 basically means: identity using whatever ID you have on that server.
 
 The OpenID response will contain the actual OpenID identifier of the  
 user at
 the end of the request.
 
 So sites that we integrate in our SSO simply sends you to Launchpad for
 authentication and then uses the returned identifier to link with  
 their local
 account representation. We also use sreg (Simple Registration) to  
 transfer
 information about the account to the integrated sites, so that they can
 update their local account representation with the central data.

I see now!  Thanks, Francis and Gary.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Single Sign On

2009-02-18 Thread Shane Hathaway
Reinout van Rees wrote:
 So: easiest way is to let some trusted apache plugin handle the hard 
 part and then laugh all the way to the bank with some 100-line 
 authentication plugin.

That would usually work, but in this case, customers will be doing their 
own installation, so we need to keep the number of installation steps down.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Proposed Patch for zope.site

2009-02-18 Thread Shane Hathaway
Today I ran into an exception masked by Zope 3.  I found the code that 
was masking the exception and fixed it locally, but since this small bit 
of code has no docs or tests, I can't be sure I won't break stuff if I 
check in my change.  What do y'all think I should do?

Here is the patch:


Index: src/zope/site/hooks.py
===
--- src/zope/site/hooks.py  (revision 96718)
+++ src/zope/site/hooks.py  (working copy)
@@ -91,10 +91,7 @@


  def adapter_hook(interface, object, name='', default=None):
-try:
-return siteinfo.adapter_hook(interface, object, name, default)
-except zope.component.interfaces.ComponentLookupError:
-return default
+return siteinfo.adapter_hook(interface, object, name, default)


  def setHooks():



Catching ComponentLookupError is a problem when an adapter factory looks 
up another adapter.  If the first adapter lookup succeeds but the second 
fails with a ComponentLookupError, the current code makes it look like 
the first adapter is not registered at all.  Very confusing.  This patch 
exposes the correct traceback.

I think my patch is correct because the 'default' parameter implies to 
me that if 'siteinfo.adapter_hook' can't find an adapter, it will return 
None, not raise ComponentLookupError.  If 'siteinfo.adapter_hook' does 
in fact raise ComponentLookupError, then something else must be wrong 
and we should report the exception.

BTW, until recently, this module lived in zope.app.component.  It looks 
like this exception masking originated in Subversion revision 26391.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Single Sign On

2009-02-18 Thread Shane Hathaway
Marius Gedminas wrote:
 It's my impression that launchpad.net is an OpenID provider only, while
 Shane is trying to figure out how to use the OpenID consumer API in
 AuthKit.

No.  I am going after the more conventional single sign on use case 
where many consumers depend on only one centralized identity provider, 
and I'd like to use a restricted form of OpenID to accomplish it.  It 
turns out that Launchpad's internal authentication system is pretty much 
exactly what I was planning to do, so Gary's info pointed me in the 
right direction.  Launchpad also happens to provide public OpenID 
services, but I don't need to do that.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Single Sign On

2009-02-17 Thread Shane Hathaway
I'm working with a customer on a single sign on (SSO) system for Zope. 
We haven't yet chosen which SSO system we want to use.  I would like to 
hear from anyone who has set up SSO with Zope.

We have some definite requirements:

* We can't accept arbitrary identities like OpenID normally does.  We 
need to set up our own identity provider (IDP) and force our servers to 
accept only identities provided by our own IDP.

* The SSO process should be very similar to an ordinary cookie-based 
login process.  I don't want the user to have to enter their username on 
one form and their password on another, but that's the standard OpenID 
process.

* This will be implemented in Zope 3.

We are considering OpenID, Shibboleth, CAS, and any other mature system 
that others might suggest.  Shibboleth seems like the most obvious fit, 
but it's nowhere near as popular as OpenID.  I haven't yet looked at CAS 
in detail.

Alternatively, I have wondered if we actually need full-blown SSO; 
perhaps a carefully constructed domain-wide cookie would do the trick. 
Any experiences with that?

Thanks to anyone who participates.

Shane
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZCML implementations: where should they go

2009-02-10 Thread Shane Hathaway
Hanno Schlichting wrote:
 Wichert Akkerman wrote:
 I'ld rather not see a whole slew of extra packagse appear. I also wonder
 how the extra number of packages and increasing size of sys.path
 influence performance and restrictions on environments like GAE.
 
 For environments like GAE you don't want setuptools and its magic to be
 part of your application. This is were repackaging your entire app into
 one zipped egg or some other flat structure comes in handy.
 
 Setuptools and eggs are a distribution format from my point of view.
 They are certainly not the best way to deploy your applications. The
 growing sys.path is affecting performance to some degree in all
 deployment environments.

Well, zc.buildout ought to be able to eliminate this concern for GAE 
deployment.  I haven't tried the recipe below, but it certainly seems 
like the right idea.

http://pypi.python.org/pypi/rod.recipe.appengine

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope 3.4.0 Released!

2009-01-31 Thread Shane Hathaway
Stephan Richter wrote:
 It is finally here! Thanks goes to everyone who involved!
 
 January 29, 2009 - The Zope 3 development team announces the Zope 3.4.0 
 release.

Excellent!

I have to say, though, that the download process is quite confusing. 
Let's say I'm a Pythonista who wants to try out Zope 3.  Google sends me 
here:

http://download.zope.org/zope3.4/

After the release overview, the document tells me Zope is now 
distributed as eggs.  I'm familiar with eggs and I like them.

Then it talks about the KGS and my buildout.  It tells me how to modify 
my buildout configuration.  Wait, what's a buildout and how do I 
configure it?  Hmm, none of the links about the KGS tell me much about 
this buildout thing.  I can already tell it's gonna be hard to learn 
about Zope...

Well, I'll skip over the KGS stuff and see what I can figure out anyway. 
  Ok, I can follow the easy_install directions.  I'm really savvy and 
I'll even use virtualenv to do it, even though the document doesn't 
mention that.  I already have the habit of using virtualenv whenever I 
use easy_install.

So, following the directions, I create a project called HelloWorld.  I 
try to fire it up.  Uh-oh...

zope.configuration.config.ConfigurationExecutionError: class 
'zope.configuration.exceptions.ConfigurationError': Help Topic 
definition [...]/transaction-1.0a1-py2.5.egg/transaction/README.txt does 
not exist

So it breaks before even starting the server.  This is really trying my 
patience, but I study a lot of web pages and discuss the problem with 
other developers over a few days.  Following a friend's recommendation, 
I add the following two lines to the [buildout] section of buildout.cfg 
generated by zopeproject:

   extends = http://download.zope.org/zope3.4/3.4.0/versions.cfg
   versions = versions

After running bin/buildout again, the server finally starts!  Of course, 
what I see when the server starts is opaque and uninviting, but I'll 
leave that for another discussion. :-)

So, my question is: what should the download page *really* say? 
Consider that existing developers of Zope 3 don't actually need this 
page at all since they already use zc.buildout.  This page's audience, 
then, is people who know little about zc.buildout, let alone the KGS. 
Newbies need straightforward directions to follow.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [ZWeb] an idea for the wiki

2009-01-31 Thread Shane Hathaway
Lennart Regebro wrote:
 On Sat, Jan 31, 2009 at 20:23, Simon Michael si...@joyful.com wrote:
 Oh. That seems a pity, with Zope 3.4 just out; a site facelift would
 help. Would the designer care to comment ?
 
 Finding a new designer shouldn't be that tricky. I know somebody that
 can skin a Plone site in a day. There has been talk about this for
 years now, it's time something is done, to be honest. Maybe we should
 forget the site-by-commitee, appoint a dictator and get it done.

+1

Shane

___
Zope-web maillist  -  Zope-web@zope.org
http://mail.zope.org/mailman/listinfo/zope-web


Re: [Zope-dev] SVN: zope.publisher/trunk/ Fixed LP #322486: setStatus() now allows any int()-able status value.

2009-01-30 Thread Shane Hathaway
Tres Seaver wrote:
 Is there any reason to hide the KeyError behind a 500, rather than
 letting it propagate to the application?   In this implementation, we
 lose the information about the bad 'status' value.

I agree, but I hit a legacy design snag.  The handleException() method 
still calls setStatus(exception_type_name), where we could be handling 
any kind of exception, similar to what Zope has always done.

IMHO, we should change the contract of setStatus() to not do any lookup 
at all and make handleException() do the lookup instead, or something 
along those lines.  But I'm trying to make conservative changes ATM.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] [Checkins] SVN: relstorage/trunk/ Corporation - Foundation

2009-01-25 Thread Shane Hathaway
Benji York wrote:
 On Sat, Jan 24, 2009 at 9:43 PM, Shane Hathaway sh...@hathawaymix.org wrote:
 Log message for revision 94997:
  Corporation - Foundation
 
 AFAIK, the IP hasn't been transfered yet.  I'm not sure what the
 implications of using Foundation are at this point.

Even so, I have no doubt that assigning the copyright to the foundation
is better than assigning to a corporation.

Shane

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


  1   2   3   4   5   6   7   >