-----BEGIN PGP SIGNED MESSAGE-----
On 6 Jul 2007, at 17:22, yuppie wrote:
Wichert Akkerman wrote:
Previously Tres Seaver wrote:
That's fine, but just means that we have to invent *new*
Tres Seaver 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.
change application code to begin calling the new APIs: right now,
nobody in the wild expects to pass a REQUEST to most of those
Once the replacement utilities are available, we can start
the "tool-ish" APIs. Note that such a change is *way* too late
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
-----END PGP SIGNATURE-----
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests