>> 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/Кирилл Захаренко (ear...@gmail.com) Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 ICQ: 104465785 --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
