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

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 <>

03/07/2007 05:45 PM

To

Rich Thompson/Watson/IBM@IBMUS, 

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-

 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

>  

>