WebSerial API

[tzi...@gmail.com]

hey guys

i was looking at the discussion of WebUSB API (https://bugzilla.mozilla.org/show_bug.cgi?id=674718) and i was particularly intrigued by the idea that popped of having a way to communicate with Serial devices, such as Arduinos, 3D printers, and other Serial devices.

I was thinking of a WebSerial API which would allow websites to access Serial ports. Chrome already has something similar, albeit only for Chrome Apps (http://developer.chrome.com/apps/serial.html), and not as a standard Web API. You can't even access it from an Extension.

We have an NPAPI plugin at codebender (http://codebender.cc), where I am the lead dev, which implements Serial Communication in C++ on top of the OS APIs, and we could probably use some of that code.

I'm interested in working on that, but i was wondering if there is interest for something like that, and I wanted to start a discussion and get everyone's feedback.

Cheers,
Vasilis

[Ehsan Akhgari]

Hi Vasilis,

Do you have a proposal for what such an API would look like? To the
best of my knowledge nobody at Mozilla is currently working on this, but
it would be interesting to look at a proposal for this!

Cheers,
Ehsan

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
>

[Vasilis Georgitzikis]

Hey Ehsan,
That's a good question. From my experience (with Arduino, Processing & Java's RxTx, pySerial and a couple of OS Serial APIs), Serial ports have a pretty strict and defined API.

That is, what you want is the following functions:
listPorts()
open()
close()
read()
write()
flush()
getFlags()
setFlags()

Some implementations also add a couple of helper functions, like readLine(), which uses read() to read a line, but that's the essence of what you need to provide. Chrome's Serial API (http://developer.chrome.com/apps/serial.html) is actually a very good reference for the APIs.

As I said, I'm very interested to work on this. I would be glad to put up a wiki page for discussion if there's interest from the community to see this done (aka we want to see web-enabled arduinos and 3d-printers!).

Cheers,
Vasilis

On Oct 10, 2013, at 12:54 AM, Ehsan Akhgari wrote:

> Hi Vasilis,
>
> Do you have a proposal for what such an API would look like? To the best of my knowledge nobody at Mozilla is currently working on this, but it would be interesting to look at a proposal for this!
>
> Cheers,
> Ehsan
>
> On 2013-10-09 2:07 PM, tzi...@gmail.com wrote:

[James Burke]

On Wed, Oct 9, 2013 at 5:25 PM, Vasilis Georgitzikis <tzi...@gmail.com> wrote:
> As I said, I'm very interested to work on this. I would be glad to put up a wiki page for discussion if there's interest from the community to see this done (aka we want to see web-enabled arduinos and 3d-printers!).

I was a commenter on the bug mentioned, so this may not count as any
new interest, but I am still very interested to see it happen.
Unfortunately, I lack the technical depth to help with it, but happy
to write JS code that tries out any implemented interface to talk to
arduinos in particular.

James

[Vasilis Georgitzikis]

Hey James,
Nice to see there's still interested. I'm not particularly worried about the technical aspects, but I do love seeing some initial interest. I went ahead and created a wiki page with some initial thoughts and suggestions. Let me know what you guys think.

https://wiki.mozilla.org/WebAPI/WebSerial

tzikis

[gorh...@gmail.com]

you have my total interest to this, we can use projects like node-serialport (https://github.com/voodootikigod/node-serialport) as a basis, since node can already talk to serial port devices with this.

I had interesting discussions at the summit with the webmaker team (jp and pomax) about extending webmaker to serial port via node, it would be even better is we could skip the node part.

waiting to hear more about it

[achr...@gmail.com]

Vasilis, this is a very interesting idea. I was looking for an API speaking with my serial port but unfortunately firefox does not support this right now. I would definitely use it if it was available. I could even support on implementing it. The ROS library looks quite good approach it is a good start. I am looking forward for more answers on this topic ...

[Eric Shepherd]

On 2013-10-09 18:07:08 +0000, tzi...@gmail.com said:

> I was thinking of a WebSerial API which would allow websites to access
> Serial ports. Chrome already has something similar, albeit only for
> Chrome Apps (http://developer.chrome.com/apps/serial.html), and not as
> a standard Web API. You can't even access it from an Extension.

I strongly urge you to file a bug with this proposal, and be sure to
include the dev-doc-needed keyword, so that the docs team can keep up
with the progress of the idea.

--
Eric Shepherd
Developer Documentation Lead
Mozilla
Blog: http://www.bitstampede.com/
Twitter: @sheppy

[Kyle Machulis]

Hey! WebSerial looks pretty cool. :D

I was one of the lead devs on the first implementation of the WebBluetooth API for FxOS, and also was looking at taking WebUSB once we had both time and whittled down the spec from "let's do ALL the usb!" to something slightly more managable (because I can't see us needing to reimplement a lot of, say, the class compliancy...).

One of the goals behind a future version of WebBluetooth is allowing developers to open/use raw RFCOMM sockets, so if WebSerial happens, I'd love to see it happen with input from Eric Chou or others on the FxOS bluetooth team to make sure we don't split APIs. I'm not sure the FxOS project is going to have time to do RFCOMM exposure in the near future, but if the APIs were synced, it'd make a lot of things "just work" wirelessly once that is done, which I think would be a huge win.

BTW, having had to deal with socket comms and what not (ipc/unixsocket is my fault :) ) up through the DOM exposure level, I'm happy to at least provide advice on WebSerial assuming it goes forward, will definitely keep an eye on the bug.

----- Original Message -----
> From: "Eric Shepherd" <eshe...@mozilla.com>
> To: mozilla-d...@lists.mozilla.org
> Sent: Sunday, October 13, 2013 7:26:37 PM
> Subject: Re: WebSerial API
>
> On 2013-10-09 18:07:08 +0000, tzi...@gmail.com said:
>

> > I was thinking of a WebSerial API which would allow websites to access
> > Serial ports. Chrome already has something similar, albeit only for
> > Chrome Apps (http://developer.chrome.com/apps/serial.html), and not as
> > a standard Web API. You can't even access it from an Extension.
>

> I strongly urge you to file a bug with this proposal, and be sure to
> include the dev-doc-needed keyword, so that the docs team can keep up
> with the progress of the idea.
>
> --
> Eric Shepherd
> Developer Documentation Lead
> Mozilla
> Blog: http://www.bitstampede.com/
> Twitter: @sheppy
>

[Thinker K.F. Li]

We have a discussion of new ideas of FirefoxOS at the summit at Brussels
last week. I also mention about the same idea of serial port API.
Since, today, there are a lot of artists use arduino and other
micro-controllers to do their artifacts. They usually need a bigger
device, like phone to control these small devices (arduino). That is
why with serial port API is good for the promtion of FirefoxOS.

--
Sinker
--
天教懶漫帶疏狂

[Anne van Kesteren]

Now including the list. Sorry about the duplicate!

On Wed, Oct 9, 2013 at 7:07 PM, <tzi...@gmail.com> wrote:
> I was thinking of a WebSerial API which would allow websites to access Serial ports.

Could you give a high-level description of what a serial API can do
with hardware versus e.g. what a USB or Bluetooth API can do? Maybe
add it to the wiki page as that will help evaluate the attack surface
better.

As far as making the API web-facing goes, my main concern is the
longevity of the API. Innovation seems to be in connecting living room
devices to the network. Devices attached to other devices seem to
merge over time. We could provide an interesting sandbox here, but is
this where things are going?


--
http://annevankesteren.nl/

[Marcos Caceres]

On Tuesday, October 15, 2013 at 4:17 PM, Thinker K.F. Li wrote:

> We have a discussion of new ideas of FirefoxOS at the summit at Brussels
> last week. I also mention about the same idea of serial port API.
> Since, today, there are a lot of artists use arduino and other
> micro-controllers to do their artifacts. They usually need a bigger
> device, like phone to control these small devices (arduino). That is
> why with serial port API is good for the promtion of FirefoxOS.
>

How do we envision people would actually use this API? Particularly, do we think people will connect FxOS phones to an Arduino (seems kinda clunky… unless FxOS starts running on something like a RaspberryPi)?

People are using Node.js to handle all this stuff already (and you can interface with the Arduino + network-shield over WebSockets in the browser - e.g. [1]) . With regards to 3D printers, won't those just be exposed as a kind of "printer" by the system rather than having to write to it directly? I don't have a 3D printer, so I don't actually know how they work ATM with regards to drivers - but having each web app implement a printer driver in JS doesn't seem like a good thing (and seems ripe for abuse/problems).

So, core question, what are we actually trying to solve here?

I agree that it would be cool™ to have the ability to connect to an Arduino over a serial port and talk to it (that seems to be the only really exciting use case here)… but that kinda defeats the purpose of an Arduino, which *is not supposed to be tethered to a computer in order to make it useful*: an Arduino is supposed to have code uploaded to it, but the problem is that that code is Processing (or c or something ugly that few people actually understand… hence everyone uploading the serial interface sketch to the Arduino… so you can actually interface with it in a non-crap environment like Node.js + the Johnny-five lib).

Using the serial interface is still *just a hack* (and a really really ugly one, because you have wires coming out of your Arduino, which is just stupid - specially if you are making a robot) - the actual *core* problem is that you can't run JavaScript natively on an Arduino, which is what people actually want to do.

Thus, what actually needs to be fixed here is to have Arduino implement Node.js or JavaScript natively so people have an easier way to hack on it without needing to make the Arduino into a dumb serial port. Then, all communication between the Arduino+Network-Shield and the browser can happen over Web Sockets rather than requiring a serial port interface.

My 2c,
Marcos

[1] One I prepared earlier - https://twitter.com/marcosc/status/255804678342864896/photo/1

[Dave Hylands]

Hi,

----- Original Message -----
> From: "Marcos Caceres" <mcac...@mozilla.com>
> To: dev-w...@lists.mozilla.org
> Cc: "Thinker K.F. Li" <thi...@codemud.net>
> Sent: Tuesday, October 15, 2013 10:51:56 AM
> Subject: Re: WebSerial API
>
> On Tuesday, October 15, 2013 at 4:17 PM, Thinker K.F. Li wrote:
>
> > We have a discussion of new ideas of FirefoxOS at the summit at Brussels
> > last week. I also mention about the same idea of serial port API.
> > Since, today, there are a lot of artists use arduino and other
> > micro-controllers to do their artifacts. They usually need a bigger
> > device, like phone to control these small devices (arduino). That is
> > why with serial port API is good for the promtion of FirefoxOS.
> >
>
> How do we envision people would actually use this API? Particularly, do we
> think people will connect FxOS phones to an Arduino (seems kinda clunky…
> unless FxOS starts running on something like a RaspberryPi)?
>
> People are using Node.js to handle all this stuff already (and you can
> interface with the Arduino + network-shield over WebSockets in the browser -
> e.g. [1]) . With regards to 3D printers, won't those just be exposed as a
> kind of "printer" by the system rather than having to write to it directly?
> I don't have a 3D printer, so I don't actually know how they work ATM with
> regards to drivers - but having each web app implement a printer driver in
> JS doesn't seem like a good thing (and seems ripe for abuse/problems).
>
> So, core question, what are we actually trying to solve here?

The typical use case I would use this for is to build a robot, and use my
phone as a UI/touchscreen interface. Since the phone typically has a camera and
decent CPU horsepower, you could also do some image processing (mounting the phone
to the robot).

Phones, in general, don't expose hardly any I/O so having an external device like
an Arduino do it makes sense.

Connecting over a network makes sense if you happen to be within range of an AP,
but this is often not the case when you're outside (think public parks).

> I agree that it would be cool™ to have the ability to connect to an Arduino
> over a serial port and talk to it (that seems to be the only really exciting
> use case here)… but that kinda defeats the purpose of an Arduino, which *is
> not supposed to be tethered to a computer in order to make it useful*: an
> Arduino is supposed to have code uploaded to it, but the problem is that
> that code is Processing (or c or something ugly that few people actually
> understand… hence everyone uploading the serial interface sketch to the
> Arduino… so you can actually interface with it in a non-crap environment
> like Node.js + the Johnny-five lib).
>
> Using the serial interface is still *just a hack* (and a really really ugly
> one, because you have wires coming out of your Arduino, which is just stupid
> - specially if you are making a robot) - the actual *core* problem is that
> you can't run JavaScript natively on an Arduino, which is what people
> actually want to do.
>
> Thus, what actually needs to be fixed here is to have Arduino implement
> Node.js or JavaScript natively so people have an easier way to hack on it
> without needing to make the Arduino into a dumb serial port. Then, all
> communication between the Arduino+Network-Shield and the browser can happen
> over Web Sockets rather than requiring a serial port interface.

A couple of platforms which are attempting to do exactly this (well using small ARM micros, and not AVRs):
http://www.espruino.com/
http://tessel.io/

Dave Hylands

[Donovan Preston]

On 10/15/13 1:51 PM, Marcos Caceres wrote:
>
>
> On Tuesday, October 15, 2013 at 4:17 PM, Thinker K.F. Li wrote:
>
>> We have a discussion of new ideas of FirefoxOS at the summit at Brussels
>> last week. I also mention about the same idea of serial port API.
>> Since, today, there are a lot of artists use arduino and other
>> micro-controllers to do their artifacts. They usually need a bigger
>> device, like phone to control these small devices (arduino). That is
>> why with serial port API is good for the promtion of FirefoxOS.
>>
> How do we envision people would actually use this API? Particularly, do we think people will connect FxOS phones to an Arduino (seems kinda clunky… unless FxOS starts running on something like a RaspberryPi)?

Absolutely, that is what I would do with it. I would build all sorts of
UIs for the Arduino using Firefox OS if we had this capability.

>
> People are using Node.js to handle all this stuff already (and you can interface with the Arduino + network-shield over WebSockets in the browser - e.g. [1]) . With regards to 3D printers, won't those just be exposed as a kind of "printer" by the system rather than having to write to it directly? I don't have a 3D printer, so I don't actually know how they work ATM with regards to drivers - but having each web app implement a printer driver in JS doesn't seem like a good thing (and seems ripe for abuse/problems).
>
> So, core question, what are we actually trying to solve here?
>

> I agree that it would be cool™ to have the ability to connect to an Arduino over a serial port and talk to it (that seems to be the only really exciting use case here)… but that kinda defeats the purpose of an Arduino, which *is not supposed to be tethered to a computer in order to make it useful*: an Arduino is supposed to have code uploaded to it, but the problem is that that code is Processing (or c or something ugly that few people actually understand… hence everyone uploading the serial interface sketch to the Arduino… so you can actually interface with it in a non-crap environment like Node.js + the Johnny-five lib).

I don't buy that the Arduino isn't supposed to be tethered to a computer
to make it useful. Many of the Arduino projects I work on have more
complicated UI requirements than a few knobs or a two line LCD display
can satisfy, and thus the interface has to move to a real computer.

I would like that real computer to be my Firefox OS phone.

Donovan

>
> Using the serial interface is still *just a hack* (and a really really ugly one, because you have wires coming out of your Arduino, which is just stupid - specially if you are making a robot) - the actual *core* problem is that you can't run JavaScript natively on an Arduino, which is what people actually want to do.
>
> Thus, what actually needs to be fixed here is to have Arduino implement Node.js or JavaScript natively so people have an easier way to hack on it without needing to make the Arduino into a dumb serial port. Then, all communication between the Arduino+Network-Shield and the browser can happen over Web Sockets rather than requiring a serial port interface.
>

> My 2c,
> Marcos
>
> [1] One I prepared earlier - https://twitter.com/marcosc/status/255804678342864896/photo/1
>
>
>

[Marcos Caceres]

On Tuesday, October 15, 2013 at 7:14 PM, Donovan Preston wrote:

> On 10/15/13 1:51 PM, Marcos Caceres wrote:
> >
> >
> > On Tuesday, October 15, 2013 at 4:17 PM, Thinker K.F. Li wrote:
> >
> > > We have a discussion of new ideas of FirefoxOS at the summit at Brussels
> > > last week. I also mention about the same idea of serial port API.
> > > Since, today, there are a lot of artists use arduino and other
> > > micro-controllers to do their artifacts. They usually need a bigger
> > > device, like phone to control these small devices (arduino). That is
> > > why with serial port API is good for the promtion of FirefoxOS.
> >
> >
> > How do we envision people would actually use this API? Particularly, do we think people will connect FxOS phones to an Arduino (seems kinda clunky… unless FxOS starts running on something like a RaspberryPi)?
>
> Absolutely, that is what I would do with it. I would build all sorts of
> UIs for the Arduino using Firefox OS if we had this capability.

To be clear, do you mean the phone or having firefox OS running on other hardware?

> >
> > People are using Node.js to handle all this stuff already (and you can interface with the Arduino + network-shield over WebSockets in the browser - e.g. [1]) . With regards to 3D printers, won't those just be exposed as a kind of "printer" by the system rather than having to write to it directly? I don't have a 3D printer, so I don't actually know how they work ATM with regards to drivers - but having each web app implement a printer driver in JS doesn't seem like a good thing (and seems ripe for abuse/problems).
> >
> > So, core question, what are we actually trying to solve here?
> >
> > I agree that it would be cool™ to have the ability to connect to an Arduino over a serial port and talk to it (that seems to be the only really exciting use case here)… but that kinda defeats the purpose of an Arduino, which *is not supposed to be tethered to a computer in order to make it useful*: an Arduino is supposed to have code uploaded to it, but the problem is that that code is Processing (or c or something ugly that few people actually understand… hence everyone uploading the serial interface sketch to the Arduino… so you can actually interface with it in a non-crap environment like Node.js + the Johnny-five lib).
> I don't buy that the Arduino isn't supposed to be tethered to a computer
> to make it useful.

Sure, but you have to admit that turning the Arduino into a dumb serial interface kinda defeats the point of it (as it makes the whole re-programmable part, as well as the standalone computer part, of an Arduino kinda redundant - we might as well make just cheaper serial interfaces where people can attach sensors instead).

> Many of the Arduino projects I work on have more
> complicated UI requirements than a few knobs or a two line LCD display
> can satisfy, and thus the interface has to move to a real computer.

It would be important to gather such projects so we can get a clear understanding of the problems that could potentially be solved.

> I would like that real computer to be my Firefox OS phone.

Are people doing this in Android land (which is the closest thing to firefox os)? That is, are projects connecting to USB over the phone to be able to read data over serial in the way you describe?

[Anne van Kesteren]

On Tue, Oct 15, 2013 at 7:06 PM, Dave Hylands <dhyl...@mozilla.com> wrote:
> Connecting over a network makes sense if you happen to be within range of an AP,
> but this is often not the case when you're outside (think public parks).

The phone can be the AP, no?


--
http://annevankesteren.nl/

[Dave Hylands]

----- Original Message -----
> From: "Anne van Kesteren" <ann...@annevk.nl>
> To: "Dave Hylands" <dhyl...@mozilla.com>
> Cc: "Marcos Caceres" <mcac...@mozilla.com>, dev-w...@lists.mozilla.org, "Thinker K.F. Li" <thi...@codemud.net>
> Sent: Tuesday, October 15, 2013 11:33:58 AM
> Subject: Re: WebSerial API
>

> On Tue, Oct 15, 2013 at 7:06 PM, Dave Hylands <dhyl...@mozilla.com> wrote:
> > Connecting over a network makes sense if you happen to be within range of
> > an AP,
> > but this is often not the case when you're outside (think public parks).
>
> The phone can be the AP, no?

Yes - I suppose it could. It would still mean having to add some type of wifi to the arduino.
The small arduino's only have 8-32K of flash, so this typically means that you need some type
of wifi-to-serial interface to talk to the chip. The wifi-to-serial adapter adds cost and eats
quite a bit of battery, when using a simple serial port in the first place would suffice.

The Wifi/Arduino shields also typically cost 2-3 times the price of the arduino itself.

Dave Hylands

[Marcos Caceres]

On Tuesday, October 15, 2013 at 7:06 PM, Dave Hylands wrote:

>
> A couple of platforms which are attempting to do exactly this (well using small ARM micros, and not AVRs):
> http://www.espruino.com/
> http://tessel.io/

Thank gawd someone is doing this! Will investigate.

I still think that having these types of devices talk either HTTP or WebSockets would address most of the use cases - what is missing is a service discovery API to allow local connections to these kinds of devices.


--
Marcos Caceres

[Vasilis Georgitzikis]

Guys, i think we're generally missing the point here. The question is not whether you want an Arduino programmable via javascript, or a HTTP/network enabled Arduino, or a wifi printer, or anything like that. The question is about exposing native functions over the web, which is the whole of WebAPI.

This is not solved by node.js, johny five, or Espruino. It's also not solved by codebender's NPAPI plugin, no matter how much we would like to think so. They still require either a native client, or it's a solution to a subset of cases.

Serial ports are currently used by a vast number of devices, including, but not limited to:
* GPS devices (yes, they GPS usb sticks, as well as devices like Garmin etc are Serial over USB, and they use a protocol called NMEA to communicate to their hosts)
* Bluetooth Modems or Headsets, including Bluetooth Phones connected to PCs i.e. iPhone (a good portion of them appear as a virtual USB * device as a way to control the device, i.e. play/stop for audio devices, and communication signals for the bluetooth communication devices)
* 3D Printers and every single kind of 1d, 2d, 3d or n-d computer-controled software (the controling signals are defined as a standard, called G-Code, which you send to the Printer/CNC/Laser-cutter over a serial port)
* Nearly every kind of programmable microcontroller (including Arduino, and the parent family called AVR, PICs, Texas Instruments, etc)

I'm afraid this conversation has moved too much towards the "hey, Kinect sucks because it's USB, we need someone to make a web-enabled Kinect-like device, or sell a raspberry-pi running node-js so that we can control it with JS" vs the "cameras are exposed as a standard device on all operating systems, and we should have that exposed for the open web too, in a standardised and open way, because it would enable a whole host of applications"

Cheers,
Vasilis

P.S. I'm working on a comparison of the USB/Bluetooth/Serial layers that Anne asked for. I think it would be a welcome addition for non-hardware geeks :)

On Oct 15, 2013, at 8:51 PM, Marcos Caceres wrote:

>
>
>
> On Tuesday, October 15, 2013 at 4:17 PM, Thinker K.F. Li wrote:
>
>> We have a discussion of new ideas of FirefoxOS at the summit at Brussels
>> last week. I also mention about the same idea of serial port API.
>> Since, today, there are a lot of artists use arduino and other
>> micro-controllers to do their artifacts. They usually need a bigger
>> device, like phone to control these small devices (arduino). That is
>> why with serial port API is good for the promtion of FirefoxOS.
>>
>
> How do we envision people would actually use this API? Particularly, do we think people will connect FxOS phones to an Arduino (seems kinda clunky… unless FxOS starts running on something like a RaspberryPi)?
>

> People are using Node.js to handle all this stuff already (and you can interface with the Arduino + network-shield over WebSockets in the browser - e.g. [1]) . With regards to 3D printers, won't those just be exposed as a kind of "printer" by the system rather than having to write to it directly? I don't have a 3D printer, so I don't actually know how they work ATM with regards to drivers - but having each web app implement a printer driver in JS doesn't seem like a good thing (and seems ripe for abuse/problems).
>
> So, core question, what are we actually trying to solve here?
>
> I agree that it would be cool™ to have the ability to connect to an Arduino over a serial port and talk to it (that seems to be the only really exciting use case here)… but that kinda defeats the purpose of an Arduino, which *is not supposed to be tethered to a computer in order to make it useful*: an Arduino is supposed to have code uploaded to it, but the problem is that that code is Processing (or c or something ugly that few people actually understand… hence everyone uploading the serial interface sketch to the Arduino… so you can actually interface with it in a non-crap environment like Node.js + the Johnny-five lib).
>

[tzi...@gmail.com]

Hey all, I have a diagram that (hopefully) shows the difference between the WebUSB and the proposed WebSerial API.

https://www.dropbox.com/s/zrz5r2klweg0fq4/webserial%20vs%20webusb.png

Like Justin Dolske gracefully noted in the original WebUSB bug (https://bugzilla.mozilla.org/show_bug.cgi?id=674718), these are not two conflicting APIs (just like WebUSB and Web Camera APIs are both useful, each for their own case), but rather they supplement each other.

Vasilis

[t...@tomorrow-lab.com]

I use this:
http://www.zambetti.com/projects/seriality/

And Codebender's plugin for over the web updating for this product:

http://waycount.com

Ted Ullrich

[Thinker K.F. Li]

My though is based on my previous experience of working with
interactive artists. I think they are the people bring us Arduino.
They have a lot of creativity of interactive applications. Most of
this kind of applications use a large number of micro-controllers,
like Arduino. And they really rely on serial ports to connect their
devices to a major server.

If B2G is adopt by applications, other than mobile phones, to show its
flexibility and adaptibility, it would create a strong developer
community, and long life B2G. Serial port is a very important feature
for this purpose. It is a simple, easy to understand, easy to use,
low power, low cost, and reliable technology. It is a powerful pivot.
You don't need to understand a lof of electronic, and knowledge of
making high working frequence HW. If we think to use USB or WiFi to
replace it, it would be not realistic for the people who will use this
kind of technologies.

We don't really need a platform provides serial port itself. FT232
series are a very common chip model to run RS232 over USB. Drivers of
linux is already there for several years. So, we just need some
one build a driver for a phone, and upload it to the phone, and plug a
FT232 cable to the phone, then we have a platform for that.

Just like what Dave had mentioned, serial ports are also used to talk
with bluetooth, zigbee, GPS, and a lot of sensor modules. It is a
foundation of a lot of applications. I think it is really worth to
invest this API.

[voodoo...@gmail.com]

Hi All,

Author of node-serialport and instigator of nodebots. Would be happy to help/advise/add any context, data, code to this discussion. I am just finding out about this and reviewing the backlog, but wanted to chime in sooner rather than later.

Yes WebSerial doesn't need a massive API, but there are some key things that are missing from the list for things like hardware/software flow controls and handling of the various options. In terms of B2G serialport access would be vital for controlling other devices (not the least of which is arduino). In contrast to USB, devices either split as a HID device or as a lower level (legacy) RS232 connection.

Also comments like marcos are incredibly short sighted as 1) the beauty of arduino boards are that they are cheap and cost effective and therefore very under powered which is where a more robust computer designed to handle complex logic can benefit and 2) Arduino isn't the only reason why you use serialport -- infact node-serialport started by integrating node to the zwave protocol through a usb stick. By simply providing the RS232 platform, you can afford emergent uses (as node-serialport has) for many things beyond your expectations. Right now node-serialport is used to drive a CNC, 3D Printers, arduinos, BeagleBones, zwave, X-10, and many many others. Please don't just assume "Put JS on it" is acceptable as a recommendation. because not all things can afford that single focus OR much weight.

Thank you,

Chris Williams
@voodootikigod

[tzi...@gmail.com]

Wow. Great analysis Chris. I honestly think Thinker's and your analyses are absolutely spot on.

And like it's been said before, the operating system already exposes this API for all Serial devices (physical or over USB or any other virtual Serial ports).

@Chris, did you have any time to check out the proposed API on https://wiki.mozilla.org/WebAPI/WebSerial ? Just as importantly, what do you think of Chrome's JS implementation (http://developer.chrome.com/apps/serial.html)?

Cheers,
Vasilis

[Marcos Caceres]

Please be mindful that it's my job to put forward what might seem like short sighted opinions/questions (as a person on Mozilla's Web API team ^_^) - it was also pointed out that there are projects that are actually trying to put "JS on it" - and it's essentially what this proposal is about (driving things with JS through the browser). So, important for me to tease out all the details of the proposal and play devils advocate. FWIW, I'm not against this proposal (I actually championed the creation of the Web of Sensors GC at the W3C [1] almost 2 years ago to standardize this stuff), but I want to make sure there are enough use cases and benefit to users before we consider any sort of integration into the engine.

It's also short sighted to think that mainstream 3D printers won't come with proper drivers in a few years, same with any mainstream CNCs. And the BeagleBones can run Ubuntu + has a built in network adaptor (if it can do that, can't it run node and talk Web Sockets?). With trends towards compact, full-featured, computers like the Raspberry Pi and BeagleBones, won't the Arduino be eventually displaced by these more capable, yet just as affordable, machines?

[1] http://www.w3.org/community/sensorweb/ - "This group explores how the Web platform could interact with sensors around us. For instance, how do we hook up an Arduino and interact with it through the Web platform?"

[voodoo...@gmail.com]

Absolutely! Comments on ChromeSerial especially from my experience managing and maintain node-serialport are the following:

* Much like the wjwwood/serial library and the revised node-serialport do not limit/constrain the available baudrate specification. We originally had this limitation but constantly received tickets about individuals want odd baudrates and by constraining the options, you don't allow people to use whatever they want.

* Mentioned above with ReadLine, etc. while nice to have, I would leave parser implementations to a higher level -- i foolishly brought this into node-serialport and it cause more trouble than good. Leave it at the higher level and just provide READ, WRITE.

* Ensuring that close() releases the FD completely down to the OS level so that it can be re opened very shortly (next tick) as is needed for things like the Leonardo boards and such.

* one thing Chrome serial (in my opinion) lacks is an event callback structure for data. One of the arguments positive for nodebots is that unlike other languages that issue a blocking read command, node-sp uses O_NONBLOCK with the SP FD to allow the port itself to interrupt and trigger an event bubble up the stack. This prevents having to poll read from the FD drastically reducing the CPU use and making for a much more interesting higher level paradigm (once again, in my opinion)

* chrome.serial lacks XON, XOFF, XANY software flow controls.

Those are just my quick off the cuff responses. Most of us involved with this are going to be at (and mozilla is sponsoring, so there is at least one ticket available) RobotsConf, would be good to meet in person and discuss this with the entire crowd assembled there (including node/ruby/python serial developers, hardware developers, and the wifi chip product developers).

A thought.

[Chris Williams]

Marcos,

I both sides clarity, fully happy with the devil's advocate play (and the
great job of yourself and the Web API) and it is much necessary (and
appreciated) just wasn't seeing much on the other side description, so
wanted to add my 2 cents.

RE: arduino being displaced is a funny thing because it should have already
been done by things like RPI, BBB, heck even arduino DUE (and the new TI
and Intel ones) but the reality is sometimes simple, dumb, specific
hardware wins (at least for the time being, granted). Even with that said
things like USB adapters for the wide spectrum of home automation devices
X10, Zigbee, Xbee, Zwave all use USB -> VCOM presentations in order to be
the most compatible for the host system (linux, mac, windows, etc.). Now
the argument was made (and justifiable) that some of these are moving
towards low-power wifi or Bluetooth LE (I am actually working on the
LowPower Wifi angle), but they aren't established or widely available (and
definitely not as cost effective).

My personal stake in the JS -> serial is well stated here:
http://voodootikigod.com/nodebots-the-rise-of-js-robotics/ the TLDR is that
by making hardware as accessible and easy as (modern) DOM manipulation,
there is a wide world of emergent ideas, thoughts, and components that will
become known. Doing this as part of the web API (and much like Chrome
Apps) makes this democratization available much easier and wider than
node-serialport ever possibly could (including packaging it up and shipping
it as an app). So to clarify, I am expressing this in passion for a better
web and by better web not just the digital web we know of today, but the
wide internet of things of tomorrow.

Cheers!

On Wed, Oct 16, 2013 at 2:49 PM, Marcos Caceres <mcac...@mozilla.com>wrote:

>
>
>
> On Wednesday, October 16, 2013 at 6:04 PM, voodoo...@gmail.com wrote:
>

> Please be mindful that it's my job to put forward what might seem like
> short sighted opinions/questions (as a person on Mozilla's Web API team
> ^_^) - it was also pointed out that there are projects that are actually
> trying to put "JS on it" - and it's essentially what this proposal is about
> (driving things with JS through the browser). So, important for me to tease
> out all the details of the proposal and play devils advocate. FWIW, I'm not
> against this proposal (I actually championed the creation of the Web of
> Sensors GC at the W3C [1] almost 2 years ago to standardize this stuff),
> but I want to make sure there are enough use cases and benefit to users
> before we consider any sort of integration into the engine.
>
> It's also short sighted to think that mainstream 3D printers won't come
> with proper drivers in a few years, same with any mainstream CNCs. And the
> BeagleBones can run Ubuntu + has a built in network adaptor (if it can do
> that, can't it run node and talk Web Sockets?). With trends towards
> compact, full-featured, computers like the Raspberry Pi and BeagleBones,
> won't the Arduino be eventually displaced by these more capable, yet just
> as affordable, machines?
>
> [1] http://www.w3.org/community/sensorweb/ - "This group explores how the
> Web platform could interact with sensors around us. For instance, how do we
> hook up an Arduino and interact with it through the Web platform?"
>

--
*Chris Williams*

@voodootikigod <http://twitter.com/voodootikigod> |
GitHub<http://github.com/voodootikigod>

*The things I make that you should check out:*
SaferAging <http://www.saferaging.com/> | JSConf <http://jsconf.com/> |
RobotsConf <http://robotsconf.com/> | RobotsWeekly<http://robotsweekly.com/>

[Dave Hylands]

Hi Marcos,

> It's also short sighted to think that mainstream 3D printers won't come with
> proper drivers in a few years, same with any mainstream CNCs. And the
> BeagleBones can run Ubuntu + has a built in network adaptor (if it can do
> that, can't it run node and talk Web Sockets?). With trends towards compact,
> full-featured, computers like the Raspberry Pi and BeagleBones, won't the
> Arduino be eventually displaced by these more capable, yet just as
> affordable, machines?

Perhaps, and perhaps not.

As lowly as the AVR processors are, there are things that I can do on those processors, that I can't do under linux.

The reasons for this relate to the fact that linux isn't realtime and certain types of waveforms are difficult to capture or generate with a non realtime OS.
The BeagleBone Black has some onboard support for hardware PWM and some more advanced input capture, but there are still a limited number of these channels.

For example, trying to control 32 RC style servos from a beagleboard is possible, but you'll get jitter in the servos. With an AVR, I can do this in a jitter free manner.

So I still see a place for low-end processors like the Arduino provides.

Dave Hylands

[Ehsan Akhgari]

On 2013-10-10 9:09 PM, Vasilis Georgitzikis wrote:
> Hey James,
> Nice to see there's still interested. I'm not particularly worried about the technical aspects, but I do love seeing some initial interest. I went ahead and created a wiki page with some initial thoughts and suggestions. Let me know what you guys think.
>
> https://wiki.mozilla.org/WebAPI/WebSerial

Thanks, Vasilis! I'd appreciate if you can sync up with Kyle, Eric and
others to come up with a more detailed API proposal. I think at the
next step, the proposal should cover the WebIDL describing the API
surface as well as the security of the API. Also, we should pay
attention to the RFCOMM upgrade path, it would be very nice if things
written on top of WebSerial can be ported to WebBluetooth relatively
easily! :-)

Cheers,
Ehsan

[fbender]

On Tuesday, October 15, 2013 8:54:15 PM UTC+2, Marcos Caceres wrote:
> I still think that having these types of devices talk either HTTP or WebSockets would address most of the use cases - what is missing is a service discovery API to allow local connections to these kinds of devices.

I was communicating with the developer of Espruino during their Kickstarter campaign (http://www.kickstarter.com/projects/48651611/espruino-javascript-for-things). The Espruino board is programmed via a Chrome Web App utilizing the Serial port API, and also provides a CLI for just-in-time code execution on the board (especially helpful for early development and tinkering). So I was proposing a cross-browser or at least Firefox version of the editor, but the developer said that as long as Firefox does not have a Serial API, this is not going to happen. I also proposed utilizing (Web)Sockets, but that's not going to happen soon, either. So a WebSerial API would solve this issue, and I'm strongly rooting for it.

I want to emphasize that this use case is mostly for Desktop and not B2G, and that's fine. I think these H/W-centric APIs should especially be available for Desktop because it allows tinkering and trying out new stuff. The lessons learned there can then be easily transferred to Mobile and/or new APIs. Developing/exploring on Mobile phones does not make that much sense due to device (mostly display & input) constraints (tablets may however work ok). The API should not be available to Web content, of course, however Firefox Addons and maybe Firefox (Desktop) Installed Apps should be able to use it!

It would be great to get this stuff going, so that I can enjoy playing with Espruino (et al.) without needing to use Chrome ;).

[tzi...@gmail.com]

Hey Florian,
I would totally agree. My original thought was also that whatever happens it could (should?) be available for both B2G and Desktop.

In fact, I intend to start the same kind of discussion about making the Chrome Apps Serial API available to websites or extensions in the Chromium project as well, given the overwhelming support I see here. (Which is part of the reason I asked opinions about their implementation, because ideally the proper way to go about this is to move towards a standardized API and push it through W3C as a web standard)

In regards to the desktop though, or idea is to expose it to Extensions, but you might also just expose it to websites in general with no significant security concerns.

Like i mention in the Wiki page, it seems to me that the security concerns are the same as the camera and location API, which are solved by asking the user to opt-in.

Thoughts on this?

[Marcos Caceres]

This is helpful info, thanks!

--
Marcos Caceres

[Donovan Preston]

On 10/16/13 3:25 PM, Dave Hylands wrote:
>
> As lowly as the AVR processors are, there are things that I can do on those processors, that I can't do under linux.
>
> The reasons for this relate to the fact that linux isn't realtime and certain types of waveforms are difficult to capture or generate with a non realtime OS.
> The BeagleBone Black has some onboard support for hardware PWM and some more advanced input capture, but there are still a limited number of these channels.

Yep -- this is exactly where the AVR still fits in and won't be
displaced by boards that run a full linux system any time soon. Having
true real time control is essential for some use cases.

In one of my projects, having access to the Mega's four hardware timers
is necessary to prevent jitter and synchronize between channels, and the
hardware interrupts are nice as well. The Raspberry Pi only has one
hardware timer, making it unsuitable.

In fact, I even have one project where I control a Mega over USB serial
from a Raspberry Pi. I'd like it to be a Firefox OS device instead :-)

Donovan

[Marcos Caceres]

On Wednesday, October 16, 2013 at 9:50 PM, tzi...@gmail.com wrote:

> Hey Florian,
> I would totally agree. My original thought was also that whatever happens it could (should?) be available for both B2G and Desktop.
>
> In fact, I intend to start the same kind of discussion about making the Chrome Apps Serial API available to websites or extensions in the Chromium project as well, given the overwhelming support I see here. (Which is part of the reason I asked opinions about their implementation, because ideally the proper way to go about this is to move towards a standardized API and push it through W3C as a web standard)

Agree, this would be the right way to go (adding more proprietary APIs to Firefox would not be a good thing). If you get enough traction and support from the Chrome guys, then you might want to bring it to the SysApps WG or DAP:

http://www.w3.org/2012/sysapps/
http://www.w3.org/2009/dap/

If you can gather some kind of list of the apps that are currently using the Chrome extension, that would be quite helpful in demonstrating both the demand and use cases. Getting buy in from Google would also go a long way in making a case for standardization (Mozilla and Google are both part of SysApps).

> In regards to the desktop though, or idea is to expose it to Extensions, but you might also just expose it to websites in general with no significant security concerns.
>
> Like i mention in the Wiki page, it seems to me that the security concerns are the same as the camera and location API, which are solved by asking the user to opt-in.
>
> Thoughts on this?

Agree. They seem fairly similar.

[tzi...@gmail.com]

@Chris:
I must say I like your analysis. Especially since you've dealt with this stuff before from a serial API developer's standpoint (whereas I have seen the other side of the coin, albeit in a good variety of languages/libraries). I particularly agree heavily on supporting non-standard baudrates, and not implementing helper functions like readLine() in this layer, and letting people implement these at a higher level, and i do agree on the close() function. I don't have too much experience with the other two, but i think we share the same mindset towards that.


@Marco
There aren't many out there to be honest (besides the Espruino one). The API came out about 4 months ago, and it's limited to Chrome Apps, so the ones I know of are an Arduino communication app http://blog.arduino.cc/2013/06/03/how-to-use-chromes-serial-api/) and some examples provided by google like https://github.com/GoogleChrome/chrome-app-samples/tree/master/serial/ledtoggle and https://github.com/GoogleChrome/chrome-app-samples/tree/master/servo

btw, purely in the interest of conversation, I would really not count on seeing serial being dropped out of the radar any time soon, or 3d printers moving from the standard (G-Code over serial, which, amazingly enough, was first developed 60 years ago, in 1950, and is so extensible and stable that it's still used as such). in fact, as people have more or less mentioned above, it's so simple and ever-present that virtually every new connectivity tech provides a compatibility layer (cases in point: usb, firewire, RFCOMM (Bluetooth), Infrared (remember that?), gps). heck, even cisco routers are programmed through a serial port (physical or virtual). i was personally not at all surprised that Chrome added support for it. i was a bit surprised that they only made it available on Chrome Apps, since there don't seem to be any security issues to justify that, but of course Google has their own agenda.

@Ehsan and everyone else,
first of all, i've started an irc channel, #webserial, to help communicate and shoot ideas in the refinement of the API. i'll be on the road for the next couple of days so you might not see me there, but everyone is definitely welcome.

do you think it would make sense to set up a meeting to discuss these? or have the discussion in bugzilla? in the meantime, i'll expand the current API to make it actually meaningful. for now, i will try to keep it as close as possible to the chrome api (in the interest of both compatibility/standardization, and because i believe it's a good reference point), while taking into account Chris' observations.

btw, it's not clear to me how the Serial and RFCOMM APIs are relevant to each other. of course, i don't know much about it, but doing a quick research, it looks like operating systems (at least os x, and according to this: https://developer.apple.com/library/mac/documentation/devicedrivers/conceptual/bluetooth/BT_Bluetooth_On_MOSX/BT_Bluetooth_On_MOSX.html) allow you to:
1. communicate with the device at the RFCOMM layer
2. expose the device as a virtual serial port, which you can then communicate to using the Serial API layer (and in this case, would also be exposed to the WebSerial API)
So it seems to me that Linux would just expose the virtual serial (bluetooth) port by design (see 2above). I might also be completely wrong about this. i've barely scratched the surface in regards to RFCOMM

cheers,
tzikis

[fbender]

On Wednesday, October 16, 2013 10:50:33 PM UTC+2, tzi...@gmail.com wrote:
> In regards to the desktop though, or idea is to expose it to Extensions, but you might also just expose it to websites in general with no significant security concerns.
>
> Like i mention in the Wiki page, it seems to me that the security concerns are the same as the camera and location API, which are solved by asking the user to opt-in.
>
> Thoughts on this?

I think it would suffice to nag the user ("Do you want XYZ.com to access device ABC?") once a piece of h/w is connected and/or the WebApp wants to connect to it through the API. Bonus points for remembering site and device combination so you only ask once, but I think it would also be ok for the UA to ask on every connect. Also, the user base for this feature is not the I-don't-know-what-a-computer-is-but-I-love-the-Internets kind but mostly people with h/w or dev knowledge, so the security measures don't have to be extrodinarily dumbo-tolerant.

However, the API should just fail (i. e. return false or Promise.reject* or whatever) when no device is connected to reduce possible attack vectors and confusion for non-users of the API.


* Please look at using Promise-s for Async operations as it's the way to go for the web platform from now on (both W3C [and WHATWG] and TC39 support it).

[pur3...@googlemail.com]

Hi, I'm the guy behind Espruino (mentioned above) and I just want to add my thoughts to this.

I'm sorry if this duplicates what others have written but I'm insanely busy right now and I don't have time to fully read the other comments :( Hopefully in a month or two the Espruino board will be with the manufacturer and I'll have more time.

* This is awesome - I'd love to see Serial access on webpages outside Google's Sandbox.

* I heard that Google will be releasing some mods to their serial port API really soon (https://code.google.com/p/chromium/issues/detail?id=307184). I don't know how this will affect their willingness to implement this new API.

* Since basically all Serial implementations use USB now, it's really likely someone will pull out the USB connector while the app is running. Chrome API (esp on Windows) handles this (disconnect + reconnect) very badly and it'd be great if this spec could do it better.

* Callbacks for (at the very least) read and connection status (disconnect) would be awesome.

- Gordon

[Ehsan Akhgari]

On 2013-10-16 7:32 PM, tzi...@gmail.com wrote:
> @Ehsan and everyone else,
> first of all, i've started an irc channel, #webserial, to help communicate and shoot ideas in the refinement of the API. i'll be on the road for the next couple of days so you might not see me there, but everyone is definitely welcome.
>
> do you think it would make sense to set up a meeting to discuss these? or have the discussion in bugzilla? in the meantime, i'll expand the current API to make it actually meaningful. for now, i will try to keep it as close as possible to the chrome api (in the interest of both compatibility/standardization, and because i believe it's a good reference point), while taking into account Chris' observations.

I tend to avoid meetings when I can. :-) I believe asynchronous
discussion through email should be easier for at least some of us, so
I'd prefer if we did that. As I mentioned before, I think the next step
is for somebody to step up and write a more detailed proposal of the API
so that we can discuss it, but if you guys have specific questions about
things that you need to know answers to in order to create the initial
proposal, please write to this mailing list. :-)

> btw, it's not clear to me how the Serial and RFCOMM APIs are relevant to each other. of course, i don't know much about it, but doing a quick research, it looks like operating systems (at least os x, and according to this: https://developer.apple.com/library/mac/documentation/devicedrivers/conceptual/bluetooth/BT_Bluetooth_On_MOSX/BT_Bluetooth_On_MOSX.html) allow you to:
> 1. communicate with the device at the RFCOMM layer
> 2. expose the device as a virtual serial port, which you can then communicate to using the Serial API layer (and in this case, would also be exposed to the WebSerial API)
> So it seems to me that Linux would just expose the virtual serial (bluetooth) port by design (see 2above). I might also be completely wrong about this. i've barely scratched the surface in regards to RFCOMM

I'm not the right person to answer this, Kyle probably is!

Cheers,
Ehsan

[Dave Hylands]

----- Original Message -----
> From: "fbender" <florian...@quantumedia.de>
...snip...
> I think it would suffice to nag the user ("Do you want XYZ.com to access
> device ABC?") once a piece of h/w is connected and/or the WebApp wants to
> connect to it through the API. Bonus points for remembering site and device
> combination so you only ask once, but I think it would also be ok for the UA
> to ask on every connect. Also, the user base for this feature is not the
> I-don't-know-what-a-computer-is-but-I-love-the-Internets kind but mostly
> people with h/w or dev knowledge, so the security measures don't have to be
> extrodinarily dumbo-tolerant.
>
> However, the API should just fail (i. e. return false or Promise.reject* or
> whatever) when no device is connected to reduce possible attack vectors and
> confusion for non-users of the API.

For the most part, its pretty much impossible to tell if a device is connected to a serial port, let alone what type of device it is.

Dave Hylands

[fbender]

Am Donnerstag, 17. Oktober 2013 17:26:37 UTC+2 schrieb Dave Hylands:
> For the most part, its pretty much impossible to tell if a device is connected to a serial port, let alone what type of device it is.

That's very unfortunate, but I expected this. Would it be possible to withheld any device answers until the user opts in (of course, only READ should be allowed for the first call)? That way the user is only nagged once a device is connected and answers (the script does not know if an answer was refused by the user, or there was no answer at all).

[florian...@quantumedia.de]

Am Mittwoch, 16. Oktober 2013 20:15:20 UTC+2 schrieb tzi...@gmail.com:
> @Chris, did you have any time to check out the proposed API on https://wiki.mozilla.org/WebAPI/WebSerial ?

I don't know a lot about this serial stuff, but I had a look at the Chrome API, and here are a few things that came to my mind:

A: getPorts() would allow fingerprinting, IMO. The severity depends on when you want to allow access to the API (e. g. when `navigator.connectSerialPort()` [1], that reduces fingerprinting to users who opt in; whereas when prompting the user upon the first data received via serial port[2] and allowing to query all available ports, that allows straight fingerprinting.

B: Selecting the port to talk to should be up to the UA (mitigating A), listing the available ports (e. g. with a LRU list at the top) with the permission prompt (this would not allow what I described at [2]), i. e. a getPorts() method is not necessary. The API should allow a mechanism to connect to multiple devices (e. g. `connectSerialPort()` passes the Serial Port Connection Object (SPCO) to the Promise.resolve callback, if the user connects to a device that he is already connected to, he receives the same SPCO).

C: … well, I had a C, but I forgot it … will post again if I remember.


[1] I propose the following interface:
`Promise<object connection> navigator.connectSerialPort(string reason[, object options])`
The `connection` object implements the open/close/read/write/etc. APIs.

[2] https://groups.google.com/d/msg/mozilla.dev.webapi/wykkibp6BKo/EFczqy7NqLsJ

[Dave Hylands]

It seems to me that if you're going to prompt for something, it should happen before the serial device is actually opened. The mere act of opening the port may change control lines.

You need to consider read-only devices, write-only devices, devices where you don't actually do any I/O but rather just read and/or write control lines (DTR/DSR, RTS/CTS, DCD, RING).

You can also configure the open to block until carrier (DCD) is present (classic with real modems), or to ignore carrier.

You also need to consider that the devices may change names depending on what else is plugged in. Especially when you're using USB-to-serial dongles that don't have serial number EEPROMs. Under linux, this manifests itself as the device showing as /dev/ttyUSB0 one time and /dev/ttyUSB1 another. I've even had that happen without physically unplugging/plugging a device. Under Windows it manifests as COMx: changes where x is some number.

Windows tends to tie the COM port number of USB serial ports to the physical port that the dongle is plugged into. Linux tends to base it on the order that the devices are plugged in.

Dave Hylands

[fbender]

On Saturday, October 19, 2013 9:18:48 PM UTC+2, Dave Hylands wrote:
> It seems to me that if you're going to prompt for something, it should happen before the serial device is actually opened. The mere act of opening the port may change control lines.

Yeah, I think that's the best approach (see https://groups.google.com/d/msg/mozilla.dev.webapi/wykkibp6BKo/2l8uokoWOPUJ). However, that poses the risk of rogue websites asking unsuspecting users to (and luring into) allow accessing hardware. The question is if we want to do something against that and protect "noob" users.

As a first step, I propose limiting calling of the API to same-origin scripts (cross-origin scripts that call this API experience the same behaviour as if the user denied access). Of course, this is up to the UA, but should be put into the standards document as a recommended measurement.

For the grand picture, maybe CSP (or else) can adopt a new directive that indicates that a site wants to (directly) talk to hardware (if directive is not present in the header, all such APIs fail with a "not allowed" answer). That will not protect users that go to a rogue site, and may not protect users visiting hacked sites (if the hacker can set headers, he can set the directive[1]), but it may protect from unintentional usage of the API, and some hacks (XSS & content injection).


[1] Such a directive should not be allowed to be set via the CSP 1.1 (currently experimental) meta[http-equiv] element.

[fbender]

On Saturday, October 19, 2013 8:23:25 PM UTC+2, florian...@quantumedia.de wrote:
> C: … well, I had a C, but I forgot it … will post again if I remember.

C: API calls should always have a (customizable[1]) timeout that calls the Promise.reject callback. This probably poses the risk of calling the same operation multiple times on slow / not reacting devices but that's up to the author to mitigate any negative effects this may have, IMO (e. g. when a write() times out, read() before trying to write() again).


[1] E.g. timeout can be set via the options parameter of `connectSerialPort()`. Should this be allowed to be reset at a later point, e. g. `serial.timeout = 20;`? (What other options should the author be able to reset on an open connection? See e. g. the options under http://developer.chrome.com/apps/serial.html#method-open)

[Thinker K.F. Li]

Marcos Caceres <mcac...@mozilla.com> writes:

> On Tuesday, October 15, 2013 at 7:06 PM, Dave Hylands wrote:
>
>>
>> A couple of platforms which are attempting to do exactly this (well
>> using small ARM micros, and not AVRs):
>> http://www.espruino.com/
>> http://tessel.io/
>
> Thank gawd someone is doing this! Will investigate.

>
> I still think that having these types of devices talk either HTTP or
> WebSockets would address most of the use cases - what is missing is a
> service discovery API to allow local connections to these kinds of
> devices.

Hi Macro,

We have some requests from TV or other applications for B2G project.
They also bring in a lot of requests for new APIs. With limited
engineering resources, I think WebSerial can be a temporary/short term
solution for various new API requests that we are not ready for. It can
be used as a communication channel between preinstalled sys apps and the
underlying platform. HW vendors can use WebSerial to control their
features that their APIs are not ready.

--
Sinker
--
天教懶漫帶疏狂

[Marcos Caceres]

On Monday, October 21, 2013 at 4:54 PM, Thinker K.F. Li wrote:

>
> Hi Macro,
>
> We have some requests from TV or other applications for B2G project.
> They also bring in a lot of requests for new APIs. With limited
> engineering resources, I think WebSerial can be a temporary/short term
> solution for various new API requests that we are not ready for. It can
> be used as a communication channel between preinstalled sys apps and the
> underlying platform. HW vendors can use WebSerial to control their
> features that their APIs are not ready.
>

Could be interesting - but note that there is generally no such thing as a temporary short term solution once content starts being used on the Web. Depending on the popularity of any given web app, we might need to support such an API for a long time (specially if it's shipped without requiring certification).

But anyway - we would need to look at these on a case by case basis and see how the Web Serial could fit to meet their requirements. Can you list some of the APIs or features that you think could be addressed by this API?

[Marcos Caceres]

A highly related API is the Web MIDI API… might be good to look at for inspiration for the security model and for an idea of how to model the API:

http://webaudio.github.io/web-midi-api/

Also, can I suggest that we form a W3C community group [2] (or reuse the Web of Sensors Group [3]) for this? Given the number of parties interested in this API, using a W3C space to put together a spec is nice from an IPR perspective.

I'd be happy to help people get started with that if interested.

>
> [1] Such a directive should not be allowed to be set via the CSP 1.1 (currently experimental) meta[http-equiv] element.

[2] http://www.w3.org/community/about/
[3] http://www.w3.org/community/sensorweb/

[Thinker K.F. Li]

From: Marcos Caceres <mcac...@mozilla.com>
Subject: Re: WebSerial API
Date: Mon, 21 Oct 2013 17:45:11 +0100

For DTV, I guess some features is usually required, but not supposed
to be accessed by apps other than system app.

- Setting colors, contracts, ..., screen relative features.
- Receiver of remote controller.
- It is very vendor specialized
- video signal source selector
- VGA, HDMI, AV, broadcast signal, ...
- channel scanning (for broadcast TV)
- control TV turner
- HW buttons
- CD player (maybe)
- eject, play, meta info, ....
- maybe more

These are features that I can imagine, and no any app, other than sys
app, should access them. I think Web Serial is feasible for early
adopters of Web-based TV to integrate these features. These features
can be seen as separated virtual devices attached to TV with serial
ports.

[Vasilis Georgitzikis]

@Thinker,
that would be a cool way for dtv manufactures to expose this kind of controlling apis, and it's in fact how GPSes, Modems, and other such devices expose their APIs. But do you know if they actually do that? I mean, do they appear as serial ports that you can talk to? If so, that definitely sounds like another cool usage of WebSerial, but if they don't, I doubt they'll change the way they work.

@Florian,
about your previous posts on reading/writing/listing ports, I think someone already mentioned that you effectively cannot identify a serial device because the name changes (there are more rules and sub-cases about how each OS handles the name change than you want to know, and even more once you start counting physical serial ports, virtual serial ports over usb, and virtual ports over bluetooth). I guess the security layer should just ask the user before even listing the ports anyway.


@Marco, you mentioned setting a W3C group for this. I'm interested in participating, and I'd love it if you could share the info you mentioned on how to start such a proposal. Would the Web of Sensors Group [1] or Device APIs Group [2] be better for that?

I haven't seen any improvement for the basic suggested API on the wiki yet, so I'll start incorporating the ideas here, hopefully soon. In the meantime, I'll be in MozFest [3] during Oct 25-28. Is anyone else going to be there? It would be great to meet there and discuss this up close, maybe even set up a hackathon while we're at it!

Cheers,
Vasilis (aka tzikis)

[1] http://www.w3.org/community/sensorweb/
[2] http://www.w3.org/2009/dap/
[3] http://mozillafestival.org/

[Lars Knudsen]

Just a small note on input to the api: We are working on a project, where
a part of it is node.js connecting to some external microcontroller HW
(similar to arduino). The way that the node module "serialport" (
https://github.com/voodootikigod/node-serialport) handles things seem quite
good for our purpose at least. E.g. we can use the pnpId returned from the
listing to determine the right port to connect to, etc. This is something
really annoying with the chrome.serial api, where you basically just get a
full list of potential serial devices (completely useless functionality ..
no.. really ;))

The way that node-serialport handles data transfers in 8bit buffers with
transparent casting from string and the general opening and closing
handling/events seem quite well done too.

Regarding bluetooth serial: when a bt serial link is created with rfcomm
(linux), this seems to work quite well with the serialport module - with no
need for the module to know anything but "this is a serial device" and a
file link. Polluting the lib/api with BT specific things might not be
good. On the other hand, if it could be possible to make some abstraction
so USB pnpIds, BT info (or other future connection tech) could be easily
listed/found when searching for a particular serial connection could be
useful.

just my DKK 0.5 input

- Lars

[Vasilis Georgitzikis]

hey lars,
that's interesting. so linux seems to handle rfcomm devices like os x. that is, by showing a (virtual) serial port on the system, that you then access over serial APIs.

in regards to the device id, that's interesting. i would guess that we can't do that, because, for example, there is no such thing as a unique device id for physical serial ports, and i wonder if this works on windows anyway. I'm hoping Chris (voodootikigod) can shed some light on this though.

Cheers,
tzikis

On Oct 23, 2013, at 2:31 PM, Lars Knudsen wrote:

> Just a small note on input to the api: We are working on a project, where a part of it is node.js connecting to some external microcontroller HW (similar to arduino). The way that the node module "serialport" (https://github.com/voodootikigod/node-serialport) handles things seem quite good for our purpose at least. E.g. we can use the pnpId returned from the listing to determine the right port to connect to, etc. This is something really annoying with the chrome.serial api, where you basically just get a full list of potential serial devices (completely useless functionality .. no.. really ;))

[Lars Knudsen]

On Wed, Oct 23, 2013 at 3:39 PM, Vasilis Georgitzikis <tzi...@gmail.com>wrote:

> hey lars,
> that's interesting. so linux seems to handle rfcomm devices like os x.
> that is, by showing a (virtual) serial port on the system, that you then
> access over serial APIs.
>

it seems to work quite well - also the closing of the port when
removed/switched off (but probably requires some further
tests/investigation ... there is probably a reason for the bt-serialport
module done as a fork [node.js again])

>
> in regards to the device id, that's interesting. i would guess that we
> can't do that, because, for example, there is no such thing as a unique
> device id for physical serial ports, and i wonder if this works on windows
> anyway. I'm hoping Chris (voodootikigod) can shed some light on this though.
>

As I mentioned - any sort of ID that can be linked to the serial port would
be great. If we don't get that when listing, it's close to useless (as
with the chrome.serial api... currently listing 20-30 serial devices on my
linux box... yeah right ;)). I am sure we can find some code to make it
cross platform from the node-serialport module.

We have been doing quite a bit of work in the field (not only with
arduinos) - so I will keep an eye on this thread to see if I can help with
some input from experiences.

br
Lars

[Marcos Caceres]

On Wednesday, October 23, 2013 at 2:21 PM, Vasilis Georgitzikis wrote:

> @Marco, you mentioned setting a W3C group for this. I'm interested in participating, and I'd love it if you could share the info you mentioned on how to start such a proposal. Would the Web of Sensors Group [1] or Device APIs Group [2] be better for that?

The Web of Sensors Group would be better, as the Device APIs Group requires you (and possibly other interested parties) to be a W3C member (which means paying a bunch of money!).

Kicking off the work over at the Web of Sensors is trivial. Everyone who wants to participate can just head over to [1], click the “join this group” button, and that will subscribe you to the list. The reason we would want everyone to join that group is because we get good patent protection for everyone who contributes ideas/code!

From there, we would just need to set up a space on Github to start hacking on the spec. Once we have a spec we are happy with, we can publish it at the W3C - plus if we manage to get something implemented in Gecko behind a flag, it would go a long way … specially if it was also compatible with what the Chrome guys are doing.

Once we have a document published, we can then start shopping it around to different working groups - either through DAP or SysApps as a co-deliverable with the community group. That would allow the document to then be put onto the W3C’s Recommendation track.

If you want to see an example of a group that has done something similar successfully, take a look at the responsive images community group [2].

Happy to walk you through the process + answer any questions.

[1] http://www.w3.org/community/sensorweb/
[2] http://responsiveimages.org/
--
Marcos Caceres

[Lars Knudsen]

On Wed, Oct 23, 2013 at 3:51 PM, Lars Knudsen <lar...@gmail.com> wrote:

>
>
>
> On Wed, Oct 23, 2013 at 3:39 PM, Vasilis Georgitzikis <tzi...@gmail.com>wrote:
>
>> hey lars,
>> that's interesting. so linux seems to handle rfcomm devices like os x.
>> that is, by showing a (virtual) serial port on the system, that you then
>> access over serial APIs.
>>
> it seems to work quite well - also the closing of the port when
> removed/switched off (but probably requires some further
> tests/investigation ... there is probably a reason for the bt-serialport
> module done as a fork [node.js again])
>
>>
>> in regards to the device id, that's interesting. i would guess that we
>> can't do that, because, for example, there is no such thing as a unique
>> device id for physical serial ports, and i wonder if this works on windows
>> anyway. I'm hoping Chris (voodootikigod) can shed some light on this though.
>>
> As I mentioned - any sort of ID that can be linked to the serial port
> would be great. If we don't get that when listing, it's close to useless
> (as with the chrome.serial api... currently listing 20-30 serial devices on
> my linux box... yeah right ;)). I am sure we can find some code to make it
> cross platform from the node-serialport module.
>

Some direct links to the juicy bits:

Windows:
https://github.com/voodootikigod/node-serialport/blob/master/src/serialport_win.cpp#L370
Linux/Unix:
https://github.com/voodootikigod/node-serialport/blob/master/serialport.js#L420

...or... "what google missed of VERY useful info for chrome.serial"

>>> @Marco, you mentioned setting a W3C group for this. I'm interested in
>>> participating, and I'd love it if you could share the info you mentioned on
>>> how to start such a proposal. Would the Web of Sensors Group [1] or Device
>>> APIs Group [2] be better for that?
>>>

>>> I haven't seen any improvement for the basic suggested API on the wiki
>>> yet, so I'll start incorporating the ideas here, hopefully soon. In the
>>> meantime, I'll be in MozFest [3] during Oct 25-28. Is anyone else going to
>>> be there? It would be great to meet there and discuss this up close, maybe
>>> even set up a hackathon while we're at it!
>>>
>>> Cheers,
>>> Vasilis (aka tzikis)
>>>

>>> [1] http://www.w3.org/community/sensorweb/

[Thinker K.F. Li]

From: Lars Knudsen <lar...@gmail.com>
Subject: Re: WebSerial API
Date: Wed, 23 Oct 2013 16:06:08 +0200

I vote to the idea of deterministic IDs, so the Apps can map serial
ports to attached devices easily. But, I think this is an
implementation dependent info. The device IDs that comes from
device's serial number or hardware address are not always work. For
example, a massive producted devices, they usually expect to name
ports according the position or order of the connectors. Just like
COM1, COM2.

I think all that we need to do is to provide a way (a string?) to
convey device ID.

[Florian Bender [:fbender]]

On Wednesday, October 23, 2013 3:21:01 PM UTC+2, Vasilis Georgitzikis wrote:
> @Florian,
>
> about your previous posts on reading/writing/listing ports, I think someone already mentioned that you effectively cannot identify a serial device because the name changes (there are more rules and sub-cases about how each OS handles the name change than you want to know, and even more once you start counting physical serial ports, virtual serial ports over usb, and virtual ports over bluetooth). I guess the security layer should just ask the user before even listing the ports anyway.

I now think that getPorts() should not be part of the API, and permission UI should display a list of ports the user can select from for the requested connection. As device identification is (at best) difficult, and ports change (depending on OS/system), this is out of scope for the API or expected UA behaviour.
See (partially quoted below): https://groups.google.com/d/msg/mozilla.dev.webapi/wykkibp6BKo/2l8uokoWOPUJ

On Saturday, October 19, 2013 8:23:25 PM UTC+2, Florian Bender [:fbender] wrote:
> A: getPorts() would allow fingerprinting, IMO. The severity depends on when you want to allow access to the API (e. g. when `navigator.connectSerialPort()` [1], that reduces fingerprinting to users who opt in; whereas when prompting the user upon the first data received via serial port[2] and allowing to query all available ports, that allows straight fingerprinting.
>
> B: Selecting the port to talk to should be up to the UA (mitigating A), listing the available ports (e. g. with a LRU list at the top) with the permission prompt (this would not allow what I described at [2]), i. e. a getPorts() method is not necessary. The API should allow a mechanism to connect to multiple devices (e. g. `connectSerialPort()` passes the Serial Port Connection Object (SPCO) to the Promise.resolve callback, if the user connects to a device that he is already connected to, he receives the same SPCO).
>

> […]

[Florian Bender [:fbender]]

Am Montag, 21. Oktober 2013 18:50:58 UTC+2 schrieb Marcos Caceres:
> A highly related API is the Web MIDI API… might be good to look at for inspiration for the security model and for an idea of how to model the API:

Excellent idea.

As far as I can see in the MIDI spec[1], there's very little prose required to indicate the prompt-for-access security model, and I think adding a "let the user select the port to access via the prompt" statement shouldn't be too much of a hassle, either.

[Lars Knudsen]

Whatever happens with the spec - just remember to make sure it runs past
some "Real Developers(TM)" before finalized. This is one of those APIs
that will be very widely used if done right - or shelved if parts are
missing. IMHO - good identification of connected units (at least to the
level of what the node-serialport module has) *has* to be part of the spec
- or a parallel spec (if you want to split it up). If not - it will be as
useless as the current chrome.serial API. So please - at least this time -
run it past some developers for a few real world reference apps. Actually,
this would be a healthy requirement for the specification process in
general. Any thoughts?

[Marcos Caceres]

Putting explicit UX requirements into a spec is not something that is usually done. For example, the Geolocation API states that:

“A conforming implementation of this specification must provide a mechanism that protects the user's privacy and this mechanism should ensure that no location information is made available through this API without the user's express permission.”

So, maybe for this spec:

“User agents must not grant Web sites access to any serial ports without the express permission of the user. A conforming implementation of this specification must provide a means for user to control which serial ports the API can access, as well as a means for the end-user to be able to revoke all access to serial ports.”

This is an example of what I had in mind for the MIDI API. I imagine we want something similar, but with just the ports.  
https://twitter.com/marcosc/status/279264665639481344/photo/1
 

[Marcos Caceres]

On October 28, 2013 at 8:27:04 AM, Lars Knudsen (lar...@gmail.com) wrote:
> Whatever happens with the spec - just remember to make sure it runs past
> some "Real Developers(TM)" before finalized. This is one of those APIs
> that will be very widely used if done right - or shelved if parts are
> missing. IMHO - good identification of connected units (at least to the
> level of what the node-serialport module has) *has* to be part of the spec
> - or a parallel spec (if you want to split it up). If not - it will be as
> useless as the current chrome.serial API. So please - at least this time -
> run it past some developers for a few real world reference apps. Actually,
> this would be a healthy requirement for the specification process in
> general. Any thoughts?

Agree. It would be good to code this up in Node in parallel (or wrap an existing Node library). If there is already a large Node community doing this, we should reach out to them early to discuss the design.   
—

Marcos Caceres

[Florian Bender]

On Monday, October 28, 2013 12:14:06 PM UTC+1, Marcos Caceres wrote:
> “User agents must not grant Web sites access to any serial ports without the express permission of the user. A conforming implementation of this specification must provide a means for user to control which serial ports the API can access, as well as a means for the end-user to be able to revoke all access to serial ports.”

Sounds great!

[Marcos Caceres]

Has anyone spun up a Github repository yet to start working on this? I would again urge interested people to move the discussion to the Web of Sensors CG [1] (Mozilla has rejoined in preparation) and that we spin up a Github repo to actually be able to work on this.

http://www.w3.org/community/sensorweb/ 

[Florian Bender]

On Monday, October 28, 2013 5:23:16 PM UTC+1, Marcos Caceres wrote:
> Has anyone spun up a Github repository yet to start working on this?

I haven't seen any, so feel free to do that (maybe create an organization so the repo can have multiple maintainers). You seem to have some prior experience with this/editing.

[voodoo...@gmail.com]

I have been remiss in following this discussion, but I 100% want to assert this is a very important point. We have many people using node-serialport from other implementations (chrome, ruby, etc) because of what it has right and that is also why it has taken off as much as it has. Happy to offer my support as much as I can with running a company, 2 conferences, and a family -- but I am here - email me directly if I am not responsive ( voodoo...@gmail.com ). I can also connect you up with all the people using node-serialport for their various use cases for review.

Keep rocking!

[Marcos Caceres]

On Tuesday, October 29, 2013 at 2:48 PM, Florian Bender wrote:

> On Monday, October 28, 2013 5:23:16 PM UTC+1, Marcos Caceres wrote:
> > Has anyone spun up a Github repository yet to start working on this?
>
>

https://github.com/organizations/sensorweb

Those that want to participate, please send me your GH username.

--
Marcos Caceres

[voodoo...@gmail.com]

I'd love to participate: voodootikigod


Thanks,


Chris Williams

[Marcos Caceres]

So, the WHATWG want us to do the work in their GH organization instead. They can help with the standardization process and make sure more implementers get their eyes on this effort.

--
Marcos Caceres

On Tuesday, October 29, 2013 at 3:02 PM, Marcos Caceres wrote:

>
>
>
> On Tuesday, October 29, 2013 at 2:48 PM, Florian Bender wrote:
>

> > On Monday, October 28, 2013 5:23:16 PM UTC+1, Marcos Caceres wrote:
> > > Has anyone spun up a Github repository yet to start working on this?
> >
>
>
>
>

> https://github.com/organizations/sensorweb
>
> Those that want to participate, please send me your GH username.
>
> --
> Marcos Caceres
>
>
>

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org (mailto:dev-w...@lists.mozilla.org)
> https://lists.mozilla.org/listinfo/dev-webapi

[Lars Knudsen]

should we add ourselves somewhere there then? (thanks for the short
membership to that other one, btw ;))

GH: "larsgk"

On Tue, Oct 29, 2013 at 4:38 PM, Marcos Caceres <mcac...@mozilla.com>wrote:

> So, the WHATWG want us to do the work in their GH organization instead.
> They can help with the standardization process and make sure more
> implementers get their eyes on this effort.
>
> --
> Marcos Caceres
>
>
> On Tuesday, October 29, 2013 at 3:02 PM, Marcos Caceres wrote:
>
> >
> >
> >
> > On Tuesday, October 29, 2013 at 2:48 PM, Florian Bender wrote:
> >

> > > On Monday, October 28, 2013 5:23:16 PM UTC+1, Marcos Caceres wrote:
> > > > Has anyone spun up a Github repository yet to start working on this?
> > >
> >
> >
> >
> >

> > https://github.com/organizations/sensorweb
> >
> > Those that want to participate, please send me your GH username.
> >
> > --
> > Marcos Caceres
> >
> >
> >
> > _______________________________________________
> > dev-webapi mailing list
> > dev-w...@lists.mozilla.org (mailto:dev-w...@lists.mozilla.org)
> > https://lists.mozilla.org/listinfo/dev-webapi
>
>
>
> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-webapi
>

[Marcos Caceres]

On Tuesday, October 29, 2013 at 3:49 PM, Lars Knudsen wrote:

> should we add ourselves somewhere there then? (thanks for the short membership to that other one, btw ;))
>

Heh! well, it’s actually a good thing that the WHATWG is interested in helping us. Lots of good people there to provide guidance, and we automatically get 16 potential contributors.

Ok, all the magic will happen here:
https://github.com/whatwg/serial

If anyone is not sure yet how they can contribute, please click on the “watch” option to watch the repo and see how things evolve.

I’ll put up a spec template there for people to hack on.


--
Marcos Caceres

[j...@hikinghomeschoolers.org]

On Thursday, October 17, 2013 8:26:37 AM UTC-7, Dave Hylands wrote:

> For the most part, its pretty much impossible to tell if a device is connected to a serial port, let alone what type of device it is.

node-serialport exposes some metadata about the serial port which can be used to auto-detect devices. For example, here is the (fragile) logic I implemented a while back in the Reflecta protocol to detect a few types of Arduinos using this metadata:

require("serialport").list(function (error, results) {

var port;
for (var i = 0; i < results.length; i++) {
var item = results[i];

if (item.manufacturer && (item.manufacturer.indexOf('PJRC') !== -1 || item.manufacturer.indexOf('Arduino') !== -1)) {
port = item.comName;
break;
}

if (item.pnpId && item.pnpId.indexOf('Arduino') !== -1) {
port = item.comName;
break;
}

if (item.pnpId && item.pnpId.indexOf('Teensy') !== -1) {
port = item.comName;
break;
}
}

Note that this logic wouldn't work with chrome.serial because it exposes a list of string port names, not a more complex port object with metadata like pnpId and manufacturer.

[j...@hikinghomeschoolers.org]

On Tuesday, October 29, 2013 8:06:24 AM UTC-7, Chris Williams wrote:
> I'd love to participate: voodootikigod

Count me in as well: JayBeavers

[Lars Knudsen]

Just bumping these links to the detection code in node-serialport. Worth:
gold ;)

>>>> @Florian,
>>>> about your previous posts on reading/writing/listing ports, I think
>>>> someone already mentioned that you effectively cannot identify a serial
>>>> device because the name changes (there are more rules and sub-cases about
>>>> how each OS handles the name change than you want to know, and even more
>>>> once you start counting physical serial ports, virtual serial ports over
>>>> usb, and virtual ports over bluetooth). I guess the security layer should
>>>> just ask the user before even listing the ports anyway.
>>>>
>>>>

[Marcos Caceres]

On Tuesday, October 29, 2013 at 4:45 PM, j...@hikinghomeschoolers.org wrote:

> On Thursday, October 17, 2013 8:26:37 AM UTC-7, Dave Hylands wrote:
>
> > For the most part, its pretty much impossible to tell if a device is connected to a serial port, let alone what type of device it is.
>
>
> node-serialport exposes some metadata about the serial port which can be used to auto-detect devices. For example, here is the (fragile) logic I implemented a while back in the Reflecta protocol to detect a few types of Arduinos using this metadata:
>

Added those to the spec. Will checkin soon.

--
Marcos Caceres

[Florian Bender]

On Tuesday, October 29, 2013 5:00:41 PM UTC+1, Marcos Caceres wrote:
> Ok, all the magic will happen here:
>
> https://github.com/whatwg/serial
>
>
>
> If anyone is not sure yet how they can contribute, please click on the “watch” option to watch the repo and see how things evolve.

Thanks for your effort!

I'll stick to watching from the distance for now. Luckily participation does not require being added to the group, so I will chime in from time to time. :)

[Marcos Caceres]

On Tuesday, October 29, 2013 at 8:35 PM, Florian Bender wrote:

> On Tuesday, October 29, 2013 5:00:41 PM UTC+1, Marcos Caceres wrote:
> > Ok, all the magic will happen here:
> >
> > https://github.com/whatwg/serial
> >
> >
> >
> > If anyone is not sure yet how they can contribute, please click on the “watch” option to watch the repo and see how things evolve.
>
> Thanks for your effort!

No probs! The “webby" straw-man is up - it’s deliberately short on details as I expect it will get ripped apart.

http://whatwg.github.io/serial/

I’ve left the original design that was on the Wiki + brought in aspects from Node Serialport API.

I’ve started to list some of the issues on GH (so we don’t flood this list with discussion items):
https://github.com/whatwg/serial/issues

It would be great if we now move the discussion to Github, IRC (#webserial on the moz server), and the public-sensorweb list:
http://lists.w3.org/Archives/Public/public-sensorweb/


--
Marcos Caceres

[Vasilis Georgitzikis]

Wow, I can't believe the amount of attention this has gotten so far. I'm still on traveling mode until Nov 5-6, so I won't be able to contribute much, but Marcos, if you can add me on the repo too (GH username: tzikis), it would be great. I am on #webserial too, and will also register on the public-sensorweb list.

Cheers,
tzikis

On Oct 29, 2013, at 9:40 PM, Marcos Caceres wrote:

>
>
> On Tuesday, October 29, 2013 at 8:35 PM, Florian Bender wrote:
>

>> On Tuesday, October 29, 2013 5:00:41 PM UTC+1, Marcos Caceres wrote:
>>> Ok, all the magic will happen here:
>>>
>>> https://github.com/whatwg/serial
>>>
>>>
>>>
>>> If anyone is not sure yet how they can contribute, please click on the “watch” option to watch the repo and see how things evolve.
>>
>> Thanks for your effort!
>

> No probs! The “webby" straw-man is up - it’s deliberately short on details as I expect it will get ripped apart.
>
> http://whatwg.github.io/serial/
>
> I’ve left the original design that was on the Wiki + brought in aspects from Node Serialport API.
>
> I’ve started to list some of the issues on GH (so we don’t flood this list with discussion items):
> https://github.com/whatwg/serial/issues
>
> It would be great if we now move the discussion to Github, IRC (#webserial on the moz server), and the public-sensorweb list:
> http://lists.w3.org/Archives/Public/public-sensorweb/
>
>
> --
> Marcos Caceres
>

[mte9...@gmail.com]

Hi everybody,
there is any chance or rlease date for have this API in Gecko?
The maker world is out of the Mozilla sphere :-(

[Kyle Machulis]

I think work stalled out on this soon after the idea came up, due to the fact that "serial" is pretty hard to nail down in a web context. We're moving toward a generalized bluetooth API that might help, but that's still a couple of FxOS versions out, and bluetooth isn't really a solution for generalized device communication.

If you've got some ideas, feel free to share them on the whatwg serial proposal repo:

https://github.com/whatwg/serial

This is where most of the work is happening to define what the API should look like. Still got tons of open issues.