[Zope3-dev] Re: Subscriber Ordering

[Philipp von Weitershausen]

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.

Philipp