Manik, No worries about the time I spent on ISPN-193. It was a challenge and enjoyment to figure out how to do this and if it is included or not I am not that concerned. I did not understand that ISPN-193 is targeted to our modules only. I thought that this feature leaves a door open to third party modules as well. What I am concerned is that: <infinispan> <namedCache name="blah"> <modules> <module name="query"/> </modules> </> </> IMO looks simpler to end user than: <infinispan> <namedCache name="blah"> <indexing enabled="true" localOnly="false" /> </> </> And don't forget that we can have more complex xml structure as well.<indexing> is a skewed example:) Also, are you looking over module versioning? If we are always going to sync release of all modules along with core module, then it is fine. Otherwise, there will be a lot of changes to schema, each module will want to tune main Configuration bean, multiply that by number of different module releses, it is a mess! If you leave a module jar to define it own configuration bean and ship configuration along with it, it would mean that end user would simply drop a module jar on a classpath. As Manik already asked, I am also asking everyone else, thoughts ? :) On 09-11-09 6:41 AM, Manik Surtani wrote: > Hmm, I don't know. The whole purpose behind this was to simplify > our inter-module dependencies on config beans, etc. And if > simplifying means pushing more complexity on to the end user, then > that's not good. I'd rather have inter-dependencies and complexity > in our codebase and a simple end-user experience than the other way > around. > > I suppose the alternative is that every time a module requires some > cfg params, we modify the Configuration bean in core to accommodate > this. So this will add *some* knowledge of the modules in core > (only from a configuration perspective) but at least it would keep > the end-user experience clean. So in the case of querying, > something like: > > Configuration.setIndexingEnabled(), Configuration.setIndexLocalOnly > () and this would give us a config file that looks like the > following? > > <infinispan> > <namedCache name="blah"> > <indexing enabled="true" localOnly="false" /> > </> > </> > > If that is the case then this would mean we don't bother with > ISPN-193 - sorry, I know you did put effort into investigating > this :( - but we would still need ISPN-245. > > Thoughts? > > Cheers > Manik > > > ----- Original Message ----- > From: "Vladimir Blagojevic&quot;&lt;vblagoje(a)redhat.com&gt; > To: "infinispan -Dev List&quot;&lt;infinispan-dev(a)lists.jboss.org&gt; > Sent: Sunday, 8 November, 2009 20:29:27 GMT +00:00 GMT Britain, > Ireland, Portugal > Subject: Re: [infinispan-dev] Module configuration proposal > > I do understand that sentiment - not wanting to overwhelm end user > with > complex configuration file. How about we make a trade off. Module > develop can specify default configuration bean setup in module.cfg > (XML > format), end user just references that module in cache.xml. End > user, of > course, has an option to change or overrride configuration in that > module.cfg file package by either modifying it inside module jar or > by > specifying configuration directly in cache.xml as we have it now. > > <infinispan> > <namedCache name="blah"> > <modules> > <module name="query"/> > </modules> > </> > </> > > > > > On 09-11-08 11:04 AM, Manik Surtani wrote: > >> Hmm - lets have a think about this. Can't say I like having >> the<module> tag exposed to end users. >> >> So I guess the alternative is to have module-specific config beans >> in the core module? E.g., move the QueryConfiguration to the core >> package, and then we could have something like the following? >> >> >> >>> <infinispan> >>> <namedCache name="blah"> >>> <indexing enabled="true" localOnly="false" /> >>> </> >>> </> >>> >>> >> Cheers >> Manik >> >> >> > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Ok then. No one is stepping up to argue either way so lets proceed in direction you propose. I can scrap ISPN-193 in a day or so and prepare Configuration to accept <indexing> tag for query. Do you want to squeeze this one in CR2? We can leave things as they are with no impact on current configuration files people already use out there and then proceed after CR2. What do you think?

