lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maros Ivanco <maros_iva...@datalan.sk>
Subject Re: lucene API
Date Thu, 18 Aug 2005 17:09:00 GMT


-----Erik Hatcher <erik@ehatchersolutions.com> wrote: -----

>To: java-dev@lucene.apache.org
>From: Erik Hatcher <erik@ehatchersolutions.com>
>Date: 18.08.2005 3:45
>Subject: Re: lucene API
>
>When I first started digging into the Lucene codebase, I felt
>similarly - the coding convention rule breaking drove me nuts.
>Lucene grew on me and I've changed my take on "conventions"
>dramatically thanks to Doug's explanations and the flavor he has
>imparted onto the codebase.  His "conventions" have changed how I
>code.

Could you please point me to the discussion?

>
>If JAX-RPC has issues with Lucene, it is more an issue with JAX-RPC
>than with Lucene.

I Disagree, the jax-rpc has no issues with Lucene, it does not even know
the Lucene exists. Of course, the same applies for Lucene, but I think the
Lucene could be more open for integration with other systems.

>There are sound reasons for the design of Lucene's
>API and the (non)serializability of most pieces of it.

What are they? Do they take into account integration with outside world?

>  What about
>the Sourceforge Lucene web service project?  Would using that rather
>
>than creating your own solution be reasonable?

I have already looked at the project, but it implements only a part of the
search API. Unfortunately, I also need index reading and writing.
Anyway, I have just finished the web service. It exposes most of the Lucene
API, so my problem is solved for now. But it is solved only partially,
because changes to the API could break my wrapper classes (or
de/serializers).
So I would realy like to contribute and make Lucene more integrable.

Maros.

>
>     Erik
>
>
>On Aug 17, 2005, at 9:26 AM, Maros Ivanco wrote:
>
>>
>>
>> Hi there,
>>
>>    I am creating a search solution based on Lucene. A part of the
>> solution
>>    is Lucene web service. Even though the Lucene API is very
>> straitforward
>>    to use on a local machine, I found creation of Lucene WS to be
>> extremely
>>    difficult. The problem causes the API, which very often does not
>
>> obey
>>    even trivial coding conventions (getter and setter names, for
>> instance).
>>    As a result, the jax-rpc subsystem is unable to produce correct
>>    serializers and deserializers. From my point of view, there are
>
>> serveral
>>    possibilities to solve the problem:
>>
>>  1., write envelopes for nonserializable objects (Document, Field,
>
>> Term,
>>  ...)
>>  2., write custom serializers and deserializers
>>  3., change lucene API
>>
>> 1. requires creation of many envelopes, since most of the Lucene
>> classes do
>> not obey JavaBean semantics thus, they are not serializable by jax-
>
>> rpc.
>> Wrapping and uwrapping of Lucene objects takes extra processing.
>> Moreover,
>> the un/wrapping is sometimes not possible, because some objects
>> (Filters,
>> for instance) do not exhibit their full state. I am doing this
>> right now
>> (and doing, and doing,... I cannot see the end :-)).
>>
>> 2. requires creation of de/serializer for every nonserializable
>> class. Also
>> requires extra configuration + generation of factories. Twice as
>> difficult
>> as solution 1. Moreover, this solution renders resulting WS as
>> nonportable.
>>
>> 3. requires change of lucene API in the way that will allow either
>
>> direct
>> de/serialization or, at least, the solution 1. As far as Lucene is
>
>> open
>> sourced, everybody can make changes, but the real question is,
>> whether the
>> changes will become part of the official distribution. If not, the
>
>> overall
>> search solution will remain stucked with current release.
>>
>> I would personally prefer the third one, but only if the changes
>> will make
>> it to the official release. Our company plans to deploy several
>> instances
>> of the solution. There is certain probability, that my employer
>will
>> contribute some resources (my time) to the project. The question
>is,
>> whether the contemporary development comunity is willing to accept
>
>> this
>> kind of changes and if I can participate. So, is it?
>>
>> Maros.
>>
>>
>>
>---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message