OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[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