powered by Jive Software

Alternatives openfire?

I tried to do a few things with openfire, but the fact that it took

me a longtime to develop asimple application that truth does nothing!

As a programmer I do not like to waste my time with “nonsense”, so I was wondering

if there is any XMPP “free or pay” I do not care, which is very useful.

I need opinions xmpp server, if it can be possible for me, I like to comment on that this week,

“I run a hurry”


openfire is one of the most notable XMPP servers out there. there are others, of course, but openfire is one of the largest (and in my opinion, one of the best).

I do not know what troubles you have encountered… but as with any new (to the developer) and large/complex codebase (openfire’s codebase has been open source since 2007, but was developed privately for many years prior to that), there is a very steep learning curve until you are familiar enough to navigate on your own.

There are also paid XMPP servers out there, but I’d note that many of them are actually openfire in disguise with some modifications to suit that vendor’s needs. Some notable paid versions are Cisco’s Finesse product and Cisco’s WebEx product, both of which take openfire and bundle it with a bunch of other collaboration software all into a single (paid) package. The same is true with the other popular XMPP servers who have licensing that allows for commercial vendors to re-package.

As far as I know, these paid versions are going to discourage “hacking” on the source code since the vendor is supporting a known-working version (that they produced and plan to support for a period of time).

Of course, depending on what you are trying to do, you may not even need openfire or any XMPP server, but rather just play around with the smack xmpp library and make your own server, or have things talk directly to each other, etc. There are many ways to go about it

To address a point you made in a previous post, yes, I do think documentation is perhaps a little lacking for not just openfire, but most of the projects here at igniterealtime. The problem is, most people would rather spend time “hacking” on the codebase to make new features or improvements rather than spend an afternoon writing boring documentation. Everyone here is volunteers, so it’s difficult to get people to do the “boring” things like documenation. Of course, if you make documentation improvements, the community would be very grateful!

Hi Jason,

Frisly great explanation.

As you say, many use xmpp smack, disguised, that you’re right.

I know a “GREAT API” called Quickblox is one that is “well documented” why? easy, you have good resources, working with the people who matter.

However the server is never yours, but that’s no problem, you can migrate the server in another computer.

What I have come to refer me, is that Quickblox can do “everything” in just one week.

I know the job of programming exceed: Android -> java -> Objects -> Json -> xml/2-> Html / 5 (javascript, ajax etc…) -> Php -> python (server).

I know the work is hard, do not deny it, but you Quickblox does it all in an instant.

cloud server, video-chat, talking with users.

My point of view I think that would be an alternative cloud Quickblox.




I’ve never heard of or worked with it.

But as it seems, it is a “closed” server, with some modifications. You also have to use the server and can’t easily switch to another, due to a custom authentication, which is used (not quite sure here!?).

The Android SDK seems to be built on top of Smack and adds more/modified functionality, like video.

E.g. I saw this in the docu:

// initialize SMACK


chat = QBChatService.getInstance().createChat(); chat.addChatMessageListener(new ChatMessageListener(){ @Override publicvoid processMessage(Message message){ Log.d(TAG, "Messags: "+ message.getBody());} @Override publicboolean accept(Message.Type type){switch(messageType){case chat:returntrue;// process 1-1 chat messagesdefault:returnfalse;}}});// send message chat.sendMessage(546, “Hi mate!”);

which looks similar to Smack.

The documentation looks good, but I guess that’s also the price you pay. (http://quickblox.com/plans)

In general, it’s a commercial product. You pay for it, so you can expect it to have better documentation.

Correct Csh ,

Similar to smack , I have personally worked with the API Quickblox , and comment that fine, any clause " for example , the server " , but otherwise fine.

I know their prices, and all together on . Jar Quickblox , however , I would create my server from "0 " to smack .

You also can use the same code to get a commercialized Quickblox and legal app , that’s very interesting today .

To migrate server , you have to make yourself the libraries . " Jar" , easy , are a set of " listeners" javas listening to others with the same netbeans can do it.

I myself could create me my libraries "smack " but do not have time to think algorithmic ( objects,json , xml etc . ) , So I’m using smack

Actually, seems like a good smack API , but lacks a few updates , for example asmack need include: Streams, virtualisation , data sharing, etc. .

I think if you strive to improve grow much .

I have a question : Who developed the library , asmack ?

I know openfire page , but I do not know if you you develop the library.

I would like to contribute ideas to the Seller asmack .

A greeting.

Nobody sells asmack (as far as I know). I think you may be misunderstanding some things.

Smack is an XMPP Library implemented in Java developed here by the igniterealtime.org community and currently led by Flow and was led for previously by rcollier for a long time. Smack is the name of this library, and the word “Smack” does not apply to any other XMPP library (there are many XMPP libraries).

Openfire is an XMPP server built using the Smack library. Spark is an XMPP client built using the Smack library. There are many other programs in the wild that use Smack as their core for XMPP.

ASmack is the Android version of Smack, developed by Flow. (Flow correct me if I"m wrong), I believe ASmack was a fork of Smack to make it compatible on Android devices. I believe currently Flow is working to merge the two back into a single library that can work on Android as well as regular devices/machines.

These are all open source software/libraries.

Many vendors, such as QuickBlox and Cisco, take these open source software/libraries and use them in their paid products, sometimes with minor modifications, sometimes without any modifications at all.

In the case of QuickBlox, it appears that they have taken Smack (the XMPP library developed here) and have used that in their product. They also may be using Openfire behind the scenes as their server. What you get when you pay them for their service, is an abstracted API they have bolted on-top of Smack/Openfire. They do this to better control what you can or can not do with their service. Essentially, you are paying them for the same underlying products (Smack and Openfire).

So the “better documentation” that QuickBlox has provided, is really only the documentation they have made for their abstracted API. Under the covers, your API calls are going to be translated into Smack API calls.

So, if you feel more comfortable paying someone to run the server and provide you with a different API, well, that may work for you. Just know, that in doing so, you may make it much more difficult to switch away from using their service in the future (their API is non-standard and non-portable to any other XMPP service because it’s their own custom API).

To address a point in another post you made, developing a full featured instant messanging client is going to require some time. You will need to first understand XMPP, and either write your own XMPP library, or use one that exists already (like Smack). Then on top of that you will build how it works and functions, the UI, etc. It seems like you have a tight deadline to have a working XMPP client. I don’t think this is something you can just “hack” together overnight. It may take weeks or months to develop a full featured client that does everything you want. Spark has been developed for years and still has bugs (like all software). Depending on what your project is, you may be better off taking an existing XMPP client (like Spark) and then modifying it until it suits your needs. But, this will require you then learn how Spark operates. There is no getting past the steep learning curve when you jump into a new codebase.

1 Like