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
