A small bug was discovered that would affect large messages sent using the HashTransport.
The bug only affected messages that would increase in size with more than ~100 characters when being encoded.

http://github.com/oyvindkinsey/easyXDM/commit/1ef...

For those concerned about the size limit in IE6 and 7 due to the use of HashTransport - there is now a new fallback transport available, the NameTransport (http://easyxdm.net/docs/?class=easyXDM.transport....
As far as I have seen, this can handle >150k messages :)
Note that you need to supply a new parameter, remoteHelper for this to kick in!

I'll see if I have time to take a look at it.
This was done a long time ago and can probably be done better - including support for using a datastore. 

Is actually right there in the comments,
<pre>
_cal.loadData([{Text:"sampleevent",Id:24234,StartTime:_startTime,EndTime:_endTime}]);
</pre>

Hm, I was sure it used a store, maybe I did that with a later version somewhere else..
Anywhat, it should be quite easy to extend it with a store. Just bind the deleteTimespan, updateTimespan etc to the proper events and vice-versa :)

And its out! See http://kinsey.no/blog/index.php/2010/01/02/easyxd... for more.

Just consider the consequences of how the jQuery plugin falls back to modifying the hash of the parent frame, and how it needs the exact url of the page.
One of the important goals of easyXDM is to be nonobtrusive, that is, not modifying any of the behavior on the primary page, and modifying the url of the main page, and also jQuery as a dependency, is what I consider obtrusive.
I\'ll release a version that will be able to utilize any file located on the main domain, like robots.txt or favicon.ico later tonight - I\'ll give you a heads up.

Hash.html is only used to support older browsers that does not support the postMessage interface, so if you can live without this, it will still work.
I\'m going to see if I can get something to work that doesn\'t rely on the user having to upload files - maybe by using the robots.txt file or something, but this will not be as efficient.

This has nothing to do with obfuscating, only with the logic for storing and retrieving privilieges in the simplest way - but if you want to, then yes, you could use hex-notation to specify the values.

The follow-up post is already published, http://kinsey.no/blog/index.php/2009/11/17/modify... and gives an example on how one could view/modify such a value through using Javascript/ExtJs.

As always when it comes to enforcing security in a webapplication, this has to be done both on the server (to actually enforce the restriction) and on the client (to avoid the user trying to do something he wil not be able to do)

The maximum lengt of the url might be 2048, but the maximum length of location.href is 4095.
You can check this your self at http://easyxdm.net/hashlength.html
Do NOT open this url in any browser except for IE6/7. This will cause it to loop for ever as Firefox etc has support for very long hrefs.