RE: [wsrp] getResource question

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

06/01/05 09:16 AM

To

"Subbu Allamaraju"
<>, "wsrp" <>

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

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

> 

> 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

---------------------------------------------------------------------

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