[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp][markup] First conference call
Hello All,
1. I have a comment regarding #3 below. The option two in #3 where a
provider adds a prefix to all the javascript functions names is a very
complex and involved task. Basically a provider will have to add a prefix
to all javascript function names wherever they are defined and referenced.
This part is easy. The real problems comes in where a javascript function
calls another javascript function and the multiple different ways it may
call the other function. The provider will have to parse through all its
javascript functions in all the referenced javascript files, find all
possible ways a js function might be calling another function and prepend
all occurences with a prefix. In my opinion, this puts a very heavy burden
on the provider. This parsing need not be done at runtime (unless all js
is dynamically generated) but my concern is that putting this restriction
on the provider essentially requires the provider to write a small js
parser for all existing javascripts.
2. The list of allowed HTML tags does not allow for any browser specific
tags. In my opinion, this can be very inhibiting for portlets that want to
use really nice but browser specific ui and would require massive changes
in some cases to conform to this standard. It almost seems that we need to
define categories of HTML elements: (a) those that may affect the
format/structure of the whole page (e.g. link, iframe etc.) (b) those that
are self-contained (e.g. image etc.). Both lists should not be extensible,
we just define the basic tags. We need to allow the second category and
disallow the first. I am not very comfortable with the approach of
defining allowed HTML tags because this lands us into an endless process of
updating the list of tags and in some cases severally restricts the
resulting ui.
3. Just like the javascripts, we need to encode the form names for
namespaces too. Actually, we will have to encode the name/id of each and
every field on the page as many browsers will break or act unpredictably if
multiple elements have same ids on a page. A better approach would be to
surround the content from each portlet into a container element (e.g. span
or a div) but even that won't solve all the problems. What do you get when
you do: document.all.item("FieldID") when you have multiple fields with id
= "FieldID".
4. In the list of allowed tags, I see that we allow the Object tag. We
definitely need to allow it but it opens up another set of problems for the
portal. What if the object tag is pointing to a signed java applet? If
the portal server is proxying it, what does it do with the codebase? What
will happen to the certificate of the portlet server? Will it work? How
many other permutations will we have to consider?
More thoughts to come,
Thanks,
KM
Khurram Mahmood
Off: (925) 694-9566
Cell: (408) 230-6784
"Carsten Leue"
<CLEUE@de.ibm.com To: "Gino Filicetti" <gfilicetti@bowstreet.com>
> cc: "'wsrp@lists.oasis-open.org'" <wsrp@lists.oasis-open.org>
Subject: RE: [wsrp][markup] First conference call
04/05/2002 04:04
AM
Hi all,
unfortunately today I got a terrible cold and may not be able to attend the
call tonight. However here are some details on markup processing I dealt
with when implementing the demo:
1. Markup Rules:
The markup a portlet generates must be restricted in such a way that it can
be aggregated together with other portlets onto a page. These restrictions
depend on every markup we want to support, so we will have to work out the
details for each case. For the case of HTML the markup restrictions were
that the markup must be embeddable into an HTML table cell (so it must not
include one of the following tags Base, body, frame, frameset, html, meta,
noframes, style).
However sometimes the portlet wishes to expose certain tags that can only
occur in a global scope (e.g. meta tags or cetain javascript methods). The
portlet API allows for this by defining the beginPage and endPage methods
in addition to the service method that generates the markup. A mapping of
these additional calls to WSRP calls would introduct two more roundtrips
what is inacceptable. My current solution is to allow the portlet to
generate markup that is structured into tree parts, one for the beginPage
equivalent, one for the service equivalent and one for the endPage
equivalent. The aggregator gets the markup in its beginPage call, parses it
and stores the fragments. It can then stream the stored fragments inside
the corresponding portletAPI methods into the output stream.
Example:
WSRP service generates in a single roundtrip
<-- BEGIN_PAGE_TOKEN -->
Begin Page Markup
<-- MARKUP_TOKEN -->
Markup
<-- END_PAGE_TOKEN -->
End Page Markup
Aggregator gets the markup in its beginPage method:
- parses the three parts. if no separator is located it assumes that the
whole markup belongs to the service method.
- outputs the beginPage part to the output stream
in the service method
- outputs the stored services part to the output stream
in the endPage method
- outputs the stored endPage part to the output stream
2. URL rewriting:
The WSRP service must have the possibility to encode URLs in the markup so
that are routed back to itself. From the point of view of the aggregator
these URLs cannot be direct links to the provider but must be intercepted
by the aggregator. I see two possibilities how such URLs can be embedded
into the markup:
2.1 the aggregator sends a prefix with each markup request to the provider.
The provider must then prefix each URL with this prefix and may append
private data. When the user clicks on a link this event is automatically
routed to the prefix's location so the aggregator can intercept.
2..2 the provider prefixes each URL with a predefined and constant value
(would be part of the WSRP spec). The aggregator must then parse the markup
for such prefixes and replace them by links that point to itself.
In the demo I implemented the 2.2. version. It seems favorable to me due to
the following reasons:
- aggregator and provider are decoupled. In 2.1 it would not be possible
for the provider to expose a static page as its markup but is must embed
the (dynamic) prefixes in any case. In 2.2. the provider is free to expose
static pages as the prefixes are constants. This also reduces the amount of
data to be transfered between aggregator and provider.
- The markup must be parsed anyway due to 1. If the prefixes are chosen
wisely (see below) this can be done in one step.
3. Namespace encoding:
If multiple portlets of the same kind are aggegrated into one page certain
named entities (like javascript methods) may appear twice causing a name
clash. To prevent this such entities must be encoded specially. One way to
do so would be to parse the markup on the aggregator's side, identify each
entity and put it into a unique namespace. However this approach requires a
parser for each type of supported markup, a task that is very laborious and
even impossible if markups are added on the fly.
A solution would be to enforce the provider to encode the named entities
somehow during markup generation. The provider would have to add a prefix
to these entities that makes them unique. As in 2. two possiblities exist,
either the aggregator passes the namespace to use to the provider or the
provider uses a constant prefix that is rewritten on the aggregator's side.
Using the same argument as in 2. I would prefer the second approach
4. Efficient parsing:
All of the steps 1-3 require the aggregator to parse the markup generated
by the provider. However it is not neccessary to understand the markup's
syntax (e.g. build a document tree) but only to locate certain tokens in
the markup and replace them by different tokens (e.g. replace the URL token
by the aggregator's access point or the namespace token by the provider
specific namespace valid in the aggregation context).
An efficient way to parse the markup would be to define an escape token
that is the same for all three cases. Specific information to distinguish
URL rewriting and namespace encoding follows this token. A parsing
algorithm could then use a very efficient search algorithm to locate the
escape token and then branch to a (slower) analysis and rewriting
procedure. As such a seach algorithm I would propose the BM alg.
This approach would imply that the escape token is relatively long and
consists of characters that are very improbable to find in a normal markup.
e.g. ESCAPE_TOKEN = {29B23528-2736-4e97-93B6-3BECD04A4F6A}
URL_TOKEN = ESCAPE_TOKEN<provider specific URL info>
NAMESPACE_TOKEN = ESCAPE_TOKEN{name}
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> |
| | |
| | 04/03/2002 06:06 |
| | PM |
| | Please respond to|
| | Gino Filicetti |
| | |
|---------+---------------------------->
>
---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: Carsten Leue/Germany/IBM@IBMDE
|
| cc: "'wsrp@lists.oasis-open.org'"
<wsrp@lists.oasis-open.org>
|
| Subject: RE: [wsrp][markup] First conference call
|
|
|
|
|
>
---------------------------------------------------------------------------------------------------------------------------------------------|
Team,
Here are the details for the conference call on Friday:
-------------------
Date: Friday, April 05, 2002
Time: 11:00 AM Eastern, 8:00 AM Pacific
Duration: 1 Hour
Title: WSRP Markup Sub-Committee
For quick access, go to https://bowstreet.spiderphone.com/27914907
(This link will help connect both your browser and telephone to the call)
OR dial 1 (866) 633-2978 (in the US) or +1 (646) 485-9300 (internationally)
and enter 2791 4907
-------------------
Carsten, I'm glad you can make the call, and we look forward to getting
your
input.
Again, this call is open to any other interested parties as well.
G
> -----Original Message-----
> From: Carsten Leue [mailto:cleue@de.ibm.com]
> Sent: Wednesday, April 03, 2002 10:42 AM
> To: Gino Filicetti
> Cc: 'wsrp@lists.oasis-open.org'
> Subject: Re: [wsrp][markup] First conference call
>
>
>
> Gino - I will be happy to attend the call on friday, 11am EST
> is ok for me.
> Can you send me an invitation together with the call-in details?
>
> To start with I could give a brief summary on what a portlet
> programmer
> must take into account to make remote portles work from my
> experience with
> the demo impl. This would include
> - namespacing of fields and javascript functions
> - URL rewriting
> - how can common javascript methods (variables) be used by different
> portlets
>
> I think that the concepts URL rewriting and namespace encoding are of
> interest to the interface group as well and we should stay in
> sync here.
>
>
> 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> |
> | | |
> | | 04/02/2002 10:15 |
> | | PM |
> | | Please respond to|
> | | Gino Filicetti |
> | | |
> |---------+---------------------------->
>
> >-------------------------------------------------------------
> --------------------------------------------------------------
> ------------------|
> |
>
> |
> | To: "'wsrp@lists.oasis-open.org'"
> <wsrp@lists.oasis-open.org>
> |
> | cc:
>
> |
> | Subject: [wsrp][markup] First conference call
>
> |
> |
>
> |
> |
>
> |
>
> >-------------------------------------------------------------
> --------------------------------------------------------------
> ------------------|
>
>
>
> Everyone,
>
> Since we didn't officially set a time for our first
> conference call during
> the face to face meeting, I'd like to propose our first
> conference call for
> this Friday, April 5th at, 11am EST, 8am PST and 6pm CET....
> Currently, we do not have any members in Germany, so we might be more
> flexible on the time... However, I think it might be useful
> to have someone
> who worked on IBM's demo implementation on the phone this
> time (and maybe
> even part of the group permanently) such as Carsten...
> Knowing more about
> the challenges faced in that initial implementation would be a good
> starting
> point for us.
> David has come up with a few topics that we should start
> initial discussion
> on during the call:
> -CSS Style: naming standards, modularisation, themes, ...
> -Markup rules : (HTML, WML, CHTML)
> -Scripting rules and conventions (JavaScript,
> VBScript, ???)
> -Namespace encoding rules
> -Developer guidelines ?
> There may be some overlap here with the work that other groups will be
> doing
> and if so, we need to iron that out as well. I know Michael
> has included
> almost all of these points in his list of topics for the
> initial con call
> of
> the interfaces and protocols sub-committee.
> Please let me know if the proposed time is acceptable and I
> will go ahead
> and schedule the conference call.
>
> . . . . . . . . . . . . . . . . . . . . . . . .
> Gino Filicetti | Software Engineer
> One Harbour Place, Portsmouth, NH 03801
> T 603.559.1692 | gfilicetti@bowstreet.com
> w w w . b o w s t r e e t . c o m
>
>
>
> ----------------------------------------------------------------
> 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>
>
----------------------------------------------------------------
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC