[Zope3-dev] Re: discussion about ObjectHub, EventService etc. (was event-meta.zcml...)

[Casey Duncan]

On Wednesday 18 December 2002 11:45 am, Steve Alexander wrote:
> >> The naming is unfortunate -- perhaps we should rename the service to=
=20
> >> be the ContentId Service or ContentHub service, and leave the name=20
> >> "ObjectHub" to be the more general implementation of this service,=20
> >> which can be used in ways other than as a service.
> >=20
> > I am fine with the way things are now, naming wise, but also fine wit=
h a=20
> > change should that be desired.
>=20
> Ok. I'll propose this as a renaming in a separate email that people can=
=20
> reply to and discuss.

I agree. Lets not get bogged down in subjective naming debates that are a=
lways=20
subject to change.
=20
> >> We could have an IZopeEventService, which extends an IEventService f=
or=20
> >> easy use in the Zope framework.
> >>
> >> So:
> >>
> >>   IEventService            Generic, useable outside of Zope.
> >>       ^                    Not specific about how subscribe() works.
> >>       |
> >>       |
> >>   IZopeEventService        Extends the semantics of the subscribe()
> >>       ^                    method to allow subscribtion by location,
> >>       |                    hubId relative to ObjectHub service, or
> >>       |                    physically locatable object.
> >>       |
> >>       |
> >>   IGlobalEventService      Has special globalSubscribe() method.
> >>                            Disables subscribe() method.
> >>                            Used as the global event service.
> >=20
> >=20
> > Ah well, one often prefers one's own ideas: the directSubscribe and t=
he=20
> > local subclassing global makes more sense to me.  But I'm amenable to=
=20
> > this.
>=20
> Ok.
>=20
> > You mention about IEventService above that it is "usable outside=20
> > of Zope".  The interface is, yes, but none of our implementations wil=
l=20
> > be, so I'm not sure what kind of win that will be.  Whatever.
>=20
> I'm guessing that we can write a useful non-zope-specific base=20
> EventService, and then derive ZopeEventService and GlobalEventService=20
> from that.

That would be fine so long as it isn't too time intensive. Using stuff ou=
tside=20
of Zope is a "nice to have" but obviously not a requirement for many of u=
s at=20
the moment.
=20
[snip]
=20
> Any comments or thoughts, Casey?

Sounds like a plan to me.

-Casey