pbossut at osafoundation.org
Fri Oct 12 12:58:42 PDT 2007
Considering all the requirements put on the alternative (and I agree
with all of them), I think unlikely to replace PyLucene with anything.
Also, though you mention using /lucene in the quick entry, the fact that
Chandler supports the Lucene syntax when doing search is a great
Chandler feature IMO.
Add to that that we barely scratch the surface of PyLucene because we
don't have features like tagging/labelling to make sense of things like
automatic sorting. When Xun made his MVA plugin during the 2006 summer
of code, he used PyLucene a lot
(http://chandlerproject.org/Journal/InternProjectMVA). Cutting it will
make the development of such advance features really difficult.
I think making a decision based on what we do today would be really
short sighted so "-1" on taking it out.
Heikki Toivonen wrote:
> Andi Vajda wrote:
>> On Thu, 11 Oct 2007, Phillip J. Eby wrote:
>>> What are we using Lucene for, exactly? Has CLucene caught up to the
>>> features we use? What do we use that is not available in other tools?
>> Currently, we've barely scratched the surface about what we can do with
>> full text index and search. It was a struggle just to get the search UI
>> into Preview. You're asking "at the moment" and the answer to that is
>> "not much".
> Ok, I think it is worth discussing if we should do something about PyLucene.
> If we could do everything we do now with PyLucene (barring the /lucene
> command in quick entry box) with something more ligtweight, I think we
> should, but only if the following hold true:
> * We have no plans to leverage more of PyLucene within the next 6
> months. If the actual plan is to never use more of PyLucene then it
> would be a no-brainer to take it out, IMO.
> * Alternative development/integration would take less than a month.
> * Alternative performs at least as well as PyLucene.
> * Alternative uses no more resources (memory, disk) than PyLucene.
> * Alternative has smaller download footprint than PyLucene + openjdk.
> * Alternative does not have unusual build requirements.
> Another point would be stability, but that can only be tested through use:
> * Alternative must be at least as bug-free as PyLucene.
More information about the chandler-dev