Scoping

[joshperry]

I have been lurking for a bit and have been enjoying the conversations going on around hardware interfacing using Javascript with node.

One thing that I haven't been able to suss out from what I've read is the scope of this working group, and what it is exactly that we are attempting to accomplish when it comes to node and hardware.

I think there are many levels at which this WG could provide effective guidance and support to users interfacing with hardware. Before we can create a viable base on which to build node's hardware strategy, I think we need to decide what part exactly we want node to play in the hardware world, and what us as a group, and node as an org, would like to provide to this segment of users.

Once we have that defined, it will be much easier to start setting goals aligned with our strategies, and derive action items from those goals. For example, once we know who we're serving, and how we're going to serve them, we can find ways to begin growing this segment of users, and we can form official relationships with hardware and software partners to drive exposure and adoption. (We could have partnered with MS to bring node to Windows 10 IoT Core.)

Driving adoption is going to give us the bodies to make this matter to the community as a whole and draw talented developers that have the skills and the willingness to contribute to the advancement of node as a hardware platform.

People of all ages, backgrounds, and disciplines love playing with things that interact with the real world. If we can position node to be a simple and robust platform for working with hardware, we will be ready to play a part in the revolution to come: IoT.

This is something that I'm pretty excited about, have a lot of thoughts on, and may be a touch opinionated about. I love Javascript, love hardware, and I want node to be a serious contender in the IoT space, and I think it will be if we act quickly, decisively, and in an organized manner.

I would really like to be a formative member of the WG and assist however I can in advancing node as an uncompromising and industry-leading platform for running Javascript on computing devices large and especially small.

[joshperry]

Scoping

These are some of the layers that I'm thinking we may want to make decisions on what it is our group is going to provide. Please chime in, I plan to continue editing this post as we talk about what we want to do.

Once we have something that we're happy with, we can codify it and publish it to the repo.

Applications

Applications are where everything comes together. Where people touch and click and things start happening. Providing an experience that makes getting to this point quickly and easily is important.

Where we can provide value:

• Documentation
• Example Applications

JS Libraries

A rich and vibrant selection of libraries are important to any segment of a platform like node. People are most happy they can simply compose libraries and focus on writing code that solves interesting problems.

There are a number of transformative libraries that are used pervasively in other parts of node: e.g. express, hapi, lodash, socket.io, bluebird, debug.

Tooling

npm, Bower, Gulp, Grunt, Mocha, Jasmine

Native Libraries

Native libraries are one of the features that helped make node what it is today and they are especially important when interfacing with hardware. Providing a quality native library can be challenging and I think this in particular is somewhere that we can add a lot to help library authors and hardware vendors have a great experience.

Native Interop

There is a certain level of pain that goes into creating and managing a native library. With libs like node-ffi, we can interoperate with native code without a platform specific compilation step.

Because interfacing with hardware necessitates communicating with native layers of the OS I believe we could add a lot of value to node by hashing out and implementing a fast and lightweight interop tech.

We're going to need political and dev support from node core developers for this, so any proposal is going to need to be well thought out and well defined.

Peripheral Support

We may not want to provide support for specific peripherals, but we may want to manage a framework of peripheral classifications and provide an easy way for peripheral manufacturers to provide connectivity to their hardware using that framework.

We gain the same benefits with making this as simple as possible for vendors as we do by making applications simple for end users to create. Users drive vendor uptake, peripheral support drives user uptake.

We could provide an attractive logo certification program that we can offer to vendors for use in co-branding campaigns. If users know their hardware will just work, they can purchase and integrate with confidence.

With a large group of consumers, vendors will eventually do the work for us to make their hardware interoperate.

Board Support

With the OS providing abstraction for interacting with shared resources, we may not need to provide any board-level support directly. But we may, again, want to provide some kind of certification program that allows compute vendors to provide turnkey solutions to their users.

[nebrius]

Wow, this is really in depth, thanks @joshperry!

I realize none of this has been documented, but I would say that this working groups mission is to reduce the barriers to entry for using NodeBots that are caused by limitations in Node.js.

I use the term "NodeBots" rather specifically, because the term "hardware" can be very vague and apply to almost anything. Johnny Five is probably the biggest library that is used for NodeBots, so in practice we tend to focus on it and various modules related to it in this working group. Another reason we focus on this library is that virtually everyone involved in this WG is involved in Johnny-Five, so internal bias/vested interest :)

