On Tue, February 20, 2007 4:42 pm, Michael Jouravlev wrote: > Hi Frank, I've taken this discussion offline if you don't mind, but if > you like we can bring ig back to the list. We had this argument > before, my reasons are the same.
Let's go ahead and bring it back to the list, ok? It's a worth-wild discussion for public consumption I think. > With current shift from s1 to s2 Paul and me are free (well, not > completely, but we have more leeway) to implement features we like, > features we always wanted but could not add to the core because of > resistance of several core committers. That's cool, I'm glad you have that leeway. But your not answering the question I've asked, which again is simply why not just create a subclass of Action that does what you want? If there's some technical reason this isn't viable, I'm all ears. But so far I haven't heard that. Isn't it still "in the core" if it's included with S1? I don't think it has to be a modified Action class to be in the core, does it? This is my only point, I AM NOT arguing with the basic concept of what your trying to do, and I get the feeling you think I am. > Whether s1 will stay viable after 1.4 release or not I want to make > changes I always wanted, and now I can do this being a committer :-) But your dealing with a code base that has a huge legacy of applications written on it, so you have to be especially careful what you do with it, right? That means considering all angles that you can, and I'm simply bringing up another. > My changes do not break backward compatibility so I don't see why you > or anyone else should be worried. If 1.4 won't be used in the field > then why would one care about its features? I'm not worried... I fully understand what your proposing doesn't break compatibility, I completely take your word for it that that's the case. But, I don't think compatibility is the only concern. For instance, isn't there, even if a miniscule, amount of overhead added to each request? If I understood the flow you posted on the JIRA ticket, there would have to be... even if it's a minute amount, you have to remember how many high-volume sites out there count on the level of performance the base Action class provides now. If you go and add to that, you conceivably impact them., whereas a new Action type doesn't. That's just one thing, but that's my point: why not simply a new type of Action? Why is it so important to modify the Action class itself? That is, and has been, my only question here. Frank > On 2/20/07, Frank W. Zammetti (JIRA) <[EMAIL PROTECTED]> wrote: >> >> [ >> https://issues.apache.org/struts/browse/STR-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40222 >> ] >> >> Frank W. Zammetti commented on STR-2940: >> ---------------------------------------- >> >> I'm not arguing what your trying to do... I'm simply asking two >> intermingled questions here: >> >> Why does what your trying to do have to involve modifying Action? Why >> isn't simply creating a new kind of Action sufficient? >> >> I imagine that when DispatchAction was first introduced, a similar >> question was asked... why not just add dispatching functionality to >> Action and be done with it? Well, somewhere along the line, someone >> decided a second kind of Action was the better answer. I'm asking the >> same question here, not debating whether what your proposing is a good >> idea or not. It seems to me, if it's a new descendant of Action, then >> that question is moot anyway. >> >> If your only goal is to push a new mindset on people, which frankly >> seems to be the case based on what you said in the previous comment, I >> would contend that's not the right reason to do this, considering the >> tremendous number of existing Struts apps that have to be maintained. >> >> A related piont, although one I hesitate to make frankly... One could >> certainly make the argument that S1 is quickly becoming legacy given the >> advent of S2, and in that frame of mind, I don't think major >> architectural changes (which this is, whether developers are forced to >> deal with it or not) should be undertaken lightly. > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
