Now that there is a Feature request bug for Smack (SMACK-333) it would be nice to add a bug for openfire too.
I know that Stream Management is not easy to implement on Server side, therefore it will take a while to accomplish. But once it is there, it would attract more mobile users to use openfire as their XMPP server.
Flow
OF-446
Any progress made on this? And is there a preferred place to place bountys on this issue/issues?
First of all, thank you the OpenFire development team for creating and sharing something so awesome.
I have on multiple occasions contemplated moving from OpenFire to another platform that supports XEP 198. As Flow has mentioned above, this is a high priority feature as everything moves to mobile.
I am sure a lot of people would like to see this implemented in a nearcoming release.
It’s not that we, the Openfire developers, don’t know of the importance of such an feature, it’s just that we currently have no volunteer for this feature.
I, and I’m sure the other developers too, would be happy to mentor someone. So if you are interested, or can spare developer time of one of your developers, then simply contact us.
There is already an Openfire implementation of XEP-0198. It is closed source. We might be able to convince the developer to open source the code with a bounty.
That sounds interesting. Any more information? I could offer some bounty.
Also i would love to help out developing openfire/smack. But i am not very familiar with the code and dont know if i am capable enough. Would definelty need someone to bump me in the right directions. (How things should be done etc.)
Experience with Android, Java EE, OSGi. Already made a very simple Openfire plugin and two asmack based messenger.
Would definelty need someone to bump me in the right directions.
Then I recommend joining Smack in freenode.
Reviewing and comment pull requests would probably help already, while you can learn more of the code.
There are also easy (but boring) tasks, like maintaining documentation (hrhrhrh), remove deprecated API usage or JavaDoc warnings, …
Java EE knowledge is definitively welcome. I once thought about introducing JPA, but it would be a (too?) major task. Another contributor (I think BigD) thought about dependency injection. Maybe you can just provide some thoughts, if you are familiar with these topics, and don’t want to develop right away.
Btw, i see that there are tickets for Openfire and Smack. Will Smack implementation automatically cover it or clients based on Smack also need additional changes?
That will mostly depend on if we enable xep198 as default in Smack or not. Most new features in Smack are disabled per default for new XMPPConnections in the Smack version they initial appear, but enabled in a later version.
But even if it’s disabled at first, enabling it is simply a matter of XMPPTCPConnection.setStreamManagementEnabled().
Any word on how high that bounty would be? And how fast the code could find its way into Openfire?
We’re currently struggeling with lost messages on mobile/shaky connections and I guess Stream Management could improve the situation quite a bit…
Any news on this one? Are you still in contact with the developer of the closed source implementation?
I just saw this blog:
Openfire XEP-0198 (Stream Management) | Atklique
Can’t it be done quickly with this way?
Unfortunately, this has little to do with XEP-198, but is some custom solution. The client also needs to understand this custom protocol.
This is also a nogo: <message type=’**client_receipt’ **/>
It’s also not clear to me how they handle the case, when the recipient is offline and Openfire sends the message 2 weeks later. If this offline-delivery fails, they won’t have the message anymore in their custom table.
It might work for them, but only with their client.
Is is possible to implement XEP-0198 as a plugin? Does clustering affect the functionality of XEP-0198?
Can someone pointed me a direction to look at if I want to implement the plugin under hazlecast cluster configuration?
And personally I am willing to put up some bounty as well, if anyone is interested in developing XEP-0198.
Is is possible to implement XEP-0198 as a plugin?
From what I know from plugin development as well as developing directly in Openfire’s core, I think it’s not possible with a plugin. Maybe the acknowledgment part of the spec, but not the stream resumption.
Does clustering affect the functionality of XEP-0198?
Yes. Because when resuming the stream (i.e. creating a new connection) it is possible, that the new connection connects to another cluster node. That new cluster node must be aware of the old session.
I can confirm that the stream management features for XEP-0198 will require additional work in clustering mode to maintain an authenticated session across multiple successive connections to different cluster nodes. This will be partially addressed with OF-689 (which will likely be implemented before OF-446).
And to complete the answer list (of my own question I asked years ago ): The acknowledging part should be pretty easy to implement (even in a clustered setup). It’s the stream resumption resumption that’s tricky.
Hi @Flow,
We are interested to implement XEP-0198 for Openfire server, and contribute to the community.
Could you please kindly share the progress made, if any, on the same?
Also, we would appreciate, if you can share your viewpoint on the high level design for the same. That would help us to speed up the process at our end. We are planning to take this up in three stages:
Implementing Acknowledgement
Implementing Stream Resumption in a stand-alone box
Implementing Cluster readiness
If you are aware of any developers already working on this, please connect us.
Your guidance will be highly appreciated.