[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. Regards, Andre From: Michael Freedman
[mailto:Michael.Freedman@oracle.com] 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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]