Thankyou Bernd. that makes it all very clear. Thanks for all your help. ------ David Hagan ([email protected])
On 06/06/2013, at 17:33, Bernd Fondermann <[email protected]> wrote: > 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]) >>
