That's right! We know have an RC on release 1.8, and boy it's a biggy: We now support both WebSockets and HTTP/Comet style communications. This simplifies writing JavaScript applications enormously and all devices you want are now at your fingertips.

And the kicker? It's all under the hood, your server side implementation does not change at all!

Other than that, there's a slew of other improvements as well...

• List services by contract type
• List/access services by annotation
• Add "attributes" to game data action/transport
• Add static file serving via HTTP

... and more.

In order to go sharp with this release we're going to improve documentation, especially around the new WebSocket/Comet functionality, run load tests and improve our JavaScript API.

You want to start using it now? Hit the download page (at the bottom) and then ask us for help here on the forums. We're here for you!

Enjoy!

Thanks, I'm installing this pre-release version to see if I can get the windows websocket poker prototype code on ubuntu.

Indirectly linked with the topic, you guys did amazing good job specially clean design of the websocket connector and its firebase/network callbacks using javascript code. I went through all js files to get an idea how it was implemented.

Wow, I'm impressed on probaly major work that Peter did but I would not be able to understand much if I haven't had prior experience with firebase and poker though using the old flex version.

Hi all,
reading your blog post www.cubeia.com/index.php/blog/archives/293
I was playing with your simple demo at
www.robotsociety.com/jslogin/login.html
and what seems strange is that the login request seems not well formed for the firebase StyxJsonSerializer.
I did some tests and debugging firebase code it seems that for the login request
{"classId":10,"data":{"user":"Chris","password":"1234","operatorId":"1"}}
StyxJsonSerializer.fromJson return a LoginRequest object with all null attributes.
Unfortunately I don't have the code of the StyxJsonSerializer class to understand well.
Could you please give me some feedbacks on the json payload format?

Ooooh, that example was written for the pre-pre-release 1.8-SNAPSHOT. I think the JSON format has been changed to be able to handle nested protocols in the RC1 release. I will check this and update the example as needed.

Thanks for pointing this out!

Tnx very much Fredrik
check also the javascript tests in client-api module (it seems all are still using the old format).
Thanks again for the quick response and let me know when you'll release some docs or new examples about websocket

The JSON format changed between the RC1 and the version I used when writing the short tutorial. I have updated the online example code and the blog post to use the new format instead.

The correct format for the login is: {"classId":10,"user":"'+username+'","password":"'+password+'","operatorId":"1"}

Thanks again for making us aware of this and giving us the chance to correct it

Hi all,
I'm never here.
I'm trying to use the WebSocket with Firebase 1.8-CE-RC.2 but I have a problem with the GameTransportPacket message received from the server using JavaScript. Reading the protocol specification the GameTransportPacket has classId=100 with tableId, pid and gamedata that should be an array of byte.
My problem is that I don't know how to use the packet.gamedata received in JS function because my JS function receive a type of string for the packet.gamedata when I expect to receive an array of byte from the server.

This is my JS function that handle the packet:
...
packetCallback: function(packet) {
message("PACKET CLASSID:"+packet.classId);
//ClassId:100
switch(packet.classId){
case 100:
var localgamedata=packet.gamedata
alert("Gamedata "+ localgamedata);//this display the string reported above
alert(typeof localgamedata);//this diplay 'string'
break;
}

}
...


This is what my server log for the forwarding packet:
...
Forwarding packets: [GameTransportPacket : tableid[1] pid[2] gamedata[{123, 34, 99, 108, 97, 115, 115, 73, 100, 34, 58, 34, 78, 111, 116, 105, 102, 121, 80, 117... (221)}] attributes[]]]
...

and this is what my JS receive in the gamedata var:

eyJjbGFzc0lkIjoiTm90aWZ5UHVibGljQ2FyZHMiLCJkYXRhIjoie1wiZ2FtZVJlZmVyZW5jZVwiOlwiMzMtMVwiLFwicHVibGljQ2FyZHNcIjpbe1wic2VlZFwiOlwiREVOQVJJXCIsXCJ2YWx1ZVwiOjh9LHtcInNlZWRcIjpcIlNQQURFXCIsXCJ2YWx1ZVwiOjZ9LHtcInNlZWRcIjpcIkNPUFBFXCIsXCJ2YWx1ZVwiOjEwfSx7XCJzZWVkXCI6XCJTUEFERVwiLFwidmFsdWVcIjozfV19In0=

The typeof gamedata is string and not array or object.
In Firebase source code there is a js bytearray.js is it helpful? If yes how I can use it to read the convert the string in byte array?

I hope all is clear

Thanks

Pass

Hi again.
I found the response by myself: the gamedata is encoded in base 64.
I used a decode64 function to decode the gamedata and I receive what I expected.

Now the question is why encode the gamedata in base 64? Is this efficient?

Thanks again.

Pass

The data in the transport packets are, as you correct found out, encoded as Base64 due to some limitations in the WebSocket specifications. It is currently not recommended to send binary data over WebSockets and since data in our transport/packets are free form we must assume they can be any binary data; thus we Base64 encode it to be sure.

There is support for pure binary streams in the drafts I think though - tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07, but for now we are sticking to B64.

Sorry about the current lack of documentation around WebSocket support, we have been too busy rolling out 1.8