Re: [wsrp-interfaces] XMLPortletRequest Proposal

[Rich Thompson <richt2@us.ibm.com>]

I agree that the proposal addresses
the Consumer assisting the Portlet in doing AJAX. I'm just focussing a
bit on what the goals for our #3 category should be. I think your recent
rewording was a great step forward, but also think that limiting the first
goal to the Consumer providing a means for portlets doing AJAX programming
is a bit too restrictive. It should include that, but I am not convinced
that should be the totality of the goal. I deleted the previous comments
about the goals since you addressed them and left a comment specific to
this concern on the wiki.

Rich

Subbu Allamaraju <subbu@bea.com>

07/06/06 03:49 PM

To	wsrp-interfaces@lists.oasis-open.org
cc
Subject	Re: [wsrp-interfaces] XMLPortletRequest Proposal

Thanks for the comments.

In my view, the proposal is addressing the cooperative model (3) where
the consumer provides a means for portlets do Ajax programming.

In addition, the proposed model could also be used to implement (2) with
the difference that consumer need not surface an XMLPortletRequest (XPR)
to portlets since the consumer is initiating Ajax requests. I just 
looked at 
http://wiki.oasis-open.org/wsrp/Supporting_Consumers_doing_client-side_page_aggregation.
In my view, solution for the client-side aggregation would provide the
basis for implementing XPR.

I'm not convinced yet if and how (1) should be addressed. The problem is
very similar to a portlet using an iframe or using getResource to bypass
consumer aggregation (Mike's use case), and the consumer can do nothing
about it unless we require some kind of rewriting. But any rewriting 
would break the assumption about consumer-awareness.

I will capture these comments on the wiki.

Subbu

Rich Thompson wrote:
> 
> I like the general nature of this proposal, but in looking at detail
at 
> it, I realized that it addresses an intermediate set of goals rather
> than one of the three set out on our calls. We had discussed three
> interesting cases:
> 1. Portlets doing AJAX without Consumer involvement/knowledge
> 2. Consumers leveraging AJAX to enable partial page updates (i.e.
> independent of what the Portlet is doing)
> 3. Consumer-Portlet cooperation such that a Portlet can leverage the
> browser-side nature of AJAX on top of the Consumer doing partial page
> updates.
> 
> This proposal hits an intermediate goal where the Consumer does partial
> page updates only in the case of the Portlet using AJAX to activate
URLs 
> (i.e. a Portlet submitting a URL not using AJAX would cause a full
page 
> refresh). Whether there is sufficient value to add this to the set
of 
> goals or simply expand this proposal to complete the 3rd set of goals
> should be one of our items to discuss.
> 
> Rich
> 
> 
> *Subbu Allamaraju <subbu@bea.com>*
> 
> 06/30/06 05:20 PM
> 
>                  
> To
>                  wsrp-interfaces@lists.oasis-open.org
> cc
>                  
> Subject
>                  [wsrp-interfaces]
XMLPortletRequest Proposal
> 
> 
>                  
> 
> 
> 
> 
> 
> I posted a rough draft of the proposal at
> 
> http://wiki.oasis-open.org/wsrp/XMLPortletRequest_Proposal
> 
> The key objective of the proposal is to allow portlets do Ajax
> programming and still participate in the three-phase lifecycle.
> 
> Subbu
> _______________________________________________________________________
> Notice:  This email message, together with any attachments, may
contain
> information  of  BEA Systems,  Inc.,  its subsidiaries
 and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted
 and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return
this
> by email and then delete it.
> 

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries
 and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted
 and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.