I am using xmpp with my browser using strophe.js library.
What I am doing is as soon as the user is creating an account on rails app, I register him on to my xmpp server too which happens through javascript which takes quite a few seconds. Even other actions related to xmpp takes a few seconds. I do know there is no concept of threading on browsers.
Is it possible for me to design this in such a way to keep the user from noticing any delay while using the rails app. Because each time the user creates a group I do that on the rails server plus on the xmpp server. This action is fast for the rails server but slow for the xmpp server
You can create the user record in your app and then queue up a background job that will create the user on the XMPP server when required. Look at something like delayed_job for this. This means the page would return as soon as the user and the delayed job were created and then a background task would do the work of creating the user on the XMPP server.
You would get faster response times and also enjoy the built in retry logic provided by most of the background job gems. If your XMPP server is down, for instance, the job will fail but retry later. The downside is that you then have to deal with the possibility that the user could have a record in your app, but not one in the XMPP server.
But derek the connection with the xmpp server is happening via the browser using a bosh connection. Is there a concept of background jobs in javascript on the client side? If the xmpp server is down can we have a retry option via javascript? Or should I monitor the state of the xmpp server via the server and then ask my javascript to execute code based on that.
Or in simple words, Can we have a background job on on the rails server side which does the job of maintaining the queue for me, and which assigns tasks to my javascript client side.
You could certainly come up with a sytem that will do what you want, it’s a matter of how complex it would have to be to suit all of your needs. If the site is basically useless to the user until the XMPP user is created then the simplest thing to do is to handle that in band of the request, like you are doing now. Or perhaps you could tackle this from the XMPP side and find an XMPP server that lets you point to an existing database of users (your rails database, in this case).
You can definitely do some fancier things with background jobs and polling via Ajax to check on the status of those jobs, but I wouldn’t let this hold you up right now.