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

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

Alejandro,

I agree that the markupParams are mainly to keep the producer stateless, but
even if the producer is _stateful_, it may want to keep things in the
Consumer URL for bookmarking purposes.

It is true that the "active" portlet (the one that did its action last) is
bookmarkable. But what about the other portlets? There markupParams will be
in the Consumer URL only if the Consumer put it there. Thus, this cannot be
done implicitly by the portler but must be done with cooperation of the
Consumer - thus we need the separation between markupParams, which the
Producer "requests" the Consumer to store in its URLs, vs. SessionID which
the Producer "says" that the Consumer can store anywhere it wants.

As for storing markupParams in the Consumer URL - I agree. This solution
works for one or two portlets maximum. For more, the Consumer would have to
store them in it's session. So, yes, the distinction is more important for
WSIA scenarios than WSRP scenarios. But it is still important.

Also, I never said that the Consumer can choose not to store markupParams or
sessionID. What I said was that the Producer hints _where_ to store those
parameters (markupParams in URL, sessionID in session), but the Consumer can
choose to ignore those hints and store it wherever it wants. but to maintain
the conversation it MUST store them.

Gil

-----Original Message-----
From: Alejandro Abdelnur [mailto:alejandro.abdelnur@sun.com]
Sent: Thu, July 18, 2002 08:32
Cc: wsrp-interfaces@lists.oasis-open.org
Subject: Re: [wsia][wsrp-interfaces] Refactoring the data objects


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>



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