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

[Gary Poster]

Steve Alexander wrote:
>> 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.

Got it--and over IRC and when you address this again below I got the 
rest I needed to understand, namely that zcml will still allow global 
subscription to notifications, just not via any service

>> 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 ;-)

OK. :-)

>>> <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.

Right.

>> 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.

Good point; I've seen that elsewhere about the root but had forgotten it.

> 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.

Cool. :-)

> I suggest that the listSubscriptions method takes the subscriber as an 
> optional argument also, so that you can use it to list all subscriptions.

You think?  I thought about it a while back and couldn't come up with a 
compelling use case, so didn't bother worrying about it.  Do you have any?

Gary