Hi,
How do i pick the Openfire and smack versions to go with each other ?
I have some sample code written against older smack library versions. Can i still use the older smack libraries to go with the latest openfire server ? Is it a tested combination ? Or is it recommended to use the latest Smack library with the latest Openfire server?
Thanks
Arun
Yes, the older Smack libraries should work against later versions of Openfire (and, indeed, any XMPP server).
Greg
Hi Greg,
Thank you for the confirmation. That is good to know - impressive even. I would have thought the proliferation of versions would make it hard to qualify / verify. How is this managed ? Do automated tests of all scenarios run against all the different combinations or is this a generic statement, given that the base interfaces have been held stable?
Thanks
Arun
I wouldn’t be so optimistic as gdt. I don’t think anyone is doing tests with Smack against every version of Openfire and i don’t think anyone even doing tests against latest version of Openfire (correct me if i’m wrong). Smack and Openfire teams are different and Smack’s lead developer is known to criticize Openfire for the the lack of standards support and various bugs. So i doubt he would devote time testing against it.
For what is worth, i can install Spark 2.6.3, which is 7 years old with some ancient version of Smack and connect to Openfire 4.2.3 and chat. I can’t test every aspect, but it seems to work in general. So, it kind of works, but maybe some complex stuff (say LDAP, pubsub, etc.) won’t work because of changes in Openfire.
Surely the latest version of openfire and smack would be tested together ?
Any more insight into this would be much appreciated, since we would like to cover the gaps in the validations ourselves, to be safe in production deployments.
Thanks
Arun
As i have told, Openfire and Smack developers are not the same and i doubt any testing is done. This is an open source project with a few volunteers doing it in a spare time. There are no resources to do such testing.
Although different versions of Smack/Openfire aren’t always tested together, and a newer feature in one may not work against an older version of another, broadly speaking they both implement the same protocol; there’s not, broadly speaking, any tie in between versions of the Apache HttpComponents HttpClient and the Apache Http Server, but they do work together. I’d expect to see the same with Smack, Openfire and XMPP.
I think the truth is probably somewhere in the middle. 
No, you are right. There are no tests against Openfire. Smack’s integration tests are run periodically for the current stable branch and the master branch against ejabberd and soon prosody.
I didn’t know that this is widely known :). But yes, given my experience with Openfire, I personally recommend ejabberd or prosody. And thus, use those as primarly target for Smack’s integration tests. That said, I would welcome integration tests against Openfire, but I won’t be the person who maintaining them.
That is a good comparison.
Open standards make it possible. It is certainly one advantage to open standards that different products from different vendors work together
Flow, what are your biggest pain points with OF and what standards are missing that you’d like to see? What is openfire missing that is currently in ejabberd or prosody? Perhaps it’s something @guus, @gdt, and @dwd could get addressed quickly.
Are there any instructions on how to run the Smack integration tests? As I recall, they were originally designed to be run against Openfire (that is, they were originally tests with Openfire as the SUT, rather than the Smack library) - though I could well be wrong.
It’d be great running these up again, and if I can make that happen automatically, then I can find some time to make this happen.
Running Smack’s integration tests can be simple as
git clone git@github.com:igniterealtime/Smack.git
cd Smack
gradle integrationTest -Dsinttest.service=my.xmppservice.org \
-Dsinttest.adminAccountUsername=admin \
-Dsinttest.adminAccountPassword=aeR0Wuub
if admin / aeR0Wuub are the credentials of an account on my.xmppservice.org which is able to create new accounts using XEP-0133.
Note that not all integration tests may run successfully against Openfire, e.g. because of OF-1224.
It is twofold. First, other XMPP server implementations, especially ejabberd and prosody, appear to have more traction. New things get implemented more quickly and there is a vibrant community around them. Furthermore, ejabberd has a strong bound with Conversations, which leads to an excellent feature coverage when it comes to modern mobile XMPP. Prosody has LUA: I’m always impressed how Prosody modules implement even complex XEPs in a matter of a few hundred lines of code. And we are talking more about one- to two-hundred lines here.
The second thing is that important bugs in Openfire releases sometimes just don’t get fixed in a timely manner. OF-1224 from above is a good example here. It affects XMPP-IM / RFC 6121 related stuff, things that are important for even basic XMPP server implementations. I also still remember the time where server-to-server dialback was broken in Openfire 3.7.0 (OF-443) which means that your Openfire could not federate with other servers. It took multiple months until the issue was fixed. IIRC that was what made me switch my personal XMPP service away from Openfire after using it since the Wildfire days.
In summary, that is why Openfire is at the moment not on my personal XMPP server recommendation list.
Just curious, does anybody know, if these implementations have paid developers? If yes, it would explain it.
It seems there’s a company behind ejabberd (ProcessOne), which supports the development. At least there’s also a “business” edition.
Yes, ejabberd is backed by a company. Prosody is not, but I believe the core prosody developers do some contract work once in a while.
Flow,
Do you talk with any of the devs from the other projects? Any chance some of them would be willing or interested in helping us out a little here? what can we do to attract more attention and build a more vibrant community here?
I personally favor OF over the others…the ease of administrating and setup is great. I feel like we a great group of core guys here, but would love to see things grow!
I think the fact that ejabberd is backed by a company plays a huge role in its success. Given that erlang is a rather exotic language, I doubt there is a big community of contributors around it apart from the core devs and one or two volunteers who are capable of writing code in erlang.
I think what Openfire lacks is visibility. While I like selfhosted solutions, I found it strange that both Openfire and Smack do not make use of Githubs issue tracker when I started to contribute. On the other hand I do not think that switching bug trackers will do the trick 
.
While i understand that Github is more convenient for many, but its issue tracker is so basic. Unless we are really sure we will get lots of visibility this way i don’t really want to go away from Jira. Jira needs integration with Github
Here some of the reasons, why in my opinion Openfire isn’t as attractive:
First, I think it’s not that easy to get started with Openfire, due to the following reasons:
Until recently it had no modern build system, it was hard (or still is) to correctly setup Openfire in your build environment, because you have to do it manually (e.g. add all dependencies from build/lib folder).
It still doesn’t use a well-known directory structure (like src/main/java), which would be familiar to new devs.
On top of that, all the plugins.
If you get it done, it’s hard to get an overview.
I once counted the lines of code, I don’t remember the numbers, but it was huge, I think it were around 320000 LOC (only Java classes, without comments), additionally all the JSP files and other stuff.
The package structure is also a mess.
Second, the code is often cumbersome and repetitive.
As an example, take a look at PubSubEngine.java. I think I counted 49 occurrences of the namespace “http://jabber.org/protocol/pubsub”, I don’t like how DOM4J elements are recreated from scratch everytime.
Another example is “urn:xmpp:delay”, every time you need this, you have to know the XML schema and use things like:
m.addChildElement("delay", "urn:xmpp:delay");
delayInformation.addAttribute("stamp", XMPPDateTimeFormat.format(unacked.timestamp));
(There are like 20 occurrences of things like that).
Third, it hardly uses standards or modern frameworks, a few examples:
StringBuffer internallyI understand, that it’s hard to update any of these things, especially due to all the third-party plugins out there, which probably would break.
Fourth, there are hardly any (unit) tests.
If you develop something, you can never be sure, that you break something, which probably discourages work on the project.
I think some of your criticisms are valid; the non-standard layout has bugged me for a while - so much so yesterday I submitted some PRs to fix some of them. Some of your comments, however, I think are incorrect.
You say that are too many plugins. I say it’s good that Openfire is so extensible.
You say it uses Jetty WebSocket API instead of javax.websocket. I think that just a misunderstanding of what’s going on; AFAICT it’s necessary to use the Jetty WebSocket API to fire up a Jetty WebSocket servlet.
You say it uses Apache MINA is dead since 2009 - there have been three releases this year.
You say it uses JSP and not something else (I assume you’re thinking Struts or similar). I think for the handful of simple admin pages that Openfire offers JSP provides sufficient functionality.
You say it should use JPA instead of JDBC; well, that’s an almost religious level of debate you could have there alone, but given the somewhat limited level of database access that Openfire uses I don’t really see any advantages.
dom4j doesn’t use StringBuffer AFAICT. A quick search of the code base shows up plenty of instances of StringBuilder.
Custom cache implementations? Yes, today I’d probably reach for Caffeine, for the non-clustered caches, but the existing code has stood the test of time well, so not sure there’s a lot of benefit to replacing them. The clustered caches of course do already use a fairly standard third-party solution.
Limited unit tests, repeated code? Perhaps true, but PRs are always welcome 
Greg
Yes, it’s good. I wanted to say there are many which by default are loaded/included in my IDE and which sometimes cause issues. And which contribute to the masses of code.
Just checked, you are right. Must have been some other framework, which I had in mind.
Hm, the core has about 100 JSP files. My argument was not about if it’s sufficient, but that JSP is an outdated technology and not very attractive to write code for (imo). Developers probably rather spend their time with more interesting technologies. Same problem I see with Spark + Java Swing.
Probably true, nonetheless I consider JPA more attractive to work with than JDBC.
They used it in 1.6.1. Version 2 improved here.