Hi David, On Wed, Jun 5, 2013 at 1:28 AM, David Hagan <[email protected]> wrote:
> How do I correctly overwrite the MUC behaviour? Essentially, I'm adding a > custom module to my embedded vysper server in my project, using: > > XMPPServer.addModule > > However, my custom module is a modified MUC (XEP_0045) behaviour module. > Do I need to disable the default MUC handling module? yes. > My Module has the > same name (as returned by getName) and the same version (as returned by > getVersion) as the matching default MUC extension for the version of vysper > that I'm running. > ok, what does it do beyond what the built-in MUC does? Some of it's functionality can be replaced (and more should be depending on user needs), especially when you consider persistence etc. In general, MUC is a XMPP standard, and altering it's behavior in a non-conformant way can lead to problems. However, we are of course interested in incorporating improvements and bugfixes into the Vysper codebase. > Essentially, I'm asking two questions: > > Will my custom module be involved in MUC messages, given that the default > module is presumably still in place? > No. The MUC module is also a 'component', running on it's own logical subdomain and receiving all stanzas targeted to this domain. In general this statement is not true for module, where a module registers additional 'handlers' which receive all stanzas targeted to a specific XMPP namespace. > Will the default module be involved in MUC messages, given that my module > has the same name and version? > Name and version should have no impact here. You can have two MUC modules side by side when you configure them under different subdomains. Bernd
