[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-interfaces] Rewritable resource URIs
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
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.
From: Nathan Lipke [mailto:firstname.lastname@example.org]
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.
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.
It is explicitly specified that the resourceID may be split between the two.
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
Don't we need to clarify on
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.
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?