[Zope3-dev] Re: Services interfaces should not include mutators
Steve Alexander
steve@cat-box.net
Sun, 22 Dec 2002 17:27:53 +0000
> On this basis of an earlier email from him about this, I think Jim's
> goal in the three-service division is that the publish code can then
> merely travel up the notification service, not having to switch over
> from local service name to global service name at the top: I understood
> this to be his main (and significant) dislike of the two-service
> division. I am in favor of the three-service approach if only because
> it is a Pope-approved way of going forward.
In the interfaces I desribed, there is no "switch over" at the top for
publishing an event. The global event service is an IEventPublisher, and
the local event service is also an IEventPublisher.
This demonstrates that publishing is all the same, and subscription is
the tricky issue.
> If we want to simplify
> contextually-wrapped subscription for the alpha (as I think is
> important) then we have less than 24 hours before the Monday morning
> deadline. So is that ok with you, Steve?
I think we should take the time to do this right. We can complete this
after the great name change -- this isn't new work, it is fixing stuff
up ;-)
>> <serviceType id="Events" interface="IEventPublisher" />
>> <serviceType id="Subscription" interface="ILocalSubscribable" />
>>
>>
>> Vastly more components are interested in sending events than in
>> subscribing to receive them. Hence the short 'Events' and the longer
>> 'Subscription'.
>
>
> That makes sense to me. If you buy my explanation of Jim's three
> service approach, then I think 'GlobalSubscription' would be the third,
> trying to extend your logic.
There is no need for a third serviceType. Just like the
GlobalAdapterService, the GlobalSubscriptionService would only be used
from zcml and from unit tests. Persistent objects would never want to
use it. It wouldn't make sense to placefully override the
GlobalSubscriptionService.
> OK, here's the interface I have been implementing with the old service
> division: I hope the changes I'll make on the basis of the new divisions
> are obvious. I'll get on IRC so you can opt to flog me about it there,
> Steve. ;-)
>
> class ILocalSubscribable(ISubscribable): # in the new plan, this will no
> # longer subclass ISubscribable and will not refer to it below.
> """A subscribable that only works with contextually wrapped objects
> or their paths or hubids."""
This has nothing to do with context wrapping. For example, you can
subscribe the root folder, which is just about never context wrapped.
The root folder is still a persistent, traversed-to object.
The issue is whether you can get a physical path for an object.
I like the explicitness of your new subscribe method, so that mostly you
can let a subscribably do "the right thing", and it will tell it what it
thought the right thing was.
This also makes sense now that locations are only string types.
I suggest that the listSubscriptions method takes the subscriber as an
optional argument also, so that you can use it to list all subscriptions.
--
Steve Alexander