lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: IndexReader plugins
Date Tue, 14 Apr 2009 19:48:02 GMT
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message