[Chandler-dev] PyLucene

Philippe Bossut pbossut at osafoundation.org
Fri Oct 12 12:58:42 PDT 2007


Hi,

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.

Cheers,
- Philippe


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 mailing list