Re: [Fwd: Re: [wsrp] Public parameters - caching]

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

There is quite a rich heritage to public
parameters ... some of which Mike and I reviewed on the last call. I will
probably miss some items, but items of note that I recall include:

1. The WSXL contributions had "request scope properties" that could be set by the Consumer or on URLs and action responses
2. The WebCollage contribution had "parameters" that could be set by the Consumer or on URLs and action responses
3. Alejandro proposed we consider a "Consumer shared session" where portlets could set and receive named values
4. Mike proposed a data-oriented coordination mechanism to the Coordination SC
5. Due to the overlap between the evolving event model and the proposed data-oriented coordination model, the Coordination SC decided to develop the event model first and then revisit whether there were significant use cases the event model did not address well
6. When the event model began to stabilize, Mike presented some use cases it did not address well and proposed "render parameters" as a means for user/Consumer sourced coordination information
7. In the TC discussions of this proposal, it was felt restricting these to rendering markup left out important use cases and they were expanded to "public parameters"
8. Richard proposed a special class of events ("Render Events") to improve fragment cachability. As these developed into use cases, it became clear they mapped better to having public parameters be able to be set on URLs and action responses.

The history is useful because the WebCollage
contribution included some examples from client work that used many parameters.
While many of these were relatively stable, others changed frequently.
They had concluded that dealing with cache maintenance was not worth it
and sent the full set each time. WSXL had both request and session scoped
properties, sending only changed items each time (request scoped properties
changed each time by definition). We had not fully dealt with issues of
robustness relative to session level properties within WSXL when it was
contributed to the WSRP effort.

Hopefully that helped answer your question,
Mike.

Rich

"Mike Caffyn" <mike@netunitysoftware.com>

06/05/05 09:05 PM

To	"WSRP TC" <wsrp@lists.oasis-open.org>
cc
Subject	Re: [Fwd: Re: [wsrp] Public parameters - caching]

I'm not quite getting the public parameters.
I must have missed discussions on it. They do indeed seem very similar
to user profile items. What situations set the public parameters? Are they
set in the consumer via mappings etc like user profile items? I would have
thought they could be returned via perform blocking interaction so portlets
could be involved in setting parameters.
 
Mike
----- Original Message ----- 
From: Rich
Thompson 
To: WSRP
TC 
Sent: Thursday, June 02, 2005 4:33 PM
Subject: Re: [Fwd: Re: [wsrp] Public parameters
- caching]


Just to be clear, I am just trying to help think clearly through the situation
before we commit to such a path ... 

While the analogy to User Profile items is tempting, I think the difference
is in the area of expected stability. User Profile data is expected to
change infrequently and it is quite reasonable for the Consumer to simply
resend the entire data set when a change does occur. I expect public parameters
to contain a mixture of items where many are relatively stable and some
change relatively frequently, though hopefully not on every user interaction
(:}). 

Here is my overall mental diagram: 

 -----------        -------------------------
| Consumer  | ---> | Mapping to Portlet 1 PP | -> sent to Portlet
1 
|  public   |       -------------------------
  
| parameter |       ------------------------- 
|   store   | ---> | Mapping to Portlet 2 PP | -> sent
to Portlet 2 
 -----------        -------------------------
E.g. zip      --->  P1(zipCode), P2(postalCode)

Adding session-level caching adds some interesting items to consider:
1. Consumers would need to track what Portlets cache PPs for use when building
SOAP messages 
2. When one PP changes on a page with many PPs, does the Consumer:
    a. Resend all PPs - greatly reduces value of doing the caching
    b. Resend only changed PPs - raises question of how to indicate
it is time to use the default value of a PP 
3. Bookkeeping relative to caching: 
    a. If a PP changes in such a manner that the Consumer is
able to get the Portlet's markup from a cache, the Consumer must track
that the Portlet doesn't yet know about the change.
    b. Answer to Q2 impacts whether bookkeeping is done per PP
