[Zope-dev] Resource Discovery (was Observer / Notification Interface Proposal) Proposal)

[Phillip J. Eby]

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.