Re: [wsrp-interfaces] interactionFieldPrefix and namespacing form params

[Richard Jacob <richard.jacob@de.ibm.com>]

Hi all,

I just decided to stress you further on the topic what we discussed last
week :-)
I started to think through what we proposed and decided to give it a shot.
So here is what I understood as the general idea, please correct me if I'm
wrong:
- introduce a new WSRP url parameter containing the namespace which was
used by the producer container and passed to the portlets, e.g. if they
call getNamespace()
- we assumed implicitly that the value of the new param is flowing back (in
InteractionParams and MarkupParams?)

What does it bring/help or was the intent of it?
- do not require namespacePrefix to be mandatory
- allow usage of wsrp_rewrite_ as the namespace prefix, here we explicitly
refered to resources using rewriting
- do not require the namespacePrefix to be constant across requests
- anything I missed?

I've been playing a little bit with it, here are some thoughts
1. portlets do not use wrsp_rewrite_ for form params namespacing
- it seems we're introducing some kind of namespace persistance across
requests through the backdoor.
Once the producer container decides to pick up a namespacePrefix from the
runtime context it is "persisted" in the URLs.
The Consumer is forced to send it back -> Producer uses it again and stores
it in the URLs.
While this seems an interesting means at the first glance, it introduces
some problems.
- How can consumers guarantee that they do not assign a new namespacePrefix
on a page which clashes with the existing ones?
- How does this new value relate with the existing namespacePrefix, seems
quite confusing here? Is the namespacePrefix assigned the new value from
the URL?
2. portlets using wsrp_rewrite_ in form names as the ns prefix
We saw that this is quite problematic. The intent of the proposal using the
URL param was that the URL param itself gets rewritten by the consumer to
the "real" namespace as well as the form fields in the markup. Thus
portlets/the producer can obtain the consumer assigned namespace to
identify the form params.
- Do we expect that Producers in this case pick up the assigned namepace
and rewrite it back again to wsrp_rewrite_ so that rewriting is always
used? -> additional producer rewriting
- If not we have just one wsrp_rewrite_ usage and then fall back to a given
namespace prefix with the implication I described in 1. ?
- I think we change the rewriting algorithms here: What do consumers do if
the wsrp rewrite token appears as a parameter value in the rewrite URL?
Aren't parameter values opaque here? Do your rewriting implementation touch
parameter values in a rewrite URL?
3. Resources using URL rewriting
I think the proposal doesn't really solve the problem. The main question
here is:
- How does the namespace prefix assigned by the consumer flow back to the
reasource?
- If it needed to flow back to the reasource it needs needs to be part of
the resource URL not the rewrite URL. But as of today, resource URLs are
opaque to the Consumer and it shouldn't touch them.

So when thinking through it, things really seem to become clumsy here, too
with not adding to much value here.
There are some implication in the proposal, which haven't been thought
through, yet.

Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Team Lead & Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com