On Thu, Jun 6, 2013 at 12:37 AM, David Hagan <[email protected]> wrote:
> 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. For a project I did I also used MUC. For every room, upon creation, I added a special system occupant (with a matching client session on the target server), which relayed all messages in all rooms to the target service. This way, I didn't need to replace the standard MUC behavior. > 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. > > 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? > No, by invokong new XMPPServer, you are building your own ServerMain, and can add or leave out all the modules you want. > 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? > Yep. > > 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]) >
