Server API Goals

Since I’ve been a little hasty about jumping in and cleaning out the server-side API, I figured it would be a good idea to step back and re-evaluate my goals for the server API. For installation we had a somewhat simple task of simply removing anything that wasn’t needed to compile, and we were able to take our time and focus on one element at a time. With the server-side API, we don’t exactly have the same luxury as we don’t know how interdependent the various modules are to each other.

Framework Notes (serverStart)

Throwing the alphabetical approach out the window, there’s file that I’m pretty interested in looking at. And that file is ServerStart.js. This file get’s loaded when a new Jaxer instance is created in order to initialize the Apps that are recognized for that instance of the server. So getting familiar with this file might help with either simplifying or reducing the number of files needed to run Jaxer.

Framework Notes (apps)

While it would be nice to move the framework around get it arranged, maybe we can look into the framework itself to start getting some context of specifically what’s running and where. We have a couple of options of do we go alphabetically or do we just jump in and start looking at what’s interesting? To start out we don’t need to pick and choose because the first file App.js looks extremely interesting.

Reducing the Framework

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.

Looking into the framework folder

Last post we looked into all of the folders for config files, and we found the script that describes where the Jaxer process should look for initialization. Today we dive into the ironically described framework folder. Ironic might not be the right term as the server-side framework is indeed located in the framework folder, but the framework folder also contains the configuration files that describes on each Jaxer process is supposed to run, and then the actual framework is stashed away in the src folder.

Finding all of the Config Files

We’ve managed to get an installation of EmraJs that’s limited only Jaxer Manager, the Jaxer executable and the Mod-Jaxer Apache Module that’s able to install from a single script on a fresh install of the latest Raspbian. Which means that next we need to try and track down all of the config files, find out what they define and if possible find out what they do. Our next focus will be the Jaxer server-side framework so it should help to have a general idea of where the configuration files are and what effects they will have on starting the server-side framework.

Cutting the Repo down to size

With more testing we’ve been working on simplifying the compile and install script for Jaxer as well as the files in the repository. And we’ve able to reduce more unused lines in the setup script, which has then allowed us to remove more folders from the repository, specifically distro and tools. So we have a much more simplified base directory for the Jaxer repository.

Addressing Local File Inclusion

We have a little bit of a mystery on our hands. The development of Jaxer was pretty much discontinued after Nodejs was released. And it’s a little unclear of how much of the community continued to use the application server after Aptana was bought by Titanium Studio. And even after continually looking we generally find new mentions of the Jaxer web server other than the little amount of information we put out on the internet.

jaxer install script

Post Install Implementation

Okay, we’ve managed to get the install script to compile and install Jaxer in from a fresh Raspberry Pi install. We can get back to where I got ahead of myself and tried to over-simplify the install script too fast and too soon without testing intermediate step along the way. Lesson learned, so now it’s time to try and look and see what can be reduced, where, why and how it can be tested without compromising runtime.

Simplifying the install script

Now that we’ve managed to remove the need to compile Apache along with Jaxer, changed the configuration to use more Linux-like paths, and created a systemd script for starting and stopping the service, it means that we can now focus on getting Jaxer to install with a single script.