Right now, our (unstated) primary goal is to a) get node-serialport to work in Node 4, which is turning out to be a bit tricky and b) remove the need for native code entirely for node-serialport (we did some investigations and determined that node-ffi was a non-starter, unfortunately).

Because of this goal, we have been wrapped up in a variety of discussions related to anything native module related in the bigger scheme of things, including integration testing, update rate of Node.js itself, etc.

One thing that's kinda unique to this working group is that there is already an established ecosystem for working with hardware and interacting with hardware vendors that is largely independent of Node and it's community. In many ways, the purpose of this working group is to act as a bridge between these two communities that have previously been independent, and haven't particularly gotten along well in the past.

Although previous acrimony between the communities is largely a thing of the past, one of the ways in which that legacy lives on is that there runs a risk of duplicating effort if you don't have a foot in both camps. Generally speaking, the goal should be for the NodeBots community to do as much of the work as possible, independently, and only involving the Node.js community (by way of this working group) when we're stuck on something we can't solve independently.

I hope this helps provide you with some context for the group, and welcome aboard!

I think this is a great thing you've started, and I highly encourage you to keep working on it! I would love to see this evolve into official documentation for the WG eventually, as you mentioned.

[nebrius]

Oh also, if you want to get involved with the NodeBots community, we mostly hang out in the Johnny-Five Gitter Channel, so I recommend stopping by there and saying hi :)

[joshperry]

Thanks for the welcome @nebrius!

Perhaps my perspective on this WG is a little different than its actual purpose. First, I just want to say that I'm firmly in the camp of providing a skinny core, where what's put directly under the node org's control and in its repos is concerned.

However, I definitely think node is severely lacking in the base of support needed for providing an effective platform for easily interacting with hardware devices and running on embedded hardware.

I guess I assumed this group was for planning, codifying, and implementing node's support for hardware, for promoting this functionality to vendors and users alike in order to grow the community, and to act as the official point-of-interaction for hardware vendor and other partnerships with the node org.

I guess this is as good a place as any to talk about this, but I think that node's interaction with hardware needs some core support, and it needs it quickly. I'm going to sound frank here, leaving out a lot of the finer points, merely in the interest of time.

Javascript became popular because it was the first time we could push logic across this new "world wide web". Not because it was the first, or even the best, but because anyone(read everyone) could do it; it was easy.

We saw another revolution in the web when XHR became a reliable cross-browser way to allow everyone to, easily, interact with the network, go back for more UI, run operations with no post-back, etc; it was so big it even got it's own name: Web 2.0.

We are even currently in the mid-to-late stages of what has become a mini-evolution inside the "html5" revolution (HTML5, CSS3, ES6, WebP2P); websockets have allowed sites of even the largest scale to provide nearly instantaneous interaction between their users, replacing notifications with engagement.

Every time more access to the network has been exposed to Javascript, it has been transformative. Its simplicity, dynamic nature, and large user base has engendered rapid uptake and high adoption rates across organizations, cultures, languages, countries, the world.

In fact, we're clawing at ways to get outside of the host computer and interact with the world, when all the browser vendors add any support for functionality that is semantically similar, even if it has to be spackled over (see jQuery, basically all of early 'AJAX', and even libraries like socket.io), we consume it at a high-rate and in massive quantities.

The next revolution already has a name even though nobody has really figured out a great way to do it: IoT. And though it's quickly becoming a buzzword on the order of "The Cloud", there is absolutely no doubt that we are clamoring to push logic to "things", and if that logic is provided with simple connectivity to the network, it will flourish.

Node is a great validation of this assertion. It became quickly popular -- virally I'd dare say -- exactly because of Javascript's deep and wide pool of developers, and even more so because it wholly embraced the network; and I mean that quite literally.

((Javascript on the client)(network)(Javascript on the server))

I can even give first-hand testimonial to the importance of adding a fourth to this mé·nage à trois, because not only am I a user of Javascript, but I am CTO of a company that could be considered an "IoT" play.

