[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-wsia] [change request #142] Remove performInteraction()?
I would also be in favour of dropping performInteraction. For me a second question arises here: If we dropped (just assuming) performInteraction then we have our clear two-phase semantics (performInteraction, wait for reply, gather markup with getMarkup()). Shouldn't we then rename performBlockingInteraction() back to performInteraction()? Mit freundlichen Gruessen / best regards, Richard Jacob ______________________________________________________ IBM Lab Boeblingen, Germany Dept.8288, WebSphere Portal Server Development Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 Email: mailto:richard.jacob@de.ibm.com |---------+----------------------------> | | Subbu Allamaraju | | | <subbu@bea.com> | | | | | | 12.02.2003 18:26 | |---------+----------------------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| | | | To: wsrp-wsia@lists.oasis-open.org | | cc: | | Subject: Re: [wsrp-wsia] [change request #142] Remove performInteraction()? | >--------------------------------------------------------------------------------------------------------------------------------------------------| I vote for the "less is more" argument. One less complex concept to understand and program to for portal developers! Subbu Rich Thompson wrote: > Document: Spec > Section: 6.3.1 > Page/Line: 40/18 > Requested by: Mike Freedman > Old text: > New text: remove performInteraction() > Reasoning: This operation was originally added to provide some semantics > defined by JSR 168. JSR 168 has redefined itself in such a way that this > operation is no longer needed [by it]. Hence we can consider dropping it. > Noet: Personally, I am torn about dropping it. Though JSR 168 doesn't > expose/need it [yet], I think the semantics are well defined, clear, and > useful. I believe that many portlets wanting optimal page rendering > performance can use "non-blocking" actions to post portlet internal data > to themselves. The only argument I see for getting rid of it [now that it > is defined] is "less is more" i.e. the specification is easier to > understand if there are fewer concepts. I can buy this but would find it > silly if this operation was added back in 1.1 or 2.0 when it could have > been in 1.0. > > [RT] I also do not see compelling reasons to drop it at this point. It > does add useful semantics and they are well defined in the spec at this > point. The concepts involved have to be understood by Consumer > implementors and therefore will not disappear from the spec. > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC