State of smack-bosh

Thanks, I’ll see to make a release soon then.

I think it is already spelled out somewhere in smack-bosh’s description, but this Smack module is in maintenance only mode. Same is true for the underlying jbosh library, which has some rough edges. So please consider experiment with XMPP over WebSocket as replacement for BOSH.

So websocket impl is in better shape than bosh?
I’m not sure we can completely switch to websocket as default jitsi-meet install comes with only bosh configured.
But I will look around for possible solutions.

Well, that is not how I would put it.

Wenn I started to maintain Smack a few years ago, I wasn’t really happy with smack-bosh’s codebase, however I decided to keep it instead of purging it, in the hope that it would improve over the time (spoiler: it mostly did not). I am also not super happy with jbosh, but it appears to do the job just fine (from what I can tell by observing the community, I don’t use BOSH personaly).

The main problem with Smack’s initial architecture is that every XMPP transport was modeled as different connection type (XMPPTCPConnection, XMPPBOSHConnection, Android once even had a XMPPSSLConnection). That probably was sensible in the pre-mobile era, but especially mobile devices may encounter situations where they need to change the transport mechanism, e.g., from TCP to BOSH. And the one-connection-type-per-transport design forces users to completely re-create the connection state (e.g., custom stanza listeners) when this happens.

Hence I few years ago, I started to create a new architecture (ModularXmppClientToServerConnection), where the underlying XMPP transport mechanism is modularized. This design allows user to use the same connection instance with multiple transports (TCP, BOSH, WebSocket, …). Currently, only TCP and WebSocket is supported, and notably, support for stream management is missing1.

This architecture is what I believe the future is. However, it hasn’t seen much usage. And no matter how many pre-release I publish, encouraging users to test it, my impression is that bug reports only start flowing in once a release has been done. :wink:

Furthermore, I think that there is no need to ever implement BOSH support for this new architecture, as I assume that WebSocket can replace BOSH in every place. On the other hand, I have a few reports where WebSockets are blocked by middleboxes whereas BOSH works fine. Although I could imagine that this does not affect your use case.

Hope that helped to shed some light into the current situation. Let me know if you have any further questions.

1: Interestingly, once ModularXmppClientToServerConnection supports stream management, then it would be possible to resume a stream established over TCP, with BOSH. However, this is currently underspecified in XMPP.

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.