roadmap and next milestones about node.native HOT 34 CLOSED

Sorry @dennycd . Just checking in here so you know you aren't being abandoned. I think a great way to start moving forward would be to compile a list of features that we already have and document those APIs. This will give perspective on what we already have, and give would be contributors an idea of how to lay things out when it comes to adding new features. Really is awesome that you are showing interest, its appreciated.

from node.native.

@divanvisagie, based on my read of the master source, the following modules are present

• net::tcp
• http
• fs (some feature missing)
• stream (incomplete)
• utility (incomplete)
• EventEmitter

according to @d5 's v0.1.0 branch plan (https://groups.google.com/forum/#!topic/nodenative/r9s7WMOwcT8) the following is being planned

• EventEmitter
• Stream
• net::Socket
• net::Server
• http::Server
• http::ServerRequest
• http::ServerResponse
• process
• Buffer

will have to look into v0.1.0 branch source to see where @d5 is at ;)

from node.native.

I guess this is a good chance to talk about the big picture of this project: what's the main goal of this project? what do we want to solve?

The very first question: is node.native purely a C++ 11 port for node.js?

One of the challenges that I had faced in node.native was the design of node.native API. Do we really want to provide the same set of APIs as that of node.js (http://nodejs.org/api/all.html)? What about the patterns? And, what about the syntactical differences in language?

My answer was... No.

When I started this project, I just wanted to create a C++ 11 based framework that simply implements the notion of 'an event-driven, non-blocking I/O model.' Yes, I have to admit that 'node' in 'node.native' name could be a little bit confusing and controversial. However, that name itself explained pretty much of the fundamental concept of this project to many people, and, it really worked well.

Even with different language syntax, features, and limitations, I guess we can provide almost the same API as JavaScript one. But, it comes with a certain amount of costs: performance and usability. Does that really make sense? Do we really need to sacrifice the benefits of nativeness of C++ 11 for such things?

I want to ask you guys and hear your thoughts on this question too.

from node.native.

I don't think an API surface that's identical to the nodejs is really a requirement. Using it for inspiration is probably as far as it should go.

I'm personally more interested in something like npm. This way the community can chip in and provide the supporting modules that we need, leveraging existing libraries out there. Maybe something simple using gyp and and npm or bower clone, with a simple source based repository using git.

from node.native.

throwing out my thoughts here ;)

What node.native gets people excited is its native performance and the potential to build scalable networking applications on top of it. It uses the same platform layer (libuv) as node.js which makes this single-threaded non-blocking async model available to C++ programmers. That being said, there are trade-off and compromises, as you can see from the discussions

• http://www.theregister.co.uk/2012/02/17/node_js_native_c_plus_plus/
• https://news.ycombinator.com/item?id=3565440
• http://stackoverflow.com/search?q=node.native

as the user-land language go down from Javascript to C++, we lose some degree of simplicity and guardian against errors, issues like memory management, buffer overflow, pointer handling will have to be carefully considered by people who are using the framework. This is going against making node.native scalable as the complexity will grow and more error-prone when people are building on top of it.

Now, I still think it is a brilliant idea to start with looking at node.js, dumping its V8 Javascript Interpreter layer but inherit its programming model and some of its native platform layers. But if we wanna really develop it into a framework that people can easily adopt, we will have to think about how to make user-land programming simple. (by user-land I mean people who are using node.native to build their own stuff, either new modules or apps, which is separate from the native core which are the code base we provided).

One virtue of node.js is its modularity that a single js file sits within its own namespace, only export what it wants to expose and imports what it wants to use. But what's more important is that when you run "node foo.js " you are loading in a piece of javascript code and then run it as part of this node "virtual machine". The current API/interface of node.native is sort of the classical Cpp library way where we provide a code base that users can link against and they are building their binary.

So here's a thought: we build node.native as a C++ "virtual machine", define a set of rules on how user-land C++ programming model should looks like, let the user write their node.native source code, we then run "native foo.cpp" to interpret user's source code. This way, we will have an opportunity to achieve both user-land simplicity while providing native performance for scalable apps.

How ? we may have to go down one layer and look at the compiler to see how we can utilizes some of the features. For example, Clang compiler front-end from LLVM has a programming interface (libclang) that allows people to extend c++ and build interesting stuff like

• language level reflection
• C++ Interpreter

We may utilize it to impose programming constraint on the language level in order to simplify the user-land interface

from node.native.

