On Sep 28, 2007, at 8:26 AM, Eric Dalquist wrote: > I agree with both of you, I think it is 'too soon' to remove the > IMultithreaded code. All of it is already marked deprecated and I > will leave it as such as I move through cleaning up code.
I think the larger question here is -- is there anything that supporting iMultithreaded makes us unable to do? Things that likely would push me in the "remove support for iMultithreade" camp probably are: - better compliance with portlet spec: if 168 or 286 had some lifecycle that was so different that supporting both IMultithreaded and that spec were a huge amount of work - a much better implementation of something like ChannelManager that gave better performance, or drastically simplified the implementation, or... that required breaking part of the IMultithreaded contract for the greater good. I guess the bottom line is I don't think now's the right time to eliminate it just because, though if there was a driving technical factor I'd be willing to consider it. I also think the logical followup question is: what other code should be deprecated? ALM? SLM? Non-Spring Message StatsRecorders? ANT Build tasks/process? Jason -- Jason Shao Application Developer Rutgers University, Office of Instructional & Research Technology v. 732-445-8726 | f. 732-445-5539 | [EMAIL PROTECTED] | http:// jay.shao.org -- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
