[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsia] RE: [wsrp-interfaces] [wsrp][interfaces]Statemanagement/paramet ers
I think Carsten is bringing up very good points here.
Regards.
Alejandro
Carsten Leue wrote:
> My comments are embedded in <cl> tags.
>
>
> 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> |
> | | |
> | | 07/23/2002 11:55 |
> | | PM |
> |---------+----------------------------->
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |
|
> | To:
|
> | cc: interfaces
<wsrp-interfaces@lists.oasis-open.org>, wsrp-wsia
<wsia@lists.oasis-open.org> |
> | Subject: Re: [wsia] RE: [wsrp-interfaces]
[wsrp][interfaces] Statemanagement/paramet ers
|
> |
|
> |
|
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
>
>
>
> Q: How are we going to distinguish between the two? [action params and
> navigational params]
> A: One way to distinguish between the two is via namespacing most likely
> prefixing one parameter type (the action params?)
>
> Q: Will developers be confused?
> A: Maybe. Depends on whether we can articulate the differences between
> these two types of parameters and whether container implementations
make it
> easy to do the right thing by providing a [good] utility
> method for constructing URLs in the markup. The thing is if we go
to the
> alternative -- only allow action parameters in an encoded Action URL and
> then let perform action return the navigational parameters
> [generally a subset of the action parameters] it will also be
confusing for
> our developers as we should only allow "blocking" actions to return such
> markupParams as otherwise we force the consumer to block
> all rendering anyway (so it can get these markup parameters and rewrite
> into all generated URLs on the page).
>
> <cl> Maybe I am confused here. If we do not allow an action in the
general
> case to return the new navigational state (the result of the action),
what
> would the action be good for? In your scenation when the action link
> contains both the new markup parameters and action parameters, would
that
> mean that when the portlet writes an action link it would have to
> precalculate the possible outcome of all actions it encodes and put this
> new state as markup parameters in the link?
> The only other way I see what actions could do is updating session or
> backend state that would not be reflected in the markup parameters?
> Am I missing something?
> I would say that the option to precalculate all state and encode the
result
> in the actions is not feasible for perfomance resons.
> </cl>
>
> Q: Does this model require rewriting all existing portlet to support it
> (since the container cannot do this for the portlet)? Yes and no. I
> believe WSRP will already require all existing portlet to be
> rewritten because of the URL writing rules whether or not we say
there are
> two types of parameters or one.
>
> <cl> I agree </cl>
>
> Q: How do we support this model when we already know that this will not
> work with some browsers/devices (because the URLs will tend to be long,
> especially if we don't support stateless stateful portlets...)?
> A: Though the model allows navigational parameters/action parameters be
> entirely maintained in the links that go all the way back to the client
> this isn't required. A consumer is free to maintain this
> information in memory as part of a URL rewriting mechanism. I would
expect
> that some portals will choose to run with minimal state [the
parameters are
> sent back to the client] whereever possible -- i.e. on
> the desktop, and support the URL rewrite/parameter caching technique for
> wireless/small sized device situations. Such portals would be oen that
> believed most of their requests were desktop requests -- hence
> seek an optimal/scalable solution in this environment.
>
> <cl> Definitely. I would assume that only very few portals will
encode the
> navigational state of all portlet on a page in the URL that gets back to
> the client. The URL will soon become much too large, so every portal
will
> need to implement state management for its portlets.
> What worries me a bit is that we make a lot of design compromizes to
fulfil
> a possibility that will not be the normal use case. What does the group
> think?
> </cl>
>
> -Mike-
>
> "Tamari, Yossi" wrote:
>
>
>>Hi Mike,
>>
>>Regarding "action parameters and navigational parameters coexist in a
>
> link and can be distinguished by the portal":
>
>>How are we going to distinguish between the two? This could very easily
>
> become confusing for developers.
>
>>Does this model require rewriting all existing portlet to support it
>
> (since the container cannot do this for the portlet)? If this is the
case I
> would say this is a huge drawback.
>
>>How do we support this model when we already know that this will not
work
>
> with some browsers/devices (because the URLs will tend to be long,
> especially if we don't support stateless stateful portlets...)?
>
>> Yossi.
>>
>>-----Original Message-----
>>From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
>>Sent: Friday, July 19, 2002 6:42 PM
>>To: interfaces; wsrp-wsia
>>Subject: [wsrp-interfaces] [wsrp][interfaces] State
>>management/parameters
>>
>>Folks,
>> At the F2F I took on the task to clarify the proposed support for
>>"stateless" entities. In the meantime a discussion has ensued regarding
>>whether sessionId can be collapsed into the markupParams. This message
>>provides an overall analysis of the general question of state management
>>and its relationship to the protocol. Based on this a particular
>>usage/semantic pattern is proposed. Its intent is to clarify both of
>>the above issues. Please let me know what you think.
>>
>>Through various discussions/analysis 4 types of state can be defined.
>>The first three are well understood web application states/styles. The
>>last is a new one that comes into existence because of the way our
>>protocol works:
>>1) Navigational (URL) state -- this is state represented as parameters
>>in the query strings of links that establish the "navigational context"
>>of a page. I.e. this is the state that allows a link to encode the
>>state of a page so it may be bookmarked, refreshed, navigated to via
>>next/back. An example of this is the amazon.com link that references
>>the page that describes a specific book. The parameters for this
>>reference are part of the link making it bookmarkable/navigatable etc.
>>2) Session state -- this is user application state that doesn't vary as
>>you navigate. An example is your shopping cart in amazon.com. The
>>items in your shopping cart don't change as you use the next/prev
>>buttons or redisplay. Unlike navigational (URL) state, session state is
>>not represented/maintained by the client, rather it is maintained by the
>>server. The client merely has a reference to this state. This
>>reference is typically in a cookie but can also be a URL parameter
>>itself.
>>3) Action (transient) state -- this is state passed on requests that is
>>meant to be processed (submitted) and then tossed -- though the
>>processing usual results in changes to either session or navigational
>>state. The example for this is form submission.
>>4) Request (transient) state -- this is intermediate state meant to be
>>created during action processing and used in the next render call of the
>>portlet. I.e. in our protocol a single user action results in two calls
>>to the portlet performAction and getMarkup. These two calls occur
>>across 2 (connectionless) SOAP calls. How does a portlet create
>>transient state in an action that is can access in the following render
>>while not needing to clean it up because it is recollected after the
>>"request" completes? I.e. in the servlet model during a single request
>>logic can attach transient request state for later logic via request
>>Attributes. How does this work between an action/render pair in our
>>protocol? Answer: invent/support request state.
>>
>>How should our protocol present the above styles/usages?
>>1) Navigational (URL) state is represented by query string parameters
>>added to links generated by the portlet in its response to getMarkup (or
>>redirects from performAction). Such parameters are presented by the
>>Portal on subsequent use to both a portlet's performAction [if an action
>>url] and getMarkup calls as request parameters (in the RequestContext).
>>They are always resubmitted on redisplay.
>>2) Action state is represented distinctly from navigational state by URL
>>parameters added to action links generated by the portlet in its
>>response to getMarkup. I.e. action parameters and navigational
>>parameters coexist in a link and can be distinguished by the portal.
>>Action parameters are only presented by the Portal on subsequent use to
>>a portlet's performAction. They are not presented to getMarkup. They
>>are passed to performAction as interactionParams.
>>3) Session state is maintained by the portlet as needed and reacquired
>>on request by reference (i.e. a sessionID is passed to all portlet APIs
>>including performAction and getMarkup so it reattach to its in memory
>>state) [See below for note on why I suggest we don't support having the
>>Portal maintain this state on behalf of the portlet and resupply on each
>>request].
>>4) Request state is an opaque value returned by a performAction call to
>>the Portal and based to [only] the next getMarkup of that entity. This
>>state is represented by the markupParams returned by performAction and
>>passed to the next getMarkup. getMarkup wouldn't return markupParams --
>>its navigational parameters/state would be encoded in its response
>>links.
>>
>>Note: In the F2F we discussed supporting "stateless" portlets. At the
>>time we attempted to model not only "stateless" portlets as those that
>>limit themselves to be represented merely by navigational state (URL
>>parameters) but also session state. I.e. one form of markupParams was
>>to allow a portlet to package its session state and return it to the
>>Portal for later submission rather then keep this information in memory
>>and merely return a reference (sessionID). I recommend we do not add
>>this functionality to version 1 of the specification [though we could
>>discuss dropping altogether from further consideration]. There are
>>three reasons for this recommendation:
>> a) this "function" is not currently readily modelled in the web
>>world. Returning session state to the client prevents effective
>>bookmarking/navigation.
>> b) adding this function complicates the API -- as sessionID covers
>>the session state case why worry now about supporting a new/extra model?
>>
>> c) having the portal maintain the session state vs a session
>>reference has negative performance/scalability implications. When a
>>portal is running in a load balanced environment state managed on behalf
>>of the portlet/entity must be maintained in a manner so all nodes see a
>>common/consistent view of this state. In such a world writes (the time
>>when state returned by the portlet has changed and needs to be rewritten
>>to the shared state manager) are generally expensive. Session
>>references rarely change (are good). Session state changes frequently
>>(often on every request) and is therefore bad.
>>
>> -Mike-
>>
>>----------------------------------------------------------------
>>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>
>
>
>
> ----------------------------------------------------------------
> 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