Ah - I see it now. Yes, your proposal does address the concern.
Regards,
Subbu
Rich Thompson wrote:
>
> 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 <>*
>
> 06/01/05 09:05 AM
>
>
> To
> wsrp <>
> 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 <>*
> >
> > 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
> >
> >
>
>
> ---------------------------------------------------------------------
> 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
>
>