per Portlet or merely per Portlet. 

Both the bookkeeping costs (memory & processing) and value of the caching
depend strongly on the answer to Q2. Answer 2.a has less caching value,
but lower bookkeeping costs. 

Rich

Subbu Allamaraju <subbu@bea.com>

06/02/05 10:10 AM

To	WSRP TC <wsrp@lists.oasis-open.org>
cc
Subject	Re: [Fwd: Re: [wsrp] Public parameters - caching]

We have a similar situation with user profile items. These items can 
change at any time depending on what goes on within the consumer's 
environment. In such cases, the consumer is supposedly responsible for
resending the user profile items even when the producer stores the 
parameters in the session.

Public parameters are in someways transient consumer-managed 
initialization parameters. Since the portlet advertises the required 
parameters at discovery time, I don't see how they can be more dynamic.
The values could change for a variety of reasons, and the consumer can
always resend when changes are detected.

Regarding Rich's comments:

1. I'm not sure if I completely follow the comment on bookkeeping. 
Whether we have this kind of caching or not, the consumer will have to
have some system of storing and tracking public parameters. If the 
consumer does not want to detect changes, it can always resend all 
values on every request. A smarter consumer would possibly send only 
those that changed from a previous request. A lazy consumer may not care
about changes during a session.

2. Stateless portlets would declare that they don't store public params
in session.

3. Whatever caching considerations we have (or don't have - I have to 
check the spec) for user profile items should apply here too.

Regards,

Subbu

> I'm a bit confused now due to the fact that I missed the early
> discussions around public params. But what Subbu describes sounds
like
> some intialization params to me as they are expected to change very
> infrequent. As these are shared parameters I find the association
with
> the session not very natural as they may be invalidated and changed
by
> all kinds of external events not related to the current user.
> 
> Or how would this work with the example in the spec of the zip code
if
> the user changes the zip code in some other application? So you would
> need the bookkeeping Rich mentioned, which sounds very expensive to
me.
> 
> 
> Stefan
> 
> 
> Rich Thompson wrote:
>  >
>  > This would change the semantics significantly, but could
also provide
>  > quite a performance boost for large public parameter sets.
Effectively
>  > this would change the lifetime of the parameters from a
Portlet
>  > perspective to the session level ... currently they are
defined to be at
>  > the request level. There would be a variety of impacts
of such a change,
>  > but it definitely is an optimization to consider. Issues
I see include:
>  >
>  > 1. Would Consumers implement the bookkeeping needed to
track what  PP
>  > has changed since the last communication with each portlet
(would have
>  > to take into account cache hits)?
>  > 2. How would this impact stateless Portlets (i.e. no session)?
>  > 3. Impacts on caching strategies where an independent cache
sits between
>  > the Consumer and Portlet?
>  >
>  > Rich
>  >
>  >
>  > *Subbu Allamaraju <subbu@bea.com>*
>  >
>  > 05/31/05 02:53 PM
>  >
>  >      
>  > To
>  >       wsrp <wsrp@lists.oasis-open.org>
>  > cc
>  >      
>  > Subject
>  >       [wsrp] Public parameters - caching
>  >
>  >
>  >      
>  >
>  >
>  >
>  >
>  >
>  > Since public parameters are supplied with each
>  > getMarkup/pbia/handleEvents request, isn't there a need
to let Producers
>  > to store these values in the session (just like URL templates
and user
>  > profile items), and let Consumers supply these values once
per session?
>  > This will be a nice performance optimization.
>  >
>  > I did not find any references to this issue in the interfaces
SC docs.
>  > Has this issue been discussed previously?
>  >
>  > Regards,
>  >
>  > Subbu
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe from this mail list, you must leave the
OASIS TC that
>  > generates this mail.  You may a link to this group
and all your TCs 
> in OASIS
>  > at:
>  > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>  >
>  >
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your
TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php