I work at an abject fledgling physical access control company (elevator pitch: swipe card, beep, click, open door) and we are on the cusp of porting the core service of our system to node. The current system simultaneously communicates with hundreds and hundreds of devices via wireless mesh network, TCP/IP, and yes even serial ports (because if you don't have a fleet of developers, forget about cross-platform native USB).

Want to know what an item on my gantt chart is? "Rewrite node-serialport", not kidding. The state of node communicating with hardware is so bad that --even though Javascript may be one of my last great loves-- I just can't justify the business risk of using it to run an embedded, near-realtime, highly-available system that I have to pay people to support and expect to keep any customers.

Embedded, near-realtime, always connected systems: this is the bread and butter of IoT, and Javascript is missing out. But it doesn't need to, and with the rapid transformation and organizational structuring that we're seeing in the node community, I have high hopes that it won't.

We need connectivity to the networks that host these swarms of sensors and access to these networks is usually through USB devices posing as serial ports because, besides TCP/IP and HTTP, that's the extent of node's hardware com capabilities (see products like the XBee, almost any CAN Bus, and rs-485 to USB adapters).

While it would be great to push connectivity to these networks off to TCP/IP connected gateways, what we really need to do is run on those gateways. That's where the magic happens, where the rubber meets the road as it were, it lets us push logic (with simple-to-use network connectivity) onto the embedded-client side of the unreliable network and drive low-latency and network-fault tolerant interactions with nearby sinks and sources.

These gateways, and even some of the larger more expensive nodes on the sensor network are going to have the compute and memory resources to run node and will have hardware sinks and sources that need to be directly polled, evented, and twiddled. Connectivity to these devices, and even to the busses (like a CAN Bus, zwave, or zigbee) that host them, can use a variety of physical connectivity methods like I2C, SPI, USB, and RS-232 UART.

This connectivity is most frequently multiplexed through a simple, naked, serial connection using a protocol like firmata.

If node, and the node community want to be a part of this market, we need to take a holistic and organized approach. We need a lot of well-organized resources, including PMs, writers, testing infrastructure, and buy-in from core devs.

I really believe that Javascript will be a key part of whatever the IoT revolution eventually turns out to be, I hope node will be a part of that, and I want to help.

A small sampling of the programmable IoT-style stuff out there

Go

• https://ninjablocks.com/ninjasphere/developer (The first iteration of Ninja blocks, some years ago, was a platform built on node running on the beaglebone black. Their newest product has abandoned node and uses Go.)

Python Small devices like these, running python (because of its array of cherry C interop layers?) are popping up all over.

• http://www.cnx-software.com/2014/08/20/79-stack-box-home-automation-iot-gateway-supports-wi-fi-ethernet-ble-xbee-x10-z-wave-and-more-crowdfunding/
• http://www.digi.com/products/xbee-rf-solutions/gateways/xbee-gateway

HTTP There are a lot of gateways out there that don't support executing end-user logic directly, which is unfortunate when you consider that you need another piece of hardware (desktop, raspberry pi, beaglebone) to provide a network-fault tolerant service that interacts with devices through this gateway, if it even supports local network API connectivity.

• http://www.wink.com/products/wink-hub/

[nebrius]

I'm sorry if I came off as dismissive, that was not my intention. I think you've got some great ideas here, and I would love to see these come to fruition.

That said, there is one major problem, highlighted here:

We need a lot of well-organized resources, including PMs, writers, testing infrastructure, and buy-in from core devs.

We simply don't have those resources or a way of obtaining those resources. Pretty much everyone in this group, myself included, do NodeBots for fun in our spare time.

If you want to get involved in this WG, perhaps a great way for you to contribute is to figure out how we can get those resources? What do you think?

[joshperry]

Nope, I didn't feel like you were being dismissive, this is just something I've been thinking about for a long time so I figured this was as good a place as any to drop it. I'm just a naturally curt writer, I apologize if I seemed anything but excited and grateful!

I know that a lot of this work is done by people in their spare time, a lot of my time contributions are done outside of work hours because I love node but still have to get product out the door.

But node is changing, for the better it seems, they're bringing more organization, more resources, and setting up WGs like this to ensure that all the parts of the org are serviced properly. I know we don't have these resources, and that's exactly what my initial post was about. How do we build a community that people want to be a part of?

How do we build a community that will draw companies like ninja blocks to the platform, and keep them, so that as their devs can, and will want to, contribute cycles to the node ecosystem while they work on their product? How do we build a community that engenders cooperation with the Microsofts of the world to assist in getting node running on Windows 10 IoT before it hits the market?

This is how we get those resources. It's not going to be a quick process, by any means, but it is a tried and true system, a lot of the love that node has gotten, and a lot of the libraries in the community, were created by developers at their full-time job.

As we grow as part of the organization, there's even the possibility that it becomes financially self-sustaining and is able to justify actual FT employee(s) in the node org, or even perhaps a benevolent enterprise assigns an employee to work on node hardware full-time.

These are things that are actually happening in the larger community already. The biggest goal of my essay was simply to get people to believe that the hardware side of node can be as large, vibrant, and well-funded a community as we want it to be.

I'm excited by the possibilities! 👍

[nebrius]

How do we build a community that people want to be a part of?

Actually, I can answer this question fairly easily, at least for where to start: we need to get people like you involved that want to build the more enterprise-y community :)

