RE: [wsrp][markup]Markup document (updated revision)

[Eilon Reshef <eilon.reshef@webcollage.com>]

Title: Message

Comments inline.

-----Original Message-----
From: Carsten Leue [mailto:cleue@de.ibm.com]
Sent: Thursday, May 16, 2002 6:33 AM
To: Gino Filicetti
Cc: 'David Taieb/Cambridge/IBM'; wsrp@lists.oasis-open.org
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ö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>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>