I like the idea of being able to modify a URL on the
client including other types of WSRP URLs. This has always been a problem
in WSRP. However, I think this proposal is too specific in implementation.
For some consumers, storing state as part of the path and not as query parameters
is too restrictive. Not all consumers can or want to remap a pseudo path
to a real path with parameters. This restriction could therefore exclude
a whole class of consumer implementations like simple ASP.NET/JSP page
consumers.
To me, the generic solution is to make it work with
consumer that store their state as query parameters in the resulting URI as
well as using the restful-path technique.
This extension is trying to solve a very specific
problem - how to use Dojo or some other Ajax
toolkit and have it dynamically load script modules without modifying it for
WSRP – and hence all the gymnastics with immutable vs. non-immutable path
manipulation and restriction on the consumer not being able to use query
parameters, etc. I’m OK with such an extension but it would be force
a very specific consumer/producer implementations. Perhaps it can be named
something more specific like "Path Rewritable Resource URLs”.
I’m voting “NO” for now. I
think this needs more thought to make it more generic or the proposal needs to
be renamed to something more specific such that we could do something more
generic later.
Nader
Oteifa
From: Nathan Lipke [mailto:]
Sent: Wednesday, November 19, 2008
1:54 PM
To: Richard Jacob
Cc:
Subject: Re: [wsrp-interfaces]
Rewritable resource URIs
Thanks for your feedback. I think I can add
clarifications without effecting the current vote (Rich please advise).
However, if you feel there are missing or wrong requirements please vote
"No" and add an appropriate comment.
See additional comments inline.
Richard Jacob wrote:
I have some more questions which I think we need to
address:
1.
the tie to the JSR spec and its behavior is somewhat missing
By
serving out-of-band resources portlets would call encodeURL() in the portlet
API. This can be either a fullpath URI or an absolute URI.
How
would the Producer split between those two?
Would
that mean that portlets need to become aware of the WSRP extension?
I
think the key issues is that we have an seperator in here. Shouldn't the
consumer decide which portions of an URL being the parameter of wsrp-url it
wants to make mutable?
The WSRP spec requires a full URI to be the value of
wsrp-url. Thus the JSR container is responsible for converting a fullpath
URI to an absolute URI. However, with this spec we rely on the producer to
determine which portions of the path are rewritable (scheme, server, and port
MUST be immutable). This is because only the producer knows which portions of
the path may require rewriting.
Example:
/webapp/images/gifs/foo.gif
The producer can decide which portions should be rewritable:
Only the file
Any file under images
Anything in the webapp
Anything on the server
2. Another issue I see is the serve resource ID
If
think we imply here (although remain silent on it) that the portlet uses the
resourceID to denote the immutable and mutable part, right?
It is explicitly specified that the resourceID may be
split between the two.
wsrp-uri-immutable - The immutable (by the
client) portion of the URI.
When isOperation is
true (getResource):
The immutable
portion of the resourceId (may be empty if the producer allows the
entire resourceId to be mutated)
wsrp-uri-mutable This value MUST NOT be URL
encoded. It represents the remaining, client-mutable portion of the URI.
When isOperation is
true (getResource):
The mutable
portion of the resourceId (may be empty - this allows path and parameter
composition)
GET style
parameters (optional)
Would you like further clarification, to be added.
And expect portlets to receive
a modified resourceID.
Yes, portlets which use this type of URL should expect
modified resourceIDs.
Don't we need to clarify on
resourceIDs here?
Can't
this also impose problems with encoding?
The current specs JSR and WSRP
remain silent on that. This means that any character can be part of the
resourceID.
How
can such a part become a part of the portal URL path if it is not URL safe?
See #4
So I think supporting
get/serveResource() needs a more detailed revisit. More than the initial
proposal for out-of-band resource URL.
3. We seem to introduce a new
flag isOperation in the URL format.
Can't
the exisiting prefereOperation flag be used here?
This was done intentionally, as it no longer a
preference but an absolute declaration by the producer.
4. What about international
domain names, how would they be encoded in the path? Especially if they are
considered immutable? Are those charcters safe?
The immutable portion of the URL should be double-encoded for non US-ASCII
characters, the mutable portion would be singly encoded. I can add a note
to this effect.
Nate
