Re: [wsrp-interfaces] Rewritable resource URIs

[Nathan Lipke <nathan.lipke@oracle.com>]

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:

OFD4D85700.761067BE-ONC1257506.006157DD-C1257506.00624245@de.ibm.com" type="cite">
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
  

OFD4D85700.761067BE-ONC1257506.006157DD-C1257506.00624245@de.ibm.com" type="cite">
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.

OFD4D85700.761067BE-ONC1257506.006157DD-C1257506.00624245@de.ibm.com" type="cite">And expect portlets to receive a modified resourceID.

Yes, portlets which use this type of URL should expect modified resourceIDs.

OFD4D85700.761067BE-ONC1257506.006157DD-C1257506.00624245@de.ibm.com" type="cite">Don't we need to clarify on resourceIDs here?
Can't this also impose problems with encoding?

OFD4D85700.761067BE-ONC1257506.006157DD-C1257506.00624245@de.ibm.com" type="cite">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

OFD4D85700.761067BE-ONC1257506.006157DD-C1257506.00624245@de.ibm.com" type="cite">So I think supporting get/serveResource() needs a more detailed revisit. More than the initial proposal for out-of-band resource URL.

OFD4D85700.761067BE-ONC1257506.006157DD-C1257506.00624245@de.ibm.com" type="cite">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.

OFD4D85700.761067BE-ONC1257506.006157DD-C1257506.00624245@de.ibm.com" type="cite">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