Forgot your password?
New user?
Document Actions
#165: TextIndexNG3 integration
- Contents
Ship Plone 3.0 with TextIndexNG3 as default text index
- Proposed by
- Andreas Jung
- Proposal type
- Architecture
- State
- being-discussed
Motivation
TextIndexNG 3 provides a much more powerful fulltext indexing story to Plone (compared to ZCTextIndex). TXNG
provides a more flexible configuration, much better i18n support, more powerful query support etc. ZCTextIndex
lacks a lot of high-level functionalities to provide a better fulltext indexing support to Plone.
Proposal
ZCTextIndex should be replaced with TextIndexNG 3.
Implementation
TXNG already supports Plone directly with adapter, quickinstaller support, migration etc.
Deliverables
TXNG needs some minor extensions:
- better support for ATFile (in order to index both Description + binary content) (will be added in TXNG 3.2.X later this year)
- review of the ranking performance
- review of the integration with Linguaplone
Risks
- TXNG 3 uses its own converter framework and therefore does not and will not use PortalTransforms. It might be confusing having two converter frameworks with different configurations.
Re: +1
Posted by
Andreas Jung
at
July 20, 2006 - 05:12
All other solutions I know are using external indexing servers based on Lucene/Pylucene adding much more complexity to the installation. And therefore they are unlikely of interested for an out-of-the-box newbie-friendly installation.
-1
Posted by
Kapil Thangavelu
at
July 24, 2006 - 01:11
95% of people want utilize tidxng3, for one reason, integrated transformation of binary types. i think textng3 carries alot of infrastructure that needs to be refactored into a catalog. in many ways, its not a plugin index, its a plugin catalog, with redundant infrastructure to whats already in plone. ie. we already have and ship an infrastructure for doing transformations in plone, in portal transforms. i'd like to see some of the infrastructure separated out or (preferrably for resuse of existing infrastructure where applicable) and the responsiblities of tidxng3 relegated to the core responsiblities of an index.
as for the query syntax, the alternatives are AdvancedQuery, ManagedIndex
as for the query syntax, the alternatives are AdvancedQuery, ManagedIndex
Nonsense
Posted by
Andreas Jung
at
December 11, 2006 - 16:33
That's totally nonsense. The complete architecture of TXNG is based on components and highly pluggable. You really have no idea what you are talking about.
missing the point
Posted by
Kapil Thangavelu
at
December 11, 2006 - 16:43
the whole point is that the relevant infrastructure shouldn't be localized txng3 it should be in the catalog for the benefit of all indexes and giving ability to localize content adaptation to the catalog, users want the functionality of indexing office types, not the nesc. the entire functionality of 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.
none of this is meant as a comment on the internal pluggability of txng3 or style of code.
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.
none of this is meant as a comment on the internal pluggability of txng3 or style of code.
Is this now moot?
Posted by
Jon Stahl
at
February 21, 2008 - 08:32
Now that Plone 3 uses its own portal_transforms to index PDF, Word, Excel docs out of the box, can this PLIP be retired?
+1
I must confess, though, I'm not sure if there are alternative candidates that should be considered.