I agree (and this has been discussed on this very thread in the past,
see Doug's comments). I would love to have someone take a look at
the flexible indexing patch that was submitted (I have looked a
little at it, but it is going to need more than just me since it is a
big change, although it is b. compatible, I believe. It needs to be
benchmarked, tested in threads, etc. so it may be a while to get to
the Flex. format. Thus, it _may_ make sense to put in payloads
first and mark them as "developer beware" in the comments and let
them be tested in the real world.
I think one thing that would really bolster the flex. indexing format
changes would be to have someone write another implementation for it
so that we can iron out any interface details that may be needed.
For instance, maybe the Kino merge model?
-Grant
On Jan 18, 2007, at 11:45 AM, Marvin Humphrey wrote:
On Jan 18, 2007, at 8:31 AM, Michael Busch wrote:
I think it makes sense to add new functions incrementally, as long
as we try to only extend the API in a way, so that it is
compatible with the long-term goal, as Doug suggested already.
After the payload patch is committed we can work on a more
sophisticated per-doc-metadata solution. Until then we can use
payloads for that use case.
I respectfully disagree with this plan.
APIs are forever, implementations are ephemeral.
By making a public API available for one aspect of the flexible
indexing format, we limit our ability to change our minds about how
that API should look later when we discover a more harmonious
solution.
If we're going to go the incremental route, IMO any API should be
marked as experimental, or better, made private so that we can toy
with it "in-house" on Lucene's innards, auditioning the changes
before finalizing the API.
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------
Grant Ingersoll
Center for Natural Language Processing
http://www.cnlp.org
Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/
LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