Johnny-Five, and thus basically everyone involved in this WG, is very DIY/education/hobbyist focused, so building the types of communities you're interested in isn't really a priority. We're focused on building out our existing community (and for the record, we have a very vibrant and successful community already).

I'm not at all opposed to reaching out to other types of communities though, and in fact this WG would be a great place for it. We'll need people involved in the WG who want to spearhead those efforts though, which currently don't exist either. Perhaps you could take this on?

[jandrieu]

Hello.

I just wanted to chime in with strong support for @joshperry 's advocacy for supporting node on embedded systems in general, beyond just NodeBots. Clearly NodeBots is pretty awesome. But what has been driving my professional engagement in node.js is using it in embedded SOCs (system on chip) running Linux, typically cameras.

Sometimes I'm using node on the device, sometimes I'm using it on a host machine. Sometimes I need to cross compile, other times not. I'm almost never doing builds on the device, and hence, can't build binary modules with npm on the device.

FWIW, I am not a Johnny-Five user... so I guess I'm wondering if this group is the best place for me to find others engaged with similar node.js adventures...

[reconbot]

I'm a maintainer of node serialport and I have similar issues. Cross compiling and precompiled binaries are both real pains to accomplish. Serialport (and J5) gets run on a wide range of SBC (single board computers) usually with Linux or Windows but dozens of platforms and architectures.

You're in the right place.

On Fri, May 6, 2016, 7:13 PM Joe Andrieu notifications@github.com wrote:

Hello.

I just wanted to chime in with strong support for @joshperry https://github.com/joshperry 's advocacy for supporting node on embedded systems in general, beyond just NodeBots. Clearly NodeBots is pretty awesome. But what has been driving my professional engagement in node.js is using it in embedded SOCs (system on chip) running Linux, typically cameras.

Sometimes I'm using node on the device, sometimes I'm using it on a host machine. Sometimes I need to cross compile, other times not. I'm almost never doing builds on the device, and hence, can't build binary modules with npm on the device.

FWIW, I am not a Johnny-Five user... so I guess I'm wondering if this group is the best place for me to find others engaged with similar node.js adventures...

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/nodejs/hardware/issues/18#issuecomment-217584930

[johnnyman727]

@reconbot I wonder if there would be demand for building out the Tessel cross compilation service a little wider to provide a number of cross-compiled options for different architectures for as many binary deps as possible 🛂

[reconbot]

There would be, we'd have to expand on the usual preloaders though as they're not aware of architectures nearly enough.

On Sun, May 8, 2016, 6:29 AM Jon notifications@github.com wrote:

@reconbot https://github.com/reconbot I wonder if there would be demand for building out the Tessel cross compilation service a little wider to provide a number of cross-compiled options for different architectures for as many binary deps as possible 🛂

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/nodejs/hardware/issues/18#issuecomment-217708171

[jandrieu]

I'm not sure how the Tessel service works, but I'm wary of depending on pre-built binaries, if that's what you mean. My work generally ends up in custom hardware, often built with customized toolchains or proprietary SDKs. Their might be generic "arm linux" binaries that would work, but if they don't it would be a debugging nightmare. Perhaps more importantly, my clients aren't keen on baking someone else's binary into their products. The preferred solution is to build from source, which gives us the best debugging, maintenance, and security options.

On the other hand, if how Tessel handles cross-compilation can be used to streamline deploying node modules from a host with one architecture to a target with another, that sounds awesome.

[rwaldron]

FWIW, I am not a Johnny-Five user...

Great, but what is the relevance of this statement?

...

w/r to your last post, no one is insisting that you use any particular precompiled binaries. A tool for cross compilation exists and can be shared, that's all.

On the other hand, if how Tessel handles cross-compilation can be used to streamline deploying node modules from a host with one architecture to a target with another, that sounds awesome.

That's exactly what it does, but it does so by copying the project directory and replacing the host-compiled binaries with our precompiled binaries. On-the-fly compilation isn't possible because it would mean recompiling all binary module dependencies on every deployment, which we all agree is not acceptable.

