OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


Is this a question that needs to be in the base interface? Can
extensibility  solve this?

Ciao,
Rex

At 3:24 PM +0300 7/18/02, Gil Tayar wrote:
>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>
>
>----------------------------------------------------------------
>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