[wsrp-wsia] Issue #45: Signalling State changes in interaction response

[Michael Freedman <Michael.Freedman@oracle.com>]

Some comments on this issue ahead of tomorrows conference call discussion:

There are two areas I would like to explore:
    a) how sticky is navigational state?
    b) is it really preferrable to interpret not returning navigational state as meaning reuse existing navigational state?

How sticky is navigational state?
Currently the specification implies its sticky.  Navigational state is provided by the consumer until the portlet explicitly changes it/removes it.  This puts a great burden on the consumer [particularly those trying to maintain such state in the client].  I.e. consider the user that is on a page with a portlet with explicit navigational state.  The user then navigates from this page to another page and so on until some time in the future a navigation is done that leads her back to the original page.  Must the consumer have maintained (and resupply) the navigational state of the portlet on this subsequent reentry?  I hope not.  I suggest we clarify the specification to only mandate that navigational state is maintained within the context of aggregated whole [i.e. page].  And the specification be mute on maintaining navigational state after navigating from this context.

Is it preferrable to interprete not returning navigational state as meaning reuse existing navigational state?
Currently, if you don't return navigational state from performInteraction, the consumer continues to use the current navigational state.  Likewise, if you don't set navigational state in a URL [link] the consumer is supposed to use the current navigational state.  I think we should do the reverse.  Navigational state must be explicitly returned/set or else the system reverts to no navigational state.  Here are me reasons:

a) Easier to debug.  In the performInteraction case there are cases where new navigational state is very similar to the old navigational state.  In this situation if a developers forgets to update the state, it likely to continue to run.  The functional problem may not even be noticeable until some further state/navigation.  Where if navigational state isn't carried forward if none is set its likely the portlet will not run or if it does run it will be very apparent that something is wrong.

b) Coincides better with Producer URL writing semantics.  I believe we expect the consumer send a {navigationalState} token in the producer template and the producer must replace it.  If this situation requires explicit setting of navigational state shouldn't we do so everywhere to be consistent?