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])
>
