OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsrp] Issue #29: Is metadata needed to indicate support forgetResource? and Issue #36: add a urlType for getResource

In the following on discussion of the over - overloading 1.0 resource URL issues, Richard made an interesting proposal which I promised to investigate when back in the New Year. The suggestion is to add a separate wsrp-id field to resource re-write expressions and templates instead of overloading the wsrp-url field we already have as currently suggested. This would more cleanly allow a producer to specify both a http (or any other Web URL scheme) and SOAP identifier for the resource. The consumer may then have some choice in how to retrieve a representation of the portlet resource.


This is similar to my previous suggestion of allowing the wsrp-url to serve both as the getResource resource identifier argument AND a Web URL IFF its format is valid as one (the consumer may then check that it's a valid URL scheme that it has a handler for and use that protocol handler if it can not or will not call the new getResource operation). But, I now agree a separate wsrp-id would be cleaner and allow more flexibility in naming the resource (as arg to getResource).


I would suggest still keeping the boolean flag indicating which method is the preferred retrieval method. This would allow the producer to serve resources using both Web and Web Service protocols, expressing an explicit preference which the consumer can override if the deployment environment makes it necessary. E.g. a consumer co-located behind a firewall could use an internally served http url while externally only a SOAP service is exposed.


With such compatibility options in place for this feature, I believe we adequately address 1.0/2.0 consumers who do not wish to upgrade fully immediately, to the same level as the Web (browser) does in that any "resource" or tag that is not understood is ignored or an "alt" is rendered. This agues against new meta-data which would have, like our 1.0 usesMethodGET, the problem that portlet writers have to remember which / be honest about the markup they generate and that is thus mainly ignored by consumers.


So, I think we have a pretty good migration story as well as clear use cases for this feature.


As for Mike's argument below, I suspect that 2.0 producers will mostly wish to still offer 1.0 port-types. Consumers that don't wish to upgrade fully should at least fail safely back on http (using wsrp-url if provided even if the flag specifies a preference for getResource/wsrp-id or provide an alternative representation for the resource) or can stay at 1.0 and continue to use the 1.0 markup port. We can review this once the getResource implementation effort is understood (low, I still think) but I suggest we now add an explict wsrp-id resource template field without any meta-data. The other (optional) features we are working on are all significant enough to justify a "2.0" label (rather than a 1.x) and the consumer modifications to optionally (at degraded user experience - the usual Web strategy) support getResource are reasonable.





From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: 22 December 2004 18:29
To: wsrp@lists.oasis-open.org
Subject: Re: [wsrp] Issue #29: Is metadata needed to indicate support forgetResource?


As I said in the conference call today, its to allow a 1.0 consumer to upgrade to 2.0 easily so they can run 2.0 producers that don't have a 1.0 port.  As it stands, this seems to be the only none optional nwe feature being added.  I might prefer leaving it out of 2.0 all together vs. making it turnkey for 1.0 consumer to get up and running on 2.0.

Rich Thompson wrote:

Is metadata required to say the caller is a v1 Consumer? I would expect a Producer which supports both v1 and v2 to know this is a v1 Consumer because the invocation came on the binding to the v1 portType.

Another possible reason for Consumer metadata would be if a v2 Consumer had the option of not supporting urls causing getResource to be invoked. We have in general steered away from such things in order to keep complexity down for the Producer and I would rather we require v2 Consumers provide this support than require v2 Producers to adapt.


Michael Freedman <Michael.Freedman@oracle.com>

12/21/2004 12:54 PM






Re: [wsrp] Issue #29: Is metadata needed to indicate support for getResource?




And vice-versa:  so a producer can adapt to run in a 1.0 consumer.

Rich Thompson wrote:

Issue #
Spec section:
Isn't metadata needed to tell a Consumer whether or not a Producer supports getResource (or is it always supported if urls encode for it and Consumers never invoke it unless a url has encoded wsrp-useOperation=true)?


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]