On Aug 18, 2005, at 1:09 PM, Maros Ivanco wrote:
To: [email protected]
From: Erik Hatcher <[EMAIL PROTECTED]>
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?
Please search the archives. I don't have handy pointers to those
discussions.
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?
As was just said on this discussion, Lucene is a library. And it's
API does work quite well with the "outside world". You're making it
sound as if it is difficult to work with Lucene's API, when in fact
it is extremely simple to work with. If you need to wrap Lucene
inside of JAX-RPC, then I recommend wrapping and perhaps simplifying
the needed functions, not exposing them directly.
Lucene uses pointers back to the IndexReader, a transient connection
to a (typical) file system resource. This is done to allow Lucene to
consume less system resources than pulling everything into RAM. This
is perhaps the main reason serializability of things is not done.
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.
That project allows writing, at least from their documentation.
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).
Lucene's public API does not change frequently, and when it does it
first becomes deprecated and then only removed in a later version.
So I don't think you have much risk of breakage with API changes.
Besides, that is what unit tests are for! :) Drop in a new Lucene
JAR, re-compile your code against, and re-run tests.
So I would realy like to contribute and make Lucene more integrable.
We would love to have contributions to improve Lucene, no question.
But it is important to understand the flavor of the community with
respect to coding conventions and rationale - so be gentle, patient,
but also aggressive with valuable suggestions :)
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
