Hash: SHA1

On 6 Jul 2007, at 17:22, yuppie wrote:
Wichert Akkerman wrote:
Previously Tres Seaver wrote:
yuppie wrote:
Tres Seaver wrote:
yuppie wrote:
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.

Speaking about roadmaps, we have had several mailing list discussions in the past where future plans or intentions get stuck in the list archives, but nowhere else. That makes it hard to keep track of actual development or bug fix tasks.

Can I suggest that we also use the CMF collector to capture specific tasks? For example, knowing that tool FOO cannot be made a utility and the decision that we should go forward and create a new utility to replace the tool we should have a collector entry for the task "develop FOO utility". Makes it much much easier to keep track of what's left to do to reach the more generic goals on the roadmap.


Version: GnuPG v1.4.7 (Darwin)

Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to