Next in thread →
Next in month →
RE: [wsrp][markup]Markup document (updated revision)
Title: Message Comments inline. -----Original Message----- From: Carsten Leue [mailto:] Sent: Thursday, May 16, 2002 6:33 AM To: Gino Filicetti Cc: 'David Taieb/Cambridge/IBM'; Subject: RE: [wsrp][markup]Markup document (updated revision) Gino - regarding the pros and cons of the scenarios I would see one of the major advantages of approach 2 vs 1,4 that this allows the integration/reference of static content. In all other cases the provider would have to modify all named entities (URLs, javascript, etc) anyway. It could e.g. not simply link in a javascript library because it would have to rewrite all function names with the correct prefixes. Give approach 2 this would be possible as the prefix is well known and static. [ER] Carsten, I still can't see how approach 2 helps with JavaScript libraries. You obviously can't use off-the-shelf JavaScript libraries since they don't use any prefix that we define. And even with custom libraries, there's still the issue of a unique prefix to JavaScript global functions and variables to allow two portlets of the same class to reside on the same page, which in any case requires rewriting that can't be done on the portal side. We might decide that this scenario is not important, but that seems a bit over-restricting. Otherwise, if the portlet can't write the URLs and the prefixes in the first place (E.g., using a JavaScript function supplied by the portlet framework), how would that scenario work? Approach 3 has the major disadvantage of being extremely complicated to implement, the provider would have to supply a special URL rewriter for all possible markups. I would see this practically impossible. Approach 4 seems to be an efficient solution as no rewriting occurs on the aggregators side. However the set of URLs the aggregator sends to the provider could become very large: this set would have to include URLs for all client side state the remote portlet could go in (minimized, maximized, etc...) [ER] Can you possibly elaborate on a case where a single URL is not enough? If the portal passes a URL that's generated dynamically and includes the appropriate state, would that address this issue (e.g., http://www.myportal.com/mypage?state=maximized). Furthermore this approach seems to imply that the client side URL can be generated by just adding a URL prefix. This might not always be the case. [ER] It is a bit limiting and in essence assumes the action is always encoded as the last URL parameter. I would also favor generalizing it so that the portal passes a URL template, e.g., http://www.myportal.com/mypage/servlet/(put-action-here)?state=maximized Conclusion: I prefer approach 2 for both URL rewriting and namespace encoding. Best regards Carsten Leue ------- Dr. Carsten Leue Dept.8288, IBM Laboratory B鐽lingen , Germany Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 |---------+----------------------------> | | Gino Filicetti | | | <gfilicetti@bowst| | | reet.com> | | | | | | 05/15/2002 04:43 | | | PM | | | Please respond to| | | Gino Filicetti | | | | |---------+----------------------------> >---------------------------------------------------------------------------------------------------------------------------------------------| | | | To: David Taieb/Cambridge/IBM@Lotus, | | cc: | | Subject: RE: [wsrp][markup]Markup document (updated revision) | | | | | >---------------------------------------------------------------------------------------------------------------------------------------------| David... We need to include all 4 of the URL rewriting scenarios that are now on the table in this doc under section 5.2.. They currently are: Scenarios: 1. Aggregator sends a prefix w/ request and portlet must use it to do the URL boundary demarcation. The aggregator then parses the markup looking for the prefix it provided. 2. All portlets use a predefined prefix which is part of the spec to demarcate URL boundaries. The aggregator then parses the markup looking for the well known prefix. 3. The aggregator automatically parses markup and heuristically determines URL boundaries and does the necessary rewriting automatically. 4. The aggregator sends the remote portlet the URL information that it needs and the remote portlet rewrites all the necessary URLs itself. The markup it sends back will then be ready for immediate inclusion in the page, no parsing necessary Also, we should list out the pros and cons for each scenario that were discussed last week and are captured in last week's minutes. And we should make specific reference to the consensus that a combination of scenarios 2 and 4 seems to be the way to go. Other than that the document looks great! G > -----Original Message----- > From: David Taieb/Cambridge/IBM [mailto:] > Sent: Friday, May 10, 2002 3:36 PM > To: > Subject: [wsrp][markup]Markup document (updated revision) > > > Hi All, > Here are the latest version of the Markup master > document based on > the latest concall > Regards, > (See attached file: WSRP Markup.doc)(See attached file: WSRP > Markup.htm) > David Taieb > Advisory Software Engineer > Lotus Software, IBM Software group > One Rogers Street > Cambridge, MA 02142 > Tel : (617) 693 5819 > Fax : (617) 693 5542 > ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
Next in thread →
Next in month →