I just looked into it, and it looks interesting for one part: the IPC one. But 
otherwise, the API seems a bit confusing. Therefore, I have some questions:

- How do we offer native functionality to a user?
- How do we simply compile the "module", and how is it properly used?
- What can we do to implement said things with NPM? AKA. how is this NPM 
compatible?
- How does one deploy a module using this "binding"?

The IPC part, as said, is quite an interesting part, as the only real good c++ 
library that offers a proper implementation is Boost - problem is, that not 
everyone wants to build the whole bulk of it. So an "extratable" implementation 
for other, non-nodejs-oriented, applications and libraries would be quite 
interesting.

This is just some questions I got at first glance. Otherwise, the idea is quite 
good :)
Am 25.03.2014 um 13:47 schrieb Liam <[email protected]>:

> I've recently posted a prototype of this project; feedback appreciated...
> 
> https://github.com/networkimprov/lode
> 
> 
> lode brings C/C++ libraries to Node.js applications
> 
> 
> Copyright 2014 by Liam Breck
> 
> Rationale
> 
> 
> Achieving the potential of a high-level language like Javascript requires 
> making the huge population of C & C++ libraries accessible within it. 
> Currently the common approach to this for Node.js is to create a C++ module 
> containing "glue code" that moves data between Javascript and library calls. 
> Such a module must use the libuv and V8 apis.
> 
> The V8 api is arcane and poorly documented. Its use requires a lot of code. 
> Its misuse causes subtle crash and memory-leak bugs. Implementing 
> asynchronous calls on libuv requires before/during/after functions. 
> Third-party glue modules may stop getting updates, or evolve in unexpected 
> and unhelpful directions. These issues are a barrier to the possibilities of 
> Node.js apps.
> 
> The lode toolkit lets C/C++ library users and developers focus on the library.
> 
> Mechanism
> 
> 
> We need JS access to a C library, "libxyz"
> 
>           | app.js
> process A | libxyz.js api module: check args and form JSON messages (unique 
> to libxyz)
>           | lode.js module
>           | node
> 
>     JSON messages via Domain Socket
> 
>           | lode shell
> process B | libxyz_lode.so glue code: call library, package results (unique 
> to libxyz)
>           | libxyz.so|a
>  
> The lode shell app can handle many requests concurrently, and is designed to 
> hand-off requests to glue code without a context switch beyond any incurred 
> by use of the socket. This mechanism should be nearly as fast as asynchronous 
> operations within the Node thread pool.
> 
> For applications that cannot bear the modest overhead of IPC, a version of 
> the lode shell implemented as a native Node module is envisioned. Such a 
> scheme would also permit synchronous invocation of the library api.
> 
> [more]
> 
> --



-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to