You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@mina.apache.org by David Hagan <da...@gmail.com> on 2013/06/05 01:28:33 UTC
Replacing MUC Module in Vysper
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? 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.
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?
Will the default module be involved in MUC messages, given that my module
has the same name and version?
Re: Replacing MUC Module in Vysper
Posted by David Hagan <da...@gmail.com>.
Thankyou Bernd. that makes it all very clear. Thanks for all your help.
------
David Hagan
(David.hagan@gmail.com)
On 06/06/2013, at 17:33, Bernd Fondermann <be...@gmail.com> wrote:
> On Thu, Jun 6, 2013 at 12:37 AM, David Hagan <da...@gmail.com> 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 <be...@gmail.com> 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 <da...@gmail.com>
>> 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 <be...@gmail.com>
>>> wrote:
>>>>
>>>>> Hi David,
>>>>>
>>>>> On Wed, Jun 5, 2013 at 1:28 AM, David Hagan <da...@gmail.com>
>>>> 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
>>>>
>>>> (david.hagan@gmail.com)
>>
>>
>>
>> --
>> David Hagan
>>
>> (david.hagan@gmail.com)
>>
Re: Replacing MUC Module in Vysper
Posted by Bernd Fondermann <be...@gmail.com>.
On Thu, Jun 6, 2013 at 12:37 AM, David Hagan <da...@gmail.com> 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 <be...@gmail.com> 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 <da...@gmail.com>
> 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 <be...@gmail.com>
> > wrote:
> > >
> > > > Hi David,
> > > >
> > > > On Wed, Jun 5, 2013 at 1:28 AM, David Hagan <da...@gmail.com>
> > > 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
> > >
> > > (david.hagan@gmail.com)
> > >
> >
>
>
>
> --
> David Hagan
>
> (david.hagan@gmail.com)
>
Re: Replacing MUC Module in Vysper
Posted by David Hagan <da...@gmail.com>.
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 <be...@gmail.com> 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 <da...@gmail.com> 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 <be...@gmail.com>
> wrote:
> >
> > > Hi David,
> > >
> > > On Wed, Jun 5, 2013 at 1:28 AM, David Hagan <da...@gmail.com>
> > 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
> >
> > (david.hagan@gmail.com)
> >
>
--
David Hagan
(david.hagan@gmail.com)
Re: Replacing MUC Module in Vysper
Posted by Bernd Fondermann <be...@gmail.com>.
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 <da...@gmail.com> 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 <be...@gmail.com> wrote:
>
> > Hi David,
> >
> > On Wed, Jun 5, 2013 at 1:28 AM, David Hagan <da...@gmail.com>
> 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
>
> (david.hagan@gmail.com)
>
Re: Replacing MUC Module in Vysper
Posted by David Hagan <da...@gmail.com>.
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 <be...@gmail.com> wrote:
> Hi David,
>
> On Wed, Jun 5, 2013 at 1:28 AM, David Hagan <da...@gmail.com> 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
(david.hagan@gmail.com)
Re: Replacing MUC Module in Vysper
Posted by Bernd Fondermann <be...@gmail.com>.
Hi David,
On Wed, Jun 5, 2013 at 1:28 AM, David Hagan <da...@gmail.com> 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