wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] Re: [wsrp-interfaces] Issue with current CachableResourceproposal
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp <wsrp@lists.oasis-open.org>
- Date: Thu, 15 Mar 2007 12:03:41 -0400
That was my first take as well, but
consider a Producer such as a JSR 286 portlet container. If it is not a
protocol field, the container would have to push this into the state which
is otherwise related only to the portlet. While this is certainly doable,
it raises a risk of name collision for this piece of state. The cost of
adding the field is so small that I prefer having the Consumer separately
supply it.
Rich
Richard Jacob <richard.jacob@de.ibm.com>
03/15/2007 11:46 AM
|
To
| Rich Thompson/Watson/IBM@IBMUS
|
cc
| wsrp <wsrp@lists.oasis-open.org>
|
Subject
| Re: [wsrp] Re: [wsrp-interfaces] Issue
with current CachableResource proposal |
|
I see, got it finally ;-)
Yes could be usefull. However the producer could encode this also opaque
to
the resource state it delivers to the consumer and on receiving that back
in gR() strip it away and make this its enforcement point. This way
consumers wouldn't need to care at all if producer are enforcing or not.
and thus have a little bit less protocol semantics.
But I don't have a strong opinion here and would also agree that we can
add
this as an explicit protocol paramter and enforce the consumer to add add
it to its resource URL state.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept. 2289, WebSphere Portal Server Development 1
WSRP Team Lead
WSRP Architecture & Standardization
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Johann Weihen
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
Rich Thompson
<richt2@us.ibm.co
m>
To
wsrp <wsrp@lists.oasis-open.org>
03/15/07 02:53 PM
cc
Subject
Re: [wsrp]
Re: [wsrp-interfaces]
Issue with
current CachableResource
proposal
Sure. If the Producer is supplying URL writing functionality to the
Portlet. It can refuse to encode disallowed URL types (e.g. throw an
exception when the Portlet attempts to write a render URL when the
cachability had been set to "full"). The spec should not require
such
enforcement of Producers, but I think enabling it would be a good idea.
Rich
Richard Jacob
<richard.jacob@de.
ibm.com>
To
Michael Freedman <michael.freedman@oracle.com>
03/15/2007 06:46
cc
AM
Rich Thompson/Watson/IBM@IBMUS, wsrp
<wsrp@lists.oasis-open.org>, WSRP Interfaces
subgroup <wsrp-interfaces@lists.oasis-open.org>
Subject
Re: [wsrp] Re: [wsrp-interfaces] Issue with
current CachableResource proposal
can you explain what you mean by enforcement?
I seem to miss context here. The parameter only influences consumer URL
rewriting and what's on the resource URL sent to the browser.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept. 2289, WebSphere Portal Server Development 1
WSRP Team Lead
WSRP Architecture & Standardization
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Johann Weihen
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
Michael Freedman
<michael.freedman
@oracle.com>
To
Rich Thompson
<richt2@us.ibm.com>
03/14/07 11:39 PM
cc
WSRP Interfaces
subgroup
<wsrp-interfaces@lists.oasis-open.o
rg>, wsrp
<wsrp@lists.oasis-open.org>
Subject
[wsrp] Re:
[wsrp-interfaces] Issue
with current
CachableResource
proposal
I am for adding it -- also copying the wsrp list in case anyone isn't on
this one.
-Mike-
Rich Thompson wrote:
I think it is a good idea to enable those Producers who
can and are
willing to enforce the restrictions.
Any objections to adding this field prior to the inclusion
of the
proposal into the draft?
Rich
Stefan Hepper
<sthepper@hursley.ibm.com>
To
03/14/2007 12:02 PM
WSRP Interfaces subgroup
<wsrp-interfaces@lists.oasis-ope
n.org>
cc
Subject
[wsrp-interfaces]
Issue with
current
CachableResource
proposal
While discussing in the JSR 286 EG how the producer may
enforce the
restrictions mentioned for the type FULL and PORTLET we
noticed that
the
producer does not get any information back on a serve resource
call
about the cachability setting.
Therefore I propose to add the following on the ResourceParams
type:
[O] string resourceCachability
providing the resourceCachability value set on the resource
URL that
triggered this getResource call. If this value is missing
the default
is
that the cachability of the getResource call is of type
PAGE.
Stefan
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]