OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]