[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsia][wsrp-interfaces] Refactoring the data objects
That is exactly Yossi's point of view. My point of view is different.
Looking at a web application, one can see that it stores is data in two
places - the URL, and the session. Even stateful applications that in theory
can save there information only in the session sometimes use the URL. The
reason is bookmarking.
In essence you are right that the producer can store both types of data in
one place, except that if the Producer wants the same distinction defined
above - it wants different data stored by the consumer in different places.
This is a hint by the producer - "Please store the markupParams data in the
URL, and please store the sessionID in your session. If you do this, and
the user will bookmark your pages, then the bookmark will also bring me to
the correct page. You can store everything in the session, but then you lose
the bookmarkability".
Yossi agrees with me on this point, but says that portals don't care about
this because portals cannot store all the portlets' markupParams in their
URL (the 1K limitation of URL-s). I _can_ argue against that, but WSIA
_does_ need this kind of capability.
-----Original Message-----
From: Carsten Leue [mailto:cleue@de.ibm.com]
Sent: Thu, July 18, 2002 14:50
To: Tamari, Yossi
Cc: 'wsia@lists.oasis-open.org'; 'wsrp-interfaces@lists.oasis-open.org'
Subject: RE: [wsia][wsrp-interfaces] Refactoring the data objects
Maybe I am missing something in the discussion. But I do not see either a
conceptual problem why the session ID should not just be one of the markup
parameters.
From my understanding the markup parameters describe the portion of the
entities transient state that is kept on the consumer whereas the sessionID
refers to state that is kept on the producer. So the sessionID itself is
just part of the transient state kept on the consumer, so part of the
markup parameters. Why distinguishing both? For me that would make a
general concept too fragmented.
Let's discuss this in today's call.
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory Böblingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+---------------------------->
| | "Tamari, Yossi" |
| | <yossi.tamari@sap|
| | .com> |
| | |
| | 07/18/2002 11:27 |
| | AM |
|---------+---------------------------->
>---------------------------------------------------------------------------
------------------------------------------------------------------|
|
|
| To: "'wsrp-interfaces@lists.oasis-open.org'"
<wsrp-interfaces@lists.oasis-open.org>, "'wsia@lists.oasis-open.org'"
|
| <wsia@lists.oasis-open.org>
|
| cc:
|
| Subject: RE: [wsia][wsrp-interfaces] Refactoring the data objects
|
|
|
|
|
>---------------------------------------------------------------------------
------------------------------------------------------------------|
Once again Gil,
Bookmarking a portal page, with the state of only one portlet, but without
the state of other portlets (perhaps from the same produce), and without
the session that linked to that portlet, seems like a broken feature to me.
Therefore I argue that it should not be a use case in WSRP. Therefore I
claim that there is no WSRP use case for differentiating between the two.
Therefore THERE IS NO CONCEPTUAL DIFFERENCE as far as WSRP goes. This leads
us back to a deferent discussion of how we deal with WSRP/WSIA specific
concepts.
I believe I also answered Alejandro why there is no conceptual difference.
I suggest I will pick this topic up tonight in the WSRP interfaces conf
call, and see what other portal vendors have to say.
Yossi.
-----Original Message-----
From: Gil Tayar [mailto:Gil.Tayar@webcollage.com]
Sent: Thursday, July 18, 2002 11:58 AM
To: 'wsrp-interfaces@lists.oasis-open.org'; 'wsia@lists.oasis-open.org'
Subject: RE: [wsia][wsrp-interfaces] Refactoring the data objects
Nothing to do with the "leaking out of the portal" discussion. I am talking
about a link from one _portlet_ page to another _portlet_ page. In this
case, if the user bookmarks this portlet page (which, yes, is in a portal
page), it would assume that opening the bookmark would lead him to the
second portlet page (again, inside the portal page). This would only work
if
the portal stores the portlet's markupParams in its URL.
Yossi - I do not see how dividing two opaque parameters break the Portal
framework. The portal can _always_ put them both in the session (and lose
bookmarkability, but that's OK for the portal).
If we step back a moment, we began with a discussion of whether there is a
_conceptual_ difference between markupParams and sessionID, and I hope
Alejandro I demonstrated that there is a conceptual difference (each of us
with our own arguments). If you are saying that this conceptual difference
does not matter to portals, that's a good discussion to have, but do you
agree about the _conceptual_ difference?
Cheers,
Gil
-----Original Message-----
From: Tamari, Yossi [mailto:yossi.tamari@sap.com]
Sent: Thu, July 18, 2002 11:49
To: wsrp-interfaces@lists.oasis-open.org; wsia@lists.oasis-open.org
Subject: RE: [wsia][wsrp-interfaces] Refactoring the data objects
This relates to another discussion we had, about redirecting outside of the
portal. I am not sure I agree with this concept. Do you mean a link to
another page in the portal, or to an outside web page? A link to an outside
page would not be an action, since it should not go through the portal. A
link to another Portal page does not really seem to be supported in our
interface (it is a more complicated issue, and I really don't want to get
into this right now).
If you mean another page within the portlet, that can not be bookmarked,
since the portlet does not have a life of its own, this is an action URL,
that goes into the portal.
What I am actually saying is that the concepts you are thinking of seem to
be breaking the Portal framework, which is a very good reason not to put
them in WSRP, even if they are needed for WSIA, and for some theoretical
portal.
Yossi.
-----Original Message-----
From: Gil Tayar [mailto:Gil.Tayar@webcollage.com]
Sent: Thursday, July 18, 2002 11:29 AM
To: wsrp-interfaces@lists.oasis-open.org; wsia@lists.oasis-open.org
Subject: RE: [wsia][wsrp-interfaces] Refactoring the data objects
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>
----------------------------------------------------------------
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>
----------------------------------------------------------------
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