Earwin Burrfoot wrote:
A hashmap. And a pair of helper methods. Maybe one class. And
a bunch of interfaces.
Cool - def don't be afraid to start small. If a prototype hits
reasonably soon, I would love to work it into 831. I won't get back to
it for a while, but when I do (unless someone el
LuceneGuice :) (Thats completely a throwaway, so don't draw any conclusions
from it :))
I'm absolutely not going to build some uberframework. Something
simple. A hashmap. And a pair of helper methods. Maybe one class. And
a bunch of interfaces.
You concluded anyway! I forgive you tho
ureComponent.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
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 int
e 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 framewo
l-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
Earwin Burrfoot wrote:
Michael McCandless wrote:
I gave the example to show the init vs inflight distinction, because
inflight makes me nervous.
I'm thinking of some (bad name follows) PluginBundle, that has
add/remove/inspect methods and constructor/method for filling it with
default
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 Ind
Michael McCandless wrote:
> I gave the example to show the init vs inflight distinction, because
> inflight makes me nervous.
I'm thinking of some (bad name follows) PluginBundle, that has
add/remove/inspect methods and constructor/method for filling it with
default Lucene components.
Then instead
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 retr
On Tue, Apr 14, 2009 at 2:53 PM, 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'?
I think the
On Tue, Apr 14, 2009 at 2:22 PM, Earwin Burrfoot wrote:
> What destroys the whole reason is the factory Michael offered - it
> hardcodes component types that you can possibly bind to the reader.
I had been focused entirely on componentizing Lucene, internally. I
agree that approach is a non-sta
Earwin Burrfoot wrote:
I just don't see any compelling reason to go hybrid here. If you have
a method to bind 'any' plugin, why do you want to have a special
method to bind ABC plugin, no matter how 'core' is it?
Thanks Earin, that was very helpful. Comment regarding the above:
The distinct
> The original example justification was to avoid putting a ValueSource in the
> IndexReader (I guess avoiding the funky init code? valueSource = new
> CachingValueSource(this, new UninversionValueSource(this))
That was a bit of drama for the sake of drama, I couldn't restrain myself :)
My justific
Any chance on a brief summary of the current motivations for IndexReader
plugins (now that all of this discussion has taken place)?
The original example justification was to avoid putting a ValueSource in
the IndexReader (I guess avoiding the funky init code? valueSource = new
>> > With the early binding approach, you wouldn't pass all plugins during
>> > creation; you'd pass a factory object that exposes methods like:
>> >
>> > getPostingsComponent(SegmentInfo)
>> > getStoredFieldsComponent(SegmentInfo)
>> > getValueSourceComponent(SegmentInfo)
>>
>> That basically k
On Tue, Apr 14, 2009 at 03:52:39PM +0400, Earwin Burrfoot wrote:
> > With the early binding approach, you wouldn't pass all plugins during
> > creation; you'd pass a factory object that exposes methods like:
> >
> > getPostingsComponent(SegmentInfo)
> > getStoredFieldsComponent(SegmentInfo)
> >
>> IndexReader.java is littered with the likes of:
>> public static IndexReader open(final Directory directory,
>> IndexDeletionPolicy deletionPolicy) throws CorruptIndexException,
>> IOException;
> But I don't understand why is this a problem...
Doubling the number of factory methods? We have to k
On Mon, Apr 13, 2009 at 9:44 AM, Earwin Burrfoot wrote:
> On Mon, Apr 13, 2009 at 17:14, Michael McCandless
> wrote:
>> On Mon, Apr 13, 2009 at 9:02 AM, Earwin Burrfoot wrote:
>>
I think I'd lean towards only at construction. Seems dangerous to
allow swap in/out at some later time.
>>
On Mon, Apr 13, 2009 at 17:14, Michael McCandless
wrote:
> On Mon, Apr 13, 2009 at 9:02 AM, Earwin Burrfoot wrote:
>
>>> 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
On Mon, Apr 13, 2009 at 9:02 AM, Earwin Burrfoot wrote:
>> 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 every
>> 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
Michael McCandless wrote:
This is really orthogonal to LUCENE-831 (the field cache is just one
component). They can land in either order...
Yes, and the API does look interesting. I didn't mean to try and tie the
discussion of it to LUCENE-831. I just wanted Earwin to know we are not
going
On Mon, Apr 13, 2009 at 7:31 AM, Earwin Burrfoot wrote:
>> I think this (truly componentizing SegmentReader) makes tons of sense.
>> After all, a SegmentReader is just a bunch of separate components
>> handling different parts of the index.
>>
>> This is really orthogonal to LUCENE-831 (the field
> I think this (truly componentizing SegmentReader) makes tons of sense.
> After all, a SegmentReader is just a bunch of separate components
> handling different parts of the index.
>
> This is really orthogonal to LUCENE-831 (the field cache is just one
> component). They can land in either orde
I think this (truly componentizing SegmentReader) makes tons of sense.
After all, a SegmentReader is just a bunch of separate components
handling different parts of the index.
This is really orthogonal to LUCENE-831 (the field cache is just one
component). They can land in either order...
Earwi
Earwin Burrfoot wrote:
But it doesn't make the proposed API any less useful.
Indeed! And I don't mean to slow down that discussion.
--
- Mark
http://www.lucidimagination.com
-
To unsubscribe, e-mail: java-dev-unsubscr...@l
,6 +560,8 @@
>> +
>> + valueSource = new CachingValueSource(this, new
>> UninversionValueSource(this));
>>
>
> No need to rid Lucene of code thats not there :) Irregardless of the merits
> of IndexReader plugins, no need to design an API to solve experimental code
> in a rou
UninversionValueSource(this));
No need to rid Lucene of code thats not there :) Irregardless of the
merits of IndexReader plugins, no need to design an API to solve
experimental code in a rough, early patch for a given issue;)
Design of the new FieldCache is happening at 831, and no comments are
ignored
To support my dream of kicking fieldCache out of the core and to add
some extensibility to Lucene, I want to introduce IndexReaderPlugins.
Rough pseudocode follows:
interface IndexReaderPlugin {
void attach(SegmentReader reader);
void detach(SegmentReader reader);
void att
30 matches
Mail list logo
