Claus Reinke wrote:
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
You can stop right there. We have one major Haskell implementation.
"Standardizing" (I'll use your scare quotes cited below, and more
fairly) an FFI for a single-implementation language "spec" is a
different and far easier problem than trying to specify and agree on a
single FFI for all JS engines in top N browsers today!
Most high-level languages seem to have some form of FFI (SML, Java, ..).
SML is also effectively single-implementation as far as an FFI
"standard" goes. For ES4 we used SML-NJ and dherman experimented with
Milton but they don't implement the same "SML".
If by FFI you mean the JNI, Java is effectively single-implementation
too, because it was single-implementation when JNI was standardized.
I recall the early days, competition between what became JNI and
Netscape's JRI. By the time IBM and others tried advancing different
Java VMs, JNI had won. No such happy history with a JS FFI (of course
similar get-on-first game theory helped JS to become a standard).
I'm not saying it cannot be done. I'm saying the odds of success are
vanishingly small. The time to try this is when a market power or
monopoly dominates the web, but even then, the security research
required to restore safety may be too hard to yield practical (usable,
sound) solutions, even when imposed by a monopoly. Remember Active X and
its trust zones?
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.
You're missing my point: the OS and compiler vendors are not Ecma TC39,
and they do not want to be constrained by JS's FFI this way.
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,
Glad I brought it up! :-P
Seriously, another difference that you've neglected is the server-side
or single-machine/admin nature of Haskell, SML, Java, etc. (ignoring
research projects). A standard FFI in JS callable from the Web in the
top N (4 or 5) browsers? That is a security nightmare on its face.
Security needs to be addressed up front, yet your first message did not
even mention the word.
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.
Are you referring to so-called "hybrid" apps on mobile devices? If so,
the webview's embedding API is much safer than a raw JS FFI. There's no
comparison.
If you mean hybrid apps contain native code that can call any loadable
library, of course that's an unsafe set of APIs. More below, but
observing that does not make the case for a standard *JS* FFI.
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.
There is no de-facto standard "webview FFI". Any "webview" embedding API
is not a general FFI. You're abusing the "FFI" TLA and slapping it on a
great many things to try to equate them all, when in practice those
things differ in kind as well as degree.
Of course, hybrid and fully-native web apps are insecure. Some vendors
claim to curate a single app-store to uphold quality standards including
security. Others don't even review what's in their store. It's a mess.
This is not a recommendation!
Let's get concrete in terms of JS engines and their FFIs.
If we take just the top open source engines' FFIs, we would have a
smaller target to try to standardize, but again that leaves out too many
players, and it defers security until "later", trying to enforce safety
properties on top of an inherently unsafe API. And we still face huge
diversity in, e.g., GC API details (exact vs. conservative vs.
ref-counting or a mix).
With Emscripten and LLJS we're taking a different route: build on the
browser security model by compiling low-level JS using typed arrays and
more extensions in the future, but never throwing safety out and trying
to restore it later.
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.
This is a non-starter. Of course, we're way past it in the W3C, whether
you like it or not.
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)
Nice dismissal of the recent standards work! Your scare quotes do not
scare, though. The problem with past attempts were that they did not
enlist browser vendors and get patches into the open source engines.
That failed, indeed. (I won't digress on the broken economics and
politics of DAP prior to last fall, or the WAC, but we've gotten past
all of that.)
The specs listed in my linked blog post are moving forward. Some are in
Last Call, about to become W3C RECs. It's happening, and an
unsafe-up-front JS FFI, with some kind of super-science safety-property
enforcing add-on is not happening.
This both a rude fact-pattern that monkey-wrenches anything like your
proposal (equivalently, Google Native Client, note well), and something
to study to understand the "why" as well as the "what", in order to
follow the "laws of physics" constraining the possible outcomes.
, but about a standard language form in which such device apis could
be specified.
When you write about "could be" or "ought", I suggest grounding what you
write in what "is". There is zero chance of an FFI standard emerging in
the foreseeable future in Ecma TC39.
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*
The confusion is all yours. No one will go the impossibly long way
'round of standardizing an unsafe FFI, then adding safety, then letting
device APIs grow on it like mushrooms in the dark. That's not going to
happen, and for good reasons adduced above.
- phonegap
... is becoming a shim library on top of the standard device and web
APIs linked to from my blog. (From Brian Leroux of Phonegap/Adobe.)
, .., 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
The shorter path is already being taken to route around the
infeasibility of what you propose.
- JS engine implementors might find it useful to use the ES FFI to
connect to native host functionality required in the ES spec
Lots of things "might" or "could" be useful. It's software, almost
anything is possible with enough effort and (this is important)
coordination or (among competing parties) cooperation. But let's be
realistic.
When you propose six hard things,
1. Unsafe FFI standard across JS engines, implying:
2. OS vendor agreement.
3. Compiler vendor agreement.
4. "Security-last" restoration of important safety properties. This is a
huge amount of work, technical and meta-tech/political.
5. Device and other browser extension APIs built on top of the standard FFI.
6. FFT libraries, etc. (this thread's subject).
the multiplication principle means the likelihood of success is a tiny
fraction near 0.
Also the path length in time/money to reach anything like the device and
web APIs already in Gecko and going into WebKit is too long:
indefinitely many years. Shorter paths win and they've already been
taken. People route around insuperable odds, especially on the Web.
A closing plea: please don't cite Haskell implementation experience
freely as if it were by default relevant to JS standardization. It's not.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
