wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] getResource question
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp <wsrp@lists.oasis-open.org>
- Date: Wed, 1 Jun 2005 09:11:20 -0400
Maybe my summary wasn't clear ... we
would likely not just change the semantics of wsrp-preferOperation
to having the portlet specify which mechanism to use when fetching the
resource, but also change the name. To me, settling on the semantics
is the first task as the name should then be chosen to reflect those semantics.
Rich
Subbu Allamaraju <subbu@bea.com>
06/01/05 09:05 AM
|
To
| wsrp <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| Re: [wsrp] getResource question |
|
Not completely. The wsrp-preferOperation gives the
control to the
Consumer, and that's a bit troubling from admin point of view. AFAIR,
one of the use cases for this operation was to take out the burden to
open up HTTP ports and managing HTTP traffic/constraints differently
from SOAP traffic.
Regards,
Subbu
Rich Thompson wrote:
>
> I don't know if this rephrasing will help:
>
> *_Current draft:_*
> Portlet URLs have several options for resource URLs:
> 1. Just specify wsrp-url => Consumer must use proxying mechanism
to
> fetch the resource.
> 2. Just specify wsrp-resourceID => Consumer must use getResource
operation
> 3. Specify both wsrp-url & wsrp-resourceID => Consumer has
a choice ...
> portlet can guide choice using wsrp-preferOperation
>
> *_Proposal:_*
> Drop wsrp-resourceID and change semantics of wsrp-preferOperation
to say
> which mechanism to use. This drops option #3, but could also reduce
> complexity (two url parameters rather than three, eliminates issue
of
> URL<->ID mapping, ...).
>
> Subbu, does this capture your thoughts?
> If so, do people prefer the current or the proposal?
>
> Rich
>
>
> *Subbu Allamaraju <subbu@bea.com>*
>
> 05/31/05 10:06 AM
>
>
> To
> wsrp
<wsrp@lists.oasis-open.org>
> cc
>
> Subject
> Re:
[wsrp] getResource question
>
>
>
>
>
>
>
>
> Rich Thompson wrote:
> >
> > The original proposal for the url parameters for getResource
had
> > parameters serving multiple uses depending on which technique
was being
> > used to fetch the resource. People thought this added complexity
for the
> > reader and set a direction for unique identifiers. At the
time it was
> > also noted that this allowed portlet URLs to provide identifiers
for
> > both forms of resource fetching such that the Consumer
could be allowed
> > to choose which to use. The wsrp-preferOperation parameter
was added to
> > provide guidance on the Portlet's preference if both mechanisms
were
> > supported.
>
> It seems that we got it backwards here. In all other cases, Producer
> makes some choices based on what is right for the producer, but in
this
> case, the Consumer seems responsible for deciding how a resource gets
> served. My fear is that this would make producer admin's job more
> difficult. For example, for a wsrp 2.0 producer, the admin may have
to
> secure both http traffic and SOAP traffic for resources. I would prefer
> to let the Producer make the right choice, and let the Consumer simply
> work with that choice, even if that means supporting getResource
> operation to be V2 compliant. That way, this behavior would be
> consistent across the spec.
>
> Regards,
>
> Subbu
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your
TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]