Looking for targets

Since I haven’t had a chance to do a lot of testing recently, I think I can go ahead and continue to look for aspects of the server-side application that can be removed or simplified. In terms of testing, I think could try using multiple Pi’s, and always have a working version on hand, so when things break I at least have something to fallback on to say, “no really it works, look”. I was thinking about maybe using KVM to create a virtual Pi for testing, but that requires setting up a new server, since I’m always paranoid about messing up the bridge-network connection and having to trouble-shoot the network so that it works again.

At the moment I’m tempted to test with a VPS and simply have the option to continually reset the instance as needed. It comes with the issue of the libmysql compiling issue as I have the arm compiled version in the repository, but honestly I’m tempted to take out the MySQL driver entirely in favor of only using MySQLite to start out with. Basically the important aspect of getting EmraJs/Jaxer working is having a simple-as-possible install working on localhost. Having only MySQLite would mean that there is a simple database implementation that only works on localhost. So surprisingly I’m tempted to start this post off with MySQL on the chopping block. But there are a few other low hanging fruits. So let’s look at them.


For the runat constants we only need run at “server”, or run at “server-proxy”. Not sure about managing the cache. For debug purposes it makes sense to not have a cache, and force a compile every request. And since I see EmraJs/Jaxer as the first prototype stage of a project to be rewritten in another language later, then maybe Cache is on the chopping block. This post is leading to a lot more blood lust than I expected.


All of XHR.js can go. The server-side http requests are actually in the Jaxer.Web namespace on the server, and that doesn’t reference the XHR object. So all of this can go. The client libraries already has ajax requests baked into it and the server doesn’t use this syntax, so it can go.


Still not even sure what the original intent of HandleServer.js was, but that means it can probably go.


I thought I got rid of Both.js, but I guess not. The functions can be copied into the Utilities.js file. And then this file can go the way of the Dodo.

Looking at the other files, it looks like they actually do something. So we might just focus on grouping files to cut down on the number of files that we need to manage. So for right now, potentially figure out how to test on a VPS, figure out how to get rid of the annoying libmysql implementation, and then get a baseline of what works and what doesn’t with the diagnostics.