The header consisted of too many unrelated stuff and macros misuse.
Some stuff is moved into scram.hrl and type_compat.hrl.
All macros have been replaced with the corresponding function calls.
TODO: probably type_compat.hrl is not even needed anymore since
we support only Erlang >= OTP 17.5
Incoming MUC PMs aren't carbon-copied, as the MUC service usually forks
them. However, don't suppress copying of outgoing PMs, where no such
forking takes place.
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
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 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 '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}
When multiple resources have the same (highest) priority, ejabberd_sm
dispatches messages addressed to the bare JID (or to an unavailable
resource) to each of these resources. Such messages are now marked with
an 'sm_copy' flag for all but one of the resources. This makes it
easier for other modules to identify those duplicates.
Resolves#1356.
Carbon copies of private MUC message are generally not desired,
especially not when multiple clients joined the room with the same nick.
In this case, the MUC service usually sends PMs to all joined resources
anyway, so carbon-copying those PMs would create duplicates.
Don't carbon-copy messages of type "normal" that don't have a body
element as an immediate subtag. Those messages are usually generated by
clients or servers (as opposed to messages written by humans). This
includes MAM messages, for example.
Before generating a carbon copy for a resource, make sure it's actually
available. This handles the case where, for some reason, the
'unset_presence_hook' wasn't called during logout of a resource. Carbon
copies sent to that resource would otherwise be re-routed to another
resource (which might've received a copy of that message already).
When multiple resources have the same (highest) priority, the session
manager routes messages sent to their bare JID to each of these
resources. When another resource has a lower priority but receives
carbon copies, make sure it won't receive multiple copies of such
messages.
An earlier version of XEP-0280 specified the <received/> and <sent/>
tags to be siblings of the <forwarded/> element, whereas the current
version mandates them to be parents of <forwarded/>. The mod_carboncopy
module supports both variants. However, the check that makes sure
clients won't receive a copy of the messages they sent didn't work for
the old-style schema. This is now fixed.
Log one instead of three [info] messages when XEP-0280 (Message Carbons)
support is enabled or disabled successfully. On failure, log an
additional [warning].
