On Mon, 11 Dec 2006 09:38:39 -0500, Daniel Nouri <[EMAIL PROTECTED]>
wrote:
Kapil Thangavelu wrote:
On Mon, 11 Dec 2006 08:55:07 -0500, Rocky Burt
<[EMAIL PROTECTED]> wrote:
On Mon, 2006-11-12 at 13:43 +0000, Martin Aspeli wrote:
Do people have opinions on this:
http://plone.org/products/plone/roadmap/177
It seems to be a very trivial patch to AT, and it could be really
useful, but I don't know about the implications for installers and how
bad the performance overhead would be.
Daniel, thoughts on this for AT trunk?
Personally I think this plip would be awesome to get in place. But
with
one small stipulation. I would adding a configlet someplace or some
config option somewhere that lets you toggle this behaviour on/off (on
a
functional level) and have it off by default. That way we don't have
to
worry about the performance implications by default. Then for Plone
3.5
we could consider having it activated by default.
+1, hmm.. instead of field changes, maybe its better to just restructure
the catalog itself, to use real adapters to index content, with a
default implementation respecting this setting. more work, but more
flexible for repurposing on other use cases, probably 3.5 material.
Why not include TXNG3?
txng3 is a huge package, its not just a plugin index, its basically its
own catalog infrastructure, with lots of code, including c extensions,
with one maintainer, afaik. 98% of the people i bet install it for one
reason, namely the focus of this plip, indexing common office file types,
and all its extra complexity, features, and options ignored. for this
particular purpose, under the hood txng3 is utilizing the same machinery,
so its best i think to just give the functionality that most users already
want, is already in the codebase, via just exposing the functionality, as
opposed to including an entirely new framework that needs to be supported
and maintained.
cheers,
kapil
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
