Jeff's Blog

Three things occur at once when the words "I think" are uttered at the beginning of a postulation. First 50% of ears close completely, 25% close a somewhat, and 25% remain at their usual condition of indifference.

Before we get there, here are some things I'd like to cover. First let's grab context from my last post. In this post I want to cover only the basic ideas that I think I can pull from the bank/balance book model, and then using those ideas, put forth a proposal to solve my concurrency problem.

1. Why asynchronous Web is not the same old, same old.
2. What I mean when I say concurrency problem.

First and foremost let's cover why I think asynchronous web applications differ from the Dumb Terminal/Main Frame world of interoperation. I am always amazed when I see what was accomplished in the pre 8086 in the computing world. I have tremendous admiration and awe for the programmers, and hardware engineers the evolved the Coding theory that allowed distributed computing to occur. To be able to gate, processes, and return input from numerous sources, and do so with incredible data integrity is something that is far beyond both my technical and creative skill levels.

There is a tremendous amount of theory and design that can be applied directly from the work of these geniuses into the problems faced by asynchronous web applications. In fact, the work on the currently "it" brain teaser "The Hat Puzzle¹" is purportedly furthering the collective understanding of operating in an networked environment where the state of all known members cannot ever fully be known.

The wrinkle in the fabric that is being ironed over by those much smarter than me is the ability to process data at both the client and the server. This presents a new set of problems, and as such will need a new batch of ready-to-shoot patterns upon which business application developers can rely. "The Hat Puzzle¹" actually does a very good job of illustrating the issues, in that at a very fundamental part of the puzzle relies on previously agreed upon strategies for interpreting state without communicating.

Asynchronous web applications have to solve both the problems of safely and reliably exchanging data with a server and the issue of resolving state conflicts in a manner that does not require constant communication.

Secondly for the purposes of simplicity, I am only considering the Single Data Editor, single data set world. The full scope of concurrency issue would require multiple treatises, and are not necessarily relevant to the problem I am trying to solve. When I am done with this blog series, I hope to have addressed only the issues related to having an asynchronous web application, with no submit or save button that modifies data state on the client and sends notifications back to the server.

Now, just what does a bank balance book mean to a bank? Here's what I think I know. (By no means is this meant to be a complete list of rules governing the bank/balance book relationship)

1. The bank has the actual state of the account balance
2. The balance book has the proposed state of the account balance
3. The proposed state of the balance book is derived by manually recording transactions.
4. The balance book's proposed state of the account balance must occasionally be synchronized with the banks actual state, in order to correct for any errors in math, or recording. If all goes well this should happen very rarely, but the facility to perform synchronization must exist.
5. When the account holder is performing actions, such as writing a check, the account holder (client) must rely on the state of the account balance as expressed by the balance book. This prevents, or reduces the likelihood that the account holder will enter an undesired state such as overdrafted.
6. Over time as the account holder becomes more accustomed to the practice of properly recording transactions in the balance book, the reliability of the proposed state of the account balance will increase

There, that seems like a few valid interpretations of the arcane model of checkbook based banking. So what then, how is this going to help me solve the problem of data synchronicity in the web world? It won't at least not directly, but let's look at these statements and see how they might or might not translate into useful building blocks for a proposed solution.

Item #1: This does seem to translate very naturally to the web world. It's a very common design that relies on the Server to have the actual validated state of the data. This has long been the model, because even before the world of asynchronous requests, there was always the possibility that a user could close their browser before submitting data, and for an application to be okay with that it had to assume the data it had was the most current until told otherwise. This played into concepts like not opening connections, using transactions or locking records across multiple web posts.

Item #2: This too is a very natural state for the web world, and functions very fluidly with a web client that has a submit or save button to "approve" its proposed state for acceptance by the server.

Item #3: Once again, this is analogous to a user selecting a value in a drop down prior to submitting their proposed state.

Item #4: Suspiciously this too is a familiar state, when the client posts its request to the server, and receives a response, this is the "synchronization" model in action.

Item #5: Okay, now this is just too much, because here the client uses this model in the web world, by checking values against each other locally prior to submitting its proposed state

Item #6: Yep, this is true to, as people interact more with your web model, the more reliable their proposed data will be.

So obviously there's a reason I chose only rules that seem to apply nicely to the web, but contrary to what you might assume it's less to do with the notion of looking like I know what I'm doing, it's actually going to come up in a later blog post, how by not looking thoroughly at the model, that I may have just proposed myself into a corner, but we'll see how that one works out later.

Given the about I think I know a way I can use that information to come up with a potential solution to the problem at hand. What it seems like I need is a way for the client to express to the server it's current complete state, and for the server to conversely synchronize itself onto the client. I don't yet know exactly how this is going to work, but looking at the specific problem value slider control problem "12" where the arrows increment the value up and down by one, I need a way not only to tell the server that an increment action has occurred, but pass my proposed value as well. Additionally the server must tell the client what the actual state of the value is each time a change is made. When I complicate this simple problem by saying that there may be multiple values in flux on the client at any given time, I come to the conclusion that I need some terse data package which can be exchanged by the server and the client to help both ends resolve state.

I think I need JavaScript objects and a strategy for using them to synchronize the state of data especially when it is likely that the server and client's states are differing. Additionally I need rely on the data possessed by the client to restrict or allow accordingly actions by the user. Lastly I need make the user aware of potential conflicts in an intuitive manner.

I really wish I knew how to do all that, but at least for now I think I have a plan, a proposal, and some basic rules to check my progress against.

¹ The Hat Puzzle created by Todd Ebert, in its simplest form is a challenge in which 3 or more participants are each given a red or blue hat. The color of each participant's hat is determined by a coin toss. Each participant can see the other participants' hats, but cannot see their own. Participants may not communicate in any way. The participants can win a prize if no participant provides a wrong guess as to the color of their hat, and at least one participant provides a correct guess.