@dennycd I would think things would still need to be compiled at the end of the day, though doing so using only node main.cpp would be great.. all linking handled etc... basically a nice module system for C++

from node.native.

Yes, we could do this using dynamic linkage, similar to the way how node's native C++ module works.

On 2013-08-24, at 11:04 AM, Divan Visagie [email protected] wrote:

@dennycd I would think things would still need to be compiled at the end of the day, though doing so using only node main.cpp would be great.. all linking handled etc... basically a nice module system for C++

—
Reply to this email directly or view it on GitHub.

from node.native.

@d5, I agree that trying to provide an API clone is not really necessary. node itself is going through intensive development and we will have a hard time keeping the API in sync with theirs, and we will end up reinventing the wheel for a lot of stuff.

from node.native.

@dennycd I think we can start with something simple that takes a standalone C++ file and automatically compiles + runs it using native main.cpp and also automatically give it access to the native namespace automatically and silently , ie, the user does not have to include node-native to access its core libraries.

from node.native.

@divanvisagie good idea. I will start from on a new branch to test it out.

from node.native.

I like the idea of starting simple. I just hope we don't pick the most challenging agenda. But, I really appreciate @dennycd for taking an ownership on this C++ module system.

from node.native.

This looks interesting.
My requirement is similar, but I am no experienced techie. I need some inputs from you guys for a business decision.

1. My webapp is mainly about rendering 3D content where users can create objects for 3D printing. They can create multitude of daily usable objects.

2. I will be using geometric kernel/libraries like CGAL(written in C++). It does all the core geometric operations like representing solids, doing boolean operations on them.

I do not want to re-write CGAL entirely for web and neither do I want to write a brand new geometric modelling kernel. Also, there are binding for CGAL in Java and Python. But they are not complete(it is work in progress).

So, my best choice is to have a web interface working with CGAL(in C++). And also I must be able to scale it if the demand grows. node.native looks good choice.

However, let me know the following:

1. I am worried managing memory, buffer overflow, pointer handling et all...is gonna trouble and users might experience huge errors. :( Have you guys worked with node.native on production. If yes, whats the scene like w.r.t above mentioned areas?
2. Does node.native give any advantage over embedding C++ in V8? https://developers.google.com/v8/embed
3. Any other inputs you want to give w.r.t my specific need.

from node.native.

@karims First I would like to take into consideration what language you are mostly familiar with. If you are creating a production level system, using the language you know the most may be a huge advantage for maintenance sake.

from node.native.

@divanvisagie I'm good with PHP, javascript, python. Also, basic familiarity with node.js. I am flexible in terms of language for web.

from node.native.

@karims
Q1: haven't used node.native in production work myself. This is one area we are hoping to improve for the next milestone release which is to simplify user-land programming and reduce coding complexity. But on other hand, you can always try to follow best-practice and use some of the new C++11 features which would help (e.g. shared/unique pointer, auto vars, or the new threading std). Again, since you are writing C++ code, some pitfalls are unavoidable and the more experience with it the better ;)

Q2: I believe yes, performance is one thing. If you are wrapping CGAL as a native node module and invoke the lib from Javascript space, you are essentially passing multiple layers of function calls (V8 layer) before it reaches the C++ library function in CGAL. If the function is invoked repeatedly in a large loop, or gets called frequently as a result of client-side request, then there will be huge performance gain ( bypassing the V8 layer and call the function directly from node.native) . The other thing would be parameter passing when interfacing Javascript object and C++ object. You might have large geometric data structure that is costly to copy and pass around.

Q3: I think in your case you need well-supported web components to work with (e.g. express, socket.io) but unfortunately they are all native javascript modules. Alternatively you can have a look at some pure C/C++ http server projects which could give you a web server interface while also alllow you to directly work with CGAL library as well. Have a look at stackoverflow (e.g. http://stackoverflow.com/questions/175507/c-c-web-server-library) I remember there are a few of them (boost.asio, libpion, lighttpd etc.)

you can definitely try node.native master branch and use it as your httpsrv front-end component. But at current stage you will have to implement some extra stuff to reach what you need (e.g. static file serving, URI handling, request/response conversion to/from geometric data structures etc. )

hope this help ;)

from node.native.

@d5 @dennycd So this happened: https://github.com/substack/dotc

from node.native.

Great. Someone did half the work for us, now we need to find a way to integrate it ;)

Sent from my iPhone 4S :-|

On Sep 19, 2013, at 12:52 AM, Divan Visagie [email protected] wrote:

