[wsrp-interfaces] old performInteraction semantics

Here is the performInteraction section
(in context) from WSRP v1 draft 0.89:

Interaction Operations

End-User interactions with the generated markup
may result in invocations for the Portlet to respond to the interactions
[A400].
In the case where the invocations may change the navigationalState
or some data the Portlet is storing in a shared data area (including a
database), an operation is needed to carry the semantics of this type of
update. Two operations are defined for processing interactions and the
state changes they may cause, one carrying the additional semantics of
blocking the Consumer from both beginning the generation of the aggregated
page and gathering markup from other Portlets on the page. 

performInteraction() Operation

This operation does not carry the semantics
of blocking the Consumer’s processing of gathering markup:

InteractionResponse
= performInteraction(RegistrationContext,
 PortletContext,

         
               
               
               
               
         
 RuntimeContext, UserContext,

         
               
               
               
               
         
MarkupParams, InteractionParams);

Faults: Security.AccessDenied, Security.InvalidUserCategory,

         
      Security.InconsistentParameters, Security.InvalidRegistration,

         
      Interface.MissingParameters, Interface.OperationFailed,

         
      Interface.InvalidHandle, Interface.InvalidCookie,

         
      Interface.UnsupportedMode, Interface.UnsupportedWindowState

         
      Interface.UnsupportedLocale, Interface.UnsupportedMarkuptype

         
      Interface.PortletStateChangeRequired

While the text does not carry Mike's
recollection that this operation was equivalent to getMarkup+InteractionParams,
the response type is of that sentiment. InteractionResponse carried all
the fields of the v1 UpdateResponse except newNavState, newMode and newWindowState.
Relative to the comments Subbu and I made about this, note that this operation
explicitly stated the Portlet could make state changes, but restricted
them to the Portlet itself (i.e. session, customizations and back-end state).
This is not quite the same as passing dynamic parameters to the idempotent
getMarkup operation.

Rich