RE: [wsrp] getResource question

[Rich Thompson <richt2@us.ibm.com>]

On the Interfaces SC call today, it
was suggested I draft an additional statement for section 10.2.1.1.3 attempting
to delineate that the Portlet's markup does have control between the three
cases described below. I would suggest appending:
"This
flexibility allows the Portlet’s markup to control which resource serving
mechanism is in use whenever it needs to and allows for the Portlet to
provide additional guidance when both mechanisms are supported, since the
fidelity of what is presented to the End-User might depend on which mechanism
is selected by the Consumer."

Note: the previously last sentence ("If
the Portlet needs to share data with the referenced resource, it can exploit
the cookie support defined in section 10.4.")
was deleted because section 10.4 is no longer valid and is being deleted.
Rich

"Andre Kramer" <andre.kramer@eu.citrix.com>

06/01/05 09:16 AM

To	"Subbu Allamaraju" <subbu@bea.com>, "wsrp" <wsrp@lists.oasis-open.org>
cc
Subject	RE: [wsrp] getResource question

I think we wanted to support dynamic situations were
the consumer's help
is needed, e.g. producer can do http & SOAP serving but the consumer
is
in a domain that only supports one protocol.

The understanding was that http may return a different representation
from SOAP (which has the full Portlet context).

Regards,
Andre

-----Original Message-----
From: Subbu Allamaraju [mailto:subbu@bea.com] 
Sent: 01 June 2005 14:05
To: wsrp
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

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