[Zope3-dev] Re: Subscriber Ordering

[Jim Fulton]

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.

Not exactly.

 > 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?

No. The first example I gave was the adding of user data after a user
is created.  There are a variety of user data that can be added, including
properties and groups.  A goal of PAS is to decentralize the handling
of this data.  For example, groups could be added from
LDAP and from specialized group managers. Similarly, properties could come from
a variety of sources, such as ldap, annotations, etc.  Sometimes, there
are ordering dependencies between these that are very application dependent.
PAS itself cannot anticipate these.

I also mentioned that this might make it easier to use subscribers, and
thus adapters, for credential extraction and challenge, but, in this case,
these would be triggered by different events, or they might even be handled by
subscriber-based adapter lookup.  I probably shouldn't have mentioned this,
however, because it just confused the issue.

> 
> 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.

No, you are missing my point. Sometimes you need to order subscribers of the
*same type*.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org