The type of the user being created is defined at creation time. This
allows the creation of basic users.
Although the users can be created internally, they cannot yet be created
via maxadmin or the REST API.
The refactored interface is now in use. The only module that used it
directly was the CDC protocol module. This should probably be changed so
that it uses the adminusers interface instead of the users interface
directly.
The module commands can now produce JSON formatted output which is passed
to the caller. The output should conform to the JSON API as closely as
possible.
Currently, the REST API wraps all JSON produced by module commands inside
a meta-object of the following type:
{
"meta": <output of module command>
}
This allows the output to be JSON API conformant without modifying the
modules and allows incremental updates to code.
The module command self links now point to an endpoint that executes the
module command. Depending on the type of the module command, either a GET
or a POST request must be made.
The static capabilities declared in getCapabilities allows certain
capabilities to be queried before instances are created. The intended use
of this capability is to remove the need for the `is_internal_service`
function.
The authenticators should have a similar way to print diagnostic
information as filter and routers do. This allows the authenticators to
print the users in their own format.
In the future, all the diagnostic entry points should be changed so that
they return a structure that contains the information in a standard
form. This information can then be formatted in different ways by other
modules.
All modules now declare a name for the module. This is name is added as a
prefix to all messages logged by a module. The prefix should help
determine which part of the system logs a message.
The MXS_MODULDE object now contains optinal pointers for functions
to be called att process and thread startup and shutdown. Since the
functions were added to the end, strictly speaking, all structures
would not have needed to have been modified, but better to be
explicit. In a subsequent change, these will be called.
C++ does not support flexible arrays, so for the time being C++
modules are restricted to 10 parameters. Better approach is to
factor out the parameters to a separate array and then just store
a pointer to that array in MXS_MODULE.
The MODULE_INFO is now the main object which is used by modules to convey
information to the MaxScale core. The MXS_MODULE name is more apt as it
now contains the actual module definition.
The old MODULES structure was moved into load_utils.c as an internal
implementation and was renamed so that it is not confused with the new
MODULE structure.
The modules are now declared with a common macro. This allows future
additions to the module loading process while also making the loaded
symbol name a constant.
This allows modules to only expose one entry point with a consistent
signature. In the future, this could be used to implement declarations of
module parameters.
