[Framework-Team] Re: PLIP 177 - Content indexing

Kapil Thangavelu k_vertigo at objectrealms.net
Mon Dec 11 15:16:25 UTC 2006

On Mon, 11 Dec 2006 09:38:39 -0500, Daniel Nouri <daniel.nouri at gmail.com>  

> Kapil Thangavelu wrote:
>> On Mon, 11 Dec 2006 08:55:07 -0500, Rocky Burt
>> <rocky at serverzen.com> 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.



More information about the Framework-Team mailing list