RE: [wsrp-interfaces] Rewritable resource URIs

["Nader Oteifa" <nader2@netunitysoftware.com>]

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:nathan.lipke@oracle.com]
Sent: Wednesday, November 19, 2008 1:54 PM
To: Richard Jacob
Cc: wsrp-interfaces@lists.oasis-open.org
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

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.

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?

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

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