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
Fragmenting
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.
Queuing
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 queuing feature, meaning that all messages will first go into a queue, which will then be emptied in a LIFO fashion.
Conclusion
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!
My name is Øyvind Sean Kinsey and I am currently a software engineer at