Re: [wsrp] getResource question

[Subbu Allamaraju <subbu@bea.com>]

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 <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
> 
>