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
<>
06/02/05 10:10 AM
To
WSRP TC
<>
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 <>*
>
>
> > 05/31/05 02:53 PM
> >
>
>
> > To
> >
wsrp <>
> >
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
