Re: [Zope-dev] Observer / Notification Interface Proposal
Michel Pelletier <michel@digicool.com> wrote:
I'll do both, this is absolutely a desperately needed feature in the ZCatalog. Currently, Cataloged items must take responsibility for notifying a catalog of their changes instead of the ZCatalog observing them.
Amos and I talked about this over Pizza a couple weeks ago but we were thinking from a pretty Catalogcentric view; or at least I was. I was considering an interface like the new Security API that could be imported in python and used to discover and notify catalogs of object changes. But this now seems to me to be some kind of pattern where objects need to discover an appropriate or canonical resource, like a catalog. This interface should be defined also, so that newly-born objects can notify a resources of their existence. I've added this to the InterfacesWiki
http://www.zope.org/Members/michel/Projects/Interfaces/Discovery
Thoughts on how they relate? Are they the same thing?
I think this pattern is orthagonal to the ObserverAndNotification pattern, but is crucial to making things like TheClassFormerlyKnownAsCatalogAware and Ken's new WikiRelationship object work. CORBA solves this by mandating that the ORB provide a lookup method:: def resolve_initial_references( resource_type ): where resource_type is a well-known string like 'NamingService', etc. In our case, perhaps it needs to be:: def findNearestResource( meta_type ): which causes a walk up the containment hierarchy, searching for objects of the given meta_type. Tres. -- ========================================================= Tres Seaver tseaver@digicool.com Digital Creations "Zope Dealers" http://www.zope.org
----- Original Message ----- From: Tres Seaver <tseaver@palladion.com>
In our case, perhaps it needs to be::
def findNearestResource( meta_type ):
which causes a walk up the containment hierarchy, searching for objects of the given meta_type.
This exists! (sort of). ObjectManager.superValues accepts a list of meta_types, and returns a list of all objects of those meta_types which can be found in any ObjectManager in the current one's acquisition context. Cheers, Evan @ digicool & 4-am
Evan Simpson wrote:
This exists! (sort of). ObjectManager.superValues accepts a list of meta_types, and returns a list of all objects of those meta_types which can be found in any ObjectManager in the current one's acquisition context.
and has done for ages... the original Squishdot code uses this to find appropriate mailhosts and I'd be suprised if ZSQL methods didn't do the same to find databse connections... cheers, Chris
Tres Seaver wrote:
Michel Pelletier <michel@digicool.com> wrote:
http://www.zope.org/Members/michel/Projects/Interfaces/Discovery
Thoughts on how they relate? Are they the same thing?
I think this pattern is orthagonal to the ObserverAndNotification pattern, but is crucial to making things like TheClassFormerlyKnownAsCatalogAware and Ken's new WikiRelationship object work. CORBA solves this by mandating that the ORB provide a lookup method::
def resolve_initial_references( resource_type ):
where resource_type is a well-known string like 'NamingService', etc.
In our case, perhaps it needs to be::
def findNearestResource( meta_type ):
There allready exists such a thing, superValues([meta_type]). But I think this is too weak to use as a discovery protocol. An observable may not know or care what type of observer it wants to discover. Also, when it finds a number of various resources, catalogs lets say, does it just notify them all? Is there a concept of a default? Can they negotiate? -- -Michel Pelletier http://www.zope.org/Members/michel/MyWiki Visit WikiCentral for the latest Zen: http://www.zope.org/Members/WikiCentral
Michel Pelletier wrote:
There allready exists such a thing, superValues([meta_type]). But I think this is too weak to use as a discovery protocol. An observable may not know or care what type of observer it wants to discover. Also, when it finds a number of various resources, catalogs lets say, does it just notify them all? Is there a concept of a default? Can they negotiate?
Can this be limited by security? Take our Free Zope server, we don't want something to discover everyone else's ZCatalog's What about non-security related? There may be similar instances where you don't want to discover anything other than a specific catalog... Also, can an observer that gets notified during discovery just turn around and so 'no, I don't want to do anything with your notification'? cheers, Chris
At 10:42 AM 5/25/00 -0400, Tres Seaver wrote:
In our case, perhaps it needs to be::
def findNearestResource( meta_type ):
which causes a walk up the containment hierarchy, searching for objects of the given meta_type.
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.)
participants (5)
-
Chris Withers -
Evan Simpson -
Michel Pelletier -
Phillip J. Eby -
Tres Seaver