Resuming your session after a page reload using CAXL

[duncan_at_hive]

Hi there,

I've run into a bit of an issue with using CAXL in our web portal to surface IM&P from our CUCM server.  The portal is quite a traditional web application - not massively ajaxified and with plenty of hard page reloads.  What I'm wanting to do is to be able to resume the use of an established XMPP server session after a page reload / refresh by supplying some information from browser storage e.g. the XMPP session id, the BOSH cookie etc to a new Client using a "reconnect" / "resume" method.

I can't find this feature documented unfortunately, meaning that every page refresh currently invokes a fresh connection with the XMPP server, which has a noticeable delay and is presumably quite expensive, serverwise.

Is there any solution to this, other than abandoning CAXL in favour of a Javascript XMPP library like converse.js that DOES support this ability?

Many thanks for any help,

Duncan

[npetrele]

Hi Duncan,

CAXL does not include any built-in features for avoiding a re-login after a hard page refresh. 

I just checked out converse.js (thanks for mentioning it - never heard of it before).  It looks like they're handling the login and roster separately from the main page.  I'll have to examine the source code to really see how they're doing that.  It may be possible to implement a strategy like that with CAXL, but you'd have to do it outside the feature-set of CAXL itself.  If I learn anything interesting, I'll come back and add a post. 

[npetrele]

Okay, converse.js is too big to fully grok in one look, but I can tell what I learned so far.  First I need to explain something about CAXL:

What we call CAXL is actually a combination of two libraries -- Jabberwerx, and Jabberwerxui. Jabberwerx is the XMPP/Jabber portion.  Jabberwerxui is the UI wrapper around Jabberwerx.

It looks like converse.js is using strophe.js for doing XMPP the same way Jabberwerxui uses Jabberwerx for doing XMPP. So converse.js is the UI, and strophe.js is the XMPP handler.

Confused yet?  Well, it gets better.  Strophe.js uses bosh.js to do the BOSH handling, and bosh.js includes session.js to store BOSH sessions.  I need to examine it more closely, but it looks like converse.js uses that information with the localStorage of the browser (window.sessionStorage).

This doesn't change anything, but I thought you might like to know.  I will be submitting a feature request for the CAXL folks to add session handling.  In the meantime, it looks like it wouldn't be too difficult to implement session storage with CAXL the same way converse.js does it. But I haven't tried it, so don't take that as definitive.

[npetrele]

Okay, this may be a game changer -- upon even closer examination, I found CAXL does session storage.  How to use it is another story.  It's not exposed in the API as far as I can tell.  Stay tuned. 

[duncan_at_hive]

OK that's exciting news!  Good luck, and your help's very much appreciated!

For your information, I am only using the jabberwerx.js library myself at the present time, and not making use of the UI library if that makes life any easier.

Thanks again and I look forward to hearing from you again!

Duncan

[npetrele · Accepted solution]

Well, you learn something every day.  Not only does CAXL allow a persistent connection, there's even an example of how to do it with the SDK.

/directory-to-your-caxl/CAXL/doc/examples/persistTest1.html

This file includes persistTest.js, which does all the magic.  It's quite simple. 

The example takes you to a second HTML page, and you can see that you're still connected.  But it also works with a refresh.  Refresh the second HTML page, and it will show you're still connected. 

I never would have found this if it wasn't for investigating strophe.js.  I saw they were using window.sessionStorage, so I grepped sessionStorage in the CAXL directories hoping to find it in Jabberwerxui.  However, I found it in the regular Jabberwerx Javascript.  I followed the trail backward until I found out where it was actually used, and that led me to the example.  It would have been simpler if I had simply grepped "persist", but it isn't the first time I learned something the hard way, and it won't be the last. 

I hope this works out for you!

[duncan_at_hive]

Wow that's fantastic thank you so much!  I will give it a go on Monday and let you know how I get on.  This is very promising!!

Thanks again, and I'll keep my fingers crossed for Monday.

Duncan

[duncan_at_hive]

Yes this worked perfectly thanks!  Took me a while to find where various things had been persisted to, but I dug out the contacts and their presence after a page reload eventually!  For anyone wanting to do the same, the RosterController is persisted in "client.controllers.roster", the Roster Contacts in "client.entitySet", and the means of getting their presence "client.getPrimaryPresenceForEntity(jid)".

Many thanks again,

Duncan