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 think my comment was a bit confusing. The main intention of the
payloads is to use it for storing per-term metadata. However, with the
workaround Nadav suggested it is also possible to use it for per-doc
metadata, by simply storing only one token per document in a special
field. This solution works but is probably not the nicest. But why not
use this workaround as long as the payloads patch does not introduce an
API for the per-doc metadata that has to be removed/changed when we come
up with a dedicated implementation for that use case. With the payloads
patch I tried to keep the API changes as simple as possible (changes are
only made to Token and TermPositions). These changes are under
discussion in this thread with the intention to make them compatible
with the flexible-indexing API. I couldn't agree more that the API has
to be well-planned and I'd love to see your comments about the API
extensions I suggested, Marvin.
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/
I certainly agree to your suggestion to mark new APIs as experimental.
Then people would know that the API may change in the future and could
use it in their apps at own risk. At the same time we would benefit from
valuable feedback from those users that would help us perfecting the
API. The idea of having a flexible index format is already a year old I
think and at least in Java-Lucene there hasn't been made any progress
yet. So I'm all for the incremental approach, while marking new APIs
carefully as experimental.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