[nebrius]

Great, but what is the relevance of this statement?

I think this comes from other statements we've made around the repos that pretty much everyone involved in this WG comes from J5, and so that's our area of expertise, but there are a lot of potential use cases for Node on embedded platforms that aren't J5 related. We've had trouble getting non-J5 initiatives started in the past for exactly this reason.

[jandrieu]

I guess I mentioned J5 to distinguish my interest in node on embedded systems from "NodeBots". The camera's that I've deployed node.js on are not robots. Node was just a good option for handling the networking and interface tasks I needed to solve.

I think NodeBots and Johnny-Five are cool. They just aren't why I'm here, and I'm trying to get a handle on (1) whether or not this group is the place for me to commiserate and collaborate about node on embedded systems and (2) how I might participate.

To the rest of your post, @rwaldron, I'm not sure I understand.

On-the-fly compilation isn't possible because it would mean recompiling all binary module dependencies on every deployment, which we all agree is not acceptable.

Most of the systems I've used have separate build and deploy steps, and with node I'm still working around the best way to separate npm install so that I have install, build, and deploy. I actually only want to run npm install explicitly to add or update components in node_modules. Everything in node_modules goes into the repo, so a normal "build" of a node app for the root image is simply copying the node_modules from our source directory to the target file system. That would keep us from running npm install every build (and updating from the wild without human involvement, which is definitely not a good idea).

It's been on my to-do list for a while now to add a 'make nodeEnv' command to properly set my compiler flags, $PREFIX, etc. so that I can run npm install on the host machine and cross-compile correctly for the target.

I understand that Tessel might be able to provide something like that, but it also provides a CLI for deployment and device bindings (for IO and such), neither of which are usually useful to me. But if there's a simpler way to use Tessle instead of that 'make nodeEnv' hack, that would be interesting to explore.

[rvagg]

(note I'm not a member here, just throwing in my thoughts from the side)

I'd love to see explicit scoping go beyond nodebots & hobbyist users as Node is becoming increasingly important in embedded and/or IoT environments and we need to have a hardware focus that spans the breadth of usage and represents all different perspectives and needs. It's also possible that there's more people out there from these other ecosystems that have more time and energy to push this group forward.

From the Build working group's perspective, we would love to have a more active and diverse group over here to lean on for advice wrt what platforms we should be supporting in our CI system. As it is we're doing all that legwork ourselves and a lot of it involves guesswork. I've been making some great connections in the ARM ecosystem and have regular offers of hardware donations but we need to prioritise and not overstretch our resources.

An open question that I have is about how much traction Intel have made in the IoT & low-power space. It seems to me that they've had extreme difficulty making any progress with Edison, I don't have a good feel for where Atom is at and how important it is to Node and Intel's missteps in the SoC market (the recent cancellation of Broxton) just confuse all of this. I'd love for us to have an expert group that we can lean on to find answers to these questions, or at the very minimum, be able to make better educated guesses than we are having to make.

[rwaldron]

I actually only want to run npm install explicitly to add or update components in node_modules. Everything in node_modules goes into the repo, so a normal "build" of a node app for the root image is simply copying the node_modules from our source directory to the target file system. That would keep us from running npm install every build (and updating from the wild without human involvement, which is definitely not a good idea).

Awesome, that's actually exactly the workflow that Tessel's t2-cli is using.

It's been on my to-do list for a while now to add a 'make nodeEnv' command to properly set my compiler flags, $PREFIX, etc. so that I can run npm install on the host machine and cross-compile correctly for the target.

Ok, then you should definitely look at https://github.com/tessel/t2-compiler, because that tool is doing what you've described here. We use that to pre-compile the binaries that will later be requested by t2-cli's run/push deployment operations (for the copy, replace & move steps)

I understand that Tessel might be able to provide something like that, but it also provides a CLI for deployment and device bindings (for IO and such), neither of which are usually useful to me. But if there's a simpler way to use Tessle instead of that 'make nodeEnv' hack, that would be interesting to explore.

Same suggestion as above, take a look at t2-compiler and see what is useful to you.

@rvagg

It seems to me that they've had extreme difficulty making any progress with Edison

I believe strongly that the developer story was the most detrimental point of failure. They invested in building a custom IDE (Intel XDK Editor, on Brackets), which I think was a mistake because most developers want to just use their own tools and extend those tools with other easily integrated tools. I don't have proof of this, just a really strong feeling ;)