Sidnei da Silva wrote at 2005-9-2 17:06 -0300:
> ...
>| >So:
>| >
>| > event(IBeforeSubsystem, SubSystem)
>| > execute SubSystem
>| > event(IAfterSubsystem, Subsystem)
>| >
>| >Back to my example, 'B' would subscribe to 'event(IAfterSubsystem,
>| >A)', and 'AB' could subscribe to 'event(IBeforeS
On Fri, Sep 02, 2005 at 08:55:28PM +0200, Dieter Maurer wrote:
| Sidnei da Silva wrote at 2005-9-1 17:13 -0300:
| > ...
| >Yes, he's the one in charge of registering the subscribers so they are
| >called in the order he wants them to.
| >
| >So:
| >
| > event(IBeforeSubsystem, SubSystem)
| > exec
Sidnei da Silva wrote at 2005-9-1 17:13 -0300:
> ...
>Yes, he's the one in charge of registering the subscribers so they are
>called in the order he wants them to.
>
>So:
>
> event(IBeforeSubsystem, SubSystem)
> execute SubSystem
> event(IAfterSubsystem, Subsystem)
>
>Back to my example, 'B' wou
On Thu, Sep 01, 2005 at 08:34:11PM +0200, Dieter Maurer wrote:
| Sidnei da Silva wrote at 2005-8-31 23:42 -0300:
| > ...
| >I would instead fire 'before' and 'after' events for each of those
| >systems, and a system that wants to explicitly run after/before
| >another system would do so as a subscr
Sidnei da Silva wrote at 2005-8-31 23:42 -0300:
> ...
>I would instead fire 'before' and 'after' events for each of those
>systems, and a system that wants to explicitly run after/before
>another system would do so as a subscriber to the explicit event
>fired.
But the "systems" do not know about o
Jim Fulton wrote at 2005-8-31 18:02 -0400:
> ...
>> The "order gimmick", while not universal, provides an easy
>> and understandable facility to handle a large group of such
>> use cases.
>
>Huh? It doesn't help these use cases at all.
Of course, it does: together with values assigned by the integ
On Wed, Aug 31, 2005 at 06:02:21PM -0400, Jim Fulton wrote:
| You might be right, but the only credible use case I've seen
| is to go last. The example Julien has something going first
| and something going last. Looking at the code, I don't see
| why the thing he wanted to go first needed to do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
ok this time I'm giving up. Not because you convinced me but because I
don't want to spend more energy on this since you'll have the last word
anyway.
You want to remove it, fine do it. Let's have several specific hook
ordering implementations on ever
Dieter Maurer wrote:
Jim Fulton wrote at 2005-8-31 10:20 -0400:
...
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)
Except that, as Tim and I have pointed out, the order gimmic didn't
deal at all w
Jim Fulton wrote at 2005-8-31 10:20 -0400:
> ...
>> 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)
>
>Except that, as Tim and I have pointed out, the order gimmic didn't
>deal at all well with the use
Julien Anguenot wrote:
Jim Fulton wrote:
...
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
-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 Indexati
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeremy Hylton wrote:
> On 8/22/05, Tim Peters <[EMAIL PROTECTED]> wrote:
>
>>Jim still wonders, and he got me wondering too, whether the `order=` gimmick
>>is really needed. For example, you could have gotten to the same end here
>>with the old metho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
> 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 -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
> 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
>>>
>>> A
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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.nu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tim Peters wrote:
> [Tim]
>
>>>...
>>>It's tricky to implement this in a way that scales efficiently to
>>>a "large number" of hooks. I assume that's not a problem, because
>>>the current implementation doesn't scale efficiently either (it's
>>>quadr
Tim Peters wrote at 2005-8-24 16:10 -0400:
> ...
>[Dieter]
>> I have a *package* (similar to Archetypes SQLStorage) that wants to go
>> after everything that might possibly change attributes whether those
>> changes are done by another component from me or any package developped
>> by someone else.
Jim Fulton wrote at 2005-8-24 16:08 -0400:
> ...
>> I have a *package* (similar to Archetypes SQLStorage) that
>> wants to go after everything that might possibly change attributes
>> whether those changes are done by another component from me
>> or any package developped by someone else.
>
>So aga
[Dieter]
>>> Now plug and play comes into play:
>>>
>>> Assume two packages developped by independent people
>>> which all want to control the order of hook execution.
[Jim]
>> Do we have evidence that such applications exist? So far, the only
>> example I've seen is one where an application w
On 8/22/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> Jim still wonders, and he got me wondering too, whether the `order=` gimmick
> is really needed. For example, you could have gotten to the same end here
> with the old method, by registering your actions with an object of your own
> creation, and
Dieter Maurer wrote:
Jim Fulton wrote at 2005-8-23 14:22 -0400:
...
For example, you could have gotten to the same end here
with the old method, by registering your actions with an object of your own
creation, and registering just one commit hook with the transaction, where
that one hook look
Jim Fulton wrote at 2005-8-23 14:22 -0400:
> ...
>>>For example, you could have gotten to the same end here
>>>with the old method, by registering your actions with an object of your own
>>>creation, and registering just one commit hook with the transaction, where
>>>that one hook looked at the act
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.
This is not sufficient IMO.
For example, y
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.
> For example, you could have gotten to the same end here
>with the o
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
"""
[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
> """
>
> H
[Tim]
>> ...
>> It's tricky to implement this in a way that scales efficiently to
>> a "large number" of hooks. I assume that's not a problem, because
>> the current implementation doesn't scale efficiently either (it's
>> quadratic-time in the number of hooks), and nobody has complained
>> about
[Jim Fulton, on Julien's addBeforeCommitHook() change]
> What is the motivation for this? Can you give any use cases?
>
> I'm -1 on this because it adds complexity to something that I think
> should be simple. It feels like something that is likely to be missused.
> I do have an open mind though.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
> Julien Anguenot wrote:
[...]
>> I would like to order the before commit hooks on a transaction by being
>> able to specify an order for a subscriber at registration time. For the
>> moment, they are called in the order they've been
Julien Anguenot wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I would like to order the before commit hooks on a transaction by being
able to specify an order for a subscriber at registration time. For the
moment, they are called in the order they've been registred.
The order argume
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I created a branch there :
http://svn.zope.org/ZODB/branches/anguenot-ordering-beforecommitsubscribers/
See changeset 37789
Check the changeset log for more information about the implementation.
J.
Julien Anguenot wrote:
> Hi,
>
> I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tim Peters wrote:
> [Julien Anguenot]
>
>>...
>>To make it clear the idea is if you got this and if we call it "order".
>>
>>Callback Ca order 0
>>Callback Cb order 99
>>Callback Cc order -99
>>
>>The order of execution will be Cc Ca and then
[Julien Anguenot]
> ...
> To make it clear the idea is if you got this and if we call it "order".
>
> Callback Ca order 0
> Callback Cb order 99
> Callback Cc order -99
>
> The order of execution will be Cc Ca and then Cb.
>
> Note the ones with a default order (e.g : 0) will be executed in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tim Peters wrote:
> [Julien Anguenot]
> ...
>
>>>The order argument could be an integer with a default value to 0 added
>>>to the registration method.
>
>
> [Gary Poster]
>
>>I usually like the word 'priority' for this sort of value, rather than
>>
On Aug 5, 2005, at 2:33 PM, Tim Peters wrote:
[Julien Anguenot]
...
The order argument could be an integer with a default value to 0
added
to the registration method.
[Gary Poster]
I usually like the word 'priority' for this sort of value, rather
than
'order'. To me 'order' implies
[Julien Anguenot]
...
>> The order argument could be an integer with a default value to 0 added
>> to the registration method.
[Gary Poster]
> I usually like the word 'priority' for this sort of value, rather than
> 'order'. To me 'order' implies unique value--i.e., with 'order' I am
> mildly sur
Julien Anguenot wrote at 2005-8-5 12:20 +0200:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>Hi,
>
>I would like to order the before commit hooks on a transaction by being
>able to specify an order for a subscriber at registration time. For the
>moment, they are called in the order they've bee
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Gary,
Gary Poster wrote:
> On Aug 5, 2005, at 6:20 AM, Julien Anguenot wrote:
>> I would like to order the before commit hooks on a transaction by being
>> able to specify an order for a subscriber at registration time. For the
>> moment, they ar
On Aug 5, 2005, at 6:20 AM, Julien Anguenot wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I would like to order the before commit hooks on a transaction by
being
able to specify an order for a subscriber at registration time. For
the
moment, they are called in the order they'v
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I would like to order the before commit hooks on a transaction by being
able to specify an order for a subscriber at registration time. For the
moment, they are called in the order they've been registred.
The order argument could be an integer wi
43 matches
Mail list logo
