Jeff's Blog

 

You can never step in the same river twice - (Heraclitus).  

 

In the process of developing systems, it's often a battle to achieve a stable state.  In order for the system to evolve, changes must be introduced, and by there very introduction destabilize the system.  For all systems, even empires, there is the rise and fall cycle to which they are subject.  No part or effort of thought or will can so thoroughly isolate any one framework such that it remains impervious to the changes that broil around it.

 

Why of course even create systems, if in the end they will fail; the more well defined and rigid they are the faster they will become irrelevant.  Or perhaps it is necessary to create these erred rises, so that the detritus of their parts will fuel the further expansions of their progeny.  In either case it is the delicate balance of patrimonial care, and philosophical antipathy that must guide the efforts fortuned upon any creation.  For whole hearted, the foolish, and fraught with ire, or apathetical and without purpose, neither is worth the course or destination of their journey.

 

I think there are two big areas I need to redress before I can work out a valid solution to the issues of data integrity and the asynchronous web. 

 

First there is the issue of forced constraints.  I have proposed that for my fictional application that the standard AJAX.asp.Net method of asynchronous web interactions, base upon the UpdatePanel is insufficiently performant for my purposes.

 

 Allowing only 200ms for a full refresh of the UI following any user interaction, while a very nice to have in terms of "real-time" feel for an end user, is obviously coming at a very high cost.  One of the things I mentioned in my last post was the way Http POST works.  This is key too the functionality of the UpdatePanel.  When using the UpdatePanel, any child of that panel that can trigger a postback ends up sending the entire Form Data back to the server.  THis in essence accomplished what I think I need a JsON object for.

 

So is it really worth the effort I'm going to go through, or should I rethink my requirement for a very responsive UI.  Well here are 3 reasons why I don't think that I should change course here. 

 

1) Going back to my first post, there's the JavaScript loading order issue.  Even though in that particular case it was Okay for me to place my required JavaScript files at Page level, that's not always going to be possible, so I want to have a reliable pattern that doesn't require that dependence.

 

2) Appearance is 2/3 of performance.  If an application appears snappy then it must be, at least to the average user, so having a lots of flexibility on the client when it comes to responding to user actions is very important

 

3) Practice.  Even though the AJAX framework that Microsoft has put out really doesn't require a lot of low level understanding for the average developer, it doesn't mean it's okay just to pretend it doesn't exist.

 

For the most part, when I'm approaching problems, I do tend to try to take the simplest approach, but sometimes I'm driven to consider alternatives, and based on my experiences this is a time when I'm going off grid.  The box solution is just not what

I need, so it's up to me to find something that satisfies my needs.

 

 

Second, Conflict Resolution:  I could go back to the bank model and look at how conflicts are resolved there, but in large part, its fair to assume, that the bank will almost always win when there's a dispute, and frankly I don't know if I like that model for my fictional application.  So despite all my rambling about using existing models to approach new problems, I think in this case I'm going to strike out into new territory.

 

Here's what I do know.  The data snapshot on the server has to be the last known good copy, however, when I look at how exchanges might happen between the server and the client it becomes clear to me that the client has the best view of the data, and therefore should likely win in the event of a conflict.

 

Consider the following set of rapid client interactions

Client increment CarsCount --> Server

Client increment BikesCount --> Gets Stalled

Client increment TripsCount --> Server

Server Responds to on CarsCount --> Client

Server Responds to on TripsCount --> Client

Stalled BikesCount --> Server

 

In this scenario I see that when the TripsCount increment is delivered to the server, it should probably take the clients value for BikesCount as well that way we know the server will be current, but then what about the BikesCount post, does the Server then take the client's TripsCount Value which is now wrong?  Well hopefully not, and the way that we let the server know not to take the Client's TripsCount value is to have an incremental VersionID property on our JsON object.

 

Here's where the opening rambling of this post ties in.  Being that I'm a paranoid coder, it's my inclination to have per field version numbers, which in any scenario that I can think of is overkill.  And yet there's this urge to be super cautious about trusting any bit of data unless I can verify its pedigree.  Rationally I know a per-object VersionID is more than sufficient here, so I'll need to trust that conclusion and work with just the single VersionID.

 

 

So that get's me back where I want to be, I have a plan, and a good set of criteria against which to validate an implementation of that plan.  So next post I'm planning on pushing out some actual code, if I can remember how.