[Zope3-dev] Re: Services interfaces should not include mutators

[Steve Alexander]

> 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