[Zope3-dev] EventService, references, and subscription semantics

[Tres Seaver]

On Mon, 25 Feb 2002, Casey Duncan wrote:

> On Monday 25 February 2002 10:24 am, Steve Alexander allegedly wrote:
> [sniplets]
> > So, transient (ie non persisted) subscription is kept distinct from
> > subscription that persists between z3.py invocations.
> > FS things are only allowed to use the FSEventService.
> > Most code that wants to use the event service will get it by asking for
> > an IEventService. The root ZODB event service will propagate events to
> > the FSEventService.
>
> Hmmm, I hadn't really considered an FSEventService, but the idea does have
> merit. I think we need to cook up some use cases, but I do think it could be
> a very useful CA addition, perhaps as a way to bind packages together or
> somesuch.
>
> I do think we should punt on the persistent objects as FS EventService
> subscribers tho, I think it is more trouble then it is worth. I seems like
> too much mixing of levels, too much complexity and brittleness for my liking.
>
> > Of course, it might turn out that we don't really need an
> > FSEventService. Although, I can see it being useful for using the
> > ComponentArchitecture outside of Zope3.
>
> Maybe not, but my intuition says that it might solve some problems pretty
> elegantly...
>
> > Then, we still have the issue of what to use for references.
> > We can use object references provided we're happy to only allow
> > persistent objects to be passed to subscribe().
>
> This is the problem I tried to work on in my ExplicitObjectReferences
> proposal. The problem with using regular object references is that the
> subscriber looses its original context and the reference makes the object
> persist even if it is deleted from its original location.
>
> So unless these two things aren't an issue, I don't think object references
> will work for this. I will definitely not mind being wrong, however.

Maybe the FS service should just store names suitable for passing
to 'resolve' (assuming, of course, that such a beast is actually
useful for anything other than working out the kinks before the
service manager stuff is really wired up).

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com