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].
As the session manager handles messages sent to unavailable resources
just like messages sent to bare JIDs, mod_carboncopy must do that, too.
That is, forward them only to those carbon-copy-enabled resources that
don't have a top priority, in order to avoid duplicates.
Use dynamic Rebar configuration
Make iconv dependency optional
Disable transient_supervisors compile option
Add hipe compilation support
Only compile ibrowse and lhttpc when needed
Make it possible to generate an OTP application release
Add --enable-debug compile option
Add --enable-all compiler option
Add --enable-tools configure option
Add --with-erlang configure option.
Add --enable-erlang-version-check configure option.
Add lager support
Improve the test suite