OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

[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


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).

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.

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.
    -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>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC