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.
The transaction state only reflects explicitly started transactions.
Thus, by looking at the autocommit mode and the transaction state a
component can figure out whether the current statement will be committed
or not.
The transaction state must be updated after a buffer has been split
into buffer containing individual packets.
NOTE: The actual updating of the transaction state and the autocommit
mode is currently wrong, but will be updated in a subsequent change.
This tracks only what is explicitly set. That is, if autocommit
has been set true then, even if a transaction is started, autocommit
will not be set false.
That is, a user of the session autocommit and transaction states
need to be aware of their semantics. If a transaction is active,
then the state of autocommit is irrelevant.
When a MySQL SSL connection is made, the first packet from the client will
contain the SSLRequest packet. This packet is a truncated normal auth
packet and the real auth packet will be sent after SSL has been
established.
The MySQLClient protocol should read the client information for SSL
connections after SSL has been established.
When a client without SSL connected to a listener which requires SSL, the
error message always used the package sequence number 3 even if the
response was the second packet.
Also fixed debug assertions which failed when non-SSL connections were
created to SSL listeners.
- Since the capabilities are a bitmask, it is better if an unsigned
integral type is used.
- Since the function is part of an ABI, it is better if an explicit
size is used.
- 64-bits so that there also is room for independent filter
capabilities.
The client protocol module now extracts the information that is relevant
for all modules. Currently this information consists of the client
capabilities, character set, username and default database.
In a subsequent change, the includes of server/core/*.c will be
cleaned up, and if there is a common set of include files, needed
by most, then a server/core/maxscale/core.h that includes those
will be introduced.
The general purpose stuff in skygw_utils.h was moved to utils.h
and the corresponding implementation from skygw_utils.cc to utils.c.
Includes updated accordingly.
Skygw_utils.h is now only used by log_manager and by mlist, which
is only used by log_manager. Consequently, skygw_utils.h was moved
to server/maxscale.
Utils.h needs a separate overhaul.
Made the packet sequence number handling automatic so that it always uses
the correct one.
All functions now have documentation in them. Cleaned up code and added
comments to GSSAPI code.
- Headers now to be included as <maxscale/xyz.h>
- First step, no cleanup of headers has been made. Only moving
from one place to another + necessary modifications.
Moving the sending of the final OK packet of the authentication process to
the client protocol plugin makes the authentication plugins simpler.
By reading the client's sequence and incrementing that by one, the client
protocol module will always send the correct sequence byte in the final OK
packet.
The MySQLCommon library contains functions used by both the protocol and
authenticator modules. The contents of the modutil.c file could also be
moved to this file if the functions in that file are only used by modules
and not the core.