[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