<SNIP> On Fri, 11 Mar 2005 11:42:20 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > At 8:29 AM -0800 3/11/05, Dakota Jack wrote: > >Thanks, Frank. I posted this code in response to Ted's suggestion > >that this is the way to go to establish a dialogue with the committers > >on code. > > I would totally endorse Ted's suggestion. </SNIP>
We will see if it works. I did that. I have made a proposal which can be assessed at this stage. There is no question about what would need to be done to implement the code I have provided. The basis is, as I said, about 15 lines of code. The idea is what is what must be accepted or rejected. I don't have time to spin my wheels. If the idea is not acceptable no matter what, then that is okay. But, if that is the case, doing "no matter what" is spinning wheels. <SNIP> > The best approach is to > publicly document approaches and, where possible, provide extension > code that can be exercised without rushing a change to the Struts > core. This is how struts-chain was developed and verified as a > reasonable approach before the core was changed. It also happens to > be how validator and tiles evolved. In a much more modest fashion, > this was the origin of the DigestingPlugIn, which I developed and > published and which was adopted into Struts all before I was a > committer. </SNIP> I am not sure what this means in terms of what I discussed and provided. I am not suggesting a change to the Struts core. I am not even suggesting something inconsistent with present practice. <SNIP> > In fact, I know of no open source project which would add > incompatible features to an older release, except in the case of a > major version number change. </SNIP> Isn't branching common? I may misunderstand this? </SNIP> > I don't think we've earned "Struts 2.0" with the other changes we > have, although until we do a release, we could certainly debate > calling the chain based processor Struts 2.0 and making room for > Frank's changes in what would then be a live development version on > the 1.x branch. </SNIP> If this is just an opening of the RequestProcessor logic, why is it discussed so much as "chain based"? Shouldn't the interface allow for changes in the future which are not chain based? There is so little discussion about core changes on this list that what is happening is impossible to tell unless you are one of the few people doing all the work. The options from someone on the "outside" seem to be to have ten people doing ten things on their own and then submitting it all at one time to see who wins, rather than working together. I thought I could work with people on a list like this. Is that not the idea? This seems to be impossible from my perspective. No matter what you provide, it is always met with "we cannot comment on that at this time because ...." or "no". It is frustrating, Martin. <SNIP> > As always, remember that we're all volunteers here, and we all have > to scrounge for the time we apply to Struts. Also, we have an > enormous installed base, and we have to take their needs into > account. If the general open source community has come to expect > compatibility between minor version releases, and if we've always > struck a firm stance towards providing that kind of compatibility in > Struts, then we need to maintain consistency. </SNIP> I think we all know that. I really do. Somehow there is this idea that this basic requirement escapes people. But, I don't think it does. -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
