Details object vs Serial Port instance

[marcoscaceres]

The SerialPortDetails dictionary currently has the following properties:

• [ ] comName
• [ ] path
• [ ] pnpId
• [ ] manufacturer
• [ ] locationID
• [ ] vendorID
• [ ] productId
• [ ] serialNumber

However, an instance of SerialPort is currently lacking those properties. It seems annoying to have to request the available ports in order to find out the details about a port itself. You would have to find the matching object, etc. etc. which is just painful.

I suggest we add the above as attributes to instances of SerialPort itself.

[JayBeavers]

@rwaldron, to be clear 'only has a path' is true only for the older RS232 ports. RS232 ports were 'obsoleted' on the PC alongside the floppy disk and the ISA bus back in August 2000 with the introduction of the Legacy-Free PC spec. Raise your hand if the computer you're using to browse Github has a nine pin RS-232 port on the back of it. Anyone? (edit: cough, sadly, my Dell T7600 workstation does...)

In all other use cases we're discussing, the device is connected via USB (directly or indirectly) and has a mandatory USB Device Descriptor record associated with it.

Let's not optimize for the vast minority case of only having a Path available. This cuts out the ability to make intelligent decisions on what device to talk to and places a technical burden on end users with insufficient information to make an informed choice.

USB Device Properties Manufacturer and Product and Serial Number are programmable in the firmware of the USB device and can be used to convey detailed information when leveraged properly -- such as 'this device has Firmata 1.1 installed on it'. This would be very helpful for your own Johnny Five project, let's not lose this ability.

The current behavior of node-serialport to not properly expose these properly on Linux or Windows can be fixed. This isn't a limitation of what can be done, it's a limitation of the state of the code as of today. I've already filed issue node-serialport #256 to get this fixed.

We're correct that this isn't the spec for node-serialport, but let's be clear that a lot of the discussion here is being driven by the principals from the node-serialport project who have experience writing a well leveraged javascript API for serial ports. I'm assuming that like me, their motivation is to have as close as possible an API experience between the browser and nodejs, so let's not drive divergence when we don't have a strong reason.

[marcoscaceres]

@JayBeavers, that's awesome. If https://github.com/voodootikigod/node-serialport/issues/256 shows that it's possible to have vendorId, productId, serialNumber, manufacturer, and product be consistent across platforms, then we are cooking :D

I will add those, along with (platform specific) path as attributes!

[rwaldron]

After reading everything that's been posted since I last responded, I feel like clicking the "Ignore" button this repo. @larsgk Yes, I too would prefer to have all the nice human readable property values

[marcoscaceres]

@rwaldron please don't lose faith - we are trying to do our best here and nothing is set in stone. We are going to have to do some iterations to come up with a good design. Will try to find you on IRC for a chat so I can get a better understanding of your concerns.

[rwaldron]

@marcoscaceres The only technical concerns I have are complexity and it appears those have been addressed in an agreeable way.

[reconbot]

I'm goin to throw a wrench into the mix here (years later) and say that some of the port info information, like BaudRate isn't really knowable until the operation of opening a port has happened. For example, you could provide an invalid buadrate and you wont know that it's invalid until after you've opened the port, set the rate and checked it again. These syscalls are sometimes blocking and better done asynchronously.

Furthermore the information retrieved while enumerating the operating system for available ports is also often only available in a partially blocking or asynchronous fashion (interrogating services, the registry, usb, etc). Browsers may be able to cache this information by path and make them available to ports but it seems like info isn't a given.

I think an async factory function to open and return ports would work around these limitations and allow us to return open port objects full of information. I don't think it's a good idea to do it in a blocking way during a serialport's object construction.

[reillyeon]

@reconbot if you look at the example code in the explainer posted in #46 I have two new methods, navigator.serial.getPorts() and navigator.serial.requestPort() which are the only way to construct a SerialPort object and both do so asynchronously.

[marcoscaceres]

Hi @reconbot 👋, would you mind formally joining the WICG? https://www.w3.org/community/wicg/

Your input will be invaluable as this ramps up again, so want to make sure you are formally part of the group.

[reconbot]

I'm pretty sure I have haven't I?

On Tue, Sep 25, 2018, 10:16 PM Marcos Cáceres notifications@github.com wrote:

Hi @reconbot https://github.com/reconbot 👋, would you mind formally joining the WICG? https://www.w3.org/community/wicg/

Your input will be invaluable as this ramps up again, so want to make sure you are formally part of the group.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/WICG/serial/issues/20#issuecomment-424561825, or mute the thread https://github.com/notifications/unsubscribe-auth/AABlbrGyhjl16n58xuA5yA-k6w1mauXWks5ueuOKgaJpZM4BLZJL .

[marcoscaceres]

Oh, apologies @reconbot. Just making sure!

[reconbot]

I wasn't sure, but I'm pretty sure now 👍