lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Earwin Burrfoot <ear...@gmail.com>
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 ..er.. typesafer than passing Map<Class, IRP> in
constructor.
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/Кирилл Захаренко (earwin@gmail.com)
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785

---------------------------------------------------------------------
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