This is cool and quite simple. But we don't just want ffi to native libs but also jvm and .net monstrosities. Since Arc is such a web2.0 language maybe some thing like a client server arch for ffi as in each language has a "ffi-server" like native-c, .net, java, python, perl ... arc connect to it via TCP and calls functions and gets data back. This could be optimized further and I think facebook has some thing like this (link any one?).
What you describe is very standard way to do a ffi - am trying to think out of the box, can I get any help?
Client-server sounds more like RPC than FFI. That leads to SOAP and WSDL, or XML-RPC if you want something lighter weight.
The biggest problem I see with implementing FFI through a server is it's very expensive if the server needs lots of the client state. For instance, suppose you implement matrix determinant in C for speed. With client-server, you'd need to copy the whole matrix across the connection; with local FFI, the C code can access the matrix directly.
Well, the client-server stuff can easily be done through sockets and a dedicated protocol on the native-process side. There are many such protocols, but this is not what I am after. I need ease of use (and, for other cases, speed).
Very standard, I know, but (as for now) I just want to use POSIX functions for a system utility. Picking in a .so file is just what I need. I don't want to start a server process, secure it (we're talking about functions manipulating my system and available to others through the net) and then communicate with it.
As for JVM and .Net, I totally agree with you. When I'll have something working, doing (for example) a JNI wrapper should be easy.
