-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
Julien Anguenot wrote:
I'm gonna respond to a number of emails at once. :)
Tim Peters wrote:
[Tim]
...
Julien provided links to code that already uses the new feature:
As an Indexation Manager :
http://svn.nuxeo.org/trac/pub/file/CPSCore/trunk/IndexationManager.py
As an Event Manager :
http://svn.nuxeo.org/trac/pub/file/CPSSubscriptions/trunk/EventManager.py
He appears to use (just) two distinct `order` levels there, and seems
just to want to make sure one class of hook gets run before the other
class of hook. The new scheme does give an easy way to do that.
OTOH, while picking levels of -100 and 100 works for that specific
use case,
looks like it threatens to become a mess if multiple subsystems try
to use
this scheme simultaneously.
We discussed quickly about this with Florent. This can be expressed by
having a coding guide for the given framework (for instance CPS). We
will provide ranges in which hooks are executed. Then if someone wants
to register another one he can check the existing ones and the ranges
they are using and what they are doing. Just a matter of documentation.
Of course, this doesn't work across projects.
ok here we agree :)
For example, someone who wants to be the last
kind of hook invoked has no way to force that, at least not short of
passing sys.maxint as the `order`. But if that's what's needed,
`sys.maxint` is a strange way to spell it.
I understand it but this is something that could be done by extending
the transaction hooks sub-system. But again we don't have YAGNI yet for
a bigger sub-system that could include this.
The very fact that to really do what you need to do today would require an
extension indicates that the current API isn't what we should be doing.
We'll never have what every application needs anyway, which is why this
ordering logic should be at the application level where it's easy to
control.
I don't understand why keeping the order paremeter is such a big deal ?
Because it clutters the ZODB API with something that is, fundamentally
application policy.
Here we disagree.
I could agree if only one hook could be registred instead of a severals
(within a tiny little tuple :) ).
Then you could say : It's application logic just register your object
as *the* hook that will deal with the order of execution of other
sub-hooks your system defines
Here, it's not the case because you can register several within a
transaction and actually the ZODB has already a policy regarding this
which is executing it in the order they've been registred.
Thus my proposal could be seen as well as a request to change (or to
make more flexible) the policy already in place. (Which was my use case)
It prevents me having to code my own specific object dealing with this
Dealing with what?
Dealing with the order of execution.
Your original need was to make something go last.
Well yes and no. What if I want to go first instead ? Or in the middle
of 2 independently (external to my system) defined hooks ?
As Tim pointed out, the order api doesn't do that and, as I've pointed out,
the existing API does deal with that.
no. not enough flexibility.
and I'm sure other people will benefit from this later on when they will
have to use this transaction feature.
That's hypothetical. In any case, if you are so sure, provide a system
that does this and let people use it. You don't need to make ZODB more
complicated to address this use case.
Jim, honestly where is the complication ?
Dieter Maurer wrote:
Tim Peters wrote at 2005-8-22 16:48 -0400:
...
Jim still wonders, and he got me wondering too, whether the `order=`
gimmick
is really needed.
But, it is a very easy concept -- both easy to grasp as well as easy
to implement.
Just because it's an easy concept, doesn't mean it belongs in
in the transaction layer. It would be just as easy a concept
as a ZODB add-on. I wouldn't object to such a thing in Zope, for
example.
Then don't allow the registration of several hooks. Just provide one
slot to register only one. Then I could be fine with this.
Let's imagine :
I got the following hypotetical architecture :
Let's say I follow what you're saying.
- --
ZODB
Zope3 - defines hook A (managing perhaps other hooks and manage the
order of execution of its sub-hooks)
z3ecm - define hook B (idem A)
CPS4 - define hook C (idem A)
- ---
Imagine within the top layer (CPS4) I want to execute one of my hook in
between two of the Zope3 and z3ecm hooks ? I definitely Can't...
Julien Anguenot wrote:
Jim Fulton wrote:
...
Do we have evidence that such applications exist? So far, the
only example I've seen is one where an application wanted a handler
to go last. As I've pointed out in a separate note, this is achievable
without the change.
We have. We are thinking of adding another hook within CPS to
