Tomorrow's Interfaces concall: Managing NavState

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:

  
Does the Enhanced proposal provide enough value to include it?  

  

  
If we go with the Base proposal, does the
wsrp-updateNavigationalContext portion of the proposal provide enough
value to include it?

  

  
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.

  
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?