That's quite a lot of new code, even for me, especially in an environment that I'm still a little unsure of. But once I got rolling it all sort of came back. (a nice trick since most of this stuff doesn't get much more cutting edge - but there's a distinct retro about many parts of the App Engine.)
It's been a good day. I have a prototype. Or perhaps I should put that in air quotes, as in "prototype", because I'm not sure it's advanced enough to deserve the appellation. I'm still driving most of it's features from the browser's command line, and most people don't even know that their browser has a command line.
There are moments when you realize that, against all the odds, it's really going to work. Today had some of those, as the first messages were serialized, queued, and resent by the daemons. That actually turned out to be the easy part. The hard part (as always) is writing the command interface, because you have to connect two worlds in a meaningful way.
In this case, the internal worlds of the web server environment (Java servlets in the GAE) and the web browser, which means JavaScript. Despite the shared name the two languages are incredibly different, and so I've been using a third language - JSON - to bridge the two.
On the server side, data is stored within Java Data Objects (JDO's) by a Persistence Manager. To say this is not your average SQL relational database is an understatement. I believe it's technically an Object Oriented Database, although it probably breaks that category in significant ways too.
The data in these Java objects is ultimately used by Javascript executing in the browser, so our modern 'layer stack' (if you want to brush off your OSI) goes like this:
- JavaScript Code
- Interpreter
- Browser
- HTTP / AJAX / JSON
- App Engine
- Java Virtual Machine
- Java Code
As a programmer, I have to accept that I have absolutely no control over the middle five layers. So I've been doing what I always do in this situation: see how wide a communications channel I can open up between the two ends that I do control.
That means AJAX, which is just JavaScript making HTTP calls back to it's originating web server using the same protocols as form submissions. Nearly every browser has now supported this for years. And as much as I like XML, parser encoding incompatibility is constantly killing umlauts and other special characters. JSON is the essence of XML without the namespace complications. It's so simple that practically every language has a parser.
Let's say you have lots of bits of data on your server, and you're using AJAX not only to retrieve it, but to update all those little checkboxes and filenames and option settings. That's when you discover most browsers limit the number of simultaneous AJAX connection to as little as 2-4 connection. How many exactly? It depends on the browser.
Each ajax call can take a few seconds. So a flurry of clicking can cause a few minutes worth of ajax calls before the system properly responds again. Not counting all the widgets which want to update regularly. Not great.
The solution is to write a 'multiplexer' which takes over the precious communications channel resources (the low number of simultaneous AJAX connections) and shares it among the many needy clients in a way that improves life for everyone. It can send all pending requests in a single batch, and get all the responses in one go. In theory only one request has to be in flight at any one time.
I've written a concept system before, but that was to connect JavaScript to PHP / mySQL. But GAE Java is a totally different environment, so I started again from scratch. Mostly I'm exploring how App Engine does it's thing.
Which pretty much explains where the thousand lines of code came from. My multiplexer is working. I can now query and update data inside the GAE DataStore by typing commands into my browser's JavaScript debugger console. Commands like:
DATACACHE.write({
type: 'option',
keys: 13,
data: { option_value: 'testing', option_desc: 'Option Description' }
});
or
DATACACHE.read({
type: 'message',
keys: 22,
call: function(x) {
_debug(['write option',x]);
}
});
It's all quite basic, but for the moment that's exactly what I need. Basic access to a handful of configuration records. Now I just have to invent some pretty buttons and HTML controls to issue the commands instead.
No comments:
Post a Comment