Re: [wsrp-interfaces] Groups - CacheableResources.html uploaded

[Rich Thompson <richt2@us.ibm.com>]

I was reflecting the discussion, but
I agree that it should be RuntimeContext (also, SessionContext is actually
named SessionParams ...). Expanding resourceState to ResourceParams has
a problem in that it pulls in NavContext, which we are trying to exclude.
Also, shared params are in NavigationalContext, not MimeRequest. In the
end I prefer the include approach because of its clarity, but I am concerned
that we are worrying too much about pulling some edge cases from "portlet"
to "full" such that we will end up sacrificing the benefit for
the larger set of use cases which "full" set out to address.

On the "portlet" wording;
the restrictions statement will apply at any level where the portlet url
parameter is specified. As a result, any nesting level can tighten the
restrictions laid down by its ancestors, but I think trying to fully express
this in the statement just confuses the underlying point that this specification
of the parameter is impacting both this resource and any secondary resources.

I agree the wording on the "page"
level statement should be made implementation independent, including those
implementations which choose to not place the state on the URI at all.
How about:

"This value for the wsrp-resourceCacheability
portlet url parameter informs the Consumer that it will need the state
required to provide the rewriting of such URIs when the user agent requests
the resource which the URI references."

Rich

Michael Freedman <michael.freedman@oracle.com>

03/07/2007 05:45 PM

To	Rich Thompson/Watson/IBM@IBMUS, wsrp-interfaces@lists.oasis-open.org
cc
Subject	Re: [wsrp-interfaces] Groups - CacheableResources.html uploaded

Unfortunately, I don't think the newly added line:
"As a result, the resource generation SHOULD only depend on the 
PortletContext, SessionContext and the explicitly supplied resourceState."

is clear enough.  First off I assume you mean RuntimeContext not 
SessionContext as the session info seems to be carried in RC and I think
resources should have access to the other RC data.  Secondly, isn't
"explicitly supplied resourceState" too restrictive and doesn't
it need 
to be qualified to the ResourceParams?  I.e. resourceState is a field
in 
ResourceParams and hence this might be interpreted as limiting you from
access/depending on the other "extra" resource parameters.  And
as for 
the shared parmeters -- defined in MimeRequest, won't the resource need
to access most of these? 

In the end I think I/we need to reverse ourselves and provide an 
explicit definition of what you can't depend on namely 
NavigationalContext.  Maybe we can finesse WS and Mode in that we
don't 
entirely guarantee the consumer preserve these -- i.e. the portlet can
depend on these (meaning will supply real value for these) but the 
consumer is encouraged to do this in a way that doesn't significantly 
impact cacheability.

As for the "portlet" level: I think the following sentence needs
additional clarification:
"These restrictions apply not only to the resource directly referenced,
but also to any secondary resources the resource references."

Should be:
"These restrictions apply not only to the resource directly referenced,
but also to any secondary resources the resource references unless such
reference sets a value of "full" at which point that reference
and its 
follow on references adhere to the tighter restrictions".

I.e. you can always go to a tighter level but never a looser one.
 
And the last level "page":
The sentence:
"This ensures the Consumer will place the state it needs for such
rewriting on the URI which the user agent will use to request the 
resource from it."

Might better be stated:
"This allows the Consumer to place the state it needs for such rewriting
on the URI which the user agent will use to request the resource from it."

I.e. the way it is currently worded assumes a single implementation 
style vs. one we want to reserve/prefer.
     -Mike-


richt2@us.ibm.com wrote:

>The document revision named CacheableResources.html has been submitted
by
>Rich Thompson to the WSRP Interfaces SC document repository.  This
document
>is revision #1 of CacheableResources.html.
>
>Document Description:
>
>
>View Document Details:
>http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/document.php?document_id=22767
>
>Download Document:  
>http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/download.php/22767/CacheableResources.html
>
>Revision:
>This document is revision #1 of CacheableResources.html.  The
document
>details page referenced above will show the complete revision history.
>
>
>PLEASE NOTE:  If the above links do not work for you, your email
application
>may be breaking the link into two pieces.  You may be able to
copy and paste
>the entire link address into the address field of your web browser.
>
>-OASIS Open Administration
>  
>