Any chance on a brief summary of the current motivations for IndexReader
plugins (now that all of this discussion has taken place)?
The original example justification was to avoid putting a ValueSource in
the IndexReader (I guess avoiding the funky init code? valueSource = new
CachingValueSource(this, new UninversionValueSource(this))
I never intended on keeping that bit of ugly code (it was a test way to
get the thing inited, and since I've taken valueSource out of the
Reader), but I guess your idea would allow me to stick my
ValueCache in using a more flexible API -
IndexReader.bind(ValueSource.class, valueSource). I don't know how
necessary that is for other pieces though. Now that I am trying to put
the valueSource back in the Reader (831 still in heavy flux), this is
looking like it could be nice for that though. But I think in flight
binding would be wrong (we shouldn't take the view of not worrying about
our users). But unless it makes sense to bind other things like that
(not the built in stuff and other than ValueSource), I dont know that it
makes sense yet. Filter caches, Query caches, etc seem easy enough to
implement external to Lucene just using the Reader instance? I guess it
helps with sharing (possible merging in RAM)?
Mike appears to have driven it towards modularizing the current pieces
in SegmentReader now. Thats not so flexible though (as a generic plugin
framework), and it seems like a bit of a leap over the original
proposal. The gain if we get this is possibly sharing the components and
being able to plug in new impls (do we really want to support that,
would it make sense based on current customization needs?)?
So Marvin has mentioned that that leads us to a bit of a hybrid
approach, but Earwin doesn't like that?
And I don't understand how initing vs inflight destroys the whole reason
for the API - if you don't necessarily care that its reconfigurable
inflight, whats the problem? The static constructors are not beautiful,
but a leaky API would be worse - I'd rather unsuspecting Lucene users
were not hit by trains :)
Hopefully I have not muddied the water further, but I can't get a clear
grasp on this. Happy to wait for example code, but if someone can unify
the discussion in a bit more a succinct way, I wouldnt complain ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
