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

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

Yossi,

A link to another page is also an "action". Not all actions are POSTS. While
it is true that some portals would not care about bookmarking this second
page, some portals would, and definitely WSIA Consumers would. It would be
bad to combine them together because _some_ portals don't care about it.
Some portals (and most WSIA consumers) _would_ care about it.

Can I infer from your summation that you agree that they should be distinct
parameters because of logical issues?

Gil

-----Original Message-----
From: Tamari, Yossi [mailto:yossi.tamari@sap.com]
Sent: Thu, July 18, 2002 11:21
To: wsrp-interfaces@lists.oasis-open.org; wsia@lists.oasis-open.org
Subject: RE: [wsia][wsrp-interfaces] Refactoring the data objects


Let me just answer this by commenting that I don't expect actions to be
"bookmarkable". This may again be an issue of portals vs. general WSIA, but
an action only has meaning in the current page state, and it can't all be
"streamed" to the URL. I think this is what you are essentially saying in
your P.S. 
This however does not mean that I don't think portals care about the refresh
case (unlike the bookmark case).

As for Alejandro's comment that sessionID is a producer's handle to its data
while markupParams is producer data stored in the consumer, I would say that
a producer's handle to its data IS a piece of producer data (a reference in
this case) stored in the consumer.

To sum, I am saying that from my point of view, this is not an interface
optimization, but a logical conclusion from the definition of markupParams
and sessionID (for WSRP at least).

	Yossi.

-----Original Message-----
From: Gil Tayar [mailto:Gil.Tayar@webcollage.com]
Sent: Thursday, July 18, 2002 7:48 AM
To: wsrp-interfaces@lists.oasis-open.org; wsia@lists.oasis-open.org
Subject: RE: [wsia][wsrp-interfaces] Refactoring the data objects


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>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>