Hi Bernd, I agree with you about the XMPP principles there. In essence, I've been using the first option you've listed (I'm using MUC, and I'm embedding my own payloads), and in the past I've been connecting some of these clients directly to a central xmpp server, but now I'm decentralizing and federating the service with another service that has common tasks. So, I'm trying to leave my clients (who were essentially written to use MUC with custom payloads) unchanged, but I'm hoping to modify my MUC server slightly so that it shares some of its state in a very particular way with the other service I'm federating with, and accepts state from that service. I was hoping to perform all the state synchronization in-memory, within the JVM, and it seems vysper might be a perfect fit to do that. So, I've written custom handlers to do that, and I've written a custom module to load those handlers, so it sounds like we're both thinking about this the same way. My custom module extends the default MUC module - I just wanted to ensure that I wasn't running both my module and the default MUC module at the same time, because that might cause some oddities.
Thanks for pointing me in the direction of spring-config.xml. I was having trouble finding the point where the MUC module was loaded, because I couldn't see it in the code, but now I see that it's explicitly loaded in: vysper-0.7-src\server\core\src\main\java\org\apache\vysper\spring\ServerMain.java Does the configuration file spring-config.xml configure modules when starting the embedded server? It seems to me that it's not, but perhaps I'm not understanding some complexities of the . Given that I'm running this from within my other project, by invoking: new XMPPServer(domain); and then adding my endpoints, storage-providers, tls-configuration, users, and any modules I'm using, do I still need to manipulate spring-config.xml? Essentially, can I simply choose not to load the default MUC module there, and load my own custom module (which extends the default MUC module) in its place? Thanks again Bernd. You've been very helpful. On 6 June 2013 06:35, Bernd Fondermann <[email protected]> wrote: > Hi David, > > first of all Vysper is a XMPP server. XMPP specifies the basic stuff like > syntax, stanzas, routing, security etc. foremost to provide chat > functionality (roster, presence, communication), see > http://xmpp.org/xmpp-protocols/rfcs/ . > Then, there is Multi-User-Chat, which already is an optional extension to > the basic XMPProtocol. You could leave out MUC and still provide chat, this > is true for any XMPP server. There are many other extension, see > http://xmpp.org/xmpp-protocols/xmpp-extensions/ ) > > Extensions reuse the basic stanza syntax, but are differentiated using > namespaces ("xmlns" xml attributes). For MUC, these namespaces start with " > http://jabber.org/protocol/muc";. > > There are three basic approaches how to implement your own business logic: > a. use an existing XMPP core protocol or extension, and embed your own > payload within the inner elements of the stanzas. these elements would be > identified by your own namespace. > example: extension 85 (http://xmpp.org/extensions/xep-0085.html) extends > the core XMPP chat features to indicate whether a user is typing or not. > b. specifiy your own extension protocol using your own namespace (that's > what MUC or PubSub or Jabber-RPC do). > c. find an XEP which already suits your needs :-) > > If you want to build your own module from the ground, have a look at those > in > org.apache.vysper.xmpp.modules.extension > > more inline... > > On Wed, Jun 5, 2013 at 3:52 PM, David Hagan <[email protected]> wrote: > > > 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. > > > > You should either conform with the MUC extension specification, or use your > own namespace as described above. > > > > 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. > > > Good idea, and this will probably work, but consider building your own > module or extending MUC (instead of altering it). > Again, can you give a hint what kind of stuff you are building? > > > > 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? > > > > Yes, you can alter or append to the list of handlers, see > MUCModule.initialize() but this requires deep understanding of Vysper, XMPP > and MUC. > > > > 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. > > > > The configuration file spring-config.xml configures all active modules. > > Bernd > > > > 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]) > > > -- David Hagan ([email protected])
