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

[Gil Tayar <Gil.Tayar@webcollage.com>]

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>