MHonArc v2.5.2 -->
wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: [wsia] The search for per-entity-per-user Consumer state
Gil - wouldn't a portlet that displays the user's prefered stock price be
an example. There you have per-entity (stock portlet) per user (stock
symbol) state.
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B�blingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+---------------------------->
| | Gil Tayar |
| | <Gil.Tayar@webcol|
| | lage.com> |
| | |
| | 06/12/2002 12:16 |
| | PM |
| | Please respond to|
| | Gil Tayar |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org |
| cc: |
| Subject: [wsia] The search for per-entity-per-user Consumer state |
| |
| |
>---------------------------------------------------------------------------------------------------------------------------------------------|
Michael,
Your inclination towards the "web approach" is largely based on scalability
reasons - i.e. try to reduce the amount of information the Consumer has to
store per all entities per all users. To that effect, let me try and
continue to search for reasons why a Consumer will _have_ to have
information per-entity-per-user.
In the discussion in the joint interfaces meeting yesterday, I suggested
that the Consumer would have to store (per-entity-per-user) whether to call
performAction or getFragment. You, rightly so, told me that you never liked
the distinction so that this is (not yet) a valid argument.
To tell you the truth, I'm not sure *I* like the distinction between
performAction and getFragment. It may be that we will have *only*
performAction, where the action should be _exactly_ the "URL state" you
mentioned in your point (a) below.
Well, in this case, if the consumer has multiple portlets on the page, it
_must_ store the "last" action of all of them, and this _must_ be per-user.
To contrast with the web approach, in the simple Web application, the
browser stores the application's state in the address bar per-user. In the
WSRP/WSIA scenario, the Consumer must also store that information,
per-portlet! This is the only way to allow stateless portlets.
Am I missing something?
Gil