wsrp-interfaces message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsrp-interfaces] Fw: [wsrp] Additional use cases for issue #44 (setnew public params)
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp-interfaces@lists.oasis-open.org
- Date: Thu, 28 Jul 2005 08:52:32 -0400
To your questions:
Simply because the user can drive the
coordination does not mean the user is editing a URL. If the user has chosen
to activate a URL which sets a PP, then the user is driving the coordination.
The Consumer can certainly generate such a URL for the user to interact
with. Why disallow the Portlet also being able to generate such a URL?
Stefan's use cases certainly make a case for allowing it.
Obfuscation does enter the picture,
nor does by reference questions. If the Consumer has particular encodings,
including using by reference, then such issues are taken care of when the
Consumer rewrites the URL.
WSRP involves the Consumer due to issues
with the network topology and access to resources which are behind firewalls.
This proposal impacts none of that reasoning nor alters choices already
made.
If you are questioning whether PPs ought
to be supplied on getResource invocations, I would consider that an orthogonal
question. One we should definitely address, but orthogonal to the issue
at hand.
Again, look back at Stefan's use cases
to see that this is not overloading PPs, but rather allowing Portlets to
have an influence on PP values. Limiting the interaction to the Portlet
which generates the URL (e.g. using navState or some new facility like
portlet_querystring) doesn't solve the use case.
Rich
"Andre Kramer"
<andre.kramer@eu.citrix.com>
07/28/05 04:43 AM
|
To
| Rich Thompson/Watson/IBM@IBMUS,
<wsrp-interfaces@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [wsrp-interfaces] Fw:
[wsrp] Additional use cases for issue #44 (set new public params) |
|
Do you expect end users to
edit URLs to override consumer (PP) settings? Then I would ask (to prime
the call today):
-
Is
such editing of URLs desirable? Allowed for Web experts for simple URLs,
I agree, but for Portlets?
-
Are
URLs not too obfuscated (encoded) to allow manual editing? Because of size
limitations, the URL may be by-reference.
-
Why
need the consumer be involved? Since user explicitly submits she may not
expect the consumer Portal to be in the loop.
-
Are
other types of URLs (to resources and out-of-Portlet Web content) also
not to be covered?
-
Why
overload PPs with this feature? Maybe a separate user to portlet channel
would be better? Something more like a query string?
My suggestion for 3.0 would
be to look at having a trailing URL part (wsrp-portlet-query-string) that
can be added to consumer produced URLs that is forwarded unmodified (or
as a separate key/value list) by the consumer to explicitly model query
strings if we really require and can support such a feature.
Regards,
Andre
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 27 July 2005 19:18
To: wsrp-interfaces@lists.oasis-open.org
Subject: Re: [wsrp-interfaces] Fw: [wsrp] Additional use cases for
issue #44 (set new public params)
To say this another way, PPs enable user/Consumer driven coordination.
The current question is whether to allow Portlets to generate URLs that
enable the user driven portion of this rather than requiring such URLs
be generated by the Consumer. I think the use cases Stefan posted say there
is value to allowing Portlets to generate such URLs.
Rich
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]