Different native-code compilers and OSes (not always tied, btw) will
choose different FFIs, depending on local macro- and micro-economics.
Even today we have a choice between calling conventions on Windows (not
always obvious; Rust has changed at least once in its young life).
That is all within the purview of a standard FFI to address. For instance,
the Haskell FFI has foreign import and export declarations that include
calling conventions, and I've seen both ccall and stdcall in practice,
depending on the native library and OS in question.
Haskell 2010> Chapter 8 - Foreign Function Interface
http://www.haskell.org/onlinereport/haskell2010/haskellch8.html#x15-1490008
Haskell code imports a Haskell library interface, it is up to the build
phase of a library with foreign declarations to connect Haskell calls
to native calls, sorting out the OS dependencies.
Sometime around 1997, I worked on connecting Haskell and Java
code via their languages' native interfaces, before they arrived at
today's standard FFIs. I found that the differing implementations
(bytecode compiler/interpreter, native compiler) had come up with
roughly similar solutions to similar problems.
The standardization processes merely removed accidental differences,
and ironed out the kinks, based on practical experience. It also reduced
the need for pre-processors that had been used to retarget a single
Haskell code base to different implementation-specific FFI approaches.
Most high-level languages seem to have some form of FFI (SML, Java, ..).
The OS and compiler release schedules are decoupled from browser
and other JS engine-bearing software cycles.
That's the whole idea of a standard FFI: it allows to specify a stable
interface, so that clients (here JS code running on JS engines) and
providers (here their host platform environments) can evolve
independently, without breaking code.
FFIs are inherently unsafe if not crippled or lumbered with a complex
research project such as NaCl or Xax.
Safety is indeed a major FFI issue, and the dynamic and pervasive
nature of JS environments makes it critical.
However, we have a whole ecosystem of JS code that relies on
webviews nested in native code, where the native code freely
re-interprets webview actions to trigger arbitrary native actions
and to feed back their results to the webview.
JS FFIs already exist in practice. One point of a standard ES FFI
would be to improve and standardize the safety aspects of JS FFIs.
2 provide a window for optimized, cross-browser
implementation of device access, without the work-arounds
currently employed in Phonegap/Cordova and related projects
You seem to have missed the work in the last 8 months in the W3C DAP and
WebAPI groups:
http://brendaneich.com/2012/02/mobile-web-api-evolution/
Gecko pioneered most of these for B2G but Samsung is getting WebKit
patches in. FFIs are *not* the way to integrate device access, note
well. We need the web JS security model, appropriately extended.
I would indeed expect a JS FFI to include a security model as a central
part of the spec.
Note that I'm not talking about, what, the third? or fourth? attempt
to provide a mobile device api (Nokia phones provided device access
before any of these "standard" device API efforts started), but about
a standard language form in which such device apis could be specified.
Since this appears to be a point of confusion, let me restate:
- tc39 would standardize an FFI as part of the ES language design,
it would *not specify any device APIs*
- phonegap, .., device and engine vendors would use the standard
ES FFI to specify and implement their device APIs; there would
still be different device APIs, and there would still be a need to
standardize device APIs, *outside tc39*, but using the ES FFI
- JS engine implementors might find it useful to use the ES FFI to
connect to native host functionality required in the ES spec
Claus
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
