[Zope3-dev] Re: Subscriber Ordering

[Philipp von Weitershausen]

Tres Seaver wrote:
> 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.

I see what you mean now. I guess I did misunderstand Jim then. In that 
case named subscription adapters seem like a good idea. And they would 
perfect the symmetry since regular adapters can be named already.

Philipp