Notably this release fixes a bug with event handlers not handling packets without child elements correctly (see ticket #17 for details). I also updated some parts of the documentation, though there’s still some work to do.
Download at http://zeank.in-berlin.de/jsjac/.
I just plopped the new .js files onto our project (was using 1.2.0), and now there is a ~10 second delay before a chat message arrives at the other participant (PSI). The other way around messages appear instantly (since it’s a LAN setup for testing).
The first time around it also seemed to have timed out (jwchat user just went offline). No errors in OpenFire or Apache.
I only changed use_bosh_ver to false, for OpenFire. Any other options that might need changing?
Hello
Does jsjac support md5 login with non-latin characters?
Does it need to support md5 with utf8 for that?
Best,
Mark
@Sabine: none that I know of concerning JSJaC. Did you follow the steps at http://chromus.kajigger.com/blog/2007/03/22/making-jwchat-work-with-openfire/ ?
@mark: XMPP uses utf8 throughout
@Steve. Thanks. utf8 works fine except for creating new accounts and login. I also tried it on jwchat.org and it doesn`t work for me.
Can I ask how do you handle network issues?
For example, if I use jsjac and my computer get “stuck” for 20 seconds or longer.
Does jsjac
– reconnect
– send the same request again with the same rid,
– send the same request with rid+1?
I`m assuming the server let the user be idle for a time long enough
jsjac rocks!!!
mark, this depends on what happens after those 20 seconds have elapsed and what the value of ‘inactivity’ (which is contained wihtin the first response).
normally jsjac just proceeds with a request of rid+1 (except the last request had failed, then the last request would be repeated automatically).
if ‘inactivity’ is below 20 the next request would fail with an 404 error as the session has timed out. in that case an onerror event is thrown indicating the session has been deleted and jsjac disconnects. so it’s up to you to handle this situation and do a reconnect.
ps: I’m asuming we’re talking about http binding (bosh) here.
Steve,
If I understand correctly:
400 is a syntax error and shouldn`t happen.
403 shouldn`t happen also if I configure jsjac and the server properly.
404 error could happen as you described. Do you try to reconnect only few times or just keep trying?
How can I tell if the request failed? Will I get another status code?
If I`ll disconnect my internet connection and the reconnect, will jsjac be aware of that?
I`ve tried this on mabber and the client lost the session without being aware of that (not sure…).
Tried that on gmail and meebo and they handled it fine.
Best,
Mark
Steve, we have since upgraded to Openfire 3.4.1. I couldn’t keep testing, because the change of our databases to UTF-8 gave us some problems with Openfire…
Anyway, it works just fine now.
problem using it with ssl jabber server how can i config it . How ever if normal jabber server is OK.
[2] starttls present, trying to use it
[2]
[0] initiating handshake
[1] STARTTLS failed: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
[2] tls failed but we don’t need to be secure
[1] socket closed
[2] inQueue:
Devil, I guess you wanted to comment on JabberHTTPBind as your debugging output is related to it not JSJaC. Anyway, it seems that your certificate is bad. In order to make Java accept your certificate it needs to identify with the same domain name as your trying to connect to.
Thanks Steve
I think U mean that I must config JabberHTTPBind to the same domain name as Jabber Server ?
No. The certificate issued by the jabber server must be for exactly the domain the jabber server is hosting.