►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Wasm Components: The Interchangeable Parts of Software - Taylor Thomas, Cosmonic
In the past year, the standards around Wasm and WASI have started to solidify and become reality. One of the most interesting emerging standards has been the Component Model. Similar to how interchangeable parts dramatically changed manufacturing, Wasm components have the potential to change we build software. However, there is still confusion among those following the growth of Wasm about how the Component Model works and what it can do. Using practical examples, code drawn from recent work on wasmCloud, and the Component Model as a backdrop, this session will explore what the Component Model is, how it works, and how it will change how software is consumed.
A
Hey
there,
everyone
so
hopefully
everyone's
gotten,
some
sugar
and
other
things
in
them
and
get
them
up
through
that
post
lunch
coma
and
hopefully
my
talk,
does
not
put
you
in
more
of
a
coma.
So
first
off
the
title
of
this
is
wasm
components:
the
interchangeable
parts
of
software.
So
brief,
introduction
to
myself
I
like
to
give
this.
This
is
the
thing
of
like
why
you
should
listen
to
me.
A
First
off
I'm,
a
director
of
customer
engineering
at
cosmonic,
you've
seen
a
lot
of
us
today.
I
am
a
restation
by
way
of
go
being
a
gopher
beforehand.
I
did
a
lot
of
go
and
then
a
lot
of
rest,
I'm
a
I'm
one
of
the
co-creators
of
crestlet
and
bindle.
So
if
you're
here
in
this
room,
you've,
probably
at
least
heard
a
cresslet,
it
was
the
first
attempt
to
really
try
to
do
something
with
webassembly
and
a
known
technology
and
then
bindle's
a
thing
that
we
can
talk
more
about
on
the
side.
A
I
am
an
open
source.
Maintainer
I
used
to
be
a
core
maintainer
of
Helm
I,
actually
wrote
a
large
chunk
of
Helm
3,
along
with
some
of
the
people
here
who
are
now
at
fermion
and
then
a
couple
others
who
I
worked
with
like
some
of
the
folks
from
VMware
who
used
to
be
at
bonami,
so
I've
done
a
lot
of
that.
A
I've
done
kubernetes
thing
since
kubernetes
1.2
lots
of
stuff
with
Docker
for
a
very
long
time,
so
I
built
kubernetes
platforms
at
various
companies
and
now
I'm
doing
a
lot
of
things
with
webassembly.
So
that's
a
little
bit
about
me.
That's
the
background
that
kind
of
goes
into
the
Talk
itself.
So
here's
what
we're
gonna
do
we're
gonna
go
through
a
brief
history
lesson.
First
and
after
we
talk
about
a
brief
history
lesson,
we're
going
to
talk
a
little
bit
about
was
on
cloud
and
components.
Some
of
this
you
heard
from
Brooks
today.
A
So,
let's
start
off
with
a
brief
history
of
the
20th
century,
I
tried
to
make
that
as
a
college
class
sounding
as
possible,
just
so
I'm
not
actually
going
to
make
it
boring.
So,
at
the
very
beginning
of
the
20th
century,
in
the
United
States,
there
was
two
important
manufacturing
Concepts
that
merged
together,
and
that
was
the
assembly
line
hint
hint
and
the
the
idea
of
interchangeable
parts.
Now
this
is
the
definition
of
interchangeable
parts
directly
from
Wikipedia.
I
did
not
doctor
this
to
include
these
words
like
components
and
assembly.
A
A
Could
take
any
one
of
these
parts
and
reassemble
them
and
in
the
picture
on
the
right,
you
see
an
old
like
assembly
line
from
the
early
1900s
in
the
United
States,
and
there
were
buckets
of
screws
and
bolts
and
things
that
were
all
the
exact
same
size
and
you
could
just
go
down,
grab
it
and
put
it
in
and
so
because
each
part
is
produced
to
those
exact
specifications.
This
is
what
this
whole
like
these
two
things,
combining
is
what
kicked
off
what
people
called
the
Industrial
Revolution.
A
Now
this
whole
lesson
of
what
happened
actually
has
surprising
applications
to
software
development
as
well,
and
so
we're
going
to
continue
with
just
a
little
bit
of
History
lesson
with
about
like
where
was
him
is
wasm
cloud
and
the
different
components
that
came
through.
So,
if
you
think
about
it
at
this
point
enough,
software
is
created
probably
on
a
daily
basis,
that
it
is
essentially
like
an
assembly
line.
A
All
of
this
code,
reuses
various
pieces
of
someone
else's
code
and
honestly,
the
best
we've
been
able
to
do
are
apis
and
apis
are
nowhere
near
interchangeable
parts
components
have
a
little
bit
different
work,
but
when
I
say
apis,
I
mean
everything
graphql,
rest,
soap,
grpc
doesn't
matter,
that's
that's
the
way,
we've
that's
a
communication
protocol,
that's
not
an
actual
interchangeable
part,
and
so,
where
we've
this
is
a
history
of
the
modern
Computing
environment.
You
saw
this
slide
earlier
with
what
Brook
said,
but
I
want
to
expand
just
a
little
bit
more
on
it.
A
We
started
right
from
like
the
old,
like
blades
in
a
data
center
I
mean
there's.
Some
of
us
I
have
done
this
too,
where
you
know
like
if
you
haven't,
if
you
haven't,
pulled
a
spinning
disc
out
of
a
running
server
and
had
it
wrench
the
arm
out
of
your
like
your
arm
out
of
its
socket
I,
don't
know
if
you've
lived
life
as
a
programmer,
but
anyway,
so
these
are.
A
These
are
the
kinds
of
things
that,
like
we
started
with,
and
we've
gone
through
this
idea
of
a
VM
which
abstracted
a
little
further
in
a
container
which
built
on
top
of
that
and
then
webassembly
itself,
and
so
along
this
path,
we've
gone
really
far
along
the
path
to
reusability,
but
we
haven't
gotten
all
the
way
there
and
as
Brooks
had
mentioned
earlier.
Wasmcloud
is
the
is
a
system
that
allows
us
to
abstract
a
little
bit
further
and
Abstract
out
these
non-functional
requirements.
A
So
I'm
going
to
talk
a
little
bit
about
that
once
again,
you'll
see
these
slides
are
similar
because
Brooks
and
I
wrote
them
together.
That's
why
he
had
these
same
ones,
but
I'm
going
to
go
into
different
details.
We've
all
talked
about
webassembly
to
death,
we're
all
here,
because
we
know
about
it.
We
know
what
it
does.
A
These
are
the
main
things
that
we
want
to
do
with
it:
portable,
secure,
small,
fast
language,
agnostic,
all
those
different
things
now
the
thing
is
this:
wasm
is
almost
nothing
without
an
application
runtime
on
top
of
it,
because
at
its
very
base
level,
I'm
talking
the
base
level
I'm,
not
talking
about
all
this
other
cool
stuff.
That's
going
on.
It's
numbers
in
numbers
out:
there's
not
there's
not
a
lot
more
than
that
you
you're
you're,
that's
how
you're
restricted
to
use
a
webassembly
module
and
in
our
in
our
case
wasn't
cloud
is
an
application.
A
Runtime
we've
created
it's
a
cncf
project,
so
this
is
entirely
open
source
and
I'm,
focusing
purely
on
the
open
source.
Here,
not
cosmonic
cosmotic
is
powered
by
Watson
Cloud,
but
this
is
all
the
wasm
cloud
side
of
things
and
it's
it's
focused
on
removing
that
boilerplate
code
that
boilerplate
code
that
I
talked
about
that
and
the
non-functional
requirements
we
don't
care
about,
and
all
this
comes
with
this
idea
of
horizontally
and
vertically
scalable.
A
A
This
is
the
part
that
actually
makes
it
distributed.
When
you
combine
all
this
together,
you
get
the
distributed
capabilities
on
top
now
I'm
going
to
talk
about
the
differences
between
those
in
just
a
second,
but
first
I
want
to
review
what
are
components
like
like
I
said:
Luke
already
talked
about
this
in
depth,
but
for
our
discussion
here.
These
are
just
a
few
points
to
keep
in
mind.
First
off
components
are
these
interchangeable
parts
I've
been
referring
to?
A
They
allow
us
to
glue
different
things
together
in
the
way
we
want
them
to
wasn't
cloud
has
capabilities
which
are
these
distributed
components,
but
we'll
still
see
that
there's
underlying
dependencies
that
can
get
compiled
in
so
with
that,
let's
talk
about
the
status
quo.
Where
do
things
stand
with
wasm
Cloud
right
now
from
this
part
of
the
talk
on
I'm
going
into
deep
technical
detail?
A
But
you
don't
have
to
understand
a
lot
about
webassembly
to
to
understand
the
concepts
I'm
going
to
talk
about,
but
this
is
going
to
be
very
practical
about
what
we're
doing
so.
First
off
just
the
super
high
level
of
how
this
works.
This
is
the
current
diagram
of
how
things
work
inside
of
wasm
cloud.
Anything!
That's
in
blue
is
user
managed
code,
so
it's
code
that
the
user
is
compiling
or
doing
something
with
I
mentioned.
We
have
this
lattice.
A
The
lattice
is
what
delivers
messages
to
and
takes
messages
that
are
going
out
from
an
actor
and
sends
them
back
out
to
whatever
else
it
needs
to
be
sent
to,
and
all
that
runs
inside
of
a
wasm
cloud
host,
but
you'll
notice
that
there
is
this
wasimbus
RPC
Library,
that's
in
there
this!
This
library
is
a
custom
Library.
We
have
to
have
that
allows
us
to
transmit
this
data
properly.
A
If
you
think
the
basic
example
I
used
to
explain
this
to
anyone
who
asks
is
think
about
the
log
4J
thing
that
happened:
okay,
because
first
off
it's
not
about
the
bug,
we've
all
written
stupid,
bugs
I
mean,
let's
be
honest,
with
ourselves:
we've
taken
down
production
once
or
twice
or
10
times,
and
so
the
the
whole
idea
behind
that
was
now.
Oh,
we
had
containers
we're
all
secure.
A
Well,
okay,
now
we
have
this
core
dependency
that
a
bajillion
things
use,
and
now
we
have
to
go
update
and
recompile
all
the
code
and
then
recompile
all
the
containers
and
then
redeploy
all
the
containers.
That
is
not
what
we
want
to
do
and
we've
managed
to
abstract
out
a
lot
of
that.
With
these
capabilities,
we've
talked
about
the
ability
to
say:
oh
I
want
a
key
value
store.
A
So
let
me
let
me
just
code
against
a
key
Value
Store
contract
and
then
I'll
choose
how
I
connect
it
later,
but
they're
still
underlying
code
that
gets
coupled
in
and
that's
something
we
don't
really
like
to
have,
and
so
what
this
ends
up
being
this
right
here
do
not
worry
about
the
whole
everything
that's
in
this
code
block
you
don't
have
to
do
it.
Everything
here
is
going
to
be
rust.
Today,
you
don't
have
to
understand
a
lot
about
rust
to
understand.
What's
going
on
here,
but
you'll
note
at
the
very
top
these
dependencies.
A
Okay,
there's
a
couple
of
them.
We
have
this
wasimbus
RPC
and
then
we
have
the
two
different
interfaces.
We
have
the
interface
HTTP
server,
that's
in
there
and
we
have
the
interface
key
value,
and
so
it's
still
really
simple.
This
is
a
simple
actor
that
does
it
receives
an
HTTP
request.
It
takes
that
path
and
uses
it
as
a
key
and
then
increments.
How
many
times
that
path
has
been
hit.
A
A
A
Keep
this
diagram
in
mind
as
we
jump
into
it,
because
we're
going
to
go
into
every
like
little
detail
on
this
thing
about
what's
going
on
now
on,
the
left
is
what
I
showed
you
before:
that's
where
we're
currently
at
and
what
we
are
currently
working
on,
as
in
like
right
now
is:
what's
on
the
right
with
webassembly
modules,
we
can
start
splitting
everything
up,
so
only
the
user
managed
code.
The
actual
business
logic
is
all
they
have
to
write,
there's
no
other
external
dependencies.
They
have
to
pull
in.
A
This
is
everything
like
all
to
be
clear,
too,
to
show
kind
of
the
benefit
of
what
wasmcloud
does
for
you
all
of
this
other
code
around
it
all.
The
other
things
that
are
not
blue
are
things
that
wasn't
Cloud
does
for
you
you.
This
is
code.
You
do
not
have
to
write
as
a
user,
we're
just
showing
you
everything
in
here,
so
you
know
what
we're
doing
so.
A
I'm
going
to
jump
into
some
very
specific
examples,
starting
at
the
top
of
this
HTTP
server,
and
once
again
this
is
going
to
be
a
practical
example
of
how
we're
implementing
components.
You've,
probably
heard
a
lot
of
stuff
about
components
being
like
Oh.
Well,
components
are
only
theoretical,
don't
you
no
they're
new
they're,
not
theoretical,
and
so
I'm
trying
to
show
you
here,
how
we're
doing
it
and
let's
go
into
it
so
first
off,
to
wit,
I've,
been
waiting
all
day
to
use
that
stupid
pun.
A
So,
let's
talk
about.
Let's
talk
about
wit
files,
so
with
files
I,
don't
even
know
if
they
technically
stand
for
anything
anymore.
Historically,
it
comes
from
the
wasm
interface
types
proposal,
and
so
that's,
where
wit
comes
from,
but
these
whip
files
are
how
you
define
what
you
want.
Your
thing,
your
contractor
interface
to
look
like,
and
these
are
API
definition.
They
look
like
API
definitions,
but
they
are
not
API
definitions,
they're
a
bit
different
in
practice
when
you
actually
use
them.
A
So
this
right
here
for
wasm
cloud
is
a
very
specific
entry
point
into
any
actor.
There
is
a
receive
method
that
has
to
be
called
in
from
an
inbound
message
from
that
lattice
that
I've
talked
about,
and
we've
alighted
some
things
like
there's
some
common
types,
we're
importing,
and
then
we
just
have
the
single
receive.
That
is
a
message
that
gets
passed
in
and
returns
back
out
a
raw
payload
that
can
then
be
parsed
by
the
underlying
system.
A
So
this
wit
file
right
here
is
our
HTTP
server
one
now
a
lot
of
these.
This
is
how
we
Define
it
for
now
and
as
we
continue
as
we
all
continue
to
use
components.
This
is
where
we
start
to
standardize
on
similar
interfaces
that
become
shared
across
everybody
and
I'll
get
to
to
a
little
bit
more
about
that
later.
Right
now,
this
is
what
our
HTTP
server
looks
like
and
and
you'll
see.
A
We
have
the
request,
the
response
and
then
some
other
little
types
that
help
things
out
and
then
at
the
very
bottom
you'll
see.
The
only
method
that
we
have
for
this
contract
is
handle
request.
It
has
to
be
something
that
receives
an
HTTP
request
and
returns
a
response,
so
this
slide.
This
is
what
it's
all
looking
like
in
code
at
the
very
top.
This
is
the
line
from
that
original
piece
of
code.
I
sent
you
so
all
of
this
that
I'm,
showing
underneath
replaces
this
whole
dependency
all
of
its
sub
dependencies.
A
Everything
else
underneath
it.
It
replaces
that
line
of
code
inside
the
original
block.
Now
on
the
left.
Once
again,
you
do
not
have
to
understand
all
the
code
here.
I
left
enough
for
context
for
those
who
really
want
to
dig
into
this
later,
but
what
it?
What
you
can
see
happening
is
we're
just
we're
receiving
this
message:
we're
matching
to
make
sure
it's
a
proper
type.
So
this
is
wasn't
Cloud,
specific
codec
matching
and
comes
in
and
says:
okay
I'm,
going
to
pass
this
off
to
a
handle
request.
A
Http
server
handle
request,
so
this
magic
HTTP
server
and
the
Implement
was,
and
bus
receiver
at
the
top
is
coming
from
something
called
cargo
component
that
I'll
mention-
and
this
is
just
inside-
of
our
cargo.tomel
file.
Only
reason
I
put
this
is
in
this
new
world
you're
going
to
have
to
have
something
that
tells
you
where
your
interface
is
at
and
in
this
case
we're
saying
we
are
importing
an
interface
called
HTTP
server
that
we're
going
to
call
and
we're
exporting
something
called
wasimbus
receiver.
A
And
so
that's
why
this
implements
the
function
that
we
expected
right.
This
receive
function
receives
a
message
and
it
is
calling
something
in
Imports,
which
is
the
HTTP
server,
so
this
code
will
receive
the
message,
turn
it
into
something
the
HTTP
server
knows
and
then
call
an
HTTP
server.
It
doesn't
know
which
HTTP
server
it's
calling
right
now.
It
just
knows
that
something
on
the
other
end
is
going
to
implement
that
contract.
A
So
we've
talked
about
this
high
level,
HTTP
server,
one
now
I'm
going
to
turn
this
like
into
a
sandwich.
The
user
managed
code
is
in
the
middle
of
the
sandwich,
we're
going
to
go
to
the
other
slice
of
bread
and
talk
about
the
key
value
in
the
sender,
because
they're
very
they're
they're
closely
related.
A
So
first
off
we
have
the
wit
files
again
now.
This
is
a
very
dumbed
down
version
of
our
key
value
interface
that
we're
still
iterating
on
that.
Just
has
the
increment
function
in
real
life.
This
will
probably
have
the
get
set,
delete
types
of
things,
you'd
expect
from
a
key
value
function,
but
for
now
we
just
for
for
proving
this
out.
We
wanted
to
get
it
to
this
increment
function.
So
same
thing:
single
increment
function.
A
A
That
package
and
all
of
the
dependencies
that
that
package
pulls
in
so
we've
now
removed
that
entirely
with
this,
with
this
method,
so
you'll
see
that
it
implements
the
key
value
thing
that
we've
we
defined
before
in
the
wit
file,
and
it's
calling
a
wasenbus
send.
So
basically,
this
takes
all
the
the
incoming
thing
and
says
how
do
I
turn
this
into
Ascend
Ascend
method
and
I
I?
Send
it
across
the
wire
now
on.
The
right
is
the
sender
code
now
for
our
example,
we're
just
giving
it
a
handle
to
standard
out
in
real
life.
A
This
will
be
connected
to
the
wasm
cloud
host,
which
will
expose
a
function
to
it,
and
it
can
call
that
function,
but
right
now,
just
for
for
Simplicity.
That's
how
we've
done
it.
So
this
goes
all
the
way
down.
It
gets
this
this
raw
message.
It
doesn't
matter
what
the
message
came
from
handles
the
message
by
sending
it
out
to
the
host
and
then
receives
and
returns
data
back
now.
Once
again,
this
sender
is
used
everywhere.
A
A
And
again
all
of
these
different
components
could
be
written
in
different
languages.
We
could
write
this
in
C.
We
could
write
the
key
value
thing
in
Python.
The
top
thing
could
be
written
in
Rust
and
it
doesn't
matter
all
of
this
code
can
then
just
be
smashed
together
as
a
component,
because
it's
all
compiled
down
to
webassembly.
You
start
to
see
some
of
the
all.
A
But
for
us
this
sender
thing
replaces
a
whole
bunch
of
like
data
copying
and
serializations
that
we
have
to
do
to
get
things
into
the
right
format,
whereas
in
with
a
component
we're
able
to
just
talk
directly
to
the
host,
we're
able
to
use
typed
functions
and
things
that
can
come
down
into
a
host
for
us.
So
this
is
this
is
a
pretty
big
deal,
but
what
does
this
all
enable
for
us?
So
we
started
off
with
this
idea
of
the
HTTP
server.
We
moved
to
the
key
value.
A
A
This
is
the
new
key
value
counter
that
we
had
that
comes
out
of
this
you'll
notice,
that
this
looks
almost
identical
to
the
one
you
you
had
before
at
the
very
beginning,
but
now
there
is
zero
wasm
Cloud
specific
code
in
here
Luke
mentioned
something
called
virtual
platform
layering
it
might
have
just
it
might
have
just
gone
over
people
in
between
all
the
awesome
details
going
on
there.
But
this
is
an
example
of
virtual
platform
layering.
A
If
we
collaborate
on
these
common
contracts
because
most
key
value
things,
everyone
is
using
the
same
set
of
get
set
and
delete,
sure
there's
some
extended
things.
People
could
do
and
people
are
allowed
to
do
that
and
wasn't
Cloud.
You
can
create
your
own
contracts
and
you
can
create
your
own
providers
and
implementations,
but
most
people
are
going
to
use
that
same
set
of
functionality
and
if
we
have
those
standard
things,
there's
nothing
stopping
someone
from
taking
an
actor
they've
written
for
wasmcloud
and
running
it
in
another
system,
because
it
uses
those
same
Imports.
A
And
so
another
thing,
that's
important
to
point
out
here
is
I'm
writing
normal
rust
code.
There's!
No!
Yes,
there's
some
magic
happening
here.
There's
going
to
be
like
the
wit
bind
gen
stuff
in
Rust
is
really
good
and
some
other
languages
like
I,
even
showed
it's
not
as
good
with
the
whole
wit
thing,
but
it
doesn't
matter
this
generation
might
will
happen
and
I
know
people
get
a
little
scared
of
the
code
generators,
but
this
isn't
like
the
kubernetes
code
generators
where
you're
committing
this
code.
A
This
is
something
that
can
be
generated
on
the
Fly
compiled
in
and
run
and
you're
just
writing
normal
code
for
your
language
and
to
to
beat
the
dead
horse
again
in
wasm
Cloud.
This
is
the
only
code
you
have
to
write.
You
get
all
of
this
distributed
goodness
I've
been
talking
about
the
whole,
putting
together
these
different
things
across
a
huge
distributive
platform.
Just
by
writing
this
code
and
there's
no
mention
of
anything
about
scaling,
nothing
about
what
you're
connecting
to
none
of
those
details,
and
you
can
you
can
see
in
the
code.
A
It's
just
really
simple.
It
says:
hi
I'm,
implementing
the
HTTP
server
contract,
pretend
I'm
an
HTTP
server.
Give
me
an
HTTP
request.
Please
that's
that
first
handle
request
function,
but
then,
when
you
go
down
the
line,
you
see
this
thing
that
says
oh
key
value,
increment
towards
the
very
bottom
of
that,
what
key
value
nobody
knows,
nor
do
they
care
and
nor
do
most
developer
developers
care
when
they're
writing
their
code.
So
we've
been
able
to
do
this
with
components,
and
what
this
allows
us
to
do
in
the
future
is
think
about.
A
A
Watson
modules
that
are
glued
together
turned
into
a
final
compiled
like
webassembly
module
for
for
sake
of
discussion
here,
and
it
runs
on
a
Watson,
Cloud
host,
but
then
you're
able
to
then
compose
what
it's
connecting
to
just
like
you
did
with
edit
runtime
to
whatever
thing
you
want
to
connect
it
to
so
we
basically
have
components
that
make
up
an
actor
and
then
multiple
actors
that
can
talk
to
different
providers
and
compose
them.
The
way
that
you
want
them
to
and
scale
the
way
you
want
to
have
them
scaled.
A
So,
just
a
few
things
about
the
challenges
that
we
faced
in
the
future,
we're
going
for
to
finish
up
everything
here.
So
first
off
this
diagram,
so
I
threw
this
together.
This
was
a
ragey
diagram
and
on
purpose
gluing.
This
all
together
is
a
bit
difficult.
Now,
I'm
going
to
be
honest,
Bailey
I'm,
going
to
do
a
shout
out
to
Bailey
Bailey
did
a
lot
of
this
code
too,
to
help
out
here,
and
so
she
discovered
a
lot
of
these
things
and
boy.
Was
it
a
little
bit
messy?
A
It's
a
bit
difficult!
So
right
now
this
is
requiring
three
separate
tools:
the
Blue
Line
you
see
on
here
anything
below
it
is
what
we
do
on
awazen
cloud
host,
but
on
the
top
we
have
to
have
this
thing.
We
have
to
have
cargo
component
that
uses
stuff
with
the
wit
files,
and
then
we
have
to
use
whip,
buying,
gen
and
wit
component
to
actually
glue
the
things
together.
It
outputs
a
wasm
file,
but
that
wasm
file
is
still
labeled
as
wasn't
32,
unknown
unknown,
because
there's
no
official
Watson
32
component
thing.
A
Yet
so
it's
it's
a
component,
but
it
doesn't
say
it
is
when
you
look
at
anyway,
it
gets
a
little
complicated
there
and
you
think
you've
made
a
mistake,
but
you
haven't
and
then
at
runtime
we
have
to
pull
down
all
the
web
assembly
modules
and
put
them
together
with
wasm
tools
compose
to
get
a
final
thing.
That's
how
we
do
it
right
now,
as
in
like
literally
right
now,
what
we're
trying
to
make
it
do
to
work.
Ideally
in
the
future.
A
This
will
continue
to
improve
for
us
personally,
we've
started
to
abstract
this
away
for
for
our
users
behind
washbuild,
so
this
is
not
there
yet,
but
we're
going
to
be
adding
that
all
behind
there.
So
as
these
standards
continue
to
improve
and
be
just
be
better
overall
and
more
solidified,
we'll
start
rolling
into
like
just
the
full
tooling,
but
it's
still
hidden
behind
for
for
our
users
behind
a
wash
build
command
and
then
obviously
the
stuff
underneath
we're
hiding
just
by
virtue
of
being
a
host,
that's
running
it.
A
So
that
was
the
first
challenge
that
I
have
listed
here.
The
second
one
is,
you
have
to
use
a
runtime
that
supports
the
component
model,
which
is
wasn't
time
and
nothing
else
so
that
we
all
love
Watson
time.
I
mean
that's
not
a
slight
against
was
entire
science.
It's
so
new
that
only
Watson
time
supports
it.
So
you
have
to
use
some
time
if
you're
going
to
use
components
right
now,
things
are
still
on
the
assembly
line.
A
Sorry
bad
dad
joke,
but
the
thing
is:
is
we
we're
on
the
bleeding
edge
here
people,
so
things
are
going
to
bleed
and
that's
part
of
the
issue
of
doing
things
with
components
right
now
is.
It
is
very,
very
it's
hemorrhaging
Edge,
so
just
make
sure
that
if
you
go
down
this
route,
you
know
that's
what
you're
going
to
get
into.
A
Also
this
talk
is
one
of
the
few
real
world
examples
out.
There
there's
been
some
talks
about
it
today,
but
like
there,
there
isn't
a
lot
out
there,
there's
probably
three
to
four
examples
of
doing
this
for
realsies,
not
like.
Oh
look
at
this
pretty
diagram,
which
are
great.
This
is
one
of
the
few
real
things
that
are
out
there.
That
was
why
we
wanted
to
to
give
this
talk.
It's
because
we
wanted
to
show
a
real
example
for
people
who
start
following
along
with,
even
though
it's
far
far
far
from
perfect.
A
So
those
are
those
are
challenges.
Just
keep
that
in
mind.
I
always
like
talking
about
those
first,
we
can
talk
about
the
positives
here
and
where
we're
going.
The
first
thing
is
that
we're
we're
going
to
be
implementing
this
as
soon
as
possible
for
wazen
cloud
like
so,
we
don't
want
to
have
to
make
people
include
their
own
Library,
like
our
own
library,
for
them
to
be
able
to
write
something.
A
We
we
we're
gonna
until
this
point
until
the
point
that
we've
actually
fully
implemented.
This
will
keep
our
our
custom
libraries
as
easy
to
use
as
possible,
but
this
is
something
that,
within
the
next
few
months,
we're
really
trying
to
get
some
first
drafts
out
with,
like
I,
said
this
code
actually
runs.
It
wasn't
worth
showing
the
demo,
because
all
it
does
is
print
line
some
stuff,
but
we're.
Actually.
A
This
is
a
real
thing
that
exists
once
we
get
this
stuff
out
with
wasm
Cloud
we're
going
to
use
that
to
give
any
feedback
back
into
the
actual
spec
for
components
and
how
they
how
they
work
and
then
we're
going
to
also
contribute
to
it.
We
want
to
help
push
it
across
the
Finish
Line.
Just
like
everybody
else
in
here
we
unlock
components.
We
unlock
and
solve
a
lot
of
problems
for
pretty
much
everybody
here
who
wants
to
use
webassembly
and
then
we're
going
to
work
on
things
like
having
a
wasm
cloud
world.
A
Now
that
isn't
a
theme
park
as
much
as
we'd
love
to
have
that
it
is
the
world
files
that
were
being
mentioned
earlier.
We
want
to
be
able
to
like
work
within
the
world
file
things
and
contribute
to
that
whole
idea
of
having
requirements
and
virtual
platform
layering
that
goes
along.
So
here's
some
references.
This
is
the
same
QR
code
that
Brooks
had
earlier.
So,
if
you
already
scanned
it
don't
need
to
scan
it
again.
It
leads
to
our
slack.
A
We
have
some
what
a
link
to
Watson
clouds,
some
more
things
about
what
our
capability
providers
are
and
what
our
interfaces
currently
look
like.
They're
all
there
also
just
as
a
heads
up.
We
have,
if
you're
interested
in
learning
how
to
do
this.
We
have
a
webassembly
crash
course
on
Tuesday
that
Bailey's
putting
on
with
me
and
a
couple
others
from
cosmonic
and
tonight
after
the
basically
the
happy
hour
at
the
Detroit
Marriott.
A
There's
details
online
with
that
QR
code.
There's
we're
getting
together
with
our
friends
at
fermion
to
do
a
meet
up
and
it's
meant
to
be
a
place
where
you
can
just
try
out
the
things
that
we're
doing
and
that
fermion's
doing
and
just
to
have
people
who
know
webassembly
all
together
in
the
same
room.
So
you
can
talk
about
whatever
you're
hacking
on,
so
that's
all
I
have
and
I
just
want
to
leave
it
open
for
any
other
questions.
C
A
A
Yeah,
so
the
question
for
those
who
are
online
or
couldn't
hear
it
is
he
asked
well,
it's
doable,
but
will
it
be
adopted?
And
my
answer
to
that
is
yes,
if
we
put
in
the
effort,
that's
why
this
talk
is
here,
because
you
know
if,
if
nobody
puts
an
effort
from
this
point,
those
of
us
who
are
trying
to
use
the
component
model,
then
it
won't
go
anywhere
like
any
other
specification
or
technology
we've
ever
used.
We
could
have
said
the
same
thing
about
Docker
when
it
first
started.
A
This
is
going
to
be
great
for
many
people
here
and
their
businesses.
But
for
me
as
a
developer,
I
don't
want
to
have
to
care
about
every
single
little
piece
and
whether
it
compiles
on
my
machine
and
which
Library
I'm,
sick
of
it
and
I
think
every
developer
is,
and
so
there
is
a
personal,
more
emotion,
more
emotional
motive
behind
how
this
is
how
this
is
coming
about,
because
we
are
tired
of
it.
A
We've
continued
to
make
our
lives
better
in
some
ways,
while
still
just
like
Reinventing
and
papering
over
the
same
problems,
and
here
I
see
something
where
we
can
get
a
lot
closer.
It's
still
going
to
have
its
edges,
it's
still
going
to
have
its
problems,
but
I
think
we
can
get
a
lot
closer
than
we
did
before.
C
I'm
sorry
I'm
going
to
take
issue
with
that.
We've
been
hearing
this
rhetoric
since
well
1995
at
least
the
object
oriented.
Oh,
it's
Lego
we'll
be
able
to
plug
in
components,
and
it's
never
really
clicked
and
I.
Don't
know.
What's
different
this
time
you
gave
the
example.
You
know
you
talk
about
interchangeable
parts.
You
gave
the
example
of
slotting
in
a
a
bug,
fix
sort
of
underneath
someone's
application.
C
A
And
that's:
what's
different,
that's
a
really
good
question!
Ivan,
so
I
know
Ivan
that
wasn't
a
plant
question.
So
one
of
the
things
here
is
you
can
actually
find
a
really
good
lesson
in
history.
So
in
the
precursor
to
this
whole
idea
of
interchangeable
parts,
people
had
tried
doing
this.
For
years
they
had
come
up
with
custom
ways
to
groove
things
and
a
couple
other
things
that
could
be
reused
and
a
lot
of
it.
A
lot
of
the
start
was
in
wood.
A
The
thing
that
I
think
is
very
different.
Now
is
that
we
have
learned
a
lot
since
those
days
if
you
know
like
J2,
EE
and
all
all
that
kind
of
stuff
that
we've
we've
talked
about
before
I.
Think
we've
we've
learned
a
lot
from
like
what
we
did
with
containers
and
then
what
we
did
with
kubernetes
and
we've
taken
those
things,
and
we
said
okay.
Well,
what
can
we
do
to
make
this
a
little
bit
more
wide
open?
And
you
can?
You
can
see
those
it's?
A
The
thing
is,
then
we
get
into
nuance
and
if
you're
new
to
webassembly
the
Nuance
might
not
be
there.
But
if
you
look
and
start
to
compare
between
like
what
the
specifications
look
like
and
what
you're
able
to
do
with
those
specifications,
you'll
see
that
they
are
still
wide
open
and
allow
for
that.
Hey
I
have
this
very
slightly
different
thing
and
it
accounts
for
that
in
someone.
A
So
yes,
part
of
this
is
that
we're
not
going
to
know
until
we
know,
but
I
do
think
that
there
is
an
evolution
that
has
occurred
between
what
we've
tried
in
the
past
and
now
and
the
lessons
we've
learned
from
doing
things
like
Docker
and
putting
together
multiple
Docker
containers
in
something
and
all
those
those
kind
of
details
have
have
really
helped
inform
this
and
you'll
see
that
it's
at
a
different
layer.
It's
not
based
on
a
single
programming
language
or
a
single
underlying
runtime
with
wasm.
A
You
have
the
goal
of
all
languages
eventually
and
even
now,
a
good
set
of
languages,
and
then
you
have
multiple
run
times
underneath
you'll
notice
that
there's
no
like
we
talk
about
wasm
time,
but
there
isn't
like
a
oh,
is
wasn't
time,
gonna
be
the
winner,
because
that
doesn't
happen
with
webassembly.
You
have
purpose-built
runtimes
for
what
you
need.
You
have
wasn't
time.
You
have
wasmer,
you
have
wasm3
whammer,
Wasim,
Edge
I
can
keep
going
and
all
of
those
things
are
used
for
different
purposes,
but
they
Implement
against
the
same
spec.