On 09-11-09 12:09 PM, Manik Surtani wrote: > Modules and core will always be released in lock-step. The only reason > modules exist is for code convenience. Even the distro packages a > single archive with the lot and modules will never be released > independently. > > Sent from my iPhone > > On 9 Nov 2009, at 15:19, Vladimir Blagojevic&lt;vblagoje(a)redhat.com&gt; > wrote: > > >> Manik, >> >> No worries about the time I spent on ISPN-193. It was a challenge and >> enjoyment to figure out how to do this and if it is included or not >> I am >> not that concerned. I did not understand that ISPN-193 is targeted to >> our modules only. I thought that this feature leaves a door open to >> third party modules as well. >> >> >> What I am concerned is that: >> >> <infinispan> >> <namedCache name="blah"> >> <modules> >> <module name="query"/> >> </modules> >> </> >> </> >> >> IMO looks simpler to end user than: >> >> <infinispan> >> <namedCache name="blah"> >> <indexing enabled="true" localOnly="false" /> >> </> >> </> >> >> And don't forget that we can have more complex xml structure as >> well.<indexing> is a skewed example:) >> >> >> Also, are you looking over module versioning? If we are always going >> to sync release of all modules along with core module, then it is >> fine. Otherwise, there will be a lot of changes to schema, each >> module will want to tune main Configuration bean, multiply that by >> number of different module releses, it is a mess! If you leave a >> module jar to define it own configuration bean and ship >> configuration along with it, it would mean that end user would >> simply drop a module jar on a classpath. >> >> As Manik already asked, I am also asking everyone else, thoughts ? :) >> >> >> >> >> >> On 09-11-09 6:41 AM, Manik Surtani wrote: >> >>> Hmm, I don't know. The whole purpose behind this was to simplify >>> our inter-module dependencies on config beans, etc. And if >>> simplifying means pushing more complexity on to the end user, then >>> that's not good. I'd rather have inter-dependencies and complexity >>> in our codebase and a simple end-user experience than the other way >>> around. >>> >>> I suppose the alternative is that every time a module requires some >>> cfg params, we modify the Configuration bean in core to accommodate >>> this. So this will add *some* knowledge of the modules in core >>> (only from a configuration perspective) but at least it would keep >>> the end-user experience clean. So in the case of querying, >>> something like: >>> >>> Configuration.setIndexingEnabled(), Configuration.setIndexLocalOnly >>> () and this would give us a config file that looks like the >>> following? >>> >>> <infinispan> >>> <namedCache name="blah"> >>> <indexing enabled="true" localOnly="false" /> >>> </> >>> </> >>> >>> If that is the case then this would mean we don't bother with >>> ISPN-193 - sorry, I know you did put effort into investigating >>> this :( - but we would still need ISPN-245. >>> >>> Thoughts? >>> >>> Cheers >>> Manik >>> >>> >>> ----- Original Message ----- >>> From: "Vladimir Blagojevic&quot;&lt;vblagoje(a)redhat.com&gt; >>> To: "infinispan -Dev List&quot;&lt;infinispan-dev(a)lists.jboss.org&gt; >>> Sent: Sunday, 8 November, 2009 20:29:27 GMT +00:00 GMT Britain, >>> Ireland, Portugal >>> Subject: Re: [infinispan-dev] Module configuration proposal >>> >>> I do understand that sentiment - not wanting to overwhelm end user >>> with >>> complex configuration file. How about we make a trade off. Module >>> develop can specify default configuration bean setup in module.cfg >>> (XML >>> format), end user just references that module in cache.xml. End >>> user, of >>> course, has an option to change or overrride configuration in that >>> module.cfg file package by either modifying it inside module jar or >>> by >>> specifying configuration directly in cache.xml as we have it now. >>> >>> <infinispan> >>> <namedCache name="blah"> >>> <modules> >>> <module name="query"/> >>> </modules> >>> </> >>> </> >>> >>> >>> >>> >>> On 09-11-08 11:04 AM, Manik Surtani wrote: >>> >>> >>>> Hmm - lets have a think about this. Can't say I like having >>>> the<module> tag exposed to end users. >>>> >>>> So I guess the alternative is to have module-specific config beans >>>> in the core module? E.g., move the QueryConfiguration to the core >>>> package, and then we could have something like the following? >>>> >>>> >>>> >>>> >>>>> <infinispan> >>>>> <namedCache name="blah"> >>>>> <indexing enabled="true" localOnly="false" /> >>>>> </> >>>>> </> >>>>> >>>>> >>>>> >>>> Cheers >>>> Manik >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Manik, No worries about the time I spent on ISPN-193. It was a challenge and enjoyment to figure out how to do this and if it is included or not I am not that concerned. I did not understand that ISPN-193 is targeted to our modules only. I thought that this feature leaves a door open to third party modules as well. What I am concerned is that: <infinispan> <namedCache name="blah"> <modules> <module name="query"/> </modules> </> </> IMO looks simpler to end user than: <infinispan> <namedCache name="blah"> <indexing enabled="true" localOnly="false" /> </> </> And don't forget that we can have more complex xml structure as well.<indexing> is a skewed example:) Also, are you looking over module versioning? If we are always going to sync release of all modules along with core module, then it is fine. Otherwise, there will be a lot of changes to schema, each module will want to tune main Configuration bean, multiply that by number of different module releses, it is a mess! If you leave a module jar to define it own configuration bean and ship configuration along with it, it would mean that end user would simply drop a module jar on a classpath.

