I’m using openfire 4.2.3 and I’m trying to connect openfire with websocket
I think that the flow will be like this (maybe it’s wrong)
client > websocket(javascript/client side) > websocket(java/server side) > openfire server
If what I’m thinking about is true
I want to know how can I modify websocket(java/server side) [for example:when connected return a json object]
because I’m using websocket which bundled with openfire after the version 4.2.0
or I should write my own websocket(server side) dont’t use the bundled one?
Just so I understand - do you want to use Openfire to host some sort of service (similar to the REST API plugin) that returns non-XMPP data over a WebSocket?
if so, that’s perfectly possible. You can’t use the WS at http://host:7070/ws/ as that only supports the XMPP protocol. However, you can write your own plugin that hosts a WS on Openfire/Jetty at http://host:7070/my-websocket-protocol/ (or wherever).
As to how - check out HttpBindManager#createWebsocketHandler and OpenfireWebSocketServlet.
It seem like that I need to write websocket(client & server) by myself.
what I’m going to do is like below with rough picture
User will run some job in the background and when the job is finished
it will send a message to openfire then openfire will tell user that his job is finished.
Though on reflection, I wonder if it may simply be easier to send the request/receive a response using an IQ ad-hoc command (XEP-0050) and use XMPP has the transport mechanism. Your client can send a iq set, your background job sends an iq result (or error) when it completes).
