►
From YouTube: CNCF Serverless WG Meeting - 2019-05-09
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A
I'm
just
get
the
other
Doug.
Well,
it's
gonna
take
a
while
I'll
circle
back
around
all
right.
Why
don't
gonna
get
started
a
short
attendee
list
today,
let's
see
community
time
all
right,
any
community
related
topics
who
want
to
bring
up
things
that
are
not
on
the
agenda
of
mainly
from
newcomers
all
right,
nothing,
that's
good!
All
right
SDK!
We
did
not
have
an
SDK
meeting
today,
cuz
we
had
no
topics
or
nothing
new
there.
C
A
A
A
We
do
a
phone
call
right
after
this
one.
There
we
talk
about
everything
related
to
coop
con,
whether
it's
the
demo
or
the
presentation
so
feel
free
to
join
that
one.
The
biggest
thing
is
for
everybody
else.
If
you
want
your
company
to
be
part
of
this
demo,
you've
got
to
start
coding
now,
because
this
one
is
bigger
than
previous
ones.
So
it
will
take
some
time
to
get
it
just
right.
So
don't
wait
for
the
last
minute.
A
If
you
want
to
join
just
a
reminder,
if
you've
all
been
warned,
so,
let's
see
what
else,
okay,
so
kook
on
itself,
as
I
mentioned,
we
do
have
a
meeting
right
after
this
one
to
talk
about
anything
related
to
coop
con
I
know
some
people
have
been
working
on
their
slides,
I,
don't
I
could
be
wrong,
but
I,
don't
believe
anybody's
slide
that
is
actually
completed
yet
I
believe
the
official
deadline
was
like
already
passed
so
technically
we're
all
late,
but
least
we're
all
in
the
same
book
together.
A
What
I'd
like
to
do
is
to
pressure
everybody
to
get
their
slides
done
no
later
than
next
week's
phone
call.
So
next
Thursday.
So
at
least
this
working
group
can
look
at
the
slides
and
have
comments
in
time
for
the
kook
on
the
following
week.
So
everybody
on
the
call
who
is
working
on
slides.
Please
try
to
eat
your
stuff
in
there
sooner
rather
than
later,
but
no
later
than
like
Wednesday
night
next
week,
if
possible.
A
Okay
moving
forward,
then
coupe
con
China,
Catherine
I
talked
a
little.
Cathy
is
going
to
be
there
so
as
of
right
now,
Cathy
and
I
will
be
doing
some
presentations.
There
are
two
35
minute
ones:
one-stroke
lab
event,
one
for
surplice.
If
you
are
going
to
be
there
and
you
would
like
to
be
part
of
those
presentations-
just
let
us
know
otherwise,
Cathy
and
I
can
handle
it's
only
35
minutes
each,
but
the
more
the
merrier.
A
If
you
guys
want
to
join,
let's
see
what
else,
okay,
so
I
was
supposed
to
present
the
cloud
event
status
on
the
CN.
Cf
COC
call
this
Tuesday.
Unfortunately,
they
ran
out
of
time,
so
I
got
bumped
to
next
Tuesday's
call.
However,
I
did
actually
finish
the
presentation,
so
the
link
is
right
here.
If
you
guys
want
to
look
it
over.
If
you
have
any
last-minute
comments
or
suggestions
for
edits,
just
let
me
know
and
I'll
try
to
get
them
incorporated
a
couple.
People
did
some
reviews
I.
A
Think
Marc
was
the
biggest
one,
did
review
and
made
some
changes
based
on
that,
but
so
I
think
it's
pretty
much
good
to
go.
It's
not
terribly
exciting,
just
a
summary.
What
we've
been
doing
so,
obviously,
since
we
did
not
have
the
phone
call
or
we
didn't
tie
mark
on
Vince
I
still
don't
have
any
resolution
on
what
three
independent
end
users
means
yet,
but
they
did
agree
to
talk
about
that
on
the
call
so
Poco.
C
E
A
Right
next,
one
Allen
is
not
on
the
phone
call.
So
I,
don't
think,
is
anything
really
discuss
on
this
one
for
those
of
you
who
were
not
on
the
call
early
clémence,
it
he's
actually
gonna,
possibly
run
into
Allen
next
week
in
a
face-to-face
meeting,
so
he
will
poke
him
on
that
to
try
to
get
his
opinion
on
that
one
and
possibly
rejoin
our
phone
call
next
week.
So
what
I
like
to
suggest
is
that
we
hold
off
until
that
time
to
see
it
and
get
Helen
to
speak
up.
A
F
C
F
A
A
G
That's
busy
listening
to
Hines
speak
on
this
very
entertaining
golf
thing
with
a
couple
weeks
ago
and
I
think
there's
so
I
agreed
that
Hines
is
is
right
that
it's
superfluous
as
an
artifact.
If
you
just
look
at
message
and
then
decide
your
positioning
strategy
from
the
message
so
either
you
know
passing
that
is
parameter
to
the
Kafka
API
or
even
making
a
call
for
the
petition
choice
directly.
G
So
basically
with
Kafka
API,
you
can
either
pick
a
key
or
you
can
even
go
and
and
send
directly
to
a
partition,
and
the
same
is
true
for
the
API,
for
instance,
a
media
for
event.
Ups.
So
for
that,
there's
no
need
to
have
that
key
inside
of
the
message,
and
of
course,
if
you
have
the
message
and
you
look
at
it,
you
can
go
and
take
you
know
you
can
synthesize
a
key
from
any
material.
That's
in
the
message,
and
so
you
can
basically
just
pick
a
natural
key.
G
G
And
you
know
why
not
have
a
extension
that
crates
or
an
official
key,
and
then
the
discussion
went
back
and
forth
for
a
while
and
I
think
we
can
actually
have
both
and
I
would
and
and
that's
what
the
proposal
is,
and
then
it's
the
the
Kafka
binding
and
any
binding,
that's
using
that's
requiring
partitioning
should
mandate
that
there
is
a
some
form
of
a
callback
that
allows
the
application
of
that
basis
goes
from
the
binding.
Whatever
the
parent
sport
mechanism
is
allows
the
applications
to
go
and
take
a
look
at
the
message.
G
The
application
will
know
what
the
schema
is.
It
will
have
full
visibility
into
into
the
message
itself
and
then
ask
that
callback
macey
ask
the
message
to
ask
the
application
to
either
create
a
partition
key
or
we
could
also
have
a
mechanism
that
allows
the
that
callback
to
determine
the
partition
outright,
and
that's
really
up
to
you
know
how
the
Kafka,
binding
or
a
future
for
potentially
event
type
binding,
might
want
to
do
that.
G
But
then
I
don't
think
it
hurts
to
have
the
partition
key
as
an
extension,
as
we
have
it
right
now,
which
is
effectively
becoming
the
default
choice
for
that
mechanism.
If
present,
so
you
can
add
the
partition
key.
If
you
want
to
I'm
using
that
extension,
the
Kafka
binding,
if
you
don't
register
with
the
callback,
the
Kafka
binding,
will
then
go
and
look
for
that
partition.
Key
that
partition
key
extension
and
if
that's
not
present,
it
will
just
you
know,
make
up
a
random
key
and
then
it
gets.
A
H
G
I
would
say
the
the
callback
overrides
so
effectively
when
you
have
to
call
back.
The
call
back
has
the
option
to
go
and
take
a
look
at
the
extension
and
that's
kind
of
the
default
implementation.
But
then
you
know
whatever
that
callback
returns
as
the
partition
key
or
partition
ID.
If
you
wanted
to
have
two
is
then
what
is
what
actually
counts?
Cool.
J
Sure
so
again,
part
of
it
is
more
of
a
philosophical
issue,
as
opposed
to
some
hard
and
fast
rule
here,
where
normally,
when
you
have
these
separations,
you
try
and
keep
them
clean.
So
from
my
perspective
of
the
the
API
are
sorry,
the
definition
of
the
specification
for
what
an
event
should
look
like
should
not
have
direct
dependencies
necessarily
on
the
binding
or
the
API
I
agree.
J
It
might
make
it
easier
to
build
the
binding
or
the
API,
but
it
opens
the
floodgates
then
of
I
want
to
make
my
binding
if
I
start
to
allow
third
parties
to
have
their
own
supported
bindings.
Or
you
know
if
they
have
large
environments
such
as
maybe
an
IBM
MQ
environment,
where
they
might
say
well,
I
want
things
put
into
that
standard
as
well,
which
really
are
not
part
of
the
event.
J
G
Make
sense
to
me
and
that's
it's
it's
it's
an
API
level,
callback
mechanism
that
basically
is
in
this
mandated,
which
then
yields
control
back
to
the
application,
and
then
say:
okay,
so
you
give
me
that
message
now
go
and
pick
out.
You
know
what
the
right
partition
key
is
because
turns
out:
I
need
to
have
a
partition
key
for
this
transport.
So
that's!
That's!
That's!
In
that
spirit.
G
We
also
have
a
partition,
key
concept
for
queues,
because
we
have
accused
that
for
reliability
and
throughput
reasons
we
go
and
shard
the
content
across
up
to
16
sub
queues
and
to
make
sure
that
all
the
messages
stay
together
that
should
belong
together
and
for
you
to
have
a
little
bit
of
control,
you
can
also
set
a
partition.
Key.
You
know
basically
just
means
that
they
are
all
the
messages
that
you
think
belong
together
by
something
by
so
means
are
stuck
into
the
same
partition
so
that
they
preserve
order.
G
So
it's
a
it's,
not
a
pattern.
That's
exclusive
to
the
Kafka,
but
it's
basically,
everything
that
has
a
has
some
kind
of
a
partitioning
model
needs
to
have
a
hint
and
that
hint
is
something
that
the
application
cares
about
and
that's
why
I
think
for
the
case
where
you
know
that
you
are
dealing
with
a
partitioned
entity
that
you
sent
to
so
you.
Basically,
you
want
to
formulate
a
cloud
event.
G
G
It
would
be
very
convenient
for
you
to
have
this
common
mechanism
to
kind
of
from
the
application
perspective,
give
that
hint
and
then
how
that
hint
is
really
applied.
Is
then
the
function
of
the
of
the
binding
so
that
you
could
always
go
and
overwrite
that
partition.
You
could
set
it,
but
then,
if
your
your,
your
partitioning
strategy
is
different
or
if
it
even
changes,
then
the
binding
has
the
opportunity
to
go
and
say:
okay,
that's
fine,
that
you
give
me
that
hint,
but
I'm
actually
going
to
do
this
differently
now.
G
K
Yes,
sorry
I
wanted
to
point
out
that,
yes,
it
does
heis
what
you
said.
It
does
make
sense
that,
for
example,
individual
transport
bindings
shouldn't
they
shouldn't
be
able
to
demand
particular
things
from
the
overall
main
spec,
but
this
is
not
in
the
overall
mass
spec.
This
is
an
extension
and
I
think
the
best
way
to
or
one
example
of
why
that,
as
an
extension,
is
useful,
is
that
if
you
would
worry
to
send
your
cloud
event,
for
example
over
HTTP
to
some
entity
that
you
know,
will
partition
it
later
on?
K
If
you
only
have
a
callback
mechanism
in
the
SDK
or
API
or
something
you
would
need
a,
you
will
need
a
third-party
extension
to
indicate
that
within
the
cloud
events
over
the
HTTP
binding
and
then
why
would
you
not
have
a
well-known
extension
for
that
which
would
be
standard?
That's
just
my
point
of
this
being
an
extension
which
doesn't
mandate
what
theistic
as
the
case,
do
it's
the
individual
bindings
could
justice
first
specify
their
own
third-party
extensions
cough
cookie.
A
A
J
If
that
is
the
case,
then,
if
I
already
have
that
data
captured
in
the
event
when
it's
passed
to
the
layer
below
my
plugin
or
pre
or
post
processing,
however,
you
want
to
implement
it
or
even
have
it
as
part
of
the
binding
we'll
also
have
that
same
data,
so
why
do
I
have
to
create
it
before
I?
Send
it
where
it's
part
of
that
same
data?
You
know
it's
kind
of
like
if
you
look
at
the
JMS
spec.
J
One
thing
I've
always
hated
is
the
fact
that
if
I
wanted
to
do
a
selector
I
had
to
take
data.
That
was
already
in
the
payload
of
my
message
and
duplicate
that
in
the
header
just
to
be
able
to
do
the
selector,
because
that's
how
they
decided
to
implement
the
binding
layer
a
little
farther
down
and
I'm
trying
to
avoid
that,
where
again
things
will
start
to
sneak
in
where,
if
it's
in
the
data,
if
it's
created
from
the
data,
it
should
be
done
at
a
lower
layer.
J
A
Someone
has
a
person
that
that's
you
know
go
to
you
so
clarifying
question
for
them
for
Hines
that
lower
layer,
though
that's
going
to
extract
the
data
or
the
bits
from
the
data
to
generate
the
key.
A
It
would
then
have
to
understand
the
payload
right.
It
would
have
to
understand
the
data,
the
format,
the
schema,
where
you
want
to
call
it
to
be
able
to
extract
the
appropriate
data
and
I'm
or
the
other
option,
is
I
think
what
Clemens
was
suggesting
is
where
there's
a
callback
mechanism
right.
So
in
my
mind
whether
there's
a
callback
mechanism,
so
that
transport
there
could
be
independent
of
the
data
or
whether
the
application
gives
you
the
key
upfront
through
some
extension.
Is
there
really
much
of
a
difference
in
your
mind,.
J
Well,
you're,
adding
something
into
the
event
definition
for
processing
at
the
next
level
and
I
agree.
It
makes
it
easier
to
process
at
the
next
level,
but
that
also
means
now,
rather
than
doing
it
once
in
the
binding
layer.
You're
gonna
have
to
do
it
for
every
message
that
you
send
using
that
event,
and
that's
you
know
really
not
that
efficient
and
you're
putting
dependencies
now
into
your
application,
as
opposed
to
extracting
them
at
the
binding
layer.
J
So,
for
example,
of
I'm
generating
a
key,
for
example,
a
Kafka
partition
that
key
is
based
on
something
in
the
data
I
mean
it's
not
just
some
random
number
sequence
or
something,
and
it
can
also
be
quite
complex
because
Kafka
is
done
a
great
job
of
making
that
key
and
object.
So
it
could
actually
be
multiple
pieces
of
data.
J
So,
if
it's
being
done
over
and
over
the
same
time,
it
should
be
done
at
the
transport
or
the
callback
where
I
plug
it
in
once,
as
opposed
to
doing
it
in
every
event,
message
sticking
it
into
the
event
specs
somewhere
in
the
event
specification
to
pass
it
to
the
lower
layer.
So
you
know
it
becomes
inefficient,
you're
passing
lower
level
processing
back
into
the
event,
and
you
know
you're
kind
of
destroying
the
shielding.
You
know
it's
kind
of
like
the
concept
of
something
like
spring
cloud
streams,
where
I
completely
abstracted
out.
J
K
If
you
are
implementing
a
higher-level
API
that
handles
events-
and
you
know
you
will
be
partitioning
those
later
on
and
your
users
know
you
will
be
partitioning
those
later
on.
They
is
no
generic
callback
mechanism.
We
can
specify
that
would
work,
because
if
you
get
those
events
over
HTTP
we're
not
going
to
start
specifying
HTTP
callbacks
in
our
spec,
so
the
situation
then
becomes
that,
if
you're
building
a
higher
level
API
that
takes
cloud
events
and
then
knows
it
will
be
partitioning
those.
I
I
guess
the
one
thing
that's
not
clear
to
me
here
and
I
think
I
think
we've
run
this
a
little
in
the
discussion
is
the
partition.
Key
is
basically
the
producer
having
an
opinion
about
how
this
maps
in
terms
of
a
grouping
to
the
destination
when
we're
talking
about
extracting
attributes
from
the
payload.
I
That
sounds
like
it's
closer
to
the
consumer,
deciding
how
the
partitioning
happens
and
potentially
different
consumers
might
make
different
partitioning
choices.
So
if
we
think
that
it's
likely
that
different
consumers
will
end
up
wanting
to
partition
different
ways,
I
know
Clemens
has
some
good
examples
from
IOT
spaces
of
you
know,
type
of
sensor,
building
and
so
forth
that
you
might
want
to
partition
differently
then
like
having
this
documented,
probably
doesn't
match.
Most
consumers
needs
the.
G
Callback
idea
was
was
also
on
the
consumer
side.
Sorry
on
the
publisher
side,
so
the
publisher
writes,
writes
a
writes,
an
event
and
then
the
callback
is
also
basically
called
you
don't
know
whether
the
event
goes
as
you
produce
it,
and
then
you
send
that
off
to
one
of
the
chosen
transports
that
is
configured
underneath
you
and
if
the
chosen,
what
happens
to
be
Kafka,
there's
a
callback
hope
that
comes
back
up
into
your
app
and
then
that
says
you
know.
Okay,
you
give
me
this
event,
no
give
me
a
partition
key.
K
Yeah
I
mean
it's
consumer
specific.
How
I
want
to
see
partition
or
the
consumer
is,
does
care
about
how
you
partition
your
events,
but
the
consumer
unfortunately
cannot
decide
that
and
it
makes
no
sense
to
specify
an
extension
that
does
that,
because
no
transport
we
know
of
does
that,
because
it
was
not
very
efficient
or
useful.
It's
out
of
bad
communication
that
you
need
for
that,
but.
G
So
that
the
implementation
of
that
callback
would
be
effectively
specific
to
that
particular
Kafka
topic
that
you're
sending
to
so
you
have
the
the
particular
Kafka
topic
has
a
particular
partitioning
strategy
and
you're
writing
a
callback
function
that
just
that
serves
that
particular
partitioning
strategy.
Looking
back
at
that
message,
that's
the
idea
of
the
callback.
A
Okay,
so
try
to
forget
where
we
are
here,
because
I'm
not
sure
I'm
hearing
anything
I
sell
a
whole
lot
of
new
from
people.
I
don't
want
to
keep
circling
Heinz
pick
on
you,
okay,
so
I
gain
the
sense
that
you
clearly
don't
if
it
was
Soviet
to
you.
You
clearly
would
not
put
this
in
there.
I
get
that,
but
I'm
trying
to
figure
out
is
whether
you
could
live
with
this,
because
what
I'm
I'm,
not
an
expert
in
this
space.
A
But
what
I'm
struggling
with
is
that
I'm
hearing
from
the
people
who
created
the
cost
of
binding
that
they
are
blocked
without
this,
and
that's
the
and
that's
the
biggest
thing,
that's
wearing
to
my
mind
in
terms
of
whether
we
need
this
or
not,
and
and
and
we
should
put
it
in
there
at
least
to
satisfy
them
because
they
seem
to
believe
they
actually
fully
need
this
to
make
good
progress,
I'm
trying
to
I'm
trying
to
resolve
that.
With
this.
J
This
was
a
topic
that
you've
seen
come
up
quite
often,
and
we've
usually
figured
out
how
to
solve
the
problem
without
having
to
front-load
dependencies
into
the
other
third
parties,
and
you
actually
implement
those
at
the
binding
layer
which
in
this
case
was
a
connector
layer
the
so
it
almost
sounds
like
we've
kind
of
painted
ourselves
into
a
corner,
and
now
we
need
to
add
this
in,
rather
than
perhaps
revisiting
the
binder.
The
other
part
which
Clemens
made
the
excellent
point
of
as
well
is.
This
is
coming
up
four
partitions.
J
What's
going
to
come
up
when
there's
other
dependencies,
that
would
make
it
easier
for
bindings
or
the
API
definitions
without
a
standard
mechanism
to
plug
these
things
in
to
solve
it
at
a
lower
layer.
You're
gonna
just
keep
coming
back
to
this,
to
make
it
easier
for
the
underlying
layers
and
I'm,
not
against
making
things
easy,
don't
get
me
wrong,
but
at
the
same
time
you
know
if
you
start
to
make
things
easy.
It
opens
the
floodgates
of
all
kinds
of
other
things
that
people
want
to
add.
J
However,
if
you
want
to
add
it
as
an
extension,
that's
one
thing,
but
then
the
extension
question
becomes
well,
it's
not
just
the
key
I
also
have
to
know
the
topic
I
may
have
to
know
the
key.
It
may
have
to
be
different
keys
depending
on
different
things.
Is
it
an
object?
Is
it
a
string?
Is
it
a
binary
now
because
it
you
know,
I
mean
even
if
you
accept
that
you're
going
to
pass
something
as
a
key?
What
is
that
key?
Because
of
the
flexibility
within
Kafka
in
itself?
E
A
K
I
just
want
to
point
out
that,
although
this
does
allow
those
that
pining
and
all
your
stuff
to
move
forward
and
I
think
it
works.
Well,
that's
the
lowest
come
on
come
on
down,
I
mean
earlier
to
the
flood
case.
You
were
talking
about
times
which
I
agree
about.
We
shouldn't
document
every
single
thing
everybody
wants
as
well:
none
extension.
They
should
define
their
own
extensions,
but
I
think
this
is
quite
spread
enough,
but
I
do
think
that
we
should
implement
the
lower
level
hooks
or
whatever
you
were
talking
about.
K
A
K
K
A
Okay,
so
Hines
it.
Let
me
ask
another
question:
would
it
be
horrible
in
your
mind
if
we
were
to
accept
this
as
an
extension
for
right
now,
with
the
assumption
that
we
can
revisit
this
later,
based
upon
the
the
next
round
of
PRS,
which
is
going
to
be
the
Kafka
PR
and
see
whether
you
can
maybe
convince
them
that
they
did
not
need
this?
After
all,
on
that
point,
we
can
always
remove
it,
since
it's
just
an
extension,
yeah.
J
Absolutely
I'm
just
bring
up
the
issues
at
this
point
to
hopefully
make
sure
they
don't
come
up
later
on.
The
fact
that
it
is
an
extension
again
is
not
such
a
bad
thing,
but
if
we're
going
to
do
it,
I'm
just
looking
at
maybe
something
a
little
more
generic
that
can
be
reused
downstream
by
things
such
as
callbacks
or
you
know,
you
know
dynamic
low
classes
and
these
kind
of
things
as
opposed
to
doing
a
specific
for
just
Kafka.
J
A
It
actually
is
worthy
enough
to
maybe
at
some
point
make
it
into
the
spec
or
worthy
enough
to
be
a
common
thing
that
enough
people
and
the
community
wants,
even
though
the
spec
itself
doesn't
have
it,
and
this
thoughts
kind
of
is
like
it's
in
that
experimental
stage.
That's
why
I'm
kind
of
inclined
to
you
push
us
a
little
to
say:
let's
add
it,
so
that
is
just
an
extension.
Which
means,
is,
you
know,
even
more
optional
than
optional
stuff
inspect
just
to
see
what
happens
with
the
Kafka
binding?
A
I
think
the
back
support
and
identity
of
that
is
they
could
live
with
or
not.
So
with
that
in
mind,
let
me
put
forward
a
proposal
and
see
what
happens
so
my
proposal
would
be
to
one
open
up
another
issue
to
add
more
examples
to
here,
because
I
think
several
people,
including
you
and
Kathy,
have
asked
for
more
examples
except
I.
A
Don't
think
that
should
initially
block
the
PR
from
going
in
to
an
action
item
to
open
issues
that
we
revisit
whether
this
extension
is
still
actually
necessary
after
we
resolve
the
cop,
the
PR
and
then
three
ask
the
guys
who
write
in
the
Kaka
binding
PR
to
strongly
consider
whether
they
really
needed
it
or
not,
and
and
Hines
would
like
you
to
join
in
that
conversation.
Yes,
no
worse.
So
what
do
people
think
about
that?
Let
me
actually
write
down
hold
on
a
sec
dad.
K
K
A
A
A
A
A
B
A
H
B
A
H
H
Now
again,
I
mean:
is
that
a
spec
issue
or
an
implementation
issue?
I,
guess:
okay,
that
that
aside,
do
it
are
we
are
we
really
voting
here
on
saying
putting
a
restriction,
all
context.
Attributes
must
be
strings
with
some.
You
know,
define
format
and
doing
away
with
numbers
and
anything
like
that
that
that's
the
bottom
line.
G
The
road
the
idea
was
to
basically
go
use,
Jason's
tech
system,
which
means
the
way
I
heard
encodes
types
which
yield
strings
and
then
do
the
encoding
that
way
which
works
for
HTTP
and
then
works
for
other
transfers
that
are
constrained
to
strings
and
their
headers,
and
so
that
was
the
that
was
the.
That
was
the
basic
idea
and
what
we
we,
since
a
strain
in
Jason,
is
encoded
with
quotes.
G
You
can't
just
omit
the
codes
and
then
still
and
then
claim
that
you
still
have
Jason,
which
means
you
can
either
have
it.
You
can
either
say:
okay,
we
are
not
going
to
encode
in
Jason
we're
going
to
encode
strings
and
then
everything
that
is
a
string
will
have
to
go
and
further
subdivide.
And
then,
if
we
want
to
have
integers,
we
basically
have
to
go
refer
to
a
rule
which
might
be
the
JSON
rule
for
how
to
go
and
encode
that
that
integer
and
we
will
be
losing.
G
But
with
that
we'll
be
losing
inference.
Because
our
signal
for
whether
something
is
a
string,
that's
the
leading
quote-
that's
no
longer
there,
which
means,
like
you,
can't
tell
for
175
1
as
a
number
from
4
for
175
1
as
a
string
and
so
there's
a
there's,
a
we
can
go
and
restructure
this
and
I
don't
think
it's
going
to
be
I
mean
it's
work
to
go
and
restructure
this
so
but
effectively.
G
What
that
means
is
that
we
have
to
change
the
type
system
such
that
if
we
care
about
having
numerals,
if
we
care
about
having
timestamps,
if
we
care
about
having
your
eyes
need
to
retain
some
sort
of
a
type
system,
because
we
want
to
have
common
definitions
for
this
well,
certainly
we
don't
want
to
have
for
it.
You
know
in
all
the
places
where
we
have
your
eyes.
We
don't
want
to
repeat
that
encoding.
So
there's
got
to
be
a
common
place.
G
You
have
to
go
and
point
to
that,
and
so
now
the
question
is
whether
we
really
need
to
have
our
own
type
system
rather
than
borrowing
the
one
from
from
Jason.
So
I
thought
for
me
personally:
that's
more
an
implementation
issue
than
anything
else
and
one
that
is
more
cosmetic
than
anything
else,
but
this
is
one
thing
where
I'm
like:
I'm
not
willing
to
have
to
fight
a
hard
fight.
I
I'm
ok
with
wherever
that
falls.
A
My
hands
up
so
the
way
I
kind
of
looked
at
this,
like
listen
to
my
comment
here,
I
kind
of
view
this
as
two
different
options
in
front
of
us
and
I
know
this.
This
may
feel
like
living
HDPE,
tail
wag,
our
dog,
but
unfortunately,
I
do
think.
Hdpe
is
a
it's
a
huge
player
in
all
this
and
I,
and
it
is
as
odd
as
it
may
be.
I'm
letting
it
kind
of
wangus
a
little
I
kind
of
view.
This
as
two
options,
one
is
make
everything
string.
A
We
for
a
long
time
have
talked
about
how
cloud
events
should
be.
You
know
minimal
things
to
add
to
the
events.
This
isn't
meant
to
duplicate
everything.
That's
in
the
data
stuff.
That's
just
meant
to
help.
You
know,
wrap
things
or
get
us
to
his
destination
and
the
always
talked
about
keeping
it
small,
lightweight
and
I.
A
Think
forcing
everything
to
be
his
string
would
help
ensure
that
happens,
because
when
you
have
a
full-blown
type
system,
then
it
kind
of
encourages
people
to
put
possibly
lots
more
data
in
there
and
they
would
maybe
normally
I'm
not
sure,
maybe
plus
the
fact
that
up
until
now,
pretty
much
everything
we
define
is
a
string
except
for
I.
Think
one
attribute,
which
is
an
integer,
tells
me
that
maybe
we
wouldn't
be
losing
a
whole
lot.
A
We
did
to
say
everything's
a
string
and
just
be
done
with
it,
but
it
says
one
option
the
other
option,
which
I
honestly
don't
know
how
I
feel
about
is
basically
what
Jim
was
suggesting,
which
is
keep
the
type
system,
but
then
encode
the
type
into
the
attribute
for
HTTP
so
resemble
for
an
integer.
It
might
be
C
I
after
your
name
or
C
e
s
for
strength.
That
way
we
keep
the
type
system,
but
we
don't
necessarily
have
to
use
jason
to
do
the
encoding.
We
can
do
what
may
be
more
natural
right.
A
So
integers
appears
just
straight.
Integer
strings
appear
as
strange
without
quotes
that
kind
of
stuff
I
kind
of
viewed
those
as
the
two
options
in
front
of
us
I
have
a
slight
preference
just
going
for
string
because
I,
like
keeping
things
simple
but
I'd,
love
to
hear
other
people
think
in
terms
of
options.
They
either
want
to
offer
up
as
alternatives
or
even
if
they
say,
keep
what
we
have
right
now
and
for
sehri
way
to
do
the
jason
coding,
as
we
crown
the
head
aspect.
A
It
does,
it
was
an
interesting
one
like
I
said
I
for
me
personally,
I
go
back
and
forth
on
it.
There's
partner
says
it's
elegant,
it's
it's
easy.
It
gives
everything.
People
need
to
know.
The
other
part
of
you
says
it's
a
little
bit
odd
to
have
a
type
in
there,
but
at
least
it's
just
it's
a
simple
character
with
a
it's,
not
that
big
in
you
right,
but.
A
H
I
I
G
I
So
the
router
doesn't
know
about
the
extension,
but
the
sender
and
the
recipient
do
mm-hmm
so,
and
the
sender
is
sending
by
JSON.
The
router
sees
a
attribute
of
an
extension
attribute.
This
type
it
doesn't
know
which
has
some
string
contents,
which,
if
parsed
could
be
a
timestamp.
It
now
needs
to
send
the
correct
type
on
to
the
destination
which
could
be
string
or
could
be
timestamp
and
it
doesn't
know
which,
because
it
it
was
built
before
the
extension
was
defined.
A
G
A
I
K
G
G
G
A
G
If
you,
if
you,
if
all
you
do,
is
a
kewpie,
so
that's
that
so
I
mean
I'm.
Just
for
the
moment
that
is
my
world
I
start
I
start
a
current
cloud.
Events
have
an
extension
and
I
sent
that
cloud
events
map
it
such
that
the
cloud
event
that
extension
property
shows
up
in
the
application
properties
in
the
application
properties.
The
value
of
that
property
is
timestamp
typed,
so
mkp
has
a
has
a
type
type
system
and
knows
timestamp.
G
A
So
what
you
do
when
you,
when
you're
in
a
world
where
it
appears
on
the
wire
as
a
string,
but
it's
coming
into
AMQP
at
some
point,
and
you
say
anyone
do
that
filtering
that
you're
talking
about.
Can
you
ever
make
the
assumption
that
it's
a
timestamp
or
you
always
have
to
trigger
to
the
string?
Because
you
just
don't
know
well.
A
A
G
Can
I
could
do
a
try
convert
and
if
I
can't
convert
it
to
a
timestamp,
then
then
I
will
take
it
treated
as
a
timestamp.
That's
that's.
That's
one
way
of
doing
it
basically
saying
if
it's
a
well-formed
iso
8601
period,
then
it's
or-or-or
date.
Then
it's
a
it's
a
timestamp,
but
otherwise
it's
a
straight.
A
Well,
that
that
gets
to
something
that
I've
been
wondering
about
is
whether,
at
the
cloud
event
spec
level,
we
could
keep
everything
as
a
string.
But
then
let
the
implementations
of
the
spec
or
SDKs
or
whatever
sits
on
top
of
the
spec,
make
those
decisions
for
itself
right
and
then
know
certain
types
aren't
just
strings.
Let
it
convert
it
and
expose
it
to
their
users
as
something
other
than
strings,
but
at
the
spec
cloud
event
level
everything
can
be
a
string.
G
A
G
All
the
if
you
want
to
take
events-
and
you
know
if
you
want
to
use
middleware
routing
expressions
on
them
in
in
compute
network
or
in
AMQP
broker,
or
you
know,
whatever
broker
that
maybe
they're
always
broken
out
into
properties.
That's
also
true
for
the
old
MVP
and
that's
true
for
mq
and
for
all
the
other
ones.
Message.
Brokers
generally
have
have
type
properties,
then
having
all
of
those
as
string
basically
means
that
everything
you
have
to
go
now.
Parse
ISO
8601
dates
in
your
in
your
expressions.
You
can't
do
that.
Okay,.
A
A
G
Agree,
thank
you
very
much
yeah.
So
I'm
I,
don't
have
it
so
I
I
have
no
good
solution
in
my
head.
I'm
like
and
I
understand,
I
understand
the
simplicity
of
making
everything
is
straight
yeah.
At
the
same
time,
I'm
I'm
worried
about
scenarios
where
you
really
want
to
go
and
take
a
look
at
a
cloud
event
and
all
of
its
its
custom
extension
properties
for
an
application,
and
those
have
you
know,
promoted
properties
that
are
promoted.
An
extension
is
effectively
promoted
property
where
you
have.
G
If
you
look
at
it
from
the
application
perspective
right
and
you
have,
you
have
an
app
the
app
goes
and
creates
a
payload
for
its
its
event
and
the
event
is
relatively
complicated
and,
of
course,
what
the
middleware
generally
can't
do
because
of
complexity
because
of
compute
workload,
etc.
Is
is
know
all
the
potential
data
structures.
G
You
know
payload
structures,
and
sometimes
it
just
can't
crack
them,
because
there's
there
are
cryptids
and
etc,
etc.
So
what
you're
doing
instead
you're
taking
some
elements
out
of
your
payload
and
you
promoting
them
out
to
properties
which,
which
we
call
extensions,
but
the
can
application
specific.
And
then,
if
you
want
to
go
and
and
have
the
the
middleware,
then
do
some
routing
rule
space
of
those.
Then
strings
become
much
more
difficult
than
numerals
or.
G
A
H
I
agree
with
the
assertion:
you
know,
if
you
put
everything
as
a
string,
then
you
you
actually
have
other
problems,
I'd
sort
of
rail
against
any
sort
of
in
type
inference
going
on.
As
you
know,
especially
if
stuffings
going
to
move
between
transports,
anything
that
might
misinterpret
stuff
along
the
way
sort
of
scares
me
a
little,
which
sort
of
leads
me
to
a
horrifying
statement.
I
I
think
you
need
a
richer
type
system
we
need
to.
H
K
I
do
agree
that
things
should
have
been
done,
willy
nilly
at
the
binding.
Will
you
just
convert
or
in
for
everything
that
sounds
absolutely
horrible,
but
I
do
think
that
the
dress
would
should
be
able
to
describe
this
Richard
type
system,
but
it
should
also
describe
how
it
will
far
about
back
those
fields
at
the
consumer.
Side
and
I
will
write
that
as
a
proposal
in
the
PR.
Okay.
G
A
A
So
please
yeah,
guys
I'd
your
comments
to
the
PR
cuz
I'd
like
to
see
if
we
get
that
one
resolved
at
some
point
next
week
would
be
really
really
nice
I
heard
Jim
dougie
once
on
the
call.
D
N
G
A
A
G
Don't
like
that,
but
I
think
there's
a
there's
daddy's
type
modifiers
in
in
c-sharp
as
demand
I
think
Java
has
them.
She
has
them
way.
You
can
go
and
say
and
modify
string
by
having
a
prefix
for
for
it,
and-
and
you
say
this
is
a
longer
string
and
then
that's
all
unicode's
and
or
you
leave
it
a
normal
string
and
then
it's
all
know
regular
bytes.
G
So
we
could
I
can
actually
imagine
that
we,
if
we
really
say
we
want
to
have
our
own
I,
think
I
think
having
our
own
type
system
is
something
that's
difficult
to
avoid.
But
if
we
could
go
and
say
and
prefix
it
a
timestamp
string
with
a
t
and
that's
that's
one
idea,
but
that
idea
is
about
30
seconds
old,
but.
G
You
can
still
have
you
can
still
have
variants
all
right.
We
mean
by
variance
meaning
meaning,
if
you
have
a,
if
you
have
your
own
custom,
if
you
have
their
own
custom
properties
and
custom
properties
may
have
may
vary
by
type,
because
you
have
a
EF,
a
dynamic
language
of
sorts
and
you're,
just
passing
messages
and
you're
passing
passing
messages
around
that
are
being
created,
and
once
you
have
a
date
and
then
for
with
the
same
like,
if
it
you
have
a
key,
you
have
two
attributes
right.
G
One
is
called
key,
the
other
one
is
called
value
or
whatever
right
and-
and
you
think
it's
a
good
idea
to
go
and
write
an
application
that
way
to
go
and
includes
the
key
and
the
value
in
your
event,
because
they're,
referring
to
whatever
that
is
with
the
prefix,
you
would
still
have
the
opportunity
to
go
and
put
the
the
value
indicate
the
value
type
indicator
instead
of
the
value
itself.
G
G
A
A
A
G
G
A
Presentations,
as
I
mentioned
on
the
previous
call,
I,
don't
think
anybody's
completely
done
with
their
presentations,
yet
am
I
correct
in
assuming
that
it's
just
a
matter
of
people
finding
time
is
there
any?
Is
there
any
issue
that
we
needed
to
discuss
relative
to
it,
or
is
it
just
people
just
need
to
sit
down
and
do
it.
G
I'm
sure
I'm
gonna
share
a
link
with
you
on
my
onedrive
and
then
you
can
go
and
open
that
PowerPoint
document.
That's
they
and
paste
your
stuff
in
and
then
we
need
to
go
and
it
puts
the
right,
template
and
I.
Think
Doug
didn't
you
sense.
I
think
he
sent
me
they
the
order
to
the
PowerPoint
again
so
I
have
to
my
it
from
the
inbox
and
then
I'll
put
our
format
that
and
put
that
together
and
I'll
give
slide
the
link
on
me
or
on
slack
okay.
O
A
E
B
A
A
Where
we,
where
do
you
guys
want
to
do
the
demo,
then
in
the
85
minute
well
did
I
do
it
somewhere,
it's
either
the
deep
dive
or
the
intro
one
of
the
two
and
I
thought
at
one
point
we
talked
about
doing
in
the
demo
because
deep
dive,
they
thought
they
were
gonna
run
out
of
time
and
the
intro
was
maybe
a
better
place
to
showcase
something.
That's
more
lightweight
like
the
airport.
Oh,
but
it's
up
to
you
guys.
A
B
A
A
A
Tend
to
agree,
would
you
like
to?
Maybe
if
you
want
we
can.
What
we
can
do
is
shorten
this
down
to
like
a
once,
like
kind
of
a
thing
where
you
were
somebody
else,
we
could
pray
that
out
later,
but
mainly
jump
into
the
other
stuff
cuz,
for
example,
I
think
Christoph
wanted
to
talk
about
some
of
his
stuff
and
then
Jude
had
something
he
wanted
to
talk
about.
B
B
P
A
Well,
its
current,
but
you
would
ask
for
some
time
to
talk
about
this
stuff,
so
it's
kind
of
up
to
you
to
decide
what
you
want
to
talk
about
here,
I'm
looking
at
that
Christoph
stuff
and
your
stuff
as
a
combination
of
things,
one
is
a
little
bit
educational
based
upon
you
know
the
topic.
You
want
to
sort
of
share
with
the
group,
but
then
also
as
a
lead-in
to
get
some
thoughts
processes
going
inside
the
audience
members.
A
So
they
could
so
they
can
have
something
to
talk
about
during
the
bird
of
a
feather
session
right,
whether
it's
direct
questions
on
what
you
talked
about
or
whether
it
just
sparks
some
ideas
on
what
in
the
server
lists
or
function
space,
they
want
us
to
look
at
it's
kind
of
up
to
them,
so
that
I
think
almost
anything
will
talk
about
there.
My
mind
is
fine.
A
A
Now
in
terms
of
the
presentation
for
the
service
summit,
if
the
presentation
is
there,
there
are
some
slides,
but
I
don't
think
it's
complete.
Yet,
let's
see
how
PA
he's
not
on
call
how
many
had
Xavier
and
I
had
had
some
brief
back
and
forth
a
little
but
I'm
gonna
poke
on
him
to
make
sure
his
stuff
is
done
next
week
as
well.
A
So
what
I'd
like
to
do
is
remind
everybody
that
try
to
get
your
stuff
done
by
Wednesday
of
next
week,
so
that
by
Thursday
we
can
tell
everybody
in
the
working
group
to
look
at
the
slides
review
them
and
get
their
comments
in
because,
because
obviously
coop
con
is
a
week
after
okay,
so
shoot
for
Wednesday
at
the
latest
to
get
your
slides
into
all
your
decks.
A
B
A
B
A
A
F
G
A
Fine,
it's
only
what
is
this.
It's
like
and
right
now
is
scheduled
for
45
minutes,
but
alex
has
actually
asked
for
a
little
bit
of
time
shift,
so
that
is
that
we're
gonna
have
less
than
45
minutes.
I.
Think
it's
going
to
closer
to
like
35,
so
I
don't
expect
it
to
be
a
whole
lot.
This
is
just
a
summary
of
everything
you
guys
already
know.
What
have
we
done
in
service
yeah,
Abigail.
A
G
A
D
A
Tell
you
what,
since
that's
a
very
basic
question
and
not
it's
a
good
one,
but
it's
a
very
basic
question.
We
can
do
it.
Oh
yeah.
D
A
I
was
gonna,
say
if
I
have
feeling
the
calls
can
end
really
really
quickly.
So
then
you
and
I
can
stay
online
and
I
can
walk
you
through
it
how's
that
great
okay,
because
I
don't
want
to
take
up
time
to
people
who
already
know
that
stuff.
So,
aside
from
the
basic
question
the
Owens
was
asking:
are
there
other
issues,
questions
concerns
people
have
about
the
demo
itself
or
is
just
a
matter
of
finding
time
to
code
it
up
or
test
it.
B
A
B
B
A
A
B
A
Does?
Oh
it's
just
funny
because
I
I've,
given
K
native
demos
or
and
meetups
and
stuff
like
that
and
there's
a
period
of
time
when
I,
have
to
wait
like
25
seconds
for
the
bill
to
happen
and
it,
and
that
is
the
longest
25
seconds
of
my
life,
because
not
only
don't
have
to
ramble,
but
then
I
have
to
sit
there
and
watch
this
thing
and
pray
to
God
that
actually
works
cuz.
You
know
after
20
seconds
you
never
know
for
sure.
A
A
B
A
B
On
a
related
or
unrelated
topic,
I
think
it
might
be
interesting
to
have
kind
of
a
picture
of
what
transports
are
in
operation
in
the
demo.
From
all
the
people
that
are
participating
like
the
the
central
hub
is
all
AMQP
right,
but
all
of
my
stuff
actually
operates
off
of
HTTP
and
sends
back
out
a
kewpie.
B
That
would
be
hard
today
right,
I
write
my
function
and
I'm
because
I'm
using
the
cloud
events,
SDK
I,
don't
have
to
change
how
I
only
have
to
switch
out
the
transport
when
I'm
testing,
so
I
can
run
it
locally.
I
can
point
it
at
a
transport.
That's
using
AMQP
bindings
I
can
switch
it
out
in
production,
see
the
HTTP
transport
and
it
still
works
the
exact
same
way
and
I.
Don't
change
code
I,
just
change
the
setup
of
how
the
function
starts
up
I.
A
Maybe
what
you
could
do
is
put
together
a
slide
or
two,
but
maybe
one
slide
that
this
says
you
know
what
that
was
about
do
the
demo
and
then
as
a
follow-up
after
the
demo
talk
about
in.
Why
don't
you
slides
whatever
you
want,
but
about
the
implementation
aspects
like
you're
referring
to
here
yeah,
but.
G
B
G
E
G
G
A
E
A
B
The
covers
as
well
just
because
it
was
easiest
so
I
have
I,
have
a
repository
that
implemented
an
AMQP
source
and
sink
so
you
can,
you
can
host
it,
and
then
you
can
bridge
events
on
to
the
broker
operate
on
stuff
and
then
send
it
back
out
on
the
sink
or
on
the
yeah
on
the
sink.
The
sink
takes
in
events
from
inside
the
cluster
and
pushes
them
back
out
to
a
predetermined
transport
is.
C
B
Plan
use
the
goal
that
go
SDK
and
all
the
transports,
and
all
that
that
I
wrote
something
called
the
I
call
a
bridge
that
bridges
to
transports
together,
and
so
it's
a
it's
a
it's
to
cloud
event:
clients,
that's
listening
on
two
separate
transports
and
then
just
shuffling
data
between
them,
and
it
might
actually
be
a
pretty
interesting
first
class
Kay
native
component.
That
does
those
bridges.
I.
B
J
G
G
A
G
B
G
Activemq
is
that
wrong?
That's
no!
That's
just
the
older
version
and
the
older
cook
base
and
the
the
new
Artemis
is
based
off
of
Horlick
you,
which
was
an
acquisition
by
Red
Hat
and
that's
just
faster
and
more
modern,
and
that's
where
they
weather
most
of
the
work
goes,
but
yeah
activated
for
my
inner
first
perspective
is
the
same
thing.
G
F
A
Know,
Scott
and
I
are
both
influencing
all
the
various
roles,
but
in
reality
for
the
demo
itself,
I
well,
I
guess
the
pen
that
make
people
we
actually
get
signed
out.
I
was
assuming
that
you
don't
want
everybody
doing
everything.
Otherwise
it's
gonna
get
very,
very
crapping.
It
I
guess
we
can
wait.
We
don't
have
to
decide
right
now,
but
at
some
point
we
may
need
to
to
assign
people
different
roles
just
so
the
screen
isn't
too
busy
because
we're
kind
of
assuming.
G
A
A
Was
thinking
either
a
supplier
or
carrier
and
they
can
make
Microsoft
a
carrier
but
I,
but
well,
okay,
once
you
start
doing
a
carrier,
then
we'll
hold
off
on
the
rest,
because
I
think
it
depends
on
how
many
other
people
other
people
join
okay,
but
at
least
that
will
give
you
at
least
one
to
start
with
it,
because
that
that's
impairment,
whoa,
okay,
okay,
okay,
any
other
questions
or
comments
all
right
cool.
Thank
you
guys,
in
that
case,
everybody's
free
to
go
except
for
Owen.
A
A
A
Okay,
what
starts
from
the
very
beginning?
It's
not
it's
not
huge!
So
basically,
oh
there
we
go
Scott's
doing
something.
So
basically
the
the
point
of
the
demo
is
simulating
a
airport
environment
where
there's
retailers-
that's
these
guys
down
here
and
they
are
gonna,
sell
coffee
to
customers
and
there's
the
wonderful
cold
start,
kicking
them
out.
A
So
we
have
retailers
down
here,
select
coffee.
We
have
suppliers
up
here
who
are
offering
up
coffee
cups.
So,
as
the
retailer
to
run
out,
they
will
send
out
an
event
saying:
hey:
I
need
more
coffee
cups,
the
suppliers
will
say:
okay,
I
thought,
I
have
a
copy,
shipment
or
coffee
cup
shipment
ready
to
get
picked
up
the
carriers.
The
little
trucks
over
here
will
then
go
to
the
various
suppliers,
carry
em
to
the
retailers
and
then
go
back
home.
Okay.
So
that's
the
basic
flow.
A
The
audience
members
are
supposed
to
participate,
because
what
we're
gonna
do
is
tell
them
to
go
to
source.com,
slash
Airport
and
they
should
see
on
their
phone.
This
little
thing
down
here
that
I'd
see
in
the
corner
so,
for
example,
they'll
be
able
to
pick
a
coffee
shop.
So
IBM
coffee
and
that
little
guy
will
walk
up
to
it
and
they
can
get
a
little
jump
button
and
that
will
jump
and
stuff
like
that
and
they
can
order
their
coffee,
so
small
in
this
case
and
then
they'll
walk
away
when
they
have
it.
A
If
the
guy,
if
the
retailer
runs
out
of
coffee,
he'll,
ask
for
more
as
I
said,
but
then
I'll
also
put
up
that
little
bubble
for
small
peers
here,
meaning
appear
here.
Large
appears
here
indicating
that
he's
out
of
coffee
cups.
So
that's
give
you
an
indication
of
something
that's
going
on,
but
that's
the
basic
flow
from
a
visual
perspective.
Okay,
now
the
weight
works
under
the
covers
is
everything
that
goes
on
here
is
event-driven,
so
we
have
a
single
rabbitmq
deployment,
that's
receiving
and
sending
out
events
for
everything.
A
Okay-
and
you
see
on
the
right-hand
side
here-
are
basically
the
cloud
events
that
flow
back
and
forth
of
the
system.
So
let's
actually
pick
one.
That
might
be
more
interesting
so
here
so
this
particular
case
when
somebody
places
an
order.
This
is
the
cloud
event
that
gets
sent
and
this
is
their
case.
The
passengers
technically
send
in
the
events.
You
know
it's
an
order
for
the
door
to
released
and
it's
going
to
be
going
to
the
retailer
called
retailer
dot.
A
Ibm
R,
which
just
happens
to
be
the
first
retailer
down
here
in
left
hand,
side
and
he's
going
to
process
it.
When
he's
done,
he'll
sent
that
an
event
saying
the
the
the
coffee
has
been
delivered
and
the
controller,
which
is
basically
the
graphical
stuff
here,
watches
for
all
the
events
and
makes
things
move
on
the
screen
accordingly,
okay
notice,
so
the
event:
ok,
the
demo
itself.
So
basically,
if
you
look
at
the
document
itself
in
case
you
don't
have
it
there's
no
idea.
Oh
you
know.
A
You
basically
look
at
the
event
flow
in
this
section.
Just
walk
through
it
and
you'll
see
all
the
various
events.
I
can
flow
through
the
system
just
once
walking
through
it,
and
so
what
you'll
see
is
initially
all
the
various
participants
will
register.
So,
let's
just
hit
the
reset
here
for
a
sec.
Let's
talk
down
here
to
register
right,
so
the
first
thing
is,
for
example,
a
retailer
registers,
and
you
can
see
what
the
event
looks
like
here,
not
not
too
exciting
use
register
your
sister.
You
have
a
system
name
and
organization.
A
A
C
A
Logo
does,
though,
right
so
you
get
a
little
icon
here
and
then
I
come
here.
Those
will
appear
because
of
this
logos,
our
URL
right
here,
okay,
so
once
you
as
a
retailer
or
supplier
carrier
register,
what's
convened,
gonna
happen
is
at
some
point
later
in
their
head
on
the
controller
will
reallocate
who's
doing
what
that
way.
Everybody
gets
a
fair
shake
in
the
demo
itself
right.
So
when
you
registered,
you
don't
say,
I
do
small
cups
for
this
particular
retailer.
A
The
controller
will
tell
you
what
you're
supposed
to
do,
and
so
it's
very
important
that
has
these
events
that
we
talked
about
here
flow
around.
You
react
to
them
appropriately
and
immediately
because,
as
new
retailers
come
on
board,
we
don't
want
to
retailers
trying
to
supply
cups
for
the
same
retailer.
That's
going
to
cause
the
system
to
get
into
a
really
weird
state,
okay,
so
well,
what
happened
is
in
this
better
case
for
a
supplier
you'll
get
a
data
section
that
says
for
this
particular
retailer.
A
Here
are
the
coffee
cup
sizes
you
support,
or
you
will
go,
yeah
you'll
send
out
boxes,
for
you
will
get
the
complete
list
of
all
retailers
that
you
support.
So
this
chunk
right
here
could
technically
be
do
a
replicated
based
upon
how
many
retailers
you're
gonna
be
supplying.
So
you
can
assume
that
anytime,
you
get
this
event.
It
will
be
the
complete
list.
It's
not
like
you're
gonna
get
three
events.
You
have
to
sort
of
merge
them
together,
because
otherwise
you
can't
tell
whether
it's
you
know
he
goes.
A
New
start
of
a
list,
so
we
just
said
no
you're
gonna
get
one
event
with
everything
you're
supposed
to
be
working
on.
So
if
you
get
a
second
event
to
that
tight
wiped
out
your
memory
about,
what's
going
on
and
start
fresh
make
sense,
okay,
so
here's
the
message
for
the
supplier:
here's
the
message
for
a
carrier,
same
type
of
thing,
you'll
get
an
array
of
to
and
from
locations,
and
that's
what
you're
going
to
be
supplying
for.
A
Let's
see
when
everything
is
done,
the
controller
sent
out
a
message
saying
that
the
passenger
has
placed
an
order,
and
this
is
actually
destined
for
a
particular
retailer.
So
this
one
of
those
cases
where
it's
a
event
that
is
technically
targeted,
so
it's
not
really
a
venting
per
se.
It's
more
messaging,
but
such
is
life.
We
needed
some
way
for
the
controller
to
say
this.
A
This
passenger
ordered
something,
but
then
from
then
on
I
think
most
everything
else
is
kind
of
a
venting
for
the
most
part,
and
you
can
kind
of
see
the
flow
here,
so
the
classic
pastor
place
in
order
retailer
deliver
the
coffee
cup,
so
this
is
Bess's,
is
actually
technically
for
the
controller
or
anything
else.
So
you
can
tell
the
little
passenger
guy
to
walk
away.
A
The
retailer
can
also
indicate
his
new
inventory
level.
Technically,
these
are
ignored
except
no,
actually
yeah.
Technically,
these
are
ignored,
except
when
it's
zero,
because
the
head,
when
it's
zero,
that's
when
the
controller
will
put
up
that
little
bubble
up
here,
just
to
know,
for
example,
that
he's
out
of
small
coffee
cups.
Let's
say
they
can
make
him.
Do
it
go.
A
When
we
invent
descent
of
an
inventory
level
zero,
that's
how
the
controller
knows
that
he's
out
of
coffee
and
that's
when
the
bubble
appears.
Okay,
the
big
one
that
you
want
to
watch
for
the
quick
one
you
want
to
do
if
you're
gonna
end
up
doing
a
retailer.
Is
this
one
order
released?
So
that's
your
way
of
telling
the
supplier
you're
at
a
coffee
in
a
particular
you're
out
of
small
cups
and
notice.
A
A
So
the
way
the
supplier
will
react
to
it
is
he's
gonna
send
out
a
notification
saying
he
has
a
box
that
needs
to
get
picked
up,
so
potential
action
status
means
I,
need
something
to
get
picked
up
and
shipped
from
IBM
s,
supplier
to
IBM
our
retailer,
and
you
just
having
me
doing
small
coffee
cups,
even
though
I
don't
think,
that's
really
use
a
place.
So
the
supplier
sends
out
this
one:
the
transport
or
the
carrier
is
gonna
react
to
it.
A
The
carrier
is
going
to
notice
that
it's
the
from
in
two
locations
that
he
supports
and
he's
gonna
react
to
that
then
he's
gonna
send
that
notification
saying
okay
action
status
is
now
or
it's
now
active
action
status.
So
he's
basically
saying
yep
I'm
gonna
pick
up
that
box.
That's
the
signal
for
the
the
controller
to
change
the
screen
so
that
he
sends
a
little
truck
on
its
way
right
to
the
supplier,
so
the
truck
will
go
from
here,
the
supplier
down
to
the
retailer
and
then
back
home
when
he's
done.
A
Okay,
so
that's
that's
the
important
message
for
the
controller
to
know
what's
going
on
so
then,
eventually,
the
controller
is
going
to
tell
the
UI
that
his
truck
is
actually
moved
to
the
retailer.
So
because
the
technically
in
the
real
world
right,
the
truck
will
tell
the
retailer
I'm
sorry,
the
truck
will
tell
the
the
carrier
when
he's
arrived,
but
because
the
UI's
had
control
things
we've
we
made
the
controller
do
this,
so
the
controller
is
basically
telling
the
carrier
yep
you're
Chuck
has
arrived
so
now
the
carrier
can
send
a
notification
saying
actually
completed.
A
Okay,
I,
don't
sure
anything
really
happens
here
other
than
it
just
sort
of
laying
the
system
know
that
everything's
there.
Oh
I
guess
that
is
that's
a
notification
for
the
retailer
to
know
that
the
package
that
been
delivered
so
now
the
retailer
can
increase
his
inventory
level
to
two
and
so
I
sent
that
notification
just
so
the
world
can
know
who
they
were
watching
that
he
now
has
two
cups
a
very
to
go
and
getting
serviced
more
customers.
A
The
current
process
we
have
right
now,
I
think,
is
that
everybody
assumes,
if
there's
two
cups
per
box,
even
though
it's
a
very
small
level,
if
you
increase
it,
you
don't
necessarily
around
the
screen
as
often
as
they
may
want
sure,
but
that's
just
obviously
something
to
easily
change
anyway.
I
ran
with
a
lot
there,
they
paused
and
to
see
where
you
have
questions.
D
D
A
D
A
D
A
A
A
Reset
everything,
and
so
the
best
thing
for
you
to
do
is
when
you
see
the
reset
message
or
a
disconnect
message
is
basically
just
reset
your
environment.
Forget
about
everything
you
know
and
re-register
great,
actually
I,
actually
I'm.
Sorry
I.
Take
that
back.
You
should
not
respond
to
a
reset.
I
mean
I,
simply
think
about.
E
A
So
many
better,
if
you
do
both
if
you
said
reset
or
you
see
a
disconnect,
you
may
want
to
just
reset
everything
either
way
and
it
doesn't
do
any
harm
to
do
it
twice
right.
So,
basically
sure
at
that
point,
if
you
see
reset
or
disconnect
go
ahead
and
forget
about
what
you
were
supposed
to
be
doing
from
the
controllers
perspective
and
then
go
ahead
and
rear
edge
astir
with
the
system
and
you'll
get
automatically
re
added
and
and
job
assignments
will
get
dis
doubts
accordingly.
A
A
A
D
F
A
There,
okay
yeah,
obviously,
please
do
not
hesitate
cuz.
The
last
thing
I
want
to
happen
is
you
feel,
like
you're,
rushing
at
the
last
minute
to
get
this
stuff
done.
So
most
most
of
us
are
hang
out
there.
So
we
have
a
question
just
paste
your
question
onto
the
slack
and
we'll
get
an
answer
to
you
as
soon
as
we
can
great.
A
Okay,
Doug
I
see
you
stole
the
calls
or
anything
you
want
to
mention
anything.
I
forgot
right
now:
I
bring
up.
A
C
A
A
It's
really
kind
of
scary
because
we
start
doing
some
really
weird
stuff
it
for
a
while
there,
but
I
think
it's
a
good
test.
The
system,
especially
when
we
we
start
having
the
audience
involved.
In
their
case,
you
can
get
a
hundred
people
sign
up
for
this
thing,
it
I'm
glad
that
he
detect
that
test
client.
It's
a
good
photo
testing
for
us
yeah.
C
A
Expect
we'll
get
at
least
one
I
think
I
think
Clemens
will
come
through
I.
Think
Jude
will
have
something:
I
can
class
saw
something
and
I
expect,
at
least
from
one
or
two
other
people
to
show
up
the
last
minute
in
a
panic,
so
I
think
I
think
we'll
be
good.
Oh
hey!
We
get
good
participation,
all
right,
all
right
anything
else.
You
guys
wanna
talk
about.