Since we got rid of all bottle-neck processes and we have
a connection pool for every database, the option is no longer
needed and in fact is detrimental: in practice what you get
is just a bunch of overloaded processes in the IQ handlers pool
no matter how much you increase the `iqdisc` value.
Given that there are close to zero operators understanding
the meaning of the option and, hence, not using it all,
it's not simply deprecated but completely removed.
The commit also deprecates the following functions:
- gen_iq_handler:add_iq_handler/6
- gen_iq_handler:handle/5
- gen_iq_handler:iqdisc/1
When the option is set to `true`, the module will generate
CAPTCHA challenges for incoming subscription requests. The option
also implies that option `drop` is set to `true`. Note that
the module won't generate CAPTCHA challenges for messages: they
will still be rejected if `drop` is set to `true`.
Fixes#2246
The callback is supposed to provide known options and their default
values, as long as the documentation. Passing default values into
get_mod functions is now deprecated: all defaults should be provided
by the Mod:mod_options/1 callback.
The option allows to set arbitrary text for disco#info identity name.
Previously, option 'name' was supported by mod_proxy65 and mod_http_upload
only. Now, all the following modules support this option as well:
- mod_disco
- mod_irc
- mod_muc
- mod_multicast
- mod_pubsub
- mod_vcard
Example:
```
modules:
...
mod_disco:
name: "Cool XMPP Server"
...
```
The purpose of the module is to cope with legacy and modern
XMPP clients posting avatars. It automatically converts vCard based
avatars (XEP-0153) to PEP based avatars (XEP-0084) and vice versa.
Also, the module supports convertation between avatar image formats on
the fly: this is controlled by `convert` option. For example, to
convert all avatars into PNG format, configure the module as:
mod_avatar:
convert:
default: png
In order to convert only `webp` format to `jpeg`, set the following:
mod_avatar:
convert:
webp: jpeg
Note: the module depends on mod_vcard, mod_vcard_xupdate and mod_pubsub.
Also, ejabberd should be built with --enable-graphics option.
The option can be used as a replacement of 'host' option
when several (sub)domains are needed to be registered for the module.
Note that you cannot combine both 'host' and 'hosts' in the config
because 'host' option is of a higher priority. Example:
mod_pubsub:
...
hosts:
- "pubsub1.@HOST@"
- "pubsub2.@HOST@"
Fixes#1883
The changes are very similar to those from previous commit:
* Now there is no need to pass validating function in
gen_mod:get_opt() and gen_mod:get_module_opt() functions,
because the modules' configuration keeps already validated values.
* New functions gen_mod:get_opt/2 and gen_mod:get_module_opt/3 are
introduced.
* Functions gen_mod:get_opt/4 and get_module_opt/5 are deprecated.
If the functions are still called, the "function" argument is
simply ignored.
* Validating callback Mod:listen_opt_type/1 is introduced to validate
listening options at startup.
Now that plugins directly use ejabberd_mnesia and can include their own
transform handler, we don't need pubsub_migrate anymore.
People upgrading from 2.1.1x version must upgrade to 17.01 first.
pubsub_migrate module remains to support any manual process requiring it
Now 'From' and 'To' arguments must be omitted in functions
and structures related to routing.
The commit deprecates the following functions:
ejabberd_router:route/3 in favor of ejabberd_router:route/1
ejabberd_router:route_error/4 in favor of ejabberd_router:route_error/2
ejabberd_local:route_iq/4 in favor of ejabberd_local:route_iq/2
ejabberd_local:route_iq/5 in favor of ejabberd_local:route_iq/3
The format of {route, From, To, Packet} is changed in favor of {route, Packet}
Add code necessary to support publishing options as described in
XEP-0060, #7.1.5. A node plugin that expects publishing options must
add <<"publish-options">> to the features/0 list and then handle the
publishing options handed over to the publish_item/7 call.
Signed-off-by: Christian Ulrich <christian@rechenwerk.net>