On 22 May 2012 12:54, Aymeric Vitte <[email protected]> wrote: > I don't see how a FFI could really help developers. >
FFIs are certainly helpful in many situations. I don't think this is one of them. Let me relay a relevant xperience. We develop applications in "Server-Side JavaScript". We have an FFI that, with some magic compile-time shims and a few other tricks, lets us write close-to-the-bare-metal applications that are portable without platform detection across many operating systems -- in fact, I believe, to any conformant SUSv3 implementation. We write nearly-C-like code on Linux, Solaris, and Mac OS X, 32 and 64 bit, to give us nice JS libraries on top of the ugly, bare metal. Our implementation is complete enough that we were able to write a complete WebSockets implementation in JS, that runs on many platforms, with no direct support in the host environment other than FFI, right down to the networking system calls, including the magic macros for select (FD_CLR et al). Sounds great, right? Well, it is for us, but it would make a lousy direction for a standard: the resultant JS is completely non-portable to Windows. Or QNX. Or Gronch. Or a myriad of other operating systems. And that's the real problem. We have overcome the typical "C porting" problems -- endianness, word size, whether fstat() is a function or a macro, etc..... but we're still nowhere close to being portable to where the web needs to run. If we want to run anywhere, we would need to FFI up one layer of abstraction, to something like APR or NSPR, and then guess what? We would be no better off in any way than what the standards guys have been up to -- and far, far, worse off in many. That's why I believe TC-39 is not the right place for a JS FFI. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
