On Friday, November 11, 2011 4:38:23 PM UTC+1, John A. Tamplin wrote: > > On Fri, Nov 11, 2011 at 5:16 AM, <[email protected]> wrote: > >> I'll reiterate my question: is there any plan to move to js-ctypes? or >> is there some better alternative? or are binary components and >> recompiling every 6 weeks a necessary evil? >> >> I mean, have you looked at the problem yet? and if so what's the >> outcome? and is there a plan on your side? >> >> If you believe js-ctypes could work, but do not have time/resources to >> invest in moving to them, then maybe I could try it on my side. But if >> you already looked at it and know that js-ctypes won't work, then I >> won't invest time. And if you have a plan to do the move on your side, >> then I'll wait too. >> > > From a brief look, it seems there is no way to get a callback when an > object is no longer referenced -- this is required to free the Java object > that has been wrapped on the JS side once it is no longer referenced. It > also wasn't clear how to create a JS object that wraps a Java object and > intercept all the methods, but I assume that part can be done in JS. >
Re. intercepting methods, it's possible using proxies (will be in EcmaScript 6; usable since Firefox 4, but discouraged): https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Proxy and the non-standard __noSuchMethod__: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/NoSuchMethod > Aside from that, it looks like it is just moving parts of the problem > around. Instead of having FF load the correct binary based on the > platform, it looks like it is up to your JS code to figure out what to load > (though the examples seem inconsistent, so maybe it isn't that bad). > As I understand it, in the case of the DevMode, only the "common", browser-independent, part would be "binary" (there might not even be a need for glue code, or only for calling back to the JS engine) and everything else would be done in JS; so it'd save us from compiling one version of the binary component per Gecko SDK version, only one per OS. So releasing for a new version of Firefox would mean, in the best case, only bumping the maxVersion in the update.rdf; something that can be done by anyone locally, and you no longer have to wait for the SDK to be released. That'd also make it possible (and really easy) to test/use the plugin on beta or aurora versions. All the calls from the plugin to the JS engine will have to be proxied > through the JS code (for example, I didn't see how to allocate a JS > string), which will mean a lot of boilerplate and a likely performance > impact. > > So, assuming the finalizer problem can be overcome, I think it would be > possible but would be a lot of work to get worse performance. > Searching a bit on the MDN, I don't see how the finalizer issue could be worked around, so I guess it's a show-stopper. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
