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: Fri, 16 Mar 2007 12:41:57 -0400
For the sake of concreteness, the following
field would go in ResourceParams:
[O] string resourceCacheability
- resourceCacheability: This field carries
the value which the Consumer received for the wsrp-resourceCacheability
portlet url parameter from the URL activation which caused this invocation
of the getResource operation.
Rich
Subbu Allamaraju <subbu@bea.com>
03/16/2007 11:51 AM
|
To
| wsrp <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| Re: [wsrp] Re: [wsrp-interfaces] Issue
with current CachableResource proposal |
|
Yes, I can imagine something like that. IMO, the spec
should not be
vague. Whatever completeness we're trying to bring in with this proposal
will be lost if the solution can't interop.
Subbu
Richard Jacob wrote:
> it would be merely an indication to the producer what was encoded
in the
> URL as the cachability flag triggering that gR().
> This way the prodcuer could for example limit its URLgenerator it
provides
> to portlet for example and prevent the portlet to set parameters to
the URL
> which would in turn contradict the cachability flag behavior.
>
> One example might be that if "full" is received, the producer
would prevent
> portlets to add pbia() URLs while generating the gR() content.
>
> 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
>
>
>
> Subbu Allamaraju
> <subbu@bea.com>
>
To
> 03/16/07 04:01 PM
wsrp <wsrp@lists.oasis-open.org>
>
cc
>
>
Subject
>
Re:
[wsrp] Re: [wsrp-interfaces]
>
Issue
with current CachableResource
>
proposal
>
>
>
>
>
>
>
>
>
>
> Assuming that there is such a flag in the request, what would the
> semantics of the flag be, for the producer?
>
> Subbu
>
> Richard Jacob wrote:
>> well typically the producer manages that state and therefor has
an
> encoder
>> for JSR286 containers anyway (it encodes e.g. render URL params
to
>> navigational state). So the likelyhood is very small indeed unless
its a
>> "simple" URL encoding of these params.
>> But as said I have no objections to add this field to the protocol.
>>
>> 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 05:03
PM
> cc
>
> Subject
>>
Re:
[wsrp] Re: [wsrp-interfaces]
>
>>
Issue
with current
> CachableResource
>>
proposal
>
>
>
>
>
>
>
>>
>>
>>
>>
>> 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>
>
>
> To
>> 03/15/2007 11:46 AM
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
>>
>>
>>
>>
>>
>>
>>
>>
> _______________________________________________________________________
> Notice: This email message, together with any attachments, may
contain
> information of BEA Systems, Inc., its subsidiaries
and affiliated
> entities, that may be confidential, proprietary, copyrighted
and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return
this
> by email and then delete it.
>
>
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries
and affiliated
entities, that may be confidential, proprietary, copyrighted
and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]