[Zope-CMF] Re: [dev] tools-as-utilities roadmap

[Wichert Akkerman]

Previously yuppie wrote:
> Hi!
> 
> 
> Wichert Akkerman wrote:
> >Previously Tres Seaver wrote:
> >>yuppie wrote:
> >>>Tres Seaver wrote:
> >>>>yuppie wrote:
> >>>>>Or do you prefer to keep things as they are over a less clean switch 
> >>>>>to utilities?
> >>>>Yes.  I'd rather get 2.1 out, even with tools-which-can't-be-utilitiies
> >>>>as they are, then delay.
> >>>I'm not just talking about CMF 2.1. I'm fine if the result of this 
> >>>discussion is a roadmap that starts with CMF 2.2. But if there is no 
> >>>realistic roadmap at all we might better revert all the 
> >>>tools-as-utilities changes. The few utilities we have right now are not 
> >>>worth the trouble. Starting the migration makes only sense if we have a 
> >>>plan to finish it.
> >>>
> >>>>Note that this problem is basically due to the desire to cache the
> >>>>aq_chain for utilities:  if we punt on that, we can then defer this
> >>>>whole issue.
> >>>Maybe that's your reason why you didn't argue against the proposal. I 
> >>>consider the possibility to cache utilities just a side effect of 
> >>>removing the REQUEST from the wrappers.
> >>I thought that caching was the *reason* for removing the request;
> >>otherwise, we could just re-wrap the tool in each 'getUtility' call and
> >>it would have access to the request as it does today.
> >>
> >>>This is not about making the implementation easier. This is about 
> >>>defining what utilities are. If they provide self.REQUEST they become a 
> >>>utility-view monster that has not much in common with Zope 3 utilities. 
> >>>Reducing Zope 2 magic to a minimum if we use Zope 3 technology is a good 
> >>>thing - even if that forces us to be more explicit about required 
> >>>REQUEST arguments.
> >>That's fine, but just means that we have to invent *new* utilities and
> >>change application code to begin calling the new APIs:  right now,
> >>nobody in the wild expects to pass a REQUEST to most of those methods.
> >>
> >>Once the replacement utilities are available, we can start deprecating
> >>the "tool-ish" APIs.  Note that such a change is *way* too late in the
> >>release cycle for 2.1.
> >
> >Aren't we talking about a post-2.1 roadmap now?
> 
> Well. The 2.1 changes are based one the assumption that we switch 
> quickly and completely to utilities, making all tools work as utilities. 
> The roadmap proposed by Tres means it will take several years and we'll 
> have to work with tools and utilities side by side for a long time.

+1 for Tres suggestion (door number 7? 8? )

> I can live with that approach, but would like to see CMF 2.1 adjusted:
> 
> 'getToolByInterfaceName' is a completely misleading method name if tools 
> will not become utilities. This method has no 'context' (or 'REQUEST') 
> argument, so it can't return tools. It returns utilities. 
> 'getUtilityByInterfaceName' would be a much better name for a 
> 'getUtility' replacement used in untrusted code.

I'm fine with that.

Wichert.

-- 
Wichert Akkerman <wichert at wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.