Hi! Thanks for sharing your feedback. I am a bit confused: the PubSub functionality is part of Openfire itself, and does not require a plugin. I think you assume it does?
Hi Guus, with an OpenFire system using pretty few plugins, we got chat and audio-/video conferencing operating. Thanks to your big efforts!
During our implementation we recognised those PubSub properties:
There is a Server-PubSub Tab, which does not help in any way for the already reached functionality.
Lately I recognised that one can deactivate it’s use, what I have done now.
There are error messages in the log regarding tries for PubSub structure use, where nothing was found.
Those errors did not result to any malfunction. Hence, we simply accept and ignore.
Probably they will disappear by deactivating the service: not yet tested.
There is a PubSub Server Info plugin, which results for a single server related node to be found now in the PubSub list.
Because the server itself is only for this configuration part of some PubSub system, I thought PubSub Server Info plugin is mandatory for it’s use.
Together with the useless property for other cases, I thought that all functionality should be dependent to the plugin instead of appearing always.
May be my considerations are wrong and there is more use behind PubSub. There could be more documentation about this feature, which I did not recognised yet. If you disagree to my consideration results, pointing me to such a documentation could be sufficient. Many thanks for your support!
I am still not quite sure what point it is that you try to get across. What exactly are your suggestions?
Publish-subscribe is a well known mechanism to decouple entities that make available data (publishers) from entities that wish to receive that data (subscribers). The mechanism itself does not have one specific use case. Rather, it provides infrastructure that typically is a dependency of all kind of other, specific, use cases.
The PubSub Server Info plugin that you’ve found is an implementation of one such specific use case: it makes available basic information about the server by publishing it via the PubSub mechanism. A well known example of a subscriber of that information is the service at https://xmppnetwork.goodbytes.im/ for example.
yes, I think I can imagine, for what the service is good. But I still do not get, for what specific purpose it is used. Probably multiple plugins rely on it. Does it mean, that those rely on PubSub Server Info, too? Do Server-to-Server connections rely on the PubSub’s Server Info?
If we assume that server identity is crucial, why is it out sourced to a plugin, although the basic functionality is integrated?
If we use a standalone server only for internal purposes, where we do neither like to connect to other servers nor want to distribute information publicly, do we still need PubSub? I guess no, but log files tell, that sub-services always try to operate with PubSub and fail, although the service has been deactivated already.
The good news is that those error events do not stop the system from operating. Hence, we are in a way fine with the behaviour. I guess, that I miss some design for its use inside of the OpenFire environment. But one may not demand such for Open Source software, I guess.
Many thanks for your support so far. We can stop here, if you do not think that you could receive more benefit by continuation.