On Sun, Jun 7, 2009 at 12:38 PM, Matt Mastracci <[email protected]>wrote:
> BTW, one advantage of this XPCOM version is that it would work on both > FF 3.0 and 3.5. The current OOPHM XPI fails on 3.5, as the Moz devs > changed some of the JS type constants. JSVAL_VOID (the effective > internal signature of the "undefined" value) is unfortunately an > entirely different constant value in 3.5. > The library names and symbols defined in them were also changed, at least for FF3.5b4 running in Fedora Core 11. It was also changed, and not compatibly, in FF3.1 on some platforms but not others -- I haven't had the time yet to figure out how we are going to support all these options without having tons of packages and making the user install the right one. These issues do make the idea of downloading the real plugin from a shim seem more attractive, but I really worry about 2 things: - security -- this would be opening up a hole to download and execute arbitrary native code in the browser, so we need to be *very* careful about it. Perhaps we can use techniques from the Google native client implementation or rely on PK signatures on the downloads (which would mean developers couldn't easily build their own versions for testing as they wouldn't have the signing key), but this would definitely take some time to make sure it is rock solid - how do you hook up the calls in the downloaded code to the browser? I'm sure it is possible, but it doesn't seem obvious how a version agnostic plugin would be able to hook everything up correctly, since we wouldn't be using the normal dynamic linker. Perhaps it is as simple as writing the downloaded code to a .so file (or equivalent for other platforms) and letting the dynamic linker handle it normally, but it sounds like this will take some experimentation -- John A. Tamplin Software Engineer (GWT), Google --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
