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.
It's now possible to use files as internal packet queues.
The following options are introduced:
* queue_type: the option can be set to `ram` (default) or `file`.
The option can be set per virtual host.
* queue_dir: path to the directory where queues will be allocated.
The default is 'queue' directory inside Mnesia directory.
This is a global option and cannot be set per virtual host.
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.
Use the user (or room) JID instead of the server JID for the 'by'
attribute of <stanza-id/> and <archived/> tags. That's what the
examples in XEP-0313 v0.2 and XEP-0359 v0.3.0 suggest.
XEP-0313 says: "a server SHOULD include in a user archive all of the
messages a user sends or receives of type 'normal' or 'chat' that
contain a <body> element."
The "assume_mam_usage" option now takes a boolean value. Setting it to
"true" has the same effect as "if_enabled" had before. The "on_request"
behavior is no longer offered, as it made the option (and its
documentation) overly complex.
Limit the number of messages returned for a given MAM request even if
the client didn't specify an RSM set (not just if the client specified
an RSM set without a limit).
This is still not done for MAM v0.2 requests though, as that version of
the XEP doesn't require clients to support RSM.
Evgeniy Khramtsov