At 10:03 AM 5/26/00 +1000, Anthony Baxter wrote:

...

...

...

"Phillip J. Eby" wrote

I would suggest that it ask for an interface, rather than a meta_type. Otherwise, you've hardwired yourself into a single object type with no extensibility. For example, an SQL method wants the nearest SQL connection, but shouldn't have to explicitly ask for each kind of SQL connection (Sybase, Oracle, etc.)

In that case, would you have a matching call in the observer objects where they can specify what it is that they offer? Rather than basing it on type, you'd say 'find the nearest resource that wants to know about blah'.

I would say that resource discovery is orthogonal to event subscription, and that if you were discovering resources for the purpose of sending them events, you should search for an interface that lets you query whether that object wants to receive events. :) In practice, however, doing resource discovery for event subscriptions is backwards. If you have a Catalog or some other thing that wants to subscribe to events below it, it should subscribe to events from containers to know when things are added, (including sub-containers, which it could also subscribe itself to) then subscribe to the objects themselves whenever it's notified of an add. Having "catalog aware" objects look for a catalog doesn't make sense in the context of an event-driven system. Objects need only generate change events, and containers need only generate add/delete events. The rest can be done by the Catalog or other observer. Notice, by the way, that a Catalog that worked this way would be extremely flexible; you could specify persistent rules for what kinds of objects would be "found into" the Catalog, and you could dynamically add/remove the catalog's hooks from various folders, "pruning" its "search" scope. The catalog itself would hold no references to the objects which send it events, but could wander far and wide over the database. At this point it's really tempting to take a whack at adding an event system to ZPatterns based on the models discussed so far, except for the fact that I'm rather behind on getting its more modest event management system finished, *and* the fact that Zope doesn't really have a robust traversal interface at the moment. If 2.2 ends up with a solid traversal system, I will certainly be willing to take a look at it. One interesting interplay between ZPatterns events and Zope events, is that ZPatterns triggers (aka RuleAgents) could be used to set up rules which fire events on managed objects. This would allow one to wrap custom events and subscriptions around any DataSkin-based object instance, without the skin's class having to have been designed to send those events. An interesting idea, indeed.