First, congrats on the IPO. Is the F2F dinner be on you ;-)
I think there has been three issues with URL rewriting by the portal, as
in option (2):
are constructed only in run-time and hence cannot be written while parsing the
code) (Sorry for re-iterating this point)
b. Processing time is inherently high, because the portal needs to parse
the entire stream. (As Alejandro noted)
c. It's hard to define how actions embedded in other formats (e.g.,
Flash) can work.
So the rationale behind supporting option (4) (rewriting by the portlet)
in the cases where companies develops a sophisticated portlet that uses one of
the constructs (a) or (c) above, and also may want to optimize performance to
eliminate the performance issue in (b) above. (Thing of a MapQuest as one
example, but also think of trying to sell to a company like Google the idea that
their output will be re-parsed, performance-wise)
It makes sense that SDKs for developing remote portlets should help
developers, for example by providing a function like an encodeURL(...) that
takes care of how to embed an action within a URL provided by the portlet, or by
providing a filter (available both in the Microsoft world and in the Servlets
world) that does this automatically.
This is not to say that option (2) (rewriting by the portal) doesn't have
its merits (namely, alleviate the need for the portlet to call this function).
The main reason to support option (2) is to support "simple" portlets (with
relatively static content). Although, as you noted yourself in a previous
message, the fact that the protocol uses SOAP as the underlying protocol means
that portlets can't really be static anyway (they have to process a SOAP
request, at the least), so given the effort involved in this there's the
question of whether calling an additional function or using a filter (both can
provided by a toolkit) are really a bid deal in addition to that
As to your specific points, assuming we want to support option (4), I
would induce from your example that the portal should not just transfer URL
prefixes, but rather URL skeletons, e.g.,
http://www.portal.com?action=(action)&user=sasha, in which the portlet can
noted. As for action encoding, we always assume that the action is opaque to the
portal, so whatever the portlet passes it also receives back. This is somewhat
ambiguous with identifiers that include URL-encoded symbols (such as %20), so we
can either disallow them or define the semantics, especially if people want to
If we decide to also support option (2), I agree with you that it's
better to have both beginning and end markers to make life easier for the
where this would still not address the issue.
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
to insert the close parens).
want to reiterate an objection I raised last week against (4) in the markup
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).
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.
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
Following are my thoughts on the scenarios (2) and
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
URL rewriting related activity for scenario (2):
uses set of standard tokens to create content
(e) consumer determines URLs, parses content and replaces tokens
URL rewriting activity for
(a) consumer determines URLs
consumer sends URLs as part of the call
(c) producer uses
received URLs to create content
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.
(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.
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:
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)?
Chris Braun wrote:
|Wednesday June 5, 12:00PM EDT
To join this
For quick access, go to
(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
qualified URL – Nothing needs to be done at the
– URL rewritten so the consumer can intercept the action and forward
the action onto the portlet service via
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
– For relative URIs the producer sends the consumer the Base URI to be
used when generating relative
other WSRP services?
1.3 Discuss possible grammars for each URL
2. CSS Classes
2.1.2 Do we need a custom class to describe wsia-table for
backgrounds, fonts, etc?