I don't see how a FFI could really help developers. What would be needed
is a not empty intersection between
http://developer.apple.com/library/safari/navigation/,
https://wiki.mozilla.org/WebAPI, WHAT WG, W3C, etc, unfortunately it is
not the case at all
Or something like phonegap if it can become a standard (out of TC39)
The reality today is that it has became impossible to developp a web app
supported by all platforms in a way that it looks like a native app
(unless you get the fundings and appropriate team, or use something like
phonegap, but what do you know about the future of phonegap ??). It
requires too many efforts, my last projects are plenty of hack/hook (if
ie, if webkit, if webkit & ios, if bada, if blackberry, if ff, if
webkit & chrome, if, if, if...), and attempts to use build-in js or css
features (animations, motion, ...) generally lead to very poor results
(of course there are plenty of perfect examples showing that this works
very well, but once the examples get modified to match reality, it never
works correctly), on your way you can be blocked by some surprising
implementation orientations (like bada deciding not to implement the
synchronous xhr), then moving forward usually you have to decide to
eliminate some platforms. At the end, finally, you can package your app
for selected platforms and your are welcome to put it on hundred of
stores, pay for it, wait for reviews, share revenues, maintain it, etc
B. Eich is mentionning the good unification efforts in terms of
specifications but some parties are missing and some regressions did
happen too.
Indeed, in all this process you might have decided to use some well
known apis for your apps, and one day you might discover that the apis
have been shut down or that you have to pay for it, or that you will
have to pay for it, or that it will be shut down and replaced by
something else less performant that you must pay too. This is not fair
of course since the community did participate to build these apis and
just get in return the fact that its apps will no longer work, this is
exactly my case today for past projects and ongoing (now blocked) one.
Nothing to do with the initial subject ? Yes, it does, "the actual (web)
world is (not) the best// of all// possible worlds" and I don't think we
can afford continuing having exploding number of platforms, systems
with different behaviors and no unified specs (not talking about tc39 here)
Maybe it's a dream or it's alreday too late
Le 22/05/2012 11:40, Claus Reinke a écrit :
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
--
jCore
Email : [email protected]
Web : www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
