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
