powered by Jive Software

Improve out of the box functionality for Openfire

Out of the box, Openfire provides a generous amount of functionality. However, more clients require more to function optimally.

Many of the required functionality is available in the form of plugins, but administrators are often not aware of this, or if they are, they have a hard time figuring out what plugins are relevant to their use-case.

We should think of a way that facilitates exposing the ‘right’ set of functionality for a server. We might take queues from the XMPP compliance suites as defined by the XSF. Online verification tools like Conversations’ Compliance Checker and the IM Observatory can help define what’s sensible.

I’m not sure if the ‘right’ set is an equal set of plugins for each instance. Perhaps we need to define ‘profiles’: a setup that’s meant to be used only internally in an organisation, with a specific client, perhaps not even exposed to the outside world, can differ greatly from an all-purpose, generally accessible server.

It can make sense to move functionality from specific plugins into Openfire (similar to what we’ve done with websockets in the past). This way, end-users need not be bothered by this. In my opinion, candidates for this are:

  • The message-archiving functionality from the Monitoring plugin
  • Http File Upload

If we do start to ship default plugins, we must define a mechanism that prevents these plugins from being re-installed when Openfire is being upgraded, if an administrator had earlier explicitly removed the pre-installed plugin.

What do you think?

I thought you meant to include these plugins in the core server instead of them being separate entities. But you only mean to have them as default plugins, bundled with main installer? In that case, yes, there should be some mechanism to check if it wasn’t uninstalled before.

I think Monitoring plugin is a good candidate. Not so sure about the file upload. Users want inline images usually and this plugin does URLs in most clients.