I was asked by the OP to answer this question, that is, how does one go about writing a custom XMPP server. My approach to this may seem unconventional, but it is a far easier approach that makes it incredibly simple for you to not just employ any existing (and bug-free!) open source XMPP server, but also allows you to extend the XMPP protocol in unforeseen ways.
There are two alternatives:
Alternative A. Write your own plugin in the native language of the XMPP server. So it’s either Java for Tigase, or Erlang for eJabberd.
Alternative B. The advantage of this alternative— though it is not quite what most people would recommend— is that you can use the XMPP server of your choice, which in my case is ejabberd, and still extend it without having to learn to develop native modules in Erlang, a language that I am not familiar with. The second best thing about this alternative is that this method makes it possible to use just about any development platform that you want, which in my case is either Java or .NET/C#.
In the macro steps that follow, I assume that you know how to manage the low-level details required at each step. For instance, I assume that you know how to deploy an XMPP server on your domain, use a binding library in the language of your choice, and so on.
- Stick with your server of choice, be it ejabberd, or Tigase, or whatever. Deploy it on your server.
- Create a single “root” user on your server. In all my development scenarios, I typically name this user friend (from my C++ days 😉 Ergo, I have one user on the system who is the system user and his JID is [email protected]/server.
- Create a service/daemon on your server and log in with your friend account within this service. Also write handlers for various XMPP events that could be generated within that service. These handlers are where your application’s business logic will reside.
- Write your own wrapper code at the client end, that is, where your users live. (Bear in mind that your entire end-to-end system works like a wrapper over the native XMPP system.) Now intercept every single event/message/presence at your client, that is whatever you are interested in based on the intent of your application, and direct all those messages to [email protected].
- When friend receives these events, it will then take appropriate action based on the nature of the event, which again depends on what purpose your application serves. Thus, friend may re-direct the event to the relevant user/s, or just send it to null.
- Use either JSON or XML as the XMPP payload to encapsulate the event. To get better performance, create the initial JSON (or XML) at the client’s end: this will offload both the time and processing load from your server to the clients.
Advantages
The advantage of this approach, other than the ones cited earlier, is that you end up using the native facilities of the XMPP standard like messaging, presence, and so on, while also adding your own “wrapper” of business functionality over and above it.
Secondly, if you think a little harder, you have, in a way, rolled out your own XMPP server by abstracting certain functions from the base server, having re-written them according to your needs. The extent to which you would want to abstract away the underlying server’s functions into your own code— or even fall back on its native functionality— is a choice that is yours to make.
Thirdly, you will be able to write your own code to friend and unfriend users (used as a verb here, and not to be confused with the friend user), and in fact sundry other functionalities that you would want to override from the underlying server.
Why would I want to do this? Because I prefer managing all relationships between users within my own code, since often it’s not just a binary choice of friend/not-friend relationships, but also about other nuances within a relationship that I can add within the system.
Fourthly, I have the advantage of having written my own “plugin” without destabilizing the server. A bug in my code certainly won’t bring my server crashing down, as an actual plugin bug would be wont to do.
However, the biggest advantage of this approach is that I have the satisfaction of having “written” my own server without the need to know the nitty-gritties of the XMPP protocol’s implementation. Using the analogy of OO-programming, I override the default functionalities that come out-of-the-box — the ones that I do not need— with my own custom functionality, while allowing the base system to function as is.
And all this while I have the advantage of a top-of-the-notch, production-ready server like ejabberd (or Tigase), with all its attendant features required for scaling. Lovely.
Disadvantages
The biggest disadvantage is that all events are first routed to friend, which then takes appropriate action before re-routing them to the concerned party. But then the friend user actually supplants a native plugin, so not much harm there.
Original post:
