lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Earwin Burrfoot <>
Subject Re: IndexReader plugins
Date Mon, 13 Apr 2009 13:02:53 GMT
>> Can we outline some requirements for the plugin API?
>> Do we want to attach/detach them to IndexReader after it is created,
>> or only during construction?
> I think I'd lean towards only at construction.  Seems dangerous to
> allow swap in/out at some later time.
I have several points pro-runtime:
1. We have a lot of static factory methods, it's gonna be a problem
passing plugins everywhere on creation.
2. public <T extends IRP> void bindPlugin(Class<? super T> type, T
instance) is typesafer than passing Map<Class, IRP> in
3. Plugins support attachment/detachment and they don't need to know
exact reason they were attached/detached for - there should be no
difference between closing a reader and removing plugin from it.

The only danger is that you can remove/change some plugin in the midst
of indexReader operation. Well, bad for you, you jumped the rails and
got hit by a train.
Another possible issue is synchronization, but synced copy-on-write
proved itself countless times :)

>> We probably want them to support (know the difference between)
>> SegmentReader/MultiSegmentReader.
> Yeah... and I think it's fine if some components only "operate" at the
> SegmentReader level.
>> What about ParallelReader (does anybody use it at all?),
>> FilterIndexReader, MultiReader?
> Presumably these would use "aggregator components" that simply take N
> components under the hood and merge their APIs.  (Like MultiTermEnum,
> MultiTermDocs).
>> For a hierarchy of readers, API should probably support the notion of
>> different plugin instances per-subreader.
> Yes, eg it needs to be easy for the N segments discovered on opening a
> MultiSegmentReader to each ask for their own instance of
> PostingsComponent.
>> Do we want plugins supporting more than one interface, or is it an
>> unnecessary complication?
>> Like:
>> indexReader.bindPlugin(instance).to(Iface1.class, Iface2.class);
>> And then:
>> indexReader.plugin(Iface1.class) == indexReader.plugin(Iface2.class)
> I would start without that, unless we have a clear "now" example that
> requires it?

Kirill Zakharenko/Кирилл Захаренко (
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message