[Zope-PTK] New tool proposal: portal_events

[Andrew Wilcox]

At 11:18 AM 8/22/00 -0400, Tres Seaver wrote:
>Of course an inheritance-based solution is actually slighly *more*
>inflexible than one which leverages Python's dynamism.  My proposal
>is actually motivated by the CORBA NotificationService, which has
>a very similar signature, passing "filterable" meta-data separately
>from the payload.  Their service was developed after extensive
>experience with strongly-typed event hierarchies, and makes some
>good tradeoffs, it seems to me.

Er, a signature which makes sense in Python may well not when you're
working within CORBA's contraints.  Correct me if I'm wrong, as I don't
have the experience with CORBA that you do, but is it fair to say that
CORBA tends not to have many of the small, lightweight classes as you'll
typically find in Smalltalk or Python programming?  Encapsulating
functionality into a class often makes sense in an object oriented
language, but CORBA needs to have API's into lots of non-oo languages.  If
I need to unpack a class from an non-oo language, that's going to create
more work for me instead of less.

So yes, certainly let's make portal events as flexible and as easy to
filter as CORBA does.  We are still free to choose our own signature.

>Filtering based on inheritance classifications has two drawbacks:
>
>  * Either you *don't* know all the event types ahead of time, in
>    which case you must do *really slow* testing for each base
>    class you *do* know about;  you can then use only the services
>    provided by those bases.  Note that subscribers have a "moral
>    obligation" to take as little time as possible during the
>    notification;  their processing is (at least in a naive
>    implementation) blocks the completion of the transaction.

Excuse me, I wasn't being clear enough, you were responding to a sentence
in which I mentioned filtering on the type of event, which I did not mean
to imply was the only kind of filtering that you'd want to do.

My suggestion for "meta data", as you call it, is to have a mixin class for
a particular set of meta data attributes; now it is easy, quick, and
reliable to test if the event supports a particular meta data attribute and
to filter on it, orthogonal to the primary type of the event.

>  * Or, you *do* know all the event types, in which case you are
>    going to dispatch on the type directly;  this is exactly the
>    case for the signature I proposed, except that the subscriber
>    has to do more work.

I read this twice, and I can't tell if the "except" clause goes with the
first or the second, i.e. in which approach you think the subscriber would
need to do more work.  As a potential future client of the framework, my
goal is to do *less* work, of course <grin>

>> With an Event class, you
>> can easily refactor your code to make the common operations methods of the
>> class, simplifying your client code.
>
>This may be so, for a specific portal;  one of the problems of the PTK
>is to provide extensible mechanisms for implementing such behavior, without
>imposing policies rigid enough to defeat the extensibility.

Yes, and encapsulation helps me.  When I create my own class to implement
my own policies, I know it will work with the rest of the system as long as
it follows the contract.

>Given the
>API I originally specified, for instance, it would be simple to deploy
>a portal which passed the kind of Event objects you describe as the payload
>paramter, passing their class object as the eventType;  all "custom" code
>in the portal would use the payload object directly, while the "framework"
>code would continue to dispatch on eventType.

Yuck!  (sorry)  I want to write some filtering code.  Now I have to look at
the eventType to see if I'm getting "normal" framework events or Event
objects and do different things depending on which I get.

It'd be nice to make the discussion more concrete.  How about some examples
of meta data you'd want to be able to filter on?

Andrew