Hi Bernd, Thanks for explaining that. I'm getting a much clearer understanding of how I could use vysper in my application, and if you don't mind answering a follow-up question, I think I'll have a clear understanding of how to do what I'm aiming to do. First though, allow me to answer your question:
I have an application which performs various actions, some of which are analogous to the XMPP MUC featureset. It already has internal routing for that purpose, as provided by custom code. What I was hoping to do was attach an embedded vysper server, so that other xmpp clients could interact with my application. In essence, I've written a replacement MUC module, which in addition to normal MUC functions also passes messages to my application, and which provides internal endpoints for my application to pass messages back. Lastly, the replacement MUC module does not store history or provide history to new members of the MUC room, because that's handled elsewhere in my application. Essentially, I'm hoping to use vysper to provide endpoints to my existing application which xmpp clients (not normal xmpp chat clients of course, but custom clients that happen to be using xmpp libraries like smack) can connect to, and I was hoping to wire those connections to my application by means of a set of MUC Handlers. To be precise - I have a custom MUCMessageHandler and a custom MUCPresenceHandler. Is it possible for me to replace the default MUC Module's handlers with my custom handlers? If not, I also have a custom MUC module, which has those handlers already attached. Can I register my custom MUC module to the default MUC Module's subdomain, so that it also listens to the MUC messages? You mentioned that I would have to disable the default MUC module. Is there a simple way of disabling the MUC module? Is it enabled by default on the embedded XMPPServer that I deploy via the maven module "vysper-core", or can I simply choose to add my MUC module instead of it? I've seen that XMPPServer has a method "addModule", but I didn't see in the API any mention of removing modules at runtime. Thanks Bernd On 5 June 2013 22:13, Bernd Fondermann <[email protected]> wrote: > 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 > -- David Hagan ([email protected])
