►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
B
B
A
Privacy
isn't
respected
companies
orphan
products,
we
have
to
beg
manufacturers
for
features
rather
than
just
writing
the
code
ourselves.
Manufacturers
make
choices
about
interoperability
based
on
their
strategic
relationships,
rather
than
our
needs
for
the
product.
The
s
and
IOT
stands
for
security
products
are
unreliable
because
companies
under
invest
in
testing,
especially
their
software.
We
won't
go
into
details.
This
is
already
well
established.
We
aren't
here
to
point
fingers
or
complain
about
IOT
we're
here
to
invite
you
to
help
fix
it.
We.
B
A
We
should
also
define
what
we
mean
by
embedded
software.
There
are
lots
of
definitions
around
code
that
works
with
hardware
code
that
runs
in
devices,
including
IOT
products
code
that
runs
on
constrained
or
resource
limited
hardware.
Often
all
of
those
are
true,
but
it
isn't
what
we
mean
by
embedded
embedded
software
is
software
written
for
a
set
of
known
constraints.
You
know
the
constraints
before
you
start
coding.
They
can
include
Hardware
constraints
like
memory,
storage,
space,
CPU
power
and
energy
or
battery
power.
A
They
could
also
include
other
software
constraints
like
knowing
which
JavaScript
engine
you
are
using,
which
JavaScript
features
it
supports
and
which
modules
are
available.
A
key
part
of
embedded
development
is
tailoring
the
implementation
to
deliver
great
results
within
the
constraints.
Fundamentally,
these
are
optimization
problems
of.
B
Course
there
are
many
differences
between
programming
in
JavaScript
for
the
web
and
programming
in
JavaScript
for
embedded
systems.
Let's
look
at
one
seemingly
simple
question:
to
see
how
and
that
question
is
what
happens
when
your
JavaScript
code
runs
out
of
memory?
No
one
really
knows
the
JavaScript
language
specification
has
almost
no
text
about
that.
There
isn't
a
memory,
full
error,
objector
or
anything.
A
Embedded
devices
memory
is
far
from
infinite.
One
of
our
favorite
trips
has
about
45
kilobytes
of
free
memory
prescribes
not
45
megabytes,
not
4,
gigabytes,
45,
kilobytes,
the
JavaScript
engines
and
web
browsers
can't
even
launch
with
45
kilobytes
of
memory
embedded
JavaScript
developers,
ship
products
with
that
memory,
maybe
you're
thinking.
Why
not
just
add
more
memory?
It
isn't
that
expensive.
It
is
that
expensive,
IOT
products
tend
to
be
cost
sensitive
because
their
profit
margins
are
thin
and
their
markets
are
competitive.
That
chip
with
45
kilobytes
of
memory
costs
about
a
dollar.
A
Adding
memory
can
easily
cost
50
cents
or
$1
more
and
make
the
board
bigger,
make
it
use
more
energy
I
had
more
high
frequency
traces
to
its
board,
which
makes
RF
certification
more
difficult
and
more
all
of
that
increases
cost
software
that
delivers
within
the
constraints
saves
people
money.
Finally,
remember
that
IOT
features
are
only
part
of
a
product.
The
product
exists
to
do
something
else,
be
it
a
door
lock,
a
washing
machine
or
a
thermostat
IOT
just
helps
here's
a
sticker
on
an
IOT
dryer
that
we
found
at
Home
Depot
notice.
A
B
Mentioned
JavaScript
engines
that
are
used
on
the
web
won't
run
on
the
hardware
and
IOT
products,
but
fortunately
there
are
JavaScript
engines
dedicated
to
embedded
devices,
and
you
may
have
heard
of
some
of
them.
There's
s
Perino
duct
tape,
gerri
script,
v7
and
several
others,
and
all
of
these
exists,
because
the
detailed
work
to
standardize
JavaScript
has
made
it
practical
to
create
engines
optimized
for
specialized
needs.
A
You
may
not
have
heard
of
the
excess
JavaScript
engine.
That's
models
engine
for
most
of
its
15-year
history.
Excess
has
kept
a
pretty
low
profile,
but
excess
is
the
only
modern
JavaScript
engine
for
embedded
devices.
How
modern
look
at
the
results
from
test
two
six
to
report
the
definitive
test
suite
for
JavaScript
language
conformance,
no
other
engine
targeting
resource-constrained
devices
is
included.
Not
only
is
excess
here
it
has
better
language
conformance
than
the
JavaScript
engines
and
many
browsers.
Why
doesn't
everyone
switch
to
XS
if
it
has
such
amazing
language
support?
A
The
answer
is
in
its
name:
XS
stands
for
extra
small
XS
focuses
on
being
small
small
memory,
size
small
code
size
to
run
on
an
expensive
Hardware.
The
engines
used
on
the
web
platform
are
optimized
for
speed.
Still
X
s
is
more
than
fast
enough
for
consumer
and
industrial
IOT
products.
Let's
take
a
quick
look
at
examples
of
consumer
and
industrial
IOT
products
built
on
X
s.
This
is.
B
A
control
panel
I
have
a
monitor
for
manufacturing
equipment.
Unlike
the
user
interface
of
most
industrial
IOT.
This
one
has
a
color
screen
with
a
familiar
touch
user
interface,
which
makes
it
easier
to
set
up
and
operate
here.
You
can
see
how
it's
configured
with
a
type
in
search
field,
similar
to
a
smartphone
and,
what's
really
surprising,
is
that
this
product
is
completely
controlled
by
a
chip
that
costs
two
dollars
and
thirty
five
cents.
B
This
is
a
sterilization
system
under
development
for
ambulances,
it
uses
half
a
dozen
sensors
to
determine
when
the
inside
of
the
ambulance
needs
to
be
sterilized
and
then,
when
it
detects
that
the
ambulance
is
empty,
it
activates
UV
lights
to
sterilize
the
inside
for
the
next
patient.
The
system
is
entirely
controlled
by
JavaScript,
including
secure
cloud
communication
to
report
the
system
status.
A
These
are
home
laundry
appliances,
the
entire
user
experience
is
coded
in
modern
JavaScript,
using
the
pew
user
interface
framework.
But
that's
not
all
the
logic
to
configure
and
control
cycles
is
to
so
it's
all
the
communication
code
to
talk
with
the
cloud
for
remote
control.
The
performance
is
great
and
the
cost
is
low
which
allows
the
manufacturer
to
include
these
features
in
dozens
of
different
models,
not
just
the
premium
ones.
A
If
you
as
a
web
developer
or
to
sit
down
and
read
the
code
of
these
products,
much
of
it
would
be
familiar
because
you
already
know
the
programming
language.
Some
api's
would
be
familiar
to
web
workers,
for
example,
but
many
would
be
unfamiliar
instead
of
Dom
for
the
user
interface
they
use
pew.
Instead
of
fetch,
they
use
a
custom,
HTTP
client
class.
A
These
classes
are
different
from
the
web,
because
they're
designed
to
work
with
far
fewer
resources
but
they're
also
different
between
different
embedded
JavaScript
engines,
because
those
embedded
JavaScript
engines
evolved
independently
kind
of
like
how
JavaScript
engines
on
the
early
web
evolved
before
ECMO
tc39
began.
The
work
of
standardization
embedded
javascript
would
be
a
lot
easier
with
standard
ap
eyes
so
model
in
beaucoup
worked
with
Ekman
International
to
create
a
new
Technical
Committee
TC
53.
To
try
to
solve
this
problem.
A
B
Tc
53
contributors
have
a
wide
variety
of
interests
and
expertise.
Representatives
like
us
for
multiple
are
interested
in
efficient,
scripting
and
touchscreen
support.
There
is
a
delegate
from
Michigan
State
University
who
focuses
on
data
precision
for
big
data
analysis.
Members
from
agora
are
interested
in
provably,
secure
script,
execution
beaucoup
brings
their
expertise
in
sensors
and
robotics
applications.
Lightin
focuses
on
portable
drivers
for
sensors
displays
and
energy
harvesting,
monotype,
bring
expertise
in
text
handling,
fonts
and
text,
rendering
and
whirlpool
for
embedded
system
requirements
and
focus
on
safe
operation.
B
The
formal
name
of
TC
53
is
Atma
script
modules
for
embedded
systems,
so
the
name
sort
of
explains
the
focus,
its
defining
standard
modules
for
JavaScript.
There's
no
intention
to
extend
JavaScript
or
to
define
a
subset
specifically
for
embedded.
The
modules
that
TC
53
defines
are
intended
for
use
in
embedded
systems
and
IOT
products.
These
api's
are
not
destined
for
the
web
anymore
than
Dom
is
destined
for
a
labeled
TC.
A
53
takes
inspiration
from
the
extensible
web
manifesto.
The
idea
that
standards
should
focus
on
low-level
api's
for
developers
to
build
on
TC
53
is
following
that
idea
by
starting
at
the
lowest
practical
level,
a
JavaScript
hardware,
abstraction
layer.
This
allows
a
device
to
boot
almost
immediately
to
JavaScript
the
dryer
you
just
saw
it
does
that
this
gives
scripts
near
complete
control
of
the
hardware
developers
build
up
from
there
with
modules
and
frameworks
to
create
products
to.
B
B
We're
practical,
TC,
53
API
is
use
familiar
API
styles,
so
notice
that
the
digital
class
API
uses
a
callback.
This
is
a
very
common
way
to
deliver
asynchronous
events
in
JavaScript.
We
recognize
that
many
newer
api's
on
the
web
use
promises.
However,
for
performance
and
simplicity,
TC
53
uses
callbacks.
The
callbacks
can
be
used
to
implement
promise
based
api's
by
libraries.
Building
up
from
the
TC
53
specified
modules
also
notice
that
the
Constructors
are
configured
with
an
options
object.
This
is
familiar
and
extensible.
B
Extensibility
is
important.
The
low-level
TC
53
api's
are
a
hardware
abstraction
layer,
not
a
least
common
denominator
api.
So
where
hardware
is
the
same,
TC
53
wants
it
to
support
the
same
api's,
but
TC
53
also
wants
it
to
be
possible
to
benefit
from
hardware
differences.
Extensibility
provides
scripts
access
to
those
unique
features.
One.
A
Of
the
coolest
features
of
TC
53
s,
work
is
inspired
by
the
Fermata
communication
protocol
used
by
the
chatty
v
robotics
library.
A
typical
embedded
system
consists
of
the
microcontroller
and
several
peripheral
chips.
Some
of
those
external
chips
add
more
I/o
capabilities.
Tc
53
has
an
I/o
class
called
an
expander
to
support
these.
A
common
type
of
expander
provides
additional
digital
pins.
A
script
creates
an
expander
using
an
options,
object
based
constructor,
you
can
access
the
digital
pins
of
the
expander,
exactly
like
the
built
in
pins.
A
In
the
blink
example,
here's
the
blink
example
modified
to
use
the
expander
pins.
All
that
has
changed
is
the
name
of
the
constructor
from
digital
to
expand
or
dot.
Digital
expanders
are
a
powerful
new
concept
for
working
with
hardware
in
JavaScript
and
they
aren't
limited
to
hardware
physically
connected
to
the
microcontroller
we've
built
expanders
that
connect
to
wearables
using
bluetooth
and
to
cloud
services
using
Wi-Fi.
This
makes
controlling
hardware
with
scripts
simple
and
consistent,
no
matter
where,
in
the
world
the
hardware
is
located.
A
Tc
53
is
also
working
on
security,
I
know,
and
everyone
in
IOT
says
that,
but
we're
taking
a
different
approach.
Actually,
at
our
first
meeting
like
everyone,
we
agreed
on
the
importance
of
security,
but
we
had
no
idea
how
to
solve
it.
So
we
set
it.
Aside
later
we
learned
about
secure
Atmos,
crypt
sess,
a
proposal
to
add
secure
execution
to
javascript
sess
is
based
on
work
by
Mark
Miller
of
a
goreck
to
bring
the
proven
object.
A
Capabilities
security
model
to
JavaScript
cess
is
great
because
it
allows
trusted
and
untrusted
scripts
to
coexist
even
communicate
directly
while
guaranteeing
security
boundaries
are
enforced.
It
does
this
using
lightweight
sand
boxes
called
compartments
which
allow
code
from
different
authors
to
be
safely
combined
in
a
single
system.
A
We
know
this
because
we
already
implemented
cess
in
excess.
Last
year
we
showed
cess
running
on
an
$18
IOT
light
bulb.
Tc
53
has
decided
to
adopt
cess
as
its
execution
security
model.
We
are
working
with
the
gorrik
to
advance
this
work
in
tc39
and
hope
it
will
one
day
be
part
of
the
javascript
standard.
B
All
of
this
is
just
some
of
the
work
that
TC
53
is
doing
to
standardize
embedded
javascript,
but
you
don't
have
to
wait
for
the
standards
work
to
be
finished,
to
get
started,
learning
and
developing
some
adventurous
web
developers
are
already
starting
to
explore.
Embedded
javascript,
some
like
Shinya
Ishikawa
son,
are
simultaneously
learning
and
teaching
others.
B
Others,
like
William
Hilton
with
his
isomorphic
git
project,
are
pushing
at
the
boundaries
of
what's
possible
on
embedded
systems
and
developing
models
for
sharing
code
between
web
and
embedded
projects
out
there
building
the
IOT
products
they
wish
already
existed
when
the
Cova
19
culture
in
place
began.
Mike
Edmund,
a
web
developer
working
from
home
had
a
difficult
time
balancing
work
meetings
with
family
communication,
so
he
used
his
JavaScript
skills
to
create
a
solution.
B
B
This
is
the
kind
of
useful
project
that
large
manufacturers
aren't
creating,
but
to
help
real
people
solve
real
problems,
Mike
published
his
code,
so
anyone
can
replicate
his
setup,
improve
it
and
adapt
it
to
their
needs.
That's
the
kind
of
people
centric
project
that
is
possible
when
web
developers
bring
their
skills
to
IOT.
A
If
you
want
to
learn
more
about
TC
53
we're
having
our
next
meeting
this
Thursday
and
Friday
you're
welcome
to
sit
in
our
first
day
agenda
is
an
introduction
to
TC
53,
so
you'll
hear
from
various
contributors
about
our
roadmap.
Please
join
us
we'd
love
to
see
more
JavaScript
developers
getting
excited
about
this
and
getting
involved.
If.
B
B
We
also
just
finished
writing
a
book
called
IOT
development
for
ESP,
32
and
esp8266
with
JavaScript.
If
you
want
a
hands-on
guide
to
building
IOT
products
that
can
buy
networking,
sensors,
actuators,
sound
graphical
user
interfaces
and
more,
this
will
be
a
great
resource
for
you.
It's
expected
to
be
published
later
this
summer,
but
you
can
pre-order
it
now.