Sorry
to follow up post to myself, but I remembered one other thing I wanted to
include. I think it's important to use tokens to mark both the beginning
and end of URLs that are to be rewritten when using (2). It will make the
kinds of URL rewriting I propose below a lot easier (i.e. if using javascript
rewriting, the parser won't have to find the end of the URL to insert the close
parens).
Sasha.
-----Original Message-----
From: Sasha Aickin
Sent: Wednesday, June 05, 2002 11:59 AM
To: Alejandro
Abdelnur; Michael Freedman
Cc: Chris Braun; WSRP
Subject:
RE: Fw: [wsrp][markup] Conf Call Agenda (June5)
Alejandro,
I
want to reiterate an objection I raised last week against (4) in the markup
conference call.
I
think that URL rewriting logic should be left to the portal to provide for the
maximum flexibility for different web application platforms and kinds of
URLs. If we use (4), then we will be forced to define a rigid way of
rewriting URLs that will need to be implemented by each producer. There
is a good chance that we would define an URL rewriting algorithm that
would be difficult to implement on some platforms or have mistakes (especially
when you consider the relatively poor and scattered support for
internationalization in URLs).
As
an example, imagine that a portlet had an URL, http://portletserver/rewriteme.htm?querystring=value,
that needed to be rewritten. One portal might want to just add
that URL to the end of its portal URL, like http://portalserver/portletgateway/http://portletserver/rewriteme.htm?querystring=value.
Another portal might want to make the portlet's URL a query string argument,
like http://portalserver/portletgateway?portletURL=http%3A%2F%2Fportletserver%2Frewriteme%2Ehtm%3Fquerystring%3Dvalue.
Yet another portal might want to make the portlet's URL into a javascript
call, like javascript:openPortletURL("http://portletserver/rewriteme.htm?querystring=value"). There
are several other ways to rewrite URLs, but I think these examples show
that we should not make all portals support the same algorithm for
rewriting. If we use (4), however, we will be forced to do this.
(2) gives us more flexibility both in the near term (for different portals to
do different kinds of rewriting) and in the long term (for revision
when new web application platforms allow for different types of
URLs).
Cheers,
Sasha.
-----Original Message-----
From: Alejandro Abdelnur
[mailto:]
Sent: Wednesday, June 05, 2002
7:51 AM
To: Michael Freedman
Cc: Chris Braun;
WSRP
Subject: Re: Fw: [wsrp][markup] Conf Call Agenda
(June5)
PEEP. I'm not participating in the markup
discussions on regular basis, so I've been trying to catch up with the URL
rewriting thing last week and I've checked with Chris on the current status
of the dicusscion.
My understanding was that the scenario 4 (the
producer does the rewriting) was still to be evaluated.
From Mike's
email I understand that scenario 2 (the portla does the rewriting) would be
the way to go.
I was planning to join the conf call
today.
Following are my thoughts on the scenarios (2) and
(4).
Regards.
Alejandro
steps of a request:
(a)
consumer prepares for call,
(b) consumer calls producer,
(c)
producer prepares content,
(d) consumer receives content,
(e)
consumer prepares content
(f) consumer presents consumer to client.
URL rewriting related activity for scenario (2):
(a) nothing
(b) nothing
(c) producer uses
set of standard tokens to create content
(d) nothing
(e)
consumer determines URLs, parses content and replaces tokens with URLs
(f) nothing
URL rewriting activity for scenario (4):
(a) consumer determines URLs
(b) consumer sends URLs
as part of the call
(c) producer uses received URLs to create
content
(d) nothing
(e) nothing
(f) nothing
neutral for (2) and (4):
from the producer perspective
(c) is equivalent for both scenarios, the only diffferent is that (2) uses a
set of predefined tokens and (4) uses a set of URLs when creating the
portlet content. i do not see there a performance impact or complexity in
the producer if using scenario (2) or (4).
pros for (2):
(a), (b) no need to do any up front work, call payload
smaller.
pros for (4):
(e), no content parsing needed.
content can be streamed back to client as a blob.
cons for (2):
(e), consumer has to parse received content and replace tokens
with URLs.
cons for (4):
(a), consumer has to
determine URLs, most likely will be a fix & predetermined set of URLs.
(b), consumer has to send the ULRs set from the consumer to the
producer thus increasing the size of the payload.
my conclusion:
considering that the number of tokens we are talking is small (about
4) i see the scenario (4) (a) and (b) steps as much ligther weight
than the scenario (2) (e) step.
Michael Freedman wrote:
Chris,
I apologize but I have a conflict tomorrow and won't be
able to call in personally. Good news however is that I didn't hear
a peep from either the JSR group or internally in requiring the portal to
support URL rewriting. I.e. it looks like there are no objections to
the consensus choice voiced last week. The one thing that was
mentioned and I think is a good idea is that all content responses must
include an indication that URL rewriting is required otherwise the portal
is free to assume that it does not. I.e. a mechanism to indicate
whether or not URL rewriting/substitution processing needs to run on this
response with the default being don't run/process the response. As
this response is coming in a SOAP response, this should be easy -- as its
just another return parameter along with the content.
As
for URL/Link types: The one thing I would like to throw into the mix
are Portal URLs. At times a portlet may want to embed a reference
(in its content) to well known Portal locations; for example
"home". Shouldn't we use our URL rewriting mechanism to manipulate
these types of links? i.e. allow a URL rewrite token to be followed by a
token indicating the portal location; something like portal:xxxx where
xxxx is a portal defined location token (e.g. portal:home)?
-Mike-
Chris Braun wrote:
Wednesday June 5, 12:00PM EDT
To join this
conference:
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 or +1
(646) 485-9300 and enter 2791 4907
Markup members, Here is the agenda for next weeks conference
call. The conference call dial in info will follow, but it's the
same as usual. Agenda: 1. URL
Rewriting2. Visual Themes
CSS Classes Items to be covered (to help guide the
conversation) 1. URL
Rewriting 1.1 Conclude Scenarios 1.1.1 Try to come to a
consensus as to which scenario/scenarios we should
use. 1.2 Possible URL Types (What is a
Link?)
1.2.1.Fully
qualified URL – Nothing needs to be done at the
consumer
1.2.2.Action links –
URL rewritten so the consumer can intercept the action and forward the
action onto the portlet service via
soap.
1.2.3.Proxy resource
links – rewritten so the consumer can intercept the resource
request.The resource can then either be pulled from an
internal consumer cache or retrieved via
http.
1.2.4.Relative URI –
For relative URIs the producer sends the consumer the Base URI to be
used when generating relative
references.
1.2.5.Actions to
other WSRP services?
1.3 Discuss possible grammars for each URL
type.
2. CSS Classes
2.1 Table
-
2.1.1 Recap
2.1.2 Do we need a custom class to describe wsia-table for backgrounds,
fonts, etc?
2.2
Sections
2.3
Forms
2.4
Menus
2.5
Portlet
