I’m hoping to gain insight on how others are using openfire, and on how we can improve it! I came up with a few questions of interest. Feel free to add or comment on anything even if it’s not listed. I’d love some constructive feedback and comments.
How are you using openfire? Personal or Work?
What challenges have you had?
Has anything not worked as expected and if so, what?
Have you considered moving away from Openfire? If so, why? What made you stay?
What does Openfire do well? Where does it fall short?
If you could change or add ONE thing to Openfire, what would it be?
Not able to share images in group chat, but i just installed 2.9.2 – this is solved (yay!)
So far, 4.6 on sparks 2.9.2 have been working okay for me
Yes – when using previous versions. We evaluated rocketchat, but it is so buggy in our limited experience’s opinion especially when connected to AD. The interface was nicer tho
Once installed properly, it doesnt really bug us with much issues. A few things can be added as future features if not already there:
inline image/video sending on groupchat as opposed to http link
built-in video/audio meeting without the need to install plugins
features for room management i.e. disable users from leaving certain MUC
built-in theme / skinning features
One thing to change ? I think the inline image/video management as we used them all the time by almost all users
Used at work for internal secure messaging we could send passwords over on Windows Server 2016.
Switched to Teams for seamless all-in-one messaging and video calls
Currently use at home and have for about five years.
Clients are Pidgin (Windows), Xabber (Android)
Good
Simple to install and set up
Message turn-around time is fast
Runs on my micro PC “server”
Bad
Server loses messages for offline clients, this gets much worse if you have an Android client that is sort of online (app in background, etc.) - number one frustration
Have never gotten easy file and image sending to work reliably
Once bricked an existing install with a patch and lost all home users
Java - the application takes a lot of memory for a little server process
This primarily is a client issue, not a server issue. If you install Openfire with the HttpFileUpload plugin, you’ll see that some clients (like Conversations) will show inline (previews of) the data that’s sent, where appropriate. Ideally, support for that is added to Spark.
I don’t expect us to turn away from plugins, but what we have been considering is:
Move functionality that’s now provided by plugins into the core Openfire build
Ship Openfire with more default plugins
Update documentation, and perhaps provide tooling, that allows administrators to more easily configure Openfire in ways most compatible with modern clients
Both Spark and Openfire used to have theming/skinning functionality, but that proves to be hard to maintain. If your organisation is looking for customized builds of either, I suggest enlisting the help of any of the commercial service providers that are supporting our projects.
If at all possible, stop using Pidgin. It’s XMPP support is pretty poor. Alternatives apart from Spark and Pade might be web-based ones, like Converse and JXCS (both of which can be installed easily through Openfire plugins.
This feels like a pretty major bug, that I’d like to address in a separate thread. Would you mind creating one, and detail the way in which we can reproduce this?
Have you tried the HttpFileUpload plugin? That’s supported by most modern XMPP clients.
That’s very unfortunate. What kind of ‘patch’ was that? Typically, the Openfire upgrade is pretty reliable. However, every update guide starts with “create backup”, just in case…
This might be the result of a bit of a balancing act. Default memory usage (through caches, for example) is geared towards not running on a minimal system. There’s a trade-off in efficiency, and user experience, where we tend to err towards user experience. Computers nowadays typically have plenty of resources available to them - the type of computers that typically run server-sided software nowadays, or are relatively inexpensive to upgrade. That said, people are running Openfire on things like Raspberry Pi’s so things are not to bad, I’d say. There will always be outliers, but I don’t think we can, or even should attempt to, optimize for resource usage in micro-environments if that potentially hurts the experience of the more common use-cases.