As Manik already asked, I am also asking everyone else, thoughts ? :) On 09-11-09 6:41 AM, Manik Surtani wrote: > Hmm, I don't know. The whole purpose behind this was to simplify our inter-module dependencies on config beans, etc. And if simplifying means pushing more complexity on to the end user, then that's not good. I'd rather have inter-dependencies and complexity in our codebase and a simple end-user experience than the other way around. > > I suppose the alternative is that every time a module requires some cfg params, we modify the Configuration bean in core to accommodate this. So this will add *some* knowledge of the modules in core (only from a configuration perspective) but at least it would keep the end-user experience clean. So in the case of querying, something like: > > Configuration.setIndexingEnabled(), Configuration.setIndexLocalOnly() and this would give us a config file that looks like the following? > > <infinispan> > <namedCache name="blah"> > <indexing enabled="true" localOnly="false" /> > </> > </> > > If that is the case then this would mean we don't bother with ISPN-193 - sorry, I know you did put effort into investigating this :( - but we would still need ISPN-245. > > Thoughts? > > Cheers > Manik > > > ----- Original Message ----- > From: "Vladimir Blagojevic&quot;&lt;vblagoje(a)redhat.com&gt; > To: "infinispan -Dev List&quot;&lt;infinispan-dev(a)lists.jboss.org&gt; > Sent: Sunday, 8 November, 2009 20:29:27 GMT +00:00 GMT Britain, Ireland, Portugal > Subject: Re: [infinispan-dev] Module configuration proposal > > I do understand that sentiment - not wanting to overwhelm end user with > complex configuration file. How about we make a trade off. Module > develop can specify default configuration bean setup in module.cfg (XML > format), end user just references that module in cache.xml. End user, of > course, has an option to change or overrride configuration in that > module.cfg file package by either modifying it inside module jar or by > specifying configuration directly in cache.xml as we have it now. > > <infinispan> > <namedCache name="blah"> > <modules> > <module name="query"/> > </modules> > </> > </> > > > > > On 09-11-08 11:04 AM, Manik Surtani wrote: > >> Hmm - lets have a think about this. Can't say I like having the<module> tag exposed to end users. >> >> So I guess the alternative is to have module-specific config beans in the core module? E.g., move the QueryConfiguration to the core package, and then we could have something like the following? >> >> >> >>> <infinispan> >>> <namedCache name="blah"> >>> <indexing enabled="true" localOnly="false" /> >>> </> >>> </> >>> >>> >> Cheers >> Manik >> >> >> > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev