[Zope3-dev] Re: Subscriber Ordering

[Tres Seaver]

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.

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