Handling signal events the same way as all other events makes sense and
seems safer than the signal handling just jumping around in C and
messing with Lua states.
signalfd allows handling signal events using the same method as sockets,
via file descriptors. Thus all signal dispatch can go through the same
main event loop as everything else, removing need for thread-scary
signal handling where execution would just jump to the signal handler
regardless of the state of Lua, and needing to keep track of Lua
states/threads.
This allows multiple modules to populate the form dynamically. Currently the
form is "owned" by mod_server_contact_info, which prevents other modules from
contributing to it.
A further commit will port mod_server_contact_info to use this module.
It was mainly used to determine whether to try IPv6 or IPv4 first,
following the rules for this in the RFC.
Now we always try IPv6 and IPv4 at roughly the same time, thus there no
need to carry these rules.
Given that there are recommendations floating around recommending 24
hours session lifetime, having buckets up to 10 minutes wouldn't be
useful in that case.
Would be nice if we had some way to automatically assign suitable number
series for buckets, scaled to what the configuration might be.
Having to add these in *there* places seems less than ideal.
I would also think that advertising disco#info is a bit redundant, since
it is a requirement for everything in XMPP and if it was missing you
would get an error back.
Suggested by jstein in the chat
This option label is used by XMPP clients to explain what the option does.
a) The user should know where the data is archived.
b) The user needs a statement that can be enabled/disabled by the variable. A question would have the wrong logic here.
Because it changes the type of the 'opt_origins' variable from util.set
to the internal _items table so next time an http app is added an error
"attempt to call a nil value (method 'empty')" is triggered. The value
is not used anywhere else.
Noticed when reviewing uses of the '_items' set property.
Not reported by any users, implying this setting is rarely used.
Where gethostname or tohostname returns an invalid name, e.g. containing
underscores or something, to_ascii would reject this and return nil,
which triggers an error in the dns lookup.
Reported by prova2 in the chat, for whom tohostname returned a long name
containing underscores.
Could be used to implement custom connection methods (c.f. mod_onions)
without needing to duplicate the rest of route_to_new_session().
Adds a feature to enable detection since it can be difficult to detect
support for an event otherwise.
