xdocs/proposals/browser-bound-app-context.xml - turbine-core - Git at Google

 <?xml version="1.0"?>
 <!--
 /*
  * Copyright 2001-2004 The Apache Software Foundation.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
  * You may obtain a copy of the License at
  *
  *      http://www.apache.org/licenses/LICENSE-2.0
  *
  * Unless required by applicable law or agreed to in writing, software
  * distributed under the License is distributed on an "AS IS" BASIS,
  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
  -->

 <document>

   <properties>
     <title>Application Service Proposal</title>
   </properties>

 <body>

 <section name="Browser window bound application context">

 <p><b>The problem: multiple windows</b></p>
 <p>
 Suppose that you write an application that will have the ability to open
 multiple windows at once. These windows will contain views for different
 application modules. Sometimes, different windows will show the same module,
 but the data or it's presentation form will be different. It is obvious that
 each of the windows has an amount of state information associated with it. The
 HTTP protocol is by design stateless. Because statefullness is necessary for a
 multitude of applications, cookies mechanism was introduced. Usually, the
 cookies passed between the server and browser carry only an identifier of the
 session. The actual data is kept in the servers memory (or other storage device)
 Unfortunately cookies are not appropriate for managing state information
 associated with a single window. The primary way of overcoming this limitation
 is encoding information about the subset of data to be displayed and the
 presentation details (like sorting order) into the request URLs. This technique
 allows the user to maintain multiple simultaneous sessions with the same screen
 of the application in different browser windows, viewing different data sets or
 using different presentation settings. This technique might be unacceptable in
 two situations:
 </p>
 <ul>
 <li>the presentation settings should not be visible in the URL so that the user
 can not tamper with them. </li>
 <li> the amount of state information is large and/or the generated page contains
 large number of links. This would lead to generating large amounts of markup,
 decreasing application responsiveness and consuming resources.</li>
 </ul>

 <p><b>The solution: server side window context</b></p>
 <p>
 A technique similar to that applied to global session data. Window specific
 information can be stored on the server, and an token allowing to uniquely
 identify this information can be added to all URLs generated on the page.
 This way on the next request originating from a given browser window, the
 application has access to the state information associated with this window.
 </p>

 <p><b>The problem: "Open in new window"</b></p>
 <p>
 If opening of windows in a multi-windowed application is utterly under control
 of the application (the window is created using JavaScript, with context
 identifier token removed from the URL, to inform the application that it needs
 to create a new context) window contexts will work fine. In reality users will
 often create new windows using "open in new window" command, or by dragging
 URLs between windows. In each of the situations mentioned above, multiple
 windows displaying the same URL (and thus, by definition the same collection
 of cookies will appear. These windows are indistinguishable to the application,
 but it is undesirable that these windows share the window context. That would
 mean that changes to the state information performed in one window would affect
 all future requests to the other windows in the group.
 </p>

 <p><b>The solution: session context tree</b></p>
 <p>
 To effectively detect opening of windows, the token identifying a session
 context must be different for every request. Please recall the example of a few
 windows opened "open in new window" command. All of them share the URL, and the
 context identifying token contained in it. This means that they can access the
 state information that was valid during the previous request. The data subset
 displayed and the presentation settings used in all of the windows is the same.
 But because there are multiple windows now, the session context must split. New
 contexts must be created, inheriting the contents of the parent (previous)
 context, an tokens identifying these newly generated context must be included
 in all URLs generated on the associated pages.
 </p>


 <p><b>The problem: the "back" button</b></p>
 <p>
 While reading the previous paragraph, you may have an impression that it is
 possible to perform educated guesses about context branching points and store
 only as many contexts as there are windows simultaneously open. But when you
 consider the situation when user uses "back" and "forward" buttons to navigate
 the application, you'll find out that ALL of the contexts must be remembered
 by the server. The state information associated with each request may be used
 multiple times in the future. An LRU garbage collection scheme could be
 performed on the context objects (only a fixed number of most recently accessed
 context would be remembered) to conserve server's memory. Unfortunately, this
 could easily lead to undesirable application operation. Imagine an application
 with two windows open.  An user performs an operation in the window A, then
 switches to window B an performs so many operations in it that the context of
 the window A is discarded. Then, performing an operation in the window A may
 yield unexpected results because the state information was lost.
 </p>

 <p><b>Explicit vs Implicit cloning.</b></p>

 <p>
 All of the the session contexts have to be replicated per every hit to the
 application. Memory consumption seems like an important factor to consider
 here. I had an idea of reducing it a bit, by requiring the programmer to
 explicitly copy the data from the previous context to the current context
 that are important. This is makes using session contexts tedious, but
 avoids cloning unused data over and over, when the user moves from one
 screen to another (which will obviously need different state information).
 This has the following downside - when the user uses a link to go back
 to a screen that he visited earlier, the state information will be lost,
 because the other screen didn't clone it (because it had no idea about them).
 The presentation details will be reset to normal. On the other hand, if
 the user pressed the "back" button multiple times to go back to that screen,
 the presentation details would be remembered (the URLs contain valid
 context identifier tokens). The conclusion is, that cloning all of the
 stuff contained in the context gives a better user experience. Memory is
 cheap these days, right? Oh, don't worry that those context have to stay
 in memory forever. They should be bound to a global (cookie style) session
 and discarded when the global session times out.
 </p>

 <p><b>A sketch of implementation</b></p>

 <p>
 <ul>
     <li>
         SessionContext interface similar to that of ServletSession
     </li>
     <li>
         getGlobalContext() and getLocalContext() methods in RunData
     </li>
     <li>
         a wrapper object containing a global context and multiple
         local context keyed by id, to be stored in the HTTP session
     </li>
     <li>
         context id tokens automatically picked up (after ParameterParser
         runs) and the context extracted/cloned/created as needed using
         the wrapper object from the session, and appropriate contexts
         made available through RunData
     </li>
     <li>
         context id added to the url by the DynamicURI et al
     </li>
 </ul>
 </p>

 </section>

 </body>
 </document>
	<?xml version="1.0"?>
	<!--
	/*
	* Copyright 2001-2004 The Apache Software Foundation.
	*
	* Licensed under the Apache License, Version 2.0 (the "License");
	* you may not use this file except in compliance with the License.
	* You may obtain a copy of the License at
	*
	* http://www.apache.org/licenses/LICENSE-2.0
	*
	* Unless required by applicable law or agreed to in writing, software
	* distributed under the License is distributed on an "AS IS" BASIS,
	* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
	* See the License for the specific language governing permissions and
	* limitations under the License.
	*/
	-->

	<document>

	<properties>
	<title>Application Service Proposal</title>
	</properties>

	<body>

	<section name="Browser window bound application context">

	<p><b>The problem: multiple windows</b></p>
	<p>
	Suppose that you write an application that will have the ability to open
	multiple windows at once. These windows will contain views for different
	application modules. Sometimes, different windows will show the same module,
	but the data or it's presentation form will be different. It is obvious that
	each of the windows has an amount of state information associated with it. The
	HTTP protocol is by design stateless. Because statefullness is necessary for a
	multitude of applications, cookies mechanism was introduced. Usually, the
	cookies passed between the server and browser carry only an identifier of the
	session. The actual data is kept in the servers memory (or other storage device)
	Unfortunately cookies are not appropriate for managing state information
	associated with a single window. The primary way of overcoming this limitation
	is encoding information about the subset of data to be displayed and the
	presentation details (like sorting order) into the request URLs. This technique
	allows the user to maintain multiple simultaneous sessions with the same screen
	of the application in different browser windows, viewing different data sets or
	using different presentation settings. This technique might be unacceptable in
	two situations:
	</p>
	<ul>
	<li>the presentation settings should not be visible in the URL so that the user
	can not tamper with them. </li>
	<li> the amount of state information is large and/or the generated page contains
	large number of links. This would lead to generating large amounts of markup,
	decreasing application responsiveness and consuming resources.</li>
	</ul>

	<p><b>The solution: server side window context</b></p>
	<p>
	A technique similar to that applied to global session data. Window specific
	information can be stored on the server, and an token allowing to uniquely
	identify this information can be added to all URLs generated on the page.
	This way on the next request originating from a given browser window, the
	application has access to the state information associated with this window.
	</p>

	<p><b>The problem: "Open in new window"</b></p>
	<p>
	If opening of windows in a multi-windowed application is utterly under control
	of the application (the window is created using JavaScript, with context
	identifier token removed from the URL, to inform the application that it needs
	to create a new context) window contexts will work fine. In reality users will
	often create new windows using "open in new window" command, or by dragging
	URLs between windows. In each of the situations mentioned above, multiple
	windows displaying the same URL (and thus, by definition the same collection
	of cookies will appear. These windows are indistinguishable to the application,
	but it is undesirable that these windows share the window context. That would
	mean that changes to the state information performed in one window would affect
	all future requests to the other windows in the group.
	</p>

	<p><b>The solution: session context tree</b></p>
	<p>
	To effectively detect opening of windows, the token identifying a session
	context must be different for every request. Please recall the example of a few
	windows opened "open in new window" command. All of them share the URL, and the
	context identifying token contained in it. This means that they can access the
	state information that was valid during the previous request. The data subset
	displayed and the presentation settings used in all of the windows is the same.
	But because there are multiple windows now, the session context must split. New
	contexts must be created, inheriting the contents of the parent (previous)
	context, an tokens identifying these newly generated context must be included
	in all URLs generated on the associated pages.
	</p>


	<p><b>The problem: the "back" button</b></p>
	<p>
	While reading the previous paragraph, you may have an impression that it is
	possible to perform educated guesses about context branching points and store
	only as many contexts as there are windows simultaneously open. But when you
	consider the situation when user uses "back" and "forward" buttons to navigate
	the application, you'll find out that ALL of the contexts must be remembered
	by the server. The state information associated with each request may be used
	multiple times in the future. An LRU garbage collection scheme could be
	performed on the context objects (only a fixed number of most recently accessed
	context would be remembered) to conserve server's memory. Unfortunately, this
	could easily lead to undesirable application operation. Imagine an application
	with two windows open. An user performs an operation in the window A, then
	switches to window B an performs so many operations in it that the context of
	the window A is discarded. Then, performing an operation in the window A may
	yield unexpected results because the state information was lost.
	</p>

	<p><b>Explicit vs Implicit cloning.</b></p>

	<p>
	All of the the session contexts have to be replicated per every hit to the
	application. Memory consumption seems like an important factor to consider
	here. I had an idea of reducing it a bit, by requiring the programmer to
	explicitly copy the data from the previous context to the current context
	that are important. This is makes using session contexts tedious, but
	avoids cloning unused data over and over, when the user moves from one
	screen to another (which will obviously need different state information).
	This has the following downside - when the user uses a link to go back
	to a screen that he visited earlier, the state information will be lost,
	because the other screen didn't clone it (because it had no idea about them).
	The presentation details will be reset to normal. On the other hand, if
	the user pressed the "back" button multiple times to go back to that screen,
	the presentation details would be remembered (the URLs contain valid
	context identifier tokens). The conclusion is, that cloning all of the
	stuff contained in the context gives a better user experience. Memory is
	cheap these days, right? Oh, don't worry that those context have to stay
	in memory forever. They should be bound to a global (cookie style) session
	and discarded when the global session times out.
	</p>

	<p><b>A sketch of implementation</b></p>

	<p>
	<ul>
	<li>
	SessionContext interface similar to that of ServletSession
	</li>
	<li>
	getGlobalContext() and getLocalContext() methods in RunData
	</li>
	<li>
	a wrapper object containing a global context and multiple
	local context keyed by id, to be stored in the HTTP session
	</li>
	<li>
	context id tokens automatically picked up (after ParameterParser
	runs) and the context extracted/cloned/created as needed using
	the wrapper object from the session, and appropriate contexts
	made available through RunData
	</li>
	<li>
	context id added to the url by the DynamicURI et al
	</li>
	</ul>
	</p>

	</section>

	</body>
	</document>