OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Why you should vote to keep performInteraction ...

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.  

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]