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
