►
From YouTube: CNCF Serverless WG Meeting - 2018-02-22
Description
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 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.
A
H
J
I
A
I
A
G
G
Be
that
kinda
day
yeah,
okay.
A
For
those
of
you
joining,
please
add
your
name
to
the
agenda
doc,
one
more
time
into
the
chat
and
we'll
come
back
around
and
mercury's
attend
or
being
online
later.
If
I,
don't
have
you
already
so
one
thing
I
wanted
to
mention
and
we
have
not
really
a
problem
per
se,
but
it
can't
can't
think
of
a
better
word
right
now
other
than
we
have
a
slight
problem.
And
but
it's
a
good
problem.
A
We
have
a
lot
of
people
on
the
call
and
we
have
a
lot
of
people
who
have
lots
of
opinions
who
are
very
energetic
about
it.
That's
all
goodness,
but
unfortunately
we
also
do
have
people
who
are
shall
we
say
more
on
the
shy
side
and
I
want
to
make
sure
that
we
that
everybody
gets
a
chance
to
speak
up
during
these
calls,
when
necessary
and
in
other
working
groups.
A
I've
been
part
of,
we
actually
instituted
some
sort
of
a
speaker,
cute
kind
of
thing
or
in
the
chat
someone
you
know
raises
their
hand
or
something,
and
then
we
just
go
through
the
queue
that
way.
Your
way
to
get
the
chance.
I'm,
not
sure
we're.
Quite
at
that
stage,
yet
so
what
I'm
reason
I
mentioned?
A
I
I
A
You're
cutting
up,
but
I,
think
you
said,
come
back
to
in
five
minutes:
right:
yeah,
okay
and
I.
Apologize
I
forgot
to
share
my
screen.
So
there
we
go.
You
guys
can
see
that
now
right,
yep,
okay,
cool,
good,
okay,
all
right,
okay!
So
next
topic,
I
asked
first
for
a
room
at
the
next
CN
CF
koukin,
for
a
possible
face
to
face
for
us
the
only
time
slot
that
I
was
able
to
get
would
be
Wednesday
night
after
the
booth,
booth,
crawl.
A
A
A
F
A
I
will
do
that.
It
didn't
sound
like
there's
any
huge
objection,
yeah
to
see
we
get
enough
people
to
make
quorum.
So
that's
a
good
sign.
Alright,
so
let's
jump
into
PR
review.
Did
it
do
the
first
one?
Okay,
this
one's
a
little
bit
old
and
the
reason
it's
gonto
before
is
because
we
had
some
signing
issues
and
stuff
like
that.
I,
don't
believe
anything
textually
actually
changed.
K
Pr,
which
does
which
actually
moves
that
out
which
didn't
get
on
the
list?
I'm
sorry
I
forgot
to
put
it
to
the
agenda.
Yeah.
A
A
That's
something
we
adopt
this
one.
Yes,
so
let's
knock
out
this,
my
first
okay,
yes,
I
apologize,
I
can't
heard
the
gentleman's
name
not
ki.
Do
you
want
to
talk
to
this
one
at
all,
amazing,
on
the
call
hold
on
I
apologize,
I'm,
really
really
bad
with
names
Ori.
You
know
it
was
worried.
Nathan!
Sorry,
Nathan!
Are
you
on
the
call?
A
Okay,
I
guess
he's
not
so,
as
I
said,
I'll
talk
to
this
one,
then
on
this
one,
all
he
did
is
move
the
references
section
out
of
the
spec.
So
that's
really
not
normative
anyway.
Just
examples
of
what's
out
there
today
and
he
added
the
OpenStack
event.
I
believe
is
right
here.
I
had
no
idea
whether
it's
right
or
wrong,
but
it
Dyson
it's
right
and
then
in
the
spec
itself,
rather
than
having
the
reference
section
down
below,
you
moved
to
have
doc,
obviously
and
then
updated
the
table.
Contents.
A
K
Yeah
we
can
close
that
I
did
I,
do
think
that
it's
the
references
shouldn't
be
actually
in
the
spec.
So
after
looking
at
that,
I
wonder
like
I
put
it
in
like
a
landscape
folder,
so
that
like
and
so
I
was
wondering
whether
people
think
that
makes
sense
to
kind
of
pull
it
out
into
supporting
material
rather
than
directly
reference
back.
And
if
people
think
it's
simple,
like
I
just
read
you
might
be.
Are.
A
H
B
I'm
gonna
second
I'm
gonna.
Second,
that
suggestion
Doug
I,
think
I
think
stairs
dude,
some
great
cleanup
work
and
if
you
get
approached
that
in
just
a
separate
PR
on
how
to
kind
of
reorganize
everything
I
think
that
would
be
helpful.
So
we
could
just
look
at
it
as
a
PR
that
solves
that
specific
problem.
B
Yes,
so
I
sent
overt
I
sent
all
of
the
information
necessary
to
transfer
the
domain
over
to
the
Linux
Foundation.
A
couple
weeks
ago,
I've
been
working
with
a
gentleman
named
Eric
Chris
ahead
checks
been
seen
on
all
those
email,
I
think
they're
just
overwhelmed.
They
haven't
been
able
to
get
to
it.
I
pinged
Eric
yesterday
just
checking
in
trying
to
get
a
status
update,
but
so
far
no
activity
on
that
end
and
I'm,
just
gonna
ping
Chris
again
see
if
you
can
help
move
it
along.
But
it's
you
know
balls
in
their
court.
A
H
B
B
Think
kind
of
looking
at
each
of
these
properties
on
a
case-by-case
basis
is
it's
kind
of
the
pattern
that
we're
falling
into
already,
and
it's
probably
I
think
the
best
pattern
moving
forward,
so
I'm
hesitant
to
I'm
not
sure
what
I
do
here
and
with
respects
to
this
other
than
you
know,
try
and
do
one
big
PR
that
seeks
to
rename
everything
all
at
once,
but
I.
Don't
again,
you
know
maybe
I
felt
that
was
the
right
approach
before,
but
I
don't
think
it's
the
right
approach
now
after
seeing
how
we're
operating
well.
K
I'd,
like
a
pretty
basic
suggestion,
which
is
like
I,
think
it
would
be
helpful
to
say
like
when
we
have
two
words:
do
we
have
a
do
we
have
interrupts?
Do
we
have
like
to
learn
it
all
together
with
one
word?
Do
it
like
its
main
consistencies
that
you
know
like
I
didn't
dwell
on
because,
like
I
was
hoping
that
you
would
buy
that
so
I?
Maybe
you
were
thinking
that
was
like
a
really
big
thing.
B
K
Maybe
we
just
say
like
a
naming
convention
rather
than
a
philosophy
and
and
awesome,
maybe
just
start
with
an
issue
that
you
know,
give
some
rationale
for
it,
so
that
people
can
chime
in
on
the
issue
before
you
bother
to
rename
everything.
I
don't
have
any
strong
opinions,
but
then,
if
somebody
else
goes
well
because
reasons
then
I
might
right
now
I'm
just
happy
to
follow
what
is
consistent.
Just.
K
H
B
And
be
as
brief
as
I
can
here
yeah
there
was
another
one
to
open
an
issue
to
gather
thoughts
around
a
reference
implementation,
so
in
the
issues
I
did
that
and
I'm
pitching
a
concept
in
there.
That
is
essentially
a
transformation
library
all
it
does
is
it
takes
common
events
like
events
on
AWS
or
web
hooks,
and
it's
it
seeks
to
simply
transform
them
into
the
cloud
events.
B
Format
and
the
goals
of
this
are
just
to
kind
of
create
a
simple
reference:
implementation
that
works
with
cloud
events,
but
also
create
a
tool
that
is
scented,
eise's
early
adoption
of
the
cloud
events
specification
and
makes
it
easier
for
people
to
use
use
the
format.
So
the
concept
here
is
one
of
the
most
important
parts
of
the
concept
is
essentially
templates
transformation
templates
that
can
be
accessed
in
any
language
because
I.
B
Imagine
if
people
value
this
library
that
is
going
to
be
rewritten
in
several
languages,
but
these
templates
are
our
authored
in
a
way
this
language,
agnostic,
maybe
they're
using
JSON
or
something
I,
suggested
JSON
here
in
this
issue,
but
again
they're,
just
simple
transformation,
Maps
saying
hey!
If
it's
this,
if
it's
this
event
from
Amazon,
take
these
properties
and
put
them
into
these
cloud
events
properties,
but
anyway,
it's
a
it's.
B
G
It
be
interesting
to
as
a
first
step
take
the
existing
examples.
We
were
just
looking
at
in
the
the
references
MD
and
manually
transform
them
into
cloud
events
before
writing
code
to
do
it
programmatically
just
to
see
what
all
of
those
different
types
of
events
might
look
like.
Given
the
current
spec.
B
So
sarah
has
done
a
great
job,
updating
our
roadmap
and
I.
Don't
know
others
have
checked
it
out,
but
I
believe
it
is.
One
of
the
first
priorities
in
our
roadmap
is
actually
not
to
do
this.
This
is
coming
up
in
our
next
version
of
cloud
events,
but
in
this
first
version
of
cloud
of
s,
we
want
to
provide
some
examples
of
common
events
in
the
cloud
events
format.
B
F
So
from
the
product
perspective
or
a
product
perspective
having
a
library
so
I
live
here
like
this
is
not
trivial,
I
mean
yeah,
it
might
be.
We
might
be
able
to
go
and
use
some
libraries
that
can
do
this,
but
you
need
to
go
and
maintain
mappings
and
because
products
change
versus
changed
and
doing
this
as
a
official
of
official
effort
of
the
foundation
of
this
crew,
I
think
is
actually
it's
a.
F
A
Guys
I
have
to
call
Thai
nerds
for
a
sec.
The
purpose
of
this
part
of
the
agenda
is
not
to
decide
deep
dive
into
the
action
items
and
in
particular,
this
issue.
Let's
schedule
this
for
a
different
time.
This
was
just
sort
of
an
update
to
say
yes
or
no.
The
action
items
were
done
or
what's
holding
them
up
or
whatever.
Well,.
K
Yes,
tchen,
which
is
we
could
we
can
I
mean
I,
do
want
to
get
to
the
point
where
we're
encouraging
people
to
like
write
experimental
code.
So
we
could
say
that
the
experimental
code
can
exist
outside
of
the
planets
repo
and
we
can
encourage
people
to
link
to
their
experiments
so
that
so
that
people
get
visibility
into
those
things
without
necessarily
having
it
be
indoors.
So.
A
Guys
guys,
please
well
III
I'm
not
trying
to
cut
off
the
conversation
here.
Let's
have
the
conversation
at
a
scheduled
time
so
in
there
in
the
issue
or
in
a
future
call,
but
we
do
have
an
agenda
that
I'd
like
to
try
to
get
to
in
terms
of
at
least
I
want
to
get
to
the
PRS
and
close
those
out,
because
we
could
think
of
faint
iris
to
call
discussing
this
and
we
wanted
to
so
I'd.
Rather,
the
Austin
update
is
on
the
AI
and
so
now
I'd
rather
move
on
to
these
scheduled
agenda
items.
A
F
Yes,
I
found
the
so
I
looked
at
the
occurrence,
and
events
actually
looked
at
at
events
first
and
then
fellow
occurrence
and
then
also
looked
at
from
thanks.
I
went
and
changed
all
three
but
separately
occurrence
occur
to
me
as
being
a
little
too
narrow,
because
it's
saying
most
typically,
when
the
system
receives
the
external
signal,
that's
Ana,
Kurds
and
as
all
kinds
of
things
that
are
happening
from
within
the
system
and
the
system
being
externally
triggered
for
then
raising
the
event
based
on.
It
is
not
necessarily
the
norm.
F
A
K
Just
want
to
say
that,
like
I
find
this
to
be
more
clarifying
like
I,
think
it's
the
same
intent
I
do
think
that
we
have
had
in
a
call
like
that.
Examples
are
useful
and
there
are
other
parts
of
the
specification
that
have
quite
a
few
examples
that
are
very
specific,
so
say:
well,
you
know
like
I'm
open
to
either
but
like
I
I,
just
want
to
raise
that
fact
that
people
have
found
the
examples
in
spec
to
be
grounding
and
I
don't
know
to
do.
F
K
Seen
from
my
reading,
your
definition
is
identical
to
what
we
attempted
to
write
initially
and
I
do
think
it
is
clarified.
However,
eg
I
don't
think
narrows
it
rather
grounds
it
in
specific
examples.
We
can
break
it
out
the
way
it
is
elsewhere
in
this
fact
with
examples
underneath
it,
but
we
have
found
that
readers
of
the
specification
can't
really
grasp
it.
I
thought.
F
K
It
was
added
because
of
a
confusion
where
people
weren't
sure
whether
the
event
described
the
actual
data
that
represented
what
were
coming
in
currents
like
there
was
a
like.
It
was
added
because
of
confusion,
right
people,
so
that,
but
an
event
is
the
thing
that
happened.
It's
not
the
notification
of
the
event,
and
so
it's
just
a
little
background.
K
F
Have
a
specifically
the
external
signal
is
something
that
I'm
that
I
find
is
confusing,
because
there's
an
external
signal,
then
there
isn't
actually
being
taken
by
the
system
that
will
result
in
something
and
then
an
event
is
raised.
Because
of
that,
you
don't
report
out
that
someone
called
you
an
HTTP
right.
F
A
F
A
So
I
think
I'm
hearing
is
people
okay
with
the
text
as
it
is,
but
there's
a
desire
to
have
some
examples
to
go
along
with
it
and
it
sounds
like
people
are
okay
with
doing
that
doing
the
examples
as
a
follow-on,
PR
and
Clemens
has
volunteered
to
accept
that
action
item.
Yes,
does
anybody
have
any
objection
to
that
stated
path
forward?
K
A
K
A
F
K
I
guess
it's
just
a
question
like
so
I.
Unfortunately,
Thomas
just
had
to
step
out
for
a
second
but
like
I
assume
he
commented
on
the
issue
because
he
had
a
question
about
it.
And
so,
if
we're
not
supposed
to
comment
on
issues
in
order
to
generate
discussion-
and
we
need
to
like
clarify
that
like
we,
we
must
comment
on
the
PR
for
you
actually
one
that
it's
a
kind
of
weird
thing.
So.
F
The
question
here
is
the
contrary:
comment
as
I
understand.
It
is
the
difference
between
the
beds
and
encourage.
Is
intentional.
That's
true
what
I
did
in
the
event
PR?
If
we
take
a
look
at
it,
is
that
I
think
the
eliminate
the
Restatement
of
one
occurrence
is
in
this
in
this
day,
right
data
representing
an
occurrence
changes
state
that
something
happened
or
did
not
happen.
J
K
A
K
And
so
this
also
adds
information
right
that
events
are
radically
emitting
source
to
interested
parties
for
the
purpose
of
notifying
about
source
occurrence.
The
surrounding
can
be
formed
based
on
information
contained
in
the
event,
but
an
event
will
generally
not
identify
specific
routing
destination.
K
Like
introduces
like
a
bunch
of
contacts
right
and
one
of
the
things
that
has
been
a
confusion
on
the
lists
and
with
newcomers
is
whether
we
are
specifying
like
what
I
would
consider
messaging,
which
is
you
know
like
you
know,
this
came
up
on
the
server
list
root
right,
so
so
that's
where
I
don't
think
we
have
written
down
effectively
that
events
don't
contain.
Like
I
mean
I
think
this
is
an
attempt
to
do
so,
but
it's
potentially
confusing
about
like
saying
that
it
the
event
will
generally
not
identify
a
specific
routing,
definite
destination.
K
F
K
E
K
F
E
E
I'm
saying
there
is
serve
a
logical
address
which
is,
for
example,
a
topic
first
name,
whatever
a
function
name,
and
there
is
a
protocol
destination
which
could
be
an
IP
address.
So
even
within
that
there
are
two
layers:
one
belongs
to
the
protocol
layer,
which
is,
for
example,
HTTP
or
Kafka,
whatever
the
one
that
belongs
to
the
envelope,
which
is
not
protocol.
Specific,
that's
different.
That's.
K
F
K
So
I
think
I'm
aligned
with
that
definition.
However,
there
are
folks
who've
been
involved
in
the
working
group
that
also
want
to
understand
that
we
are
making
a
commitment
to
separately
or
in
a
related
separately
or
somewhere
else
in
the
specs
specify
how
we
couple
the
sources.
So
what
you
say
that
operation
of
concerns
articulated.
J
A
K
K
F
K
K
A
Okay,
so
I
hear
your
take
the
next
time
to
write
up
this
design
goals,
principles.
Whatever
phrase
you
want
to
use
as
a
PR
issue
for
us
to
then
discuss
if,
as
we
go
forward
in
the
agenda
today,
you
come
across
a
particular
PR
or
issue
that
people
feel
are
is
blocked
by
the
resolution
of
your
action
item.
At
that
point
in
time
we
can
then
say:
okay,
we're
gonna
defer
this
till
after
the
action
item
is
completed.
That's
not
fair!
Yes,.
A
Yeah,
let's,
let's
try
to
identify
the
roadblock
and
quickly
and
then
avoid
it
and
move
on
to
the
next
topic
if
the
fest
was
necessary,
so
I
so
I
heard
is
Clemens
is
gonna,
revamp
the
text
here
but
based
on
the
inputs,
but
we
found
the
call
today
as
well
as
any
input
that
he
gets
in
the
issue,
I'm,
sorry
in
the
PR
itself.
So
please
comment
in
there.
If
you
have
suggestions
or
concerns,
is
there
anybody
who
did
not
speak
up
on
this
issue
very
quickly?
Who
wants
to
speak
up
now?
D
Okay,
I
have
a
comment
here:
I
think
you
know
for
the
event
the
destination
or
not
should
not
be
part
of
it,
because
but
the
source
I
think
you
know
either
in
the
metadata
or
in
the
event,
data
itself,
I
think
most
partly
in
the
metadata,
because
the
source
is
not
just
the
use
for
routing
purpose.
They
could
also
be
used
for
correlation
purpose.
For
example,
in
some
scenario
we
might
need
to
correlate.
You
know
event
from
different
sources
to
trigger
action.
Now.
How
do
we
do
that?
E
A
F
A
G
A
A
K
F
Informed
informed
by
reading
this
and
some
other
comments.
This
is
why
I
filed
the
issue
where
I
put
in
a
straw,
man
for
HTP
before
an
HTTP
binding,
just
basically
for
having
a
visual
that
people
can't
see
without
this
tonight.
Oh
this
might
end
up
mapping
without
this
being
even
a
serious
proposal.
But
since
the
current
the
current
definitions,
fairly
abstract,
it
may
make
sense
for
people
to
go
and
take
a
look
at
that
issue
and
see
how
things
may
go
and
project
out
to
a
protocol
that
yeah.
K
F
Called
soul,
yeah
he's
so
good
know
about
it.
There's
a
large
body
of
work
we
can
draw
on
and-
and
it's
not
clear
to
me-
that
we
really
need
to
go
and
retrieve
any
any
of
that,
but
rather
go
and
take
learnings
from
it.
And
some
of
the
folks
here
on
this
in
this
group
may
be
familiar
with
it
and
trying
to
build
the
minimal
thing
that
gets
us
to
success
rum
and
try
to
boil
the
ocean
yet
again,
because
we
know
how
that
winds,
I,
don't.
H
A
K
This
came
out
of
a
brainstorm
with
Austin
and
me
a
while
back
where
we
we
haven't
actually
done
what
was
like
I,
we
said,
had
like
sort
of
a
direction
of
what
we
wanted
to
do
every
month,
but
that
it
by
separating
it
into
kind
of
numbered
milestones.
Then
we
we
can,
you
know,
sort
of
make
progress
without
getting
you
know,
updating
it
all
the
time
of
the
dates,
and
so
this
was
an
attempt
to
separate
things
into
logical
chunks
without
bringing
up
anything
particularly
too
contentious
and
I
can
talk
through
it
or
I.
G
B
Want
one
quick
comment:
there's
some
additional
items
below
at
the
bottom
that
aren't
really
put
into
versions,
perhaps
actually
putting
those
back
and
do
into
the
versions
might
just
help
ensure
those
get
done
at
a
reasonable
time
and
assign
them
to
different
people.
So
all
of
them
I
think
are
somewhat
still
pressing
like
you're.
Getting
our
website
up
and
whatnot,
so
I
mean.
B
A
K
A
All
right,
not
here,
it's
cool,
thank
you
Sara,
all
right,
next,
all
right!
So
where
is
it?
Okay,
yeah
things
keep
moving
in
and
out
of
here?
Okay.
So
what
is
source
last
week,
I
believe
regional
suggested
that
we
have
people
give
sort
of
presentations
or
lead
a
discussion
from
their
point
of
view
in
terms
of
what
is
source
I
know.
H
F
A
A
I
A
F
The
string,
tock
tick,
tock,
Casey,
yes,
okay,
great
so
I'm,
going
to
give
you
an
example
from
industrial
automation
on
on
source
and
how
that's
actually
extracting
the
typical.
So
here's
a
typical
flow
we
have
to
device
the
device
raise
an
alarm
that
goes
to
some
distribute
this
event
distributor
and
it's
middleware
that
we
build
you
build
and
then
it
goes
into
gets,
pushed
towards
handlers
or
local
balancer
gets
executed.
So
that's
kind
of
the
typical
flow
that
I
think
most
of
our
platforms
do
and
now
I'm,
going
to
double
click.
F
There
is
no
path
back
to
that
robot
and
if
you
double
click
on
this
you'll
find
that
internet
robot,
you'll
have
particular
sensors
and,
let's
say
what's
broken
here-
is
actually
not
the
robot
per
se.
But
there's
a
sensor,
that's
broken
and
the
sensors
are
actually
are
smart
about
it
and
can
tell
you
when
they
are
no
longer
properly
calibrated
or
if
they're
broken.
So
now,
a
rat
a
sensor
raise
an
alarm
that
goes
out
to
an
OPC
UA
server.
The
OPC
UA
server
alerts.
Message.
Writer
push
that
out.
F
The
event
that
we're
talking
about
here
is
actually
written
on
that
in
that
OPC.
Ua
server
then
goes
to
the
operator
system,
which
may
run
the
Oracle
cloud,
which
then
gets
routed
into
the
plant
integrator
system,
which
goes
away,
which
may
run
an
AWS
which
may
go
run
to
the
machine
manufacturer
system
which
most
of
the
component
manufacturer
system.
That
is
actually
only
that
safe
sensor,
which
wants
to
do
once
the
catch
the
alert
and
then
send
out
a
wrap.
F
There
is
a
way
that
that
consumer
can
talk
back
on
or
you
can
identify
with
a
network
address
that
particular
sensor,
but
it
can
do
that,
however,
is
it
can
go
and
identify
that
using
an
abstract
address.
So
what
we're
doing,
for
instance,
in
ATP
that
I'm
involved
in
as
the
co-chair
of
the
Oasis
P
committee,
we
have
an
ATP,
a
notion
of
routing
addresses
or
of
source
identifiers,
and
those
are
fully
abstract.
F
You
can
make
them
addresses
that
you
can
resolve,
but
generally
our
attitude
in
nqp
as
a
messaging
protocol
is
to
not
interpret
the
the
our
addressing
fields,
whether
they
may
be
the
no
indicating
with
the
sources
or
what
this
nation
is,
but
rather
treat
them
as
aspect
strings
and
then
leave
its
rules
in
the
middle
of
where
to
go
and
evaluate.
Those.
So
point
is
even
if
the
consumer
has
the
need
to
communicate
back
to
the
vendor
of
an
event
the
event
source
identifier.
F
What
we
have
no
help,
if
interpreted
as
a
network
address
particular
in
these
scenarios
and
the
source
may
for
trivial
scenarios
being
network
resolved
dress.
You
can't
do
that,
but
often
it
will
be
an
abstract
identifier,
because
there's
plenty
of
scenarios
that
exists
where
the
emitter
of
the
events
itself
is
identifiable,
but
it's
not
a
neck
network
routable
entity.
So
so
the
result
of
all
this
is
that
the
source
identifier
should
be
where
the
source
should
be
a
string
that
can
hold
some
information
that
is
appropriate
for
the
source,
and
it
should
be
your
eye.
A
A
D
D
Okay,
I
do
not
have
the
slice
tool,
but
I
okay,
I
can
I
try
to
describe
it
so
for
like
for
IOT
cases
right,
you
are
going
to
have
some
camera
capture
the
some
information,
for
example,
some
motion
picture,
and
so
that
camera
will
be
okay
and
then
you
know
you
might
have
some
other
sensors
capture
other
information,
for
example,
some
window
open
events
when
the
open
events
they
might
need
to
correlate
them
together
to
know
okay,
which,
let
me
say
you
know
which
windows
which
who
the
opening
event
will
correct,
which
you
know
camera
right,
don't
want.
D
You
know
like,
for
example,
Sarah's
house
camera
to
be
on
the
event
to
relate
it
to
Cathy's.
You
know
window
opening
right,
so
the
I
think
it's
important
to
have
that
source
information
and
that
would
be
a
unique
identifier
will
not
be
like
any
IP
address.
Yeah,
that's
my
point.
So
I
think
you
know
the
source
how
we
define
the
source
is
important
in
in
this
use
case.
Okay,.
A
A
G
Question
for
cast
on
her
example:
I'm
sorry
go
ahead,
then.
Yes,
the
the
example
you
gave
where
there's
a
sensor
inside
a
house
that-
and
you
want
to
do
that
kind
of
correlation-
almost
implies
some
kind
of
hierarchy
to
the
source.
Is
that
implication,
intentional
and
part
of
what
you
would
want
to
describe
as
as
should
be
in
that
source
or
know
that
you
don't
need
it.
You
don't
mean
to
explicitly
describe
some
sort
of
hierarchy
as
the
source
field.
D
I
I
do
not
have
the
intention
to
like
you
know
the
hierarchy
of
the
other
events,
I'm,
not
sure
whether
I
understand
your
question
correctly.
I
think
you
know
we
need
some.
This
is
a
use
case.
I
think
there
are
many
scenarios
case.
As
far
as
we
need
to
the
you
know,
it's
multiple
events
correlation
to
trigger
a
function.
D
G
D
I'm
not
I,
think
we
need
another
field
in
in
addition
to
the
source,
you
are
a
unique
identifier.
We
need
another
field
because
the
source
you
are
I
could
be
a
string
that
could
be
have
you
know
quite
some
information
inside
it.
We
need
to
know
how
to
identify
the
information
for
to
correlate
this
event
together.
So
I
think
I'm
I'm,
going
to
present
next
I'm
gonna
write
some
try
to
present
about
that.
All.
A
E
A
E
Think
Sarah
made
a
good
point
because
I
think
when
we
say
event,
we
don't
all
mean
the
same
thing,
so
at
least
I
want
to
try
and
clarify
you
know.
I
know
all
those
details
about
exactly
the
structure
of
value.
T
sensor
is
sending
the
message.
Those
are
the
kind
of
things
I
want
to
try
and
stay
away
from,
because
there
are
endless
amount
of
use
cases.
I
think
the
scope
that
I'm
trying
to
figure
out
this.
Let's
assume
there
is
a
skank
schema
and
there
is
a
message
which
is
defined
somewhere
else.
E
Okay,
how
do
we
transfer
that
from
a
certain
source
service?
And
yes,
there
are
multiple
definitions
of
a
source
we'll
get
to
that
to
some
function
or
another
micro
service
that
consumes
that
and
first
we
need
to
understand
that
there
are
two
types
of
events:
I
separate
them:
external
events
and
internal
events.
In
some
cases,
their
platform
events,
for
example,
Google
Cloud,
the
Amazon
Cloud-
will
have
a
notification,
all
notification
you're,
not
even
aware
of
the
messaging
protocol
or
the
messaging
envelope.
Okay.
But
when
you
have
external
events,
then
those
events
have
several
elements.
E
One
is
the
message
body,
which
is
this
thing
that
was
stand
by
the
IOT
sensor
or
by
the
camera,
etc.
There
is
an
envelope
that
the
finite
things
like,
where
is
it
destined
to?
Where
did
it,
came
from
what
schema?
What's
the
content
type
to
decipher
it
etc?
And
then
there
is
another
protocol
that
this
thing
sits
on
top
of
it,
and
it
needs
to
be
some
translation
between
how
this
envelope
and
body
are
mapped
to
specific
implementations
of
protocol,
but
it's
HTTP
or
AMQP
or
Kafka,
whatever
okay,
I,
think.
E
The
scope
of
what
we're
trying
to
do
is
there's
also
another
higher-level
thing
that
I
wrote
out
of
scope,
which
is
how
do
I
orchestrated
a
certain
sensor,
will
send
all
its
data
to
a
certain
function.
Let's
leave
it
in
a
web
tool,
too
much
complexity
by
anyway.
So
the
first
thing
is
the
event.
Api
is
like
how
the
consumer
consume
the
event,
because
in
some
cases
the
event
won't
even
have
a
message
body
an
envelope
and
that's
something
that
probably
different
languages
will
have
different
implementation,
because
some
languages
are
typed.
Some
are
untyped.
E
It's
not
that
easy
to
say:
I
have
a
scheme
I
want
my
service
framework
to
decipher
my
schema,
because
if
it's
a
go
program
or
receive
program,
that
means
at
that
point
that
the
runtime
engine
needs
to
know
all
the
schemas
in
the
world
to
be
able
to
decipher
them.
So
we'll
talk
about
that
and
then
the
second
thing
that
we
need
to
define
is
serve
the
message
taking
it
forgetting
about
the
protocol
for
a
minute.
E
It's
just
the
body
and
the
envelope,
and
the
third
thing
is
to
have
some
concrete
implementation,
we'll
need
to
say
how
those
body,
an
envelope
map
to
specific,
widely
adopted
transports
and
and
I
think
they
deserve
a
little
more
discussion.
But
that's
the
problem
I'm
trying
to
solve
I'm,
not
trying
to
solve
the
how
specific
message
for
an
IOT
device
or
for
some
other
thing
is
now
defined
or
many
committees
that
can
do
that.
E
Just
the
problem
that
I'm
trying
to
solve
is
this
one
I,
don't
think
any
of
you
have
seen
that
I
published
it
once
this
is
when
you're
in
in
Amazon
lambda,
and
you
want
to
figure
out
where
what
kind
of
event
you're
handling.
This
is
what
you
need
to
do.
Okay,
so
I
want
us
to
be
a
very
specific
of
when
the
function
is
invoked.
I
know
where
is
it
coming
from
I
know?
E
What's
the
schema
that
I
need
to
interpret
without
trying
to
poke
into
all
those
his
lectures
and
when,
when
I
say
events,
the
reason
I'm
so
focused
on
not
just
JSON
is
because
events
can
come
in
different
forms.
The
camera
may
send
the
actual
picture
which
son
had
read
on
top
of
it
and
want
to
push
it
along.
It
doesn't
necessarily
have
to
be
textual.
An
IOT
sensor
may
I
may
actually
throw
its
information
in
a
binary
format
for
an
mqtt
protocol.
E
Okay
or
people
for
a
sake
of
efficiency
may
choose
something
like
robot
for
a
bro
or
flat
buff
or
you
know,
I
knew
some
messaging
systems
like
Africa,
etc,
and
we
may
have
to
encapsulate
the
existing
events
into
that
as
well.
So
those
are
just
use
cases.
I've
tried
to
show
that
it's
not
that
simple,
that
we
can
take
everything
in
a
JSON
structure.
You
know
we'd
like
a
header
and
throw
it
away
across
the
world,
so
we
have
to
think
about
those
use
cases
as
well.
E
You
know
just
a
very
abstract
way
for
me
to
think
about
an
API
and-
and
it's
not
complete,
just
as
a
high-level.
This
is
our
serve
go
going
to
face
when
I'm
consuming
lis.
That
I
do
want
to
go
through
interfaces
and
don't
necessarily
want
to
go
through.
Like
here's
already,
a
DC
realized
object.
I
want
to
be
able
to
consume
about
the
message,
either
as
a
body
and
then
I
don't
care
about
the
actual
schema.
E
You
know
maybe
I'm
just
a
router
that
affords
that
from
one
half
to
another
I,
don't
really
care
about
the
schema
or
maybe
I
need
to
I
want
to
go
by
field
and
then
I
serve
one
system
to
decipher
that
that,
for
me
and
and
all
those
headers
I
can
just
go
and
access
them
through
a
map.
So
that
helps
me
in
terms
of
flexibility.
E
A
Cool
and
but
that
is
unfortunately,
we
are
out
of
time,
so
we
have
to
save
questions
on
your
own
stuff
till
the
next
week,
because
I
do
want
to
be
respectful
people's
time.
Most
people
do
have
phone
calls
or
other
things
to
do
at
the
top
of
the
hour.
So
let
me
just
quickly
get
the
last
people
on
the
agenda
or
for
the
attendance
David
Lyle.
Are
you
there?
Yes,
I'm.