This page outlines the Roadmap, of specifically where the team intends to take Jaxer. Right now the server itself is actually very robust, offering a lot of basic functionality right out of the box, and even more functionality if you dig deep enough.
Though to start out with, there's actually a lot of legacy concepts that are outdated and can be removed. Most of the client side framework is dedicated towards XML parsing and serialization. And the server contains functions for callback onload, and excessive server side rendering code.
So inititially development will be placed into scaling down Jaxer and making something more managable and easier to be used in projects. From there we will look into adding more functionality that maybe needed for current generation web projects.
I'll also take this oppertunity to explain our versioning. The first digit indicated release. The second digit indicated major releases, specifically one of the benchmarks below. And lastly the third digit is minor changes, for small fixes or changes to the source code. Once all of the benchmarks have been completed, we will roll over the number to the 2.0.0 release and continue to support from there.
Another important note to mention is that while there are no large changes to the Server Side API planned. The server may benefit via either speed or stability improvements from refacoring, but the API is not expected to under-go and large changes.
The client side API on the other hand may potentially see a few changes, and has already seen one significant change before release. The original Jaxer release used synchronous Ajax calls to default causing the main thread to freeze. This functionality has been removed entirely in the 1.1.0 release infavor of ansynchronous callbacks. All documentation on this site will refer to the Client Side API 1.1.0 or later to reflect this change.
Refactor Client Side Framework
The original client side framework has a few glaring problems. One of the most significant is that Ajax calls to the server call synchronous calls by default. And while the API does have the option to call ansynchronously, the interface for doing so is incredibly clumbsy. This has been changed to use the standard 'Nodejs' format, where arguments are provided, and the callback is the last parameter included in the function call.
Another problem is that the original client API uses unsafe eval, which can cause problems with content-security-policies. This has been changed using a potentially unconventional use of the bind function. One change that still remains, is the unsafe-inline is still required to create the client-side callbacks, but this requires server side refactoring and will be the subject of a later benchmark.
Remove Support for Windows, MacOS
Not sure if benchmarks usually involve removing support for something, but in this case it does. The original release of Jaxer was far too wide reaching with options for compiling and running on MacOS and Windows. While we can understand that there could potentially be cases where someone would want to run Jaxer on these platforms, our priority is first and formost Linux support. Plus with rubust virtualization platforms on Windows and MacOS. Not to mention the fact that Jaxer works on the Raspberry Pi, there's very little reason (if any) for us to split our resources to support unnecessary platforms.
Update XPCOM and Spider Monkey
Jaxer uses a lot of programs from the Mozilla ecosystem. Up to the point where I could be convinced it's a tweaked version of Firefox that has been altered to have server functionality. Since a lot of the libraries are the same, it means potentially that internal libraries like XPCOM and Spider Monkey can be updated with the latest or at least later versions. Also there are a lot of linked programs to GTK and X11 in the make files, that can potentially be removed since servers normally run headerless without a user interface.
Refactor Server Side Framework
This is mostly a matter of coding style, but the person who originally wrote the server side code might have had an extreme addiction to nested try and catch statements. A lot of the code of on the server can be simplified, improved for readability or at least formatted to conform to JS-Lint standards. The main reason for this is to improve understanding and documentation of the server side framework to enable extending the functionality of server side code.
Remove Studio and Proframework
More unnecessary functionality included in the original release. Aptana tried to narrow distribution to their editor with the release of Aptana Studio. References need to be removed from the repository.
The Proframework is also included in the repository. I supposed this was intended for clients who bought a 'Pro' license. This implementation is confusing and needs to be removed from the repository.
Promise Client Side Framework
Right now callbacks in the client side framework are defined by providing a callback function into the server call, that either returns an error or the value returned by the server. This functionality could potentially further be improved with the use of Promises to allow for the async, await syntax to make handling async calls easier to read.
The challenge for doing so will be to implement this change in such a way that does not break compatibility while leaving the option to be enabled as default later. Right now we're leaning towards the option to set a parameter on the client-side Jaxer object, that can be enabled to be the default on the server.
The commands for starting and stopping Jaxer are done with shell files that are stored on the server. The functionality for starting, enabling and disabling the Jaxer server as a service could be improved by writing configuration files for systemctl to able to take advantage of this tool which is now included standard on Linux.
Web Worker Client Side Framework
With the rise of popularity of multiple domain applications, Web Workers are being used to retrieve data from different domains. Jaxer already includes a function for retreiving data from different domains, by having the server proxy the request to a micro-service. The main reason for including this functionality is that along with removing the insafe-inline calls to set up proxy callbacks on the client, the potential for implementing the server calls as a web worker exists and will be looked into.
Stretch goals are goals that would be nice to have and will be pursued given the amount of support or community contributions. And maybe not be feasible for the amount of resources available. As such they are not specifically planeed for the 2.0.0 release, but will be included if they completed. Otherwise this functionality will be voted on for the 3.0.0 release.
Right now Apache needs to be compiled with Jaxer in order for Jaxer to work. This makes the installation a little clunky, as in order to use Jaxer with other server-side languages Nginx needs to be used as a reverse proxy before being sent to Jaxer. Since Jaxer communitcates with Apache over port 4327, there is the potential that Jaxer could be installed as a stand alone application able to communicate with Nginx or an existing Apache installation if configured to do so.
Linux Package Managers
As we've just started support for Jaxer, it's still a very hands on experience, requiring the user to compile from source. And the post compile configurations relagate Jaxer to the /opt directory. It would increase visibility and useability if Jaxer were to be included into the apt-get and yum repositories to be installed with a single line command.
Bcrypt Hashing Support
Since it's been over ten years since Jaxer has been in active development, the encryption and hashing algorythms are somewhat out of date. Adding support for Bcrypt would make Jaxer much more robust for handingling user logins.
One of the main advantages of refactoring the server side code will be a better understanding of how the server side API function builds on a few fundamental system calls to create more rubust functionality. One of the tests for performing this maintenance will be to try and support more types of databases than MariaDB/MySQL and SQLite. Postgress seems like a primary candidate because of its use with GIS systems and support for the JSON data type and UUID functionality.
How to Contribute
This is the basic outline for the core functionaility of the changed planned to be implemented into Jaxer. For more information on how to contibute code, translations, submit bugs reports or doman, head over to the Contribute page.