So this happened: https://github.com/substack/dotc

—
Reply to this email directly or view it on GitHub.

from node.native.

I'm very interested in a project like this succeeding. It is very clear to me that a C++ web/app "server" is going to be where all the action is. I think people getting serious about HTTP applications are disenchanted with the LAMP stack and since the HTTP protocol is fairly simple, will be moving to Node like platforms.

If I may suggest some direction.

Understand who you're creating this for ... developers creating HTTP servers where every client has its connection and state persisted. Intel i7 servers with 16GB of RAM are cheap. So, an event based, message queue, and threading management server API with a simple interface ... that is your goal.

Offer support for the most common needs. HTTP parsing with an OpenSSL wrapper. A message queue API so that in the event callback (new HTTP client) you can post a long operation to a thread or thread pool (the message queue).

Provide really easy examples for your target audience.

Don't force your users to install build tools and assemble the sources. Provide a single header and single C file if possible, otherwise explain clearly what files to link.

If we successfully pull this off, there are a lot of people hosting web apps who are going to want this. Standard C and C++ syntax is pretty easy to use. Getting to simply create some struts or class objects and pass 'em around using node.native would be sweet!

from node.native.

@pcunite thanks a lot for the input. Glad that u find the project motivating as we do ;)

from node.native.

I am interested in node.native as it would give me an easy way to develop a program which is an HTTP daemon and could incorporate all the C++ code we have in our company. Right now, we have a need to develop an IPP implementation (a version of CUPS - www.cups.org). This is essentially a web server, which accepts and makes POST requests to accept and send print documents. node.native would make this really easy. However, I don't think the project is complete enough to use - it doesn't seem like there's any way to get at the POST data, and I don't think there's any SSL implementation; so no HTTPS, which is a requirement. I could help bring these into the project, but I'd need some assistance to get me started.

from node.native.

Some more examples of using the code would be useful - a bit more than the existing webserver.cpp/webclient.cpp example code - wouldn't have to be much to be really useful.

My alternative is to use boost::asio to implement the server and do some home-made http parsing.

from node.native.

@sebjameswml thanks for the message. As discussed earlier in this thread, the current node.native implementation is a very bare-bone http server. We are in the process of planning for the future milestones of the project and your input & contributions are most welcome ;)

from node.native.

I'm back to looking at node.native again - I found out how to get at the body of the request (pull request to follow). I'm trying to resolve the problem in issue#28 first - what to do on socket close and why the delete causes a crash.

from node.native.

@dennycd I have to say - I'm not convinced by the native.vm idea. For me, being able to use node.native as the entry point for my own C++ code is just fine - I don't feel any need to be able to run my cpp program as if it were javascript interpreted code. Do you think there are many people out there who'd want to work with node.native like this?

from node.native.

@sebjameswml ideally people would be using node.vm the same way as they are using node.js right now, except that they will be writing c++ instead of javascript, with improved performance (w/o V8 layer) and easier integration with existing cpp/c libs. But I agree the goal is a bit over ambitious and it is not clear how useful it would be. I actually like @pcunite 's suggestions to go with a cpp web/app server approach and develop node.native into such a framework.

from node.native.

@dennycd - I'd counsel to keep things as simple as possible. I also agree with @pcunite and I think that is a good description of an initial milestone. I plan to try building my app with what is already in place (plus the one or two changes I've made). If that seems to be working out, I will think about adding the OpenSSL support to provide an https as well as an http API.

from node.native.

I am probably missing the point of node.native; but what I am looking for is a simple + efficient C++ micro-HTTP-stack with routing.

So I can bind functions to routes.

Obviously other features such as HTTPS support would not be amiss.

Is this something possible to do with the current node.native, or is this on the roadmap even?

from node.native.

@AlecTaylor can you explain what you mean by "routes"?

from node.native.

I've got some immediate needs which I plan to work on - to do with persistent connections and being able to handle Expect: 100-Continue; this really means implementing more of the features seen in the node.js http interface.

from node.native.

@sebjameswml
He is referring to URL routing. A user or AJAX call hits //mysite.com/cmd/object/123 etc. and gets mapped to an internal function.

from node.native.

Gentlemen,
To get some dialog going I have put together a very rough outline. Before we create a single line of code I suggest we design the customer facing API first. What follows is a sample project description and Quick start guide.

node.native
A C syntax event and thread based message queue server that understands the HTTP/SSL protocol.

