Why you should vote to keep performInteraction ...

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

Title:

performInteraction is an important optimization method that gives portlets
the ability to impact the overall throughput of the pages they are on. In
general it is as useful and maybe even more useful an optimazation technique
then our having added the ability to return markup from performBlockingInteraction.
 If you beleive that our protocol should contain mechanisms that allow portlets/portals
to get improved performance you should vote to keep performInteraction.  

Why is it an optimization?
The easy answer is because it doesn't block parellel rendering.  Many portlets
need to do form processing, etc yet don't need to update navigational state
nor be concerned about side-effects with other portlets.  performInteraction
gives them the facility to accomplish this in an optimized way.

Why isn't returning markup from performBlockingInteration a sufficient
optimization?
Because performBlockingInteraction allows you to change navigationalState
which is intended to be useful by allowing users to bookmark content/pages,
many consumers will choose to do a client redirect following the return from
the call.  In these situations it is likely that the optimized markup returned
by the performBlockingInteraction will be tossed.  The subsequent client
request that results from the redirect will trigger the necessary renders.
 Thus the optimization has been lost.  

But what about the arguments against keeping it?
The main argument I remember voiced against keeping the method is that by
having the method the overall complexity of the specification is increased
making it harder for developers to implement and demonstrate conformance.
 Well, its certainly true that any new feature adds complexity.  However,
we have demonstrated in the past that we are willing to add complexity where
it optimizes the protocol.  For example, adding the ability to return markup
from performBlockingInteraction adds all sorts of subtleties for the portlet
developer [in terms of dealing with in/out navigational state, etc].  Like
returning markup, this is another example of an optimization we should keep
vs. removing it to keep the protocol simpler.  
   -Mike-