Earwin Burrfoot wrote:
Mark Miller wrote:
The distinction I am making with core is that we will have to call known
methods on those
core 'modules' that are not very generic? Doesn't that keep it from playing
nice with the very generic 'attach this to this segment'?
Genericity spans binding, notifications and retrieval of a component
from a reader.
For binding and notifications you can do whatever you want inside your
component, because you're provided with the full public IndexReader
interface.
When you retrieve a component, you get your very own interface with
all your needed and totally nongeneric methods.
ObscureComponent c = reader.plugin(ObscureComponent.class);
c.performSomeObscureNonGenericLogic();
This very code can be located both in userland, dealing with custom
components and in coreland, dealing with well-known Lucene core
components.
Thats sounding interesting. From what you and Mike are saying, its a
dependency injection framework basically then? Impls are plugged in from
a configuration class? Except you can plug in your own random stuff
thats not used internally, so its also kind of an Impl cache?
So IndexReader Plugins would be: per Reader impl configuration and
caching - with call backs too though - I guess you could add other
callbacks and get involved in some more interesting stuff as well, if
you wanted?
It keeps growing on me anyway.
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