Overview:
The future of the web is persistent client connections where servers maintain state, static pages, and whole files in RAM. The URL is the new command line and RPC call. Servers respond to these URL requests (Ajax most likely) via a URL-to-function-call routing mechanism. Now, imagine this need being meet with only one executable, one config file, optional plug-in folder, and runs on Windows or Linux!

Goals:
. Single portable executable per platform. SSL support included via a linked object in the plug-in folder.
. One configuration file that supports multiple domains.
. Easy syntax. Our users come first.
. Elegant mixing of events and threads via a message queue.
. HTTP parsing and URL routing included in the box.
. Caching of any file type.

Target Customer:
. Programmers who use Visual Studio for debugging but run production apps on a CentOS x64 box.

API Look & Feel (fantasy maybe, but let's try):
. The developer should only need to interact with the API with four function calls. Everything else is their code.
. Load a config file, start the server, respond to a new client, optionally pass client object to message (threaded) queue, parse URL.

Sample Quick Start Guide:

1. Download node.native and unpack to a folder.
2. Edit the config file. Sample shown below. (API calls could this on the fly).
3. Create a main() function that looks like linked example.
   Read in the following order: main(), onClient(), Route(), then aboutFunc().
   http://pastebin.com/ZHrze6ZH

[APP]
domain=myDomain.com
ssl_support=yes
ports=80,443
url_route_file=/path/login – login.html
url_route_func=/path/about – aboutFunc()
cache_file=/path/app.js – app.js
cache_func=/path/img.jpg – myFile();
403_file=/path/403.html
404_func=404func()
logging=/path/file.log

[APP]
domain=myDomain2.com
etc ...

from node.native.

thanks @pcunite ! I will look at this in more detail

Sent from my iPhone 4S :-|

在 Nov 22, 2013，12:57 PM，pcunite [email protected] 写道：

Gentlemen,
To get some dialog going I have put together a very rough outline. Before we create a single line of code I suggest we design the customer facing API first. What follows is a sample project description and Quick start guide.

node.native
A C syntax event and thread based message queue server that understands the HTTP/SSL protocol.

Overview:
The future of the web is persistent client connections where servers maintain state, static pages, and whole files in RAM. The URL is the new command line and RPC call. Servers respond to these URL requests (Ajax most likely) via a URL-to-function-call routing mechanism. Now, imagine this need being meet with only one executable, one config file, optional plug-in folder, and runs on Windows or Linux!

Goals:
. Single portable executable per platform. SSL support included via a linked object in the plug-in folder.
. One configuration file that supports multiple domains.
. Easy syntax. Our users come first.
. Elegant mixing of events and threads via a message queue.
. HTTP parsing and URL routing included in the box.
. Caching of any file type.

Target Customer:
. Programmers who use Visual Studio for debugging but run production apps on a CentOS x64 box.

API Look & Feel (fantasy maybe, but let's try):
. The developer should only need to interact with the API with four function calls. Everything else is their code.
. Load a config file, start the server, respond to a new client, optionally pass client object to message (threaded) queue, parse URL.

Sample Quick Start Guide:

1. Download node.native and unpack to a folder.
2. Edit the config file. Sample shown below. (API calls could this on the fly).
3. Create a main() function that looks like linked example.
   Read in the following order: main(), onClient(), Route(), then aboutFunc().
   http://pastebin.com/ZHrze6ZH

[APP]
domain=myDomain.com
ssl_support=yes
ports=80,443
url_route_file=/path/login – login.html
url_route_func=/path/about – aboutFunc()
cache_file=/path/app.js – app.js
cache_func=/path/img.jpg – myFile();
403_file=/path/403.html
404_func=404func()
logging=/path/file.log

[APP]
domain=myDomain2.com
etc ...
—
Reply to this email directly or view it on GitHub.

from node.native.

examples
would be great especially if JSON-RPC ones

from node.native.

It's now dec 20 2014, is this project still going? C++ is becoming a great language as they fix more and more pain points, even more so with C++14. I'd love to see this project come to fruition. I, like many of the previous voices have no real need for a node.js like interface in C++ - rather I have a very intimate knowledge of C++ and given that node.js is mostly written in that language, feel that I should be able to write that last little bit of glue and processing in C++ also. I'm fine with compiling it rather than having a VM and interpreter.

I am looking for the same thing as @AlecTaylor:
"What I am looking for is a simple + efficient C++ micro-HTTP-stack with routing. So I can bind functions to routes."

from node.native.