Tomorrow's Interfaces concall: Managing NavState

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

Folks,
    The primary discussion item in tomorrow's Interfaces concall is trying to make futher progress/resolve the getResource/Managing NavState issue.  Rich has now written the spec language for our preferred definition of handling navState in getResource (it can't be explicitly changed either in the request (URL) or in the response.  His description is here.

So, now we just need to resolve how the producer can truly manage these deltas.  The two recent proposals are focused on using events.  One seems to be a refinement of the other.  What I think we need to focus on is the value/need of the refinement.

Because the two proposals were written up by different folks (Rich and myself) the relationship between them may not be clear.  Let me summarize:

Base Proposal (Rich):
Consumer unbeknownst to the producer manages a notion of NavigationalState scope.  It is able to determine transitions from one scope to another scope. The specific policy for this is undefined.  When a consumer detects such a transition (end of one NavigationalState scope and the beginning of another) it sends a wsrp-XXXX event  (wsrp-newNavigationalContextScope or wsrp-endNavigationalContextScope?) to each portlet that has subscribed to this event.  This affords the portlet an opportunity to cleanup any local state/resources associated with a particular NavigationalContext scope.

In addition, we will support a consumer policy that offers a subscribing portlet the opportunity to update its NavigationalContext at times other then a PBI or upon receipt of a HE instigated by another portlet.  I.e. a consumer can have a policy that defines appropriate times to  send a consumer event to the portlet to give it an opportunity to update its NavigationalContext.  When a consumer decides its appropriate to update the portlets NavigationalContext it sends a wsrp-updateNavigationalContext event to all subscribing (in-context) portlets.

Enhanced Proposal (Mike):
In the base proposal the consumer only has the event subscription information to determine if a portlet should be sent an event.  In the enhanced proposal, portlets provide to the consumer an indication of whether their NavigationalContext is dirty.  This allows efficient consumers to limit who it sends the  wsrp-endNavigationalContextScope event to.  More importantly, having such a dirty flag allows consumers to be much more aggressive in requesting the portlet update its navigationalContext by sending the wsrp-updateNavigationalContext event.  I.e. with a dirty flag the consumer can have a policy to send the event to the portlet on the next request/next appropriate opportunity.  Without such a flag its unlikely such regular communication will occur because of concerns related to performance.  An additional potential benefit is that by encouraging the consumer to let the producer resync its navigationalState when it needs to the consumer can run with a simple/no policy related to maintaining NavigationalState scope.  I.e. if the portlets state is generally in sync there is less of a need to inform it of a scope transition.

Discussion items:

1. Does the Enhanced proposal provide enough value to include it? 
   
2. If we go with the Base proposal, does the wsrp-updateNavigationalContext portion of the proposal provide enough value to include it?
   
3. If we go with the Base proposal do we need to provide a definition of/guidance for NavigationalState scope?  I.e. is there minimal support that Consumers must implement?  If not, its unclear how much we have really addressed the problem as current use cases that are addressed by portlet/producer managed notion of this scope couldn't migrate to this mechanism because there is no intrinsic support and the new use cases (getResource) would just not work well in those consumers whose policy supported only a single NavigationalState scope.
4. If the event were to called wsrp-newNavigationalContext what is the meaning is the portlet returns a navigationalContext in the response to this HE call?  Likewise if the event were to be called wsrp-removeNavigationalContext what is the meaning is the portlet returns a navigationalContext in the response to this HE call?