easyXDM – finally with queuing and fragmenting!

With the newest release, 1.7.4 (see the commits here), we have added two important features, fragmenting for the HashTransport, and queing for both the HashTransport and NameTransport


The first is definitely something that many has been waiting for, until now the HashTransport class just didn’t cope with messages that would create URLs longer than 4095 character (the maximum size allowed by IE6). If a longer message was send (something that could easily happen when using the Interface class), the transport would just fail. But not anymore, you are now able to send however long messages you’d like, and of course, this was all made possible with the new queuing feature.


Until now, when you tried to rapidly send messages, if you were so unfortunate to do so before the message had been read, it would be overwritten. This was especially easy to do when the HashTransport was in polling mode, as it then only checks for new messages every 300ms.

Both the HashTransport and the NameTransport has now been extended with a live casino sites queuing feature, meaning that all messages will first go into a queue, which will then be emptied in a LIFO fashion.


easyXDM just got even better, thats about it. The only known feature request as it is now is message receipts, making the transport completely reliable, but I’m think this probably belongs in the Channel class..

By the way, the Continual Integration system has now been set up so that the test suite for the current head from GitHub will always be available at http://easyxdm.net/dev/tests/.

And one final thing: The project has finally got its first contributors!

Tags: , , , , , ,

This entry was posted on Monday, February 22nd, 2010 at 20:11 and is filed under easyXDM. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

  • Maneesh Gupta

    Sean , Do you have any sample code for the message receipts(reliable) and error handling , i tried out all websites could not find any exaples for the same.

    • Could you be a little more specific? All the transports are reliable, so if you want receipts then you need to implement this on top of easyXDM’s transport channel (although I see no reason why).

      What kind of errors are you trying to handle? easyXDM either works or it doesn’t – it’s pretty robust.

      • maneesh Gupta

        Thanks Sean for quick response…
        I am using SameDomainTransport and specified the acl in provider like as acl : “http://example123.com” now my consumer which is on loaclhost able to recieve the message which is wrong as per my understaning only http://example123.com domain would get message not others . Please correct if i am wrong.

        Other thing if am throwing exception like this below:
        concatNames: function(a, b){

        throw new Error(“foo error”);


        do you think i should get message in the consumer error callback but i am not getting any error.
        remote.concatNames(a1, a2, function(result){
        var a3=result;
        alert(a1 + ” + ” + a2 + ” EQ= ” + result);

        alert(“error” + error);

        • The acl feature should work – it’s tested in the test suite – I would have to know more to be able to debug. Perhaps you could trace using firebug or something and see whats going on?

          About the errors;
          from src/stack/RpcBehavior.js

          try {
          var result = fn.method.apply(fn.scope, params.concat([success, error]));
          if (!undef(result)) {
          catch (ex1) {

          So the error should be caught and returned to the error handler – also, the test suite tests this, and it works.
          What behavior are you seeing?

  • maneesh Gupta

    easyXDM- do you have any example how to use acl feature , I am integrating acl with provider but eventually unspecified consumer getting the message from the provider , is there any bug in the implemenation , please specify….

    • You should continue this on easyxdm.net, or on the google group.
      The ACL feature is pretty simple, this is copied verbatim from the docs (http://easyxdm.net/current/docs/?class=easyXDM.Socket)

      acl : Array/String
      (Provider only) Here you can specify which ‘[protocol]://[domain]’ patterns that should be allowed to act as the consumer towards this provider.
      This can contain the wildcards ? and *. Examples are ‘http://example.com’, ‘*.foo.com’ and ‘*dom?.com’. If you want to use reqular expressions then your pattern needs to start with ^ and end with $. If none of the patterns match an Error will be thrown.

      If you have examples of this not working, then I would like to see the consumers domain, and the used ACL entry.

  • Quỳnh Như