gdp's Comments

Rantings in the dark : easyXDM v1.8.0 relased

Sat, 13 Mar 2010 09:38:58 +0000

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...

Rantings in the dark : easyXDM - extremely easy cross-domain scripting

Wed, 3 Feb 2010 10:15:46 +0000

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!

Rantings in the dark : Ext Calendar

Wed, 20 Jan 2010 07:54:03 +0000

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.�

Rantings in the dark : Ext Calendar

Tue, 19 Jan 2010 22:57:14 +0000

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

Rantings in the dark : Ext Calendar

Tue, 19 Jan 2010 08:18:50 +0000

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 :)

Rantings in the dark : easyXDM - extremely easy cross-domain scripting

Sat, 2 Jan 2010 20:42:46 +0000

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

Rantings in the dark : easyXDM - extremely easy cross-domain scripting

Sat, 2 Jan 2010 16:48:08 +0000

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.

Rantings in the dark : easyXDM - extremely easy cross-domain scripting

Sat, 2 Jan 2010 11:54:02 +0000

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.

Rantings in the dark : Storing multiple privileges/settings in a single integer

Wed, 2 Dec 2009 14:37:36 +0000

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)

Rantings in the dark : easyXDM - extremely easy cross-domain scripting

Tue, 10 Nov 2009 14:28:55 +0000

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.

Rantings in the dark : easyXDM - extremely easy cross-domain scripting

Tue, 10 Nov 2009 08:29:42 +0000

That is the url limit, the hash is not actually a part of this. I remember doing some tests, and I think I got quite a bit more than 2048. But I have been thinking about chunking, although it will create a bit of a overhead as the sending party will have to be notified about the message having been read, so that it can send the next one. For all my applications the size limit has not been a limit, but I guess I could take a look at this as well..

Rantings in the dark : easyXDM - extremely easy cross-domain scripting

Mon, 9 Nov 2009 22:18:22 +0000

As previously stated, WebKit only crashes when running the HashTransport using onresize instead of polling - the usage of HashTransport over the preferred PostMessageTransport is forced to support the test. You can safely try the examples, like http://consumer.easyxdm.net/example/data.html as these will never use the HashTransport when running in WebKit (WebKit supports PostMessage). But yes, again as stated, the intention is for it to not crash in any case, so I'm going to take a look at this. Btw, there is actually a chance that it is the test framework itself that is crashing WebKit

Rantings in the dark : easyXDM - extremely easy cross-domain scripting

Mon, 9 Nov 2009 22:07:27 +0000

These are both based on the WebKit browser engine, so I was pretty much expecting that much..

Rantings in the dark : easyXDM - extremely easy cross-domain scripting

Mon, 9 Nov 2009 21:15:13 +0000

I just tried it in the newest Chrome and can confirm that it crashes - the previous version did not. From what I can deduce its the hashprovider that causes it to crash when using the resize event instead of polling. Under normal use this will never occur as easyXDM will use the PostMessageTransport in Chrome and all other browsers that support this. But still, the library should not crash any browser - kinda funny how such simple code can do so :)

Rantings in the dark : easyXDM - extremely easy cross-domain scripting

Sun, 4 Oct 2009 15:02:27 +0000

Sorry about the delay :) The code looks correct, and if you say that you did receive correct data earlier then there is no reason why the value of the input fields should not reflect that. The best way to debug this is to look through the easyXDM trace output and verify that the message is indeed correct, and then step through the code using e.g firebug and breakpoints.. If you supply a url I could take a look.

Rantings in the dark : easyXDM - extremely easy cross-domain scripting

Sun, 4 Oct 2009 14:58:06 +0000

Sorry about the delay, but I need a bit more information than that :) But as soon as you mix http and https you create a boundary due to the Same Origin Policy. If you could provide a link I could take a look at it..

Rantings in the dark : easyXDM - extremely easy cross-domain scripting

Sat, 5 Sep 2009 13:42:22 +0000

For easy inclusion of this table you have two options, either having the consumer insert a script tag pointing to a dynamically generated script on your domain, which would in turn add the needed DOM elements, or by having an Iframe pointing to a url on your domain. These are the ONLY options you have. If you plan on more advanced scenarios I would use the iframe option much like in the example found here http://easyxdm.net/example/methods.html . This gives you the option of presenting an iframe with visible content (your table), as well as exposing/consuming methods across the boundary (and yes, these methods could involve XHR calls). Of course, if you start by going down the script tag path, then you could actually use the js to load all needed libraries (like json2, easyxdm etc) and also to insert the iframe. This way the consumer only needs to insert a single script tag. But either way, I'm gonna have to disappoint you, Iframes will be involved if you are looking for advanced functionality :). But this really should not be a problem when using easyXDM. (and no, there is no other way ;) Du kan eventuelt sende av gårde en e-post om du lurer på noe mer :)

Rantings in the dark : easyXDM - extremely easy cross-domain scripting

Thu, 27 Aug 2009 10:39:41 +0000

oyvind at kinsey.no works fine :), it also works for IM in msn and gtalk. I would love to hear about how the library is working for you, and where it might fail.

Rantings in the dark : easyXDM - extremely easy cross-domain scripting

Thu, 27 Aug 2009 09:57:16 +0000

what version are you using? in hash.html, transport should be all in lowercase letters. This was changed with 1.5.1 i think :) This is the cause :)

Rantings in the dark : easyXDM - extremely easy cross-domain scripting

Wed, 26 Aug 2009 15:45:00 +0000

Do you have hash.html present on the local domain? In IE7 easyXDM falls back to using HashTransport, and this demands the presense of hash.html. Are you using tools like Fiddler2 and maybe a scriptdebugger? If onReady is not called (most likely due to hash.html not being loaded) nothing else will work either. Also, I suggest that maybe you try setting up the transport example just to make sure the basic communication works.