[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: FW: [wsrp][markup] First conference call
Sorry, I meant to send this to the whole list.
S.
-----Original Message-----
From: Sasha Aickin
Sent: Thursday, April 11, 2002 7:16 PM
To: 'Carsten Leue'
Subject: RE: [wsrp][markup] First conference call
Carsten,
Some reactions I have:
(1) I see a third way of URL rewriting, which is that the aggregator
parses the markup and does it automatically. This is more difficult to
do from an aggregator's perspective, but it eases the burden for the
developer tremendously. We would leverage techniques that markup
developers already know, and we would have an easier time reusing
pre-existing, non-WSRP markup.
(2) While I appreciate the parsing concerns you have, I don't like the
idea you put forward in (4) to create semi-unique tokens that appear at
the beginning of an URL to indicate that it should be transformed. The
first reason is that it might not be entirely clear where the URL to
transform ends. I think that you are assuming that rewriting an URL
will always involve just adding a prefix, but it could also involve
transcoding the contents of the URL (based on character set issues) and
adding a suffix. If we do not specifically mark the end of the URL, we
many encounter problematic cases. Second, it seems to me that the
problem of choosing a sufficiently improbable token has been solved with
XML namespaces. Finally, just because we use XML tags to indicate what
should be rewritten does not mean that we cannot write a state machine
parser that can go through the markup in order(n) time. To be clear,
I'm envisioning something like this in markup:
Here is a <a
href="<wsrp:transformurl>directory/link.html</wsrp:transformurl>">link I
want to transform</a>. Here is a <a href="directory/link.html">link I
don't want to transform</a>.
(3) The Begin Page/Main Content/End Page dynamic is cool, but I'm
concerned that there are other places that a portlet might want to put
content in HTML (specifically in the BODY tag). Also, I'm not sure how
well this will apply to wirless markup languages. I would be interested
in either making the list of places that markup content could go
extensible or restricting the markup to only go in one place (since I
actually think that most interesting functionality can be achieved
inside the portlet's table cell).
Cheers,
Sasha.
-----Original Message-----
From: Carsten Leue [mailto:CLEUE@de.ibm.com]
Sent: Friday, April 05, 2002 4:04 AM
To: Gino Filicetti
Cc: 'wsrp@lists.oasis-open.org'
Subject: RE: [wsrp][markup] First conference call
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