Hardware Inclusive

[voodootikigod]

If this is a hardware group and not just serial port, it should be inclusive of HID devices, Bluetooth (BLE) devices, and others. Together all these libraries (as well as many not listed) make up the hardware community using JS.

/cc @sandeepmistry @node-hid

[sandeepmistry]

I would definitely be interested in being involved in the discussion.

[trevnorris]

IMO some level of change will need to go into libuv. If nothing else as an abstract interface on which we can support all these new peripherals.

[voodootikigod]

@trevnorris this is a first step, it will most likely include/require setting up a similar group in libuv, but for now this is the start of a long journey in our mind. Agree?

[trevnorris]

Cool

[voodootikigod]

Spreadsheet to gather all hardware focused node modules.

https://docs.google.com/spreadsheets/d/1YLiyY0d6xEcI-LAejFFswIspGv1BjA_JiJfM9TBjDL8/edit?usp=sharing

Please contribute!

[noopkat]

I added a bunch of stuff to the spreadsheet, but need help with further completing it. Please add your own packages if they are not there already. The 'hardware owned' tab is also a great idea if you don't mind sharing your collection. Physical testing can be a godsend if you have others to pitch in on it with their own devices.

[Frijol]

cc @johnnyman727 @rwaldron @tcr for having hardware modules to add to the spreadsheet

[johnnyman727]

We have a bunch of "hardware" focused modules like vclib for generating and parsing packets to talk to a specific camera IC or bglib for talking to BlueGiga BLE devices but I'm not sure what would be useful to add to the list. What's the end goal here?

[dtex]

@johnnyman727 The end goal of this table specifically? We've been focused on serialport and how the build step is a pain point given varying platforms and node versions. I think @voodootikigod wants to make sure we maintain a holistic view so that we might solve challenges across the board, not just for serialport. Because so many of us depend on serialport it would be easy for us to get myopic and miss out on an opportunity to do larger good.

[johnnyman727]

Thanks for the context, @dtex. So for this table, are you mostly looking for hardware-focused modules with binary dependencies so we can work on smoothing out the install process across various platforms?

[noopkat]

@johnnyman727 that would be a great goal to have on the table. I'm also (personally, not speaking for the group) curious about the nature and variety of hardware libs out there in npm, which are the most heavily used, and having a better general awareness of our little world in npm :grin: I believe I've used maybe only a dozen hardware related Node libraries in total.

[johnnyman727]

:+1: Got it!

[Resseguie]

EDITED: In that spreadsheet, are we wanting to list other Johnny-Five IO Plugins that have native firmware dependencies? spark-io (voodoospark), imp-io (Tyrion), for example. Or are we primarily concerned about host computer native dependencies here?

[nebrius]

That's a good question @Resseguie. My initial reaction is that we should probably only be concerned with things run with in a Node.js process (whether native or JS), but I'm worried that may have unintended side effects and unknown edge cases.

I think it's probably safe to say they're not a core focus though.

What does everyone else think?

[noopkat]

@Resseguie I'm with @nebrius on this one

[reconbot]

It's a good question, but I think in the end it's up to the projects to deal with the communication and firmware. Firmata is the common one, but are other applications that will call for other kinds of protocols I know there's been some research around it. So I agree, out of scope for this WG, even though very important.

[Resseguie]

Sounds good to me. I agree.