[wsrp-interfaces] old performInteraction semantics

[Rich Thompson <richt2@us.ibm.com>]

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