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

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!

Bookmark and Share

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.

Leave a Reply

blog comments powered by Disqus