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.
- Change order of the hooks in mod_mam for sending and receiving packets. Messages are archived before a carbon copy is send to the other recourcces.
- Add archived tag and unique stanza id to the outgoing packet to have message carbons with the archive information.
- Add additional hook (in mod_mam) to strip the archive tag for outgoing packets after message carbons have been send.
XEP-0313 says: "A MUC archive MUST check that the user requesting the
archive has the right to enter it at the time of the query [...]. In
the case of open MUC rooms, the MUC archives can generally be accessed
by any users [...] who do not have an affiliation of 'outcast'".
Include the occupant JID with MUC MAM messages if the room is not
anonymous, and also when the MAM user sent the MUC message himself (not
just in the case where he is a room moderator).
Strip any pre-existing <x/> tags which have an <item/> child with a
'jid' attribute from MUC MAM messages. This way, if such a tag exists,
clients can be sure it was added by mod_mam.
If a stream management session times out for a user who appears to be
using MAM, drop any unacknowledged messages rather than resending or
bouncing them. This avoids duplicates or bogus error messages.
However, this is only done if the new mod_mam option "assume_mam_usage"
is set to 'if_enabled' or 'on_request'. In the former case, a user is
assumed to be using MAM if archiving is enabled for his account. In the
latter case, MAM usage is assumed only if archiving was explicitly
requested by the client, or if archiving was enabled by means of
mod_mam's "request_activates_archiving" option.
Sort the messages retrieved from an Mnesia archive before selecting the
subset limited by the <max/> value. This makes sure the desired subset
of messages is sent to the client.
If the client doesn't specify a maximum number of messages to retrieve
per page, set a limit of 50 messages. If the client specifies a limit
larger than 250, cap the number to 250 messages.
These limits aren't enforced for MAM v0.2 requests though, as that
version of the XEP doesn't require clients to support RSM. The newer
revisions say that "a server MAY place a reasonable limit on how many
stanzas may be pushed to a client in one request. Whether or not the
client query included a <set/> element, the server MAY simply return its
limited results, modifying the <set/> element it returns appropriately."
If an <index/> is specified in the MAM request, reject the request
rather than ignoring the desired index and returning wrong results.
XEP-0059 says that the server "MAY return a <feature-not-implemented/>
error."
Make sure the binary comparison performed when clients use message UIDs
to page through Mnesia archives yields correct results even if the
specified UIDs don't have the same number of digits as the UIDs of the
stored messages. This way, MAM will continue to work as expected after
migrating from mod_mam_mnesia to mod_mam.
The new "delete_old_mam_messages" command allows for purging all MAM
messages of the specified type older than the specified number of days.
(Currently only implemented for Mnesia archives.)
Enabling "request_activates_archiving" tells mod_mam not to store any
messages for a user until his client issued a MAM request, regardless of
mod_mam's "default" option. Once a MAM request is issued, messages are
archived as usual.
Use <stanza-id/> elements instead of <delay/> tags to check for messages
resent by the stream management code. The <stanza-id/> element is
preferable, as it is added by mod_mam itself.
As per XEP-0313 version 0.2 and newer, advertise the MAM feature in the
service discovery information for the bare account (or MUC room) JID.
Some clients check the server's discovery information instead, so we'll
continue to advertise the feature there as well.
