RE: Limitations of WSRP

[mohan.radhakrishnan]

Hi,   1.       JSR 168 portlets can co-operate in they are within the same WAR. If it is WSRP then there is no concept of WAR. Right ? It is remote. So the normal co-operation that the JSR 168 spec. defines will not apply. 2.       Actually I was trying to find out if SAML is used now in conjunction with WSRP widely. I think that SAML is used for federated identity management ? 3.       WSRP security means normal SSL or something else. Right ? Doesn’t SOAP define security ? 4.       “WSRP will not properly handle cookie information from your portlet all the way back to the client.” Why is that ? 5.       “Unfortunately, the information between the a tag (i.e. <a href="" will be rewritten</a> ) will get rewritten as well.  This could lead to problems if NOT careful.” Can you point me to some examples ? 6.       AJAX in WSRP.   So many things that are possible with portlets seem to break in WSRP.     Thanks, Mohan From: Tali Garsiel [mailto:[EMAIL PROTECTED] Sent: Thursday, May 11, 2006 7:53 PM To: wsrp4j-user@portals.apache.org Subject: RE: Limitations of WSRP   Hi,   I think a big limitation is that’s almost impossible to use AJAX calls in WSRP portlets.   Tali   From: James Moliere [mailto:[EMAIL PROTECTED] Sent: Thursday, May 11, 2006 5:01 PM To: wsrp4j-user@portals.apache.org Subject: RE: Limitations of WSRP   Mohan,   1 – Yes.  Think of WSRP and JSR168 as a standard where WSRP is the remote portlet and JSR168 is the local portlet.  They are similar technologies that avoid stepping on each others toes. 2 -- ? 3 -- ? 4 – In WSRP, any type of HTML may lead to problems – i.e. the base tag ( <BASE SRC="" for HTML may become a problem for you if the URL doesn’t get rewritten.  In the case of _javascript_, remember that the portlet you are developing will likely go into a container that serves the HTML in a table.  The problem with this is that other portlets that have _javascript_ may collide with your functions (names space collisions).  In essence, avoid _javascript_.  Another problem is Cookies – avoid cookies as well.  WSRP will not properly handle cookie information from your portlet all the way back to the client.  Even if it tried, the spec for cookies is, 20 cookies from one domain will get sent back from the client to the server.  If a user just happened to have 21 portlets (where rewrite is turned-on on all of them) on 1 page all requiring 1 cookie – one of the cookies will not get sent back to its respective remote service.   5 -- To rewrite the URLs in WSRP, the algorithm is a simple search and replace throughout the whole document and replace the URL.   The problem with this is that the standard should have been written to contextually search and replace a document.  For example, the following HTML tags <a href="" <img src="" could be searched and replaced as expected. Unfortunately, the information between the a tag (i.e. <a href="" will be rewritten</a> ) will get rewritten as well.  This could lead to problems if NOT careful.   I’m really looking forward to an update to the spec – WSRP 2.0.   I hope this was helpful   James Moliere   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, May 11, 2006 3:41 AM To: wsrp4j-user@portals.apache.org Subject: Limitations of WSRP   Hi,       We have been trying to list the limitations of WSRP 1.0. I have a few questions. Appreciate if somebody can answer or point at the mistakes.   What impact does WSRP have on co-operating JSR168 portlets ? Can they still co-operate if they are served by the producer ? Is there any integration API available for WSRP and SAML ? What are the security mechanisms available to secure WSRP communication? Can I assume that any type of HTML/DHTML markup and _javascript_ can be served by the WSRP impl. ?       5. What other limitation does WSRP impose ?   Thanks, Mohan This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.