Next in thread →
Next in month →
RE: [wsrp][markup] First conference call
Title: Message
Comments inline
-----Original Message-----
From: Carsten Leue
[mailto:]
Sent: Wednesday, April 17, 2002 9:57
AM
To:
Cc: Gino Filicetti;
''
Subject: RE: [wsrp][markup] First
conference call
Khurram -
thanx for your comments.
Here are some additional thoughts:
1. I agree that the requirement to put javascript methods into
a WSRP
namespace may introduce some work for remote
services that make use of this
feature heavily.
However I do not see a much easier solution.
- the
functions must be prefixed in some way to avoid disambiguities
between javascript methods exposed from multiple portlets
that are
aggregated onto one page
- there are two options to do so:
- parse the markup on consumer side and
prefix all functions: this
would be easiest for the
provider. However every consumer would have to
implement a parser for every supported markup type. This will be
very
laborious to do and furthermore the set of markup
types cannot be easily
extended.
- let the provider prefix the functions:
this put sort of burden on
the provider but he must
prefix his js methods only once. A consumer can
than
be written in a very generic, efficient and markup agnostic
form.
> This definitely makes sense
- parsing JavaScript is pretty much impossible due to the fact that
you can create and execute JavaScript code dynamically.
2. From my point of view we should pass information on the
current browser
capabilities as a parameter to the
provider when requesting markup. I would
not advise to
make this part of the metadata but handle it dynamically e.g.
based on CC/PP.
For the proposition to define
either a positive list or a negative list
regarding
the HTML tags I am with you. Maybe we should rather define the
list of disallowed tags than the list of allowed
ones.
> I would even use the term "discouraged" rather
than "disallowed". For example, there's probably no reason to put a
<META> tag in a WSRP service (or: at least not in the "main" portion),
but since no harm is done by putting it in, there doesn't seem to be a real
benefit to ruling out services that do so (for any, not necessarily good,
reason)
3. just as in 1. I would expect that this issue would be
solved if we let
the provider prefix these names and
rewrite these entities on the consumer
side to make
the names unique.
4. this is a very valid comment. An equivalent problem occurs
for images
and other server resources. In principle
the aggregating portal would have
to act as a proxy
server for such resources. But we will have to further
discuss the issue.
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B鐽lingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+------------------------------>
|
|
Khurram_Mahmood@peo|
|
|
plesoft.com |
|
|
|
|
| 04/17/2002 05:04
AM|
|
| Please respond
to |
|
|
Khurram_Mahmood |
|
|
|
|---------+------------------------------>
>--------------------------------------------------------------------------------------------------------------------------------------------|
|
|
|
To: Carsten
Leue/Germany/IBM@IBMDE
|
|
cc: "Gino Filicetti"
<>, "''"
<>
|
| 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"
<
To: "Gino Filicetti"
<>
>
cc:
"''"
<>
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鐽lingen , 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:
"''"
<>
|
| 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:]
> Sent: Wednesday, April 03, 2002 10:42 AM
> To: Gino Filicetti
> Cc:
''
> 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鐽lingen , 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:
"''"
>
<>
>
|
>
| 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 |
> 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>
----------------------------------------------------------------
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 →