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 <>
05/31/05 10:06 AM
To
wsrp <>
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
