amethystwss/amethyst

The Amethyst WebSocket Server, a complete, specification compliant WebSocket server implementation.

amethyst's Issues

Move all core directives to separate file

Right now, all core module directives are hardcoded in the config_parser src file. This is a problem, since it means we have to search through a massive file to find something miniscule within core.

We should migrate all that we can into a separate and dedicated file.

Note that we absolutely cannot move certain methods, such as LoadModule. However, if we are willing to copy some code from it to initialize the core module, we can mover everything.

Get an idea for module event dispatching

Before we/I get to far into the fun+misery of developing a dependency-free web server, we should probably figure out which events to use for modules and when they occur.

For example, should we have an event the fires when a TCP connection is established? If so, what should it be called.

To close this thread, we need to have a complete list of events that we should handle.

Use module's home object for this keyword

Right now, when an event is dispatched, the methods placed inside the store make a call to the apply member of each function.

apply takes two arguments, the object to use for this, and the arguments to give the function, and right now, we set the this object to null.

This should probably be fixed to be the module's main exports object is the this object, or, at the very least, the events object inside of it.

Linux distribution discrepancy

To my knowledge, all POSIX compliant operating systems, including the Linux kernel, use the Filesystem Hierarchy Standard, support the same signals (for the most part), etc. If this is meant to be built for Ubuntu, which is POSIX compliant, shouldn't we just expand that range of support to all POSIX compliant systems (without major discrepancies in things like filesystems)? To my knowledge, there isn't anything within Node.js that we will need to depend on that is specific to Ubuntu/Debian-like systems, given that we are dependency free.

Honestly, since this project is super young, we shouldn't have to worry about too much disruption, and right now, all it takes is removing an else statement in the code, so I'm going to mark this as unimportant.

Make module names determined by the module

As of the writing of this issue, the names of modules are determined by the user, via a LoadModule argument.

If backend code within other modules, or even itself within the global scope, needs to grab data from another module, if it is there, there needs to be a standardized module name for each module, determined by the developer of the module.

[MODULES] Configure the `config` object that is passed

Some methods within a module, directives, blocks, or events, require access to other module's configuration variables. The way Amethyst currently behaves is that it whitelists a couple of core events and directives, blocking any other modules from accessing everything. For blocks, this isn't an issue, since blocks have to get access to the entire config object if they are supposed to conditionally perform the contents inside, which may be from other modules.

The default should be the module's own configuration object, but it should be an option that the module developer can set. Maybe set each directive entry inside directives to be either a plain function (configuration object is the local module's), or an object with options, one of which being the function to execute, say callback.