[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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. 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...) 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. Conclusion: I prefer approach 2 for both URL rewriting and namespace encoding. Best regards Carsten Leue ------- Dr. Carsten Leue Dept.8288, IBM Laboratory Böblingen , 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, wsrp@lists.oasis-open.org | | 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:david_taieb@us.ibm.com] > Sent: Friday, May 10, 2002 3:36 PM > To: wsrp@lists.oasis-open.org > 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC