[Zope3-dev] Re: Subscriber Ordering

[Tres Seaver]

Philipp von Weitershausen wrote:
> Tres Seaver wrote:
> 
>> Philipp von Weitershausen wrote:
>>
>>> Jim Fulton wrote:
>>>
>>>> Currently, the order that subscription adapters are called in is
>>>> undefined [1]_.  Sometimes, we *do* want some control over the order
>>>> of subscriber notification.  There are a number of ways to do this:
>>>>
>>>> 1. You can publish multiple events.  This has the disadvantage that
>>>>    the publisher of the events has to be aware of the desired
>>>>    ordering. It doesn't work if the ordering is a policy of the
>>>>    subscribers themselves.
>>>>
>>>> 2. If a subscriber needs to come after some earlier subscriber, we
>>>>    have the earlier subscriber generate an event. The later subscriber
>>>>    subscribes to the event generated by the earlier subscriber, rather
>>>>    than to the original event.  This requires the collaboration of the
>>>>    subscribers to implement the policy.
>>>>
>>>> It would be nice, at times, to provide the ordering policy outside the
>>>> subscribers and the notifiers.  Here is an idea.
>>>>
>>>> - We allow subscribers to be named.  There could be multiple
>>>>   subscribers of the same type [2]_ and name, so the names will
>>>>   really name classes of subscribers.
>>>
>>>
>>>
>>>
>>> -1
>>>
>>> As far as I understand this, you want to express the functionality of 
>>> the subscriber in these names. The example you mention is PAS which 
>>> needs to send out events for credential extraction and challenge. 
>>> They are essentially registered for the same event so there needs to 
>>> be a way of telling them apart so that we can invoke them in a 
>>> defined order.
>>> Did I get this right?
>>>
>>> I think introducing subscriber names is not necessary. I think one 
>>> can leverage the understanding (and implementation) of subscribers as 
>>> subscription *adapters*.  They subscribe to an object in order to 
>>> provide certain functionality for it which is expressed in the 
>>> provided interface they are registered with.
>>>
>>> In other words, instead of having PAS send out events like this (I'm 
>>> using mock-up code here):
>>>
>>>   zapi.subscribers((NeedYouToDoSomething, request),
>>>                    name="credentials")
>>>   zapi.subscribers((NeedYouToDoSomething, request),
>>>                    name="challenge")
>>>
>>> or even
>>>
>>>   zapi.subscribers((NeedYouToDoSomething, request),
>>>                    order=["credentials", "challenge"])
>>>
>>>
>>> I would prefer it subscription-adapting them to specific interfaces 
>>> that describe the functionality you'd expect from the subscribers:
>>>
>>>   zapi.subscribers((NeedYouToDoSomething, request),
>>>                    IExtractCredentials)
>>>   zapi.subscribers((NeedYouToDoSomething, request),
>>>                    IChallengeUser)
>>>
>>> Advantages:
>>>
>>>   - Consistency: interfaces are used to describe functionality
>>>
>>>   - It's already implemented.
>>>
>>> As you suggested, decoupling event send out and the subscribers from 
>>> the actual order can be achieved through an "unnamed" (providing None 
>>> in my case) subscriber that somehow "knows" the order (probably 
>>> through configuration). In my case, of course, the elements in that 
>>> ordered list would be interfaces, not names.
>>
>>
>>
>> Yuo are missing Jim's point:  for a given subscriber interface, there 
>> may be *multiple* subscribers, and we may need to control the order in 
>> which those subscribers are notified.
> 
> 
> Nope, I didn't miss that point. I'm just saying that I want a different 
> way of controlling that order. Jim wants to introduce names, I'm saying 
> let's use the interfaces we already have.


If I have three plugins which implement a given plugin interface (e.g., 
IExtractCredentials), how do you propose that I specify the order in 
which they are notified?  Your syntax above gives me *no* control over 
that order.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver at zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com