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?