Re: [wsia][wsrp-interfaces] Refactoring the data objects

[Alejandro Abdelnur <alejandro.abdelnur@sun.com>]

Gil,

I can see a portlet encoding state in action/render URLs that could be 
bookmarkable. I do not argue that at all, portlets can do that today by 
adding any parameter to the action/render URLs the generate.

The markupParams are mainly to keep portlet state while keeping the the 
producer stateless. They are pushed back to the portal, so the portal is 
the one keeping the state now. It would be also possible for the portal 
to push back the markupParameters futher (to the client) by embedding 
them in all the URLs the portal generates.

 From your note I'm not sure if you are suggesting this. If so, the 
following paragraph applies.

This would be have to be done for the markupParams of all the portlets 
that are present in the portal page and, of course, use markupParams. 
Because implementation limitations (browsers, proxies, web servers) on 
the length of URLs (sometimes 255, sometimes around 2K) I do not see 
using the URL for all this stuff as a very viable scenario.

Going to your statement that the sessionID and markupParams given by the 
producer to the consumer are not necessary stored by the consumer (and 
send back on later request) by the consumer, that is a suggestion. If a 
consumer always ignores the sessionID and the markupParams, then no 
conversational state can be maintained at all.

Regards.

Alejandro.

Gil Tayar wrote:
> Alejandro (and Yossi),
> 
> I would like to resend something I sent in another thread. I think it is
> important, and concerns the fact that the separation is _not_ superficial,
> and supplies important functionality not to be had if they were both
> separated:
> 
> Let's take a normal web application, and we'll use one which _is_
> "session-stateful", i.e. has a session. In most cases, this application will
> not only store things in the session, it will also continue to store things
> in the URL. Why? Because the information in the URL is (to coin a phrase)
> "bookmarkable", i.e. the user expects that if it bookmars the page, it will
> return to it when using the bookmark. In session-based applications, this
> may happen after a "re-login", but if enough information is stored in the
> URL, it will happen. If the app had stored everything in the session, it
> would not have supported this.
> 
> To sum it up, a stateful application stores its state both in the URL and in
> the session. The URL state is usually "bookmarkable" (or "navigation")
> state, while the session state isn't.
> 
> Going back to WSIA/WSRP, the Producer must _hint_ to the Consumer what state
> is which type, and thus the separation between markupParams and sessionID.
> The Producer _expects_ the Consumer to store the markupParams in its URL and
> the sessionID in its session. This is only a suggestion, because of course
> the Consumer CAN do whatever it wants.
> 
> Maybe markupParams should thus be called "interactionParams" (or
> "interactionState") because it stores navigation/interaction state, and thus
> its difference from session would be more clear.
> 
> Gil
> 
> P.S. So, in response to your original email. 
>  > ...
>  > I still think that separating sessionID from markupParams is
>   > superficial, since consumers really need to treat them in
>   > the same way.
>  >
> 
> The consumer should _not_ treat them in the same way - the markupParams need
> to be embedded in the Consumer URL and the session ID should use cookies. Of
> course - the consumer can choose not to do so, and in a portal, will
> probably save everything in the session (because embedding all markupParams
> in the portal's URL is not feasible).
> 
> -----Original Message-----
> From: Alejandro Abdelnur [mailto:alejandro.abdelnur@sun.com]
> Sent: Thu, July 18, 2002 00:46
> Cc: wsrp-interfaces@lists.oasis-open.org
> Subject: Re: [wsia][wsrp-interfaces] Refactoring the data objects
> 
> 
> Yossi,
> 
> The sessionID somehow implies that the producer is keeping all state
> key-ed off with the sessionID.
> 
> The markupParams allows (actually it just makes it easy) to keep state
> (for the portlet entity) outside of the producer. Of course you could
> serialize all the markupParams in a blob an use that as sessionID.
> 
> I also see this separation as superficial, but I think it will make 
> things easier and manageable for vendors that want to have stateless 
> producers.
> 
> Regards.
> 
> Alejandro
> 
> Tamari, Yossi wrote:
> 
>  > ...
>  > I still think that separating sessionID from markupParams is
>   > superficial, since consumers really need to treat them in
>   > the same way.
>  >
> 
> 
> 
> ----------------------------------------------------------------
> 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>