Remove the user capability to add a rule with a name of another rule that exists.

A number of packages that sequioa depends on are now old versions and have major vulnerabilities. Updating them is easy but some of the functions used in sequioa depend on are deprecated in the newer versions of the packages. Hence the code needs to be changed.

We need a front page talking about sequoia and what it does for people who view the website, so they have a better idea of what we are and what we do. In addition, if people are going to visit us, wouldn't we like for them to be able to make an account to start using sequoia and saving, importing, and downloading their proofs 😉.

So we need the following:

• A nice front page detailing who we are and what we do

• A user model

• A user account controller (creating, signing in, signing out, updating, deleting)

• A user controller to save, get, delete, and update proofs

The files used to apply rules and parse the user input and more are all in the frotnend, which allows any user to access them. Which is not necessarily bad, since it offloads the work off the server, but it is better to have them in the backend to be able to use them as an API service. This gives us the freedom to use languages other than pure javascript and the use of npm packages and other libraries if needed. In addition to making it accessible with other platforms such as mobile application, where you do not have to redo the logic of the functions used in the web version on the application required language, instead all that needs to be done is call the API and receive the results that then can be render to the user in any way needed.

Functions to be moved to the backend

• apply/apply.js

• apply/applyRule.js

• rule/addRule.js

• rule/parser_rules.js make the parser function it is own separate controller

We need to define and agree on a specific coding style to be used over the life span of this project to stay consistent.

This coding style needs to provide:

• ease of readability
• a good understanding of what the function does
• ease of adding new code
• ease of modifying code
• modularity

We need to document the functions we make in addition to the api, so it is accessible by other people to use right outside the box without needing to look at the functions code. Hence we need to make a page for that.

Adding a page to contain the rules of each calculus the user specify.

Add an interface that can visualize the proof tree while deriving sequents.

When a rule is added, it gets written to the file system of the sever which in production is very bad. Since the server will contain each user defined rule file. A better way of doing this is to generate the sml file without saving it on the system, instead running it straight from the command line to get the result.

The controllers functions only take request and response as parameters which is not ideal for chaining other functions, since they are asynchronous. For example, you want to use the output of one of the functions in another one, this wont work since the first function will pass undefined to the second function since it does not wait for the first one it to finish.

var output = parser(req,res); \\undefined
addRule (output)

The way to fix this is by adding callbacks tot he controllers as follows

//creating a rule
function parser (req, res, callback) {
	// if no callback is passed then just return the value
	if (!callback) callback = function (result) { return result; };
	
	...
	
	// after each return
	return callback(...);
}

No if we look at our previous example we can do the following:

parser(req, res, function (output) {
	addRule(output); //parsed output
}); 

Since these are systems that are made to generate proofs from derivations, and they are under constant changing, we need to rigorously test them to make sure nothing breaks after a change in the code in addition to making sure that our system output is correct. I suggest using Mocha and Chai http.