In the past two blog posts we looked at the possibility of removing more unused folders from the final run time install location, and then we also looked into moving the server side frameworks source into the src folder. For the first possibility, we were able to find more unused content and remove it from the repository. For prospect of moving the framework source, we were unable to successfully move the files without causing errors, and weren’t given many clues as to what the issue is.

With that, it seems like the next steps for cleaning up Jaxer are to try and get a set of tests to run, and to start to analyze all of the files that make up the server-side framework so we can start taking notes of what they are, when they are used, and if they can be removed or updated or not.

Appender.js
App.js
BinarySocket.js
Both.js
CacheManager.js
CallbackManager.js
Certificate.js
ClientError.js
Container.js
Cookie.js
CoreAppender.js
CoreEvents.js
CRC32.js
Crypto.js
DateTime.js
DB.js
DB_MySQL.js
DBPersistor.js
DB_SQLite.js
Dir.js
DOM.js
Exception.js
Extend.js
FileAppender.js
File.js
FunctionInfo.js
HandleCallback.js
HandlePage.js
HandleService.js
Includer.js
InitHead.js
jslib_namespace_import.js
Level.js
LogInit.js
Log.js
Math.js
ModuleLogger.js
MultiHash.js
NewElement.js
Overrides.js
ParseComplete.js
ParseStart.js
Process.js
RequestComplete.js
Request.js
RequestStart.js
Response.js
ResultSet.js
RunatConstants.js
Sandbox.js
ScriptInfo.js
ScriptProcessor.js
Serialization.js
ServerStart.js
SessionManager.js
SMTP.js
Socket.js
Stopwatch.js
String.js
System.js
TextParser.js
Thread.js
Url.js
Utilities.js
Web.js
XHR.js

Above is the full list of the server side framework, and it’s about as long as I might expect, but longer than I could hope for. There are about 66 files, and the file names do a decent job of describing the functionality contained within, but don’t do a very good job of grouping files into similar name spaces.

For instance we have DB.js and it looks like most of the database related files are grouped around the “DB” related files, but then we also have “ResultSet.js” that defines the rules for a given set of results.

We need to think of an approach for trying to create a strategy for sorting and documenting and testing each one of these modules. Trying to find the low hanging fruit for modules that seem like they are easy to remove and looking for where they are referenced seems like an option. Though beyond that we’re going to need a way to categorize and group modules that focus on certain aspects of implementation.

For low hanging fruit, we have a few options: HandleService.js, Both.js, XHR.js, Sandbox.js and ClientError.js seem like tempting options as we don’t need services or client-side code on the server. But even if we remove those five files, we still have roughly sixty server-side files to sort and approach so need we’d need some kind of classification.

Logging
Appender.js
LogInit.js
Log.js
ModuleLogger.js
CoreAppender.js

Core
App.js
ServerStart.js
Process.js
System.js
jslib_namespace_import.js
RunatConstants.js

Sockets
BinarySocket.js
Socket.js

Cookies
CacheManager.js
Cookie.js
SessionManager.js

Callbacks
CallbackManager.js
RequestComplete.js
Request.js
RequestStart.js
Response.js
FunctionInfo.js
HandleCallback.js
HandlePage.js
ScriptInfo.js
ScriptProcessor.js
ParseComplete.js
ParseStart.js
Includer.js
TextParser.js
NewElement.js
DOM.js

Crypto
CRC32.js
Crypto.js
Certificate.js
MultiHash.js

Files
FileAppender.js
File.js
Dir.js

Utilities
DateTime.js
Exception.js
Extend.js
Math.js
Serialization.js
SMTP.js
Stopwatch.js
String.js
Thread.js
Url.js
Utilities.js
Web.js

Database
DB.js
DB_MySQL.js
DBPersistor.js
DB_SQLite.js
ResultSet.js

The categories are pretty rough as I tried to pull out what I could sepate out quickly. The Log category would probably be a subset of the Files category as logging would need an interface for accessing the file system to be able to work. Core is poorly named and I generally grouped it based on which files are run on start up to define how the Jaxer process functions.

The Callbacks category is a very broad category as it covers from when a page is first requested when all of the server-side functions are parsed and stored in database, and then callbacks are created on the client. To when the ajax requests from the client are later called to access those functions later. This group likely depends on Files, Database and Cookies.

The rest of the groups, Files, Cookies, Database Utilities and Sockets, should be pretty self explanatory. It comes down to making sure that all of the files are grouped correctly, and any dependencies are mapped out.

Even after making the categories we still have five files that are left over: Container.js, CoreEvents.js, InitHead.js, Level.js and Overrides.js. Which would be a pretty big benefit to the original five low hanging fruit. Removing five files would be a small dent, but getting the total number of closer to fifty would make tackling the rest of the files easily.

Before we get into sorting out the server side the framework files. We also need an approach for testing. Right now we’re passed the point where we need to build the environment over and over again from scratch. Mostly we need a test suite to find out what’s working and not working so we know when we break something. We also need a way to restore the server-side framework to the last known working configuration. Very tempted to take a Dark Souls approach, set up a lot of servers, and then see how much server-side code I can rewrite until Jaxer stops working and then move on to the next one.