By starting with the built-in defaults, we get a nice history of
differences from those as we figure out what settings suit us
Sorted make comparisons easier.
Previously these events fired after the session had been destroyed, which
removes many of the useful properties. The ones I chose to preserve here are
the ones used by the community module mod_audit, which seems like a good
baseline.
When registration_delete_grace_period is set, accounts will be disabled for
the specified grace period before they are fully deleted.
During the grace period, accounts can be restored with the user:restore()
shell command.
The primary purpose is to prevent accidental or malicious deletion of a user's
account, which is traditionally very easy for any XMPP client to do with a
single stanza.
This is a shortcut for module:on_ready() which exposes the functionality in an
idiomatic way consistent with module.load, module.unload, etc.
module.ready runs when the module is loaded and the server has finished
starting up.
Some storage drivers will perform cleanup after the last iteration, but
if only one step is taken this might be delayed until the garbage
collector gets to it.
This should simplify adding shell commands from other modules, which will
reduce the growth of mod_admin_shell and make it easier for community modules
to expose commands too.
Previously only SQL settings and the 'path' for internal storage could
be set, and only for SQL and internal storage.
input {
type = "whatever";
config = {
whatever_foobar = "something"
}
}
With epoll(7), MAX_EVENTS controls how many events can be retrieved in one
epoll_wait call, while with poll(2) this MAX_WATCHED controls how many
sockets or other FDs can be watched at once.
Weak tables are said to have suboptimal performance, so we might as well
get replace it with an increased default LRU cache size.
Sorry about the 'and'
Otherwise requests with Connection: close would be stuck in the async
wait that starts after the handle_request() call.
Together with the new async debugging, this makes the async thread stay
in the set of waiting runners forever, where previously it would simply
be garbage collected.
Gives some access to node details which are otherwise hard to determine
if you only see the plain text summary, since it is shared based on the
pubsub#type setting (or payload xmlns).
This is purely for informational purposes, so it's possible to determine
externally whether a runner is using the default runner function (which
executes functions as work items) or a custom runner function.
