[Zope3-dev] Re: Subscriber Ordering

[Philipp von Weitershausen]

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.

Philipp