Hanno Schlichting a écrit :
> On Mon, Aug 3, 2009 at 11:09 PM, toutpt<tou...@gmail.com> wrote:
>> I don't really understand why all these improvements are not merged
>> inside plone3.X and CMF and are marked up as 'experimental'.
> The opaque items issue at hand is not a simple and clear "bug fix". On
> the Plone level we have decided to no longer support this particular
> feature of CMF as it causes too much of a performance bottleneck for
> us. This is removing a feature which might be used by custom code or
> add-ons, even though there are no known add-ons, which actually depend
> on this feature. In a major release like the new Plone 4, we can make
> such a more radical change and remove a feature, but this has been too
> invasive to put into a Plone 3.x release.
> The improvements form the contentcreation package are similar and can
> potentially cause problems for code that relies on specific semantics
> during content creation in the portal_factory tool. The changes have
> been merged into the Plone 4 code as well now, but have been found to
> be too risky for Plone 3.x.
> The catalogqueryplan work is of a different kind and really requires a
> complete re-factoring of the catalog system as used in Plone to be
> done properly. Right now it is a set of monkey-patches for various
> internals of the catalog and the BTree classes. The work is also still
> ongoing to make the code more general. Since the catalog is one of the
> spots that thanks to its widespread use in Plone is also customized
> extensively, changes to it are particular risky to do.
> There is a whole number of other changes and techniques that are known
> to speed up Plone. One of the major problems is that these are often
> very easy to do given a particular single site, which can assume a lot
> of constraints about the way it is used. But the complexity of
> different usage patterns and the endless flexibility of configuration
> options make it very hard to improve performance in a general way.
> A typical issue of this kind is the question if a particular feature
> needs to be configurable per database configuration or just based on
> file system settings. In the latter case there can often be a number
> of things that can be cached at startup time avoiding the additional
> database lookups per view call. This is something Plone cannot do in
> general, but can bring substantial improvements for particular sites.
> Hanno
Thank you for this very clear answer. I better understand your point of view 
and i will try to work in that way.

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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Reply via email to