[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsia] Re: [wsrp-interfaces] State change in getMarkup?
Hi Mike -
from my point of view the JSR enforces a special implementation flavour of
WSRP in order to not modify the navigational state.
Assume that I want to build a stateless producer based on JSR 168. I could
simulate a session to the JSR porlet but implement it by serializing the
session's state as navigational parameters back to the consumer. But if the
portlet may modify state I can't do this.
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory Böblingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+----------------------------->
| | Michael Freedman |
| | <Michael.Freedman@|
| | oracle.com> |
| | |
| | 08/20/2002 07:30 |
| | PM |
|---------+----------------------------->
>-------------------------------------------------------------------------------------------------------------------------------|
| |
| To: wsrp-wsia <wsia@lists.oasis-open.org>, interfaces <wsrp-interfaces@lists.oasis-open.org> |
| cc: |
| Subject: [wsia] Re: [wsrp-interfaces] State change in getMarkup? |
| |
| |
>-------------------------------------------------------------------------------------------------------------------------------|
Carsten,
You are correct that sessionID prevents stateless consumers. This was
one
of the reasons I argued for the sessionID to be consumer based vs. producer
based. What we have now is mostly stateless consumers. This is still
better
then allowing any ole markup state to be modified in that sessionIds don't
change very often and are small. This allows for reasonable consumer
caching
implementations in a load balanced environment (read many/write few -- as
writes are very costly).
How do you think JSR 168 allows you to modify navigational state in
getMarkup? I don't see where it does. If you are refering to sessionId --
yes
it can be modified (reestablished) during a getMarkup -- but that puts us
back
to my answer to 1 above -- i.e. we threw out truly stateless consumers when
we
defined entity sessions vs. consumer sessions. My understanding from the
F2F
is that we could all live with that.
-Mike-
Carsten Leue wrote:
> One issue I would like to bring up again (maybe just as a clarification
for
> me) is the ability of an entity to modify state in getMarkup.
> If I remember correctly be decided that an entity should not be able to
> modify conversational state in getMarkup, primarily for the reason that
we
> want to be able to write a stateless consumer. Such a consumer would need
> to know all of the conversational state of all portlets on a page before
it
> streams any markup to the client (because the consumer wants to encode
the
> state in the URL).
>
> 1. What about the sessionID? Currently we allow getMarkup to return a
> sessionID. Wouln't a stateless consumer need to encode this ID also in
the
> client URL? How could he do so if it might change in getMarkup?
> 2. JSR168 does not prevent portlets from modifying state in the service
> method (the getMarkup equivalent). How does this match with WSRP?
>
> Best regards
> Carsten Leue
>
> -------
> Dr. Carsten Leue
> Dept.8288, IBM Laboratory Böblingen , Germany
> Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC