►
From YouTube: CNCF Serverless WG Meeting - 2018-11-01
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
A
A
B
A
A
Now
the
interesting
thing
is
we'll
talk
a
little
bit
more
about
this
later
is
we
talked
about
doing
our
trying
to
get
out
0.24
Seattle,
which
basically
leaves
us
three
phone
calls
to
resolve
any
0.2
issues.
So
keep
that
in
mind
as
we
go
forward?
Okay,
but
in
four
months,
of
course,
at
any
objection,
then,
to
this
being
our
schedule
for
canceling
calls
and
if
not
that'll,
make
the
approach
I'll
take
the
appropriate
actions
to
get
cancellation
notices,
sent
out
and
send
out
a
note
stuff
like
that,
but
any
objection
to
the
schedule.
A
Objection
all
right
cool.
Thank
you
guys,
all
right
community
time.
All
right
is
there.
Anybody
on
the
call
new
to
the
community
who
would
like
to
bring
up
a
topic
that
they
would
like
to
discuss.
This
is
typically
for
time,
a
type
of
people
who
are
we're
not
normally
part
of
the
working
group,
and
there
is
not
an
agenda
item
for
the
topic
they
would
like
to
discuss.
A
All
right
cool
you're,
not
hearing
any,
we
all
keep
moving
forward.
Then.
Oh
all
right.
Moving
forward.
Okay,
SDK
work
group,
so
Austin
you're
on
the
call
here,
but
let
me
just
say
what
happened
offline
so
I
did
I'm
down
Austin.
Currently
he
decided
to
take
some
vacation
shocking,
but
because
of
his
work
schedule
come
on
here
Austin.
You
want
me
to
at
least
set
up
the
meetings
for
the
SDK
calls
going
forward
and
what
I
was
thinking
about
doing
was
rather
than
sitting
at
the
doodle
poll
and
wasting
time
going
to
that
process.
A
A
Okay,
we'll
do
that.
Thank
you
guys,
so
I'll
send
out
meeting
notices
to
the
whole
group.
So
just
myself
and
look
for
those
so
in
terms
of
SDK
work,
honestly
I'm,
a
little
worried
I
know
that
the
goaline
guys
of
the
Galang
one
from
VMware,
looks
fairly
complete
at
least
there's
code
out
there,
I
haven't
seen
anybody
asking
for
access
to
any
of
the
repos.
So
please
be
thinking
about
that,
because
next
Tuesday
is
called.
A
A
D
Are
our
company
has
been
doing
a
lot
of
work
on
this
and
we've
baked
it
all
into
the
next
version
of
our
service
framework
product
and
there's
some
great
stuff
that
we've
done
and
we've
definitely
invested
a
lot
in
this
direction?
We
just
have
to
put
that
into
an
SDK
and
put
that
in
the
in
submit
that
to
the
push
that
to
the
repo,
but
just
want
to
put
that
out
there
in
case
anyone
else
is
working
on
any
flavors,
any
JavaScript
flavors
of
the
SDK.
But
we've
we've
done
some
pretty
good
work
here.
D
E
Awesome
I.
Well
let
me
first
date:
I,
don't
want
to
go
too
deep
in
terms
of
SDK,
since
we
have
other
meetings
for
this,
but
it
would
be
great
if
we
started
to
think
about
what
are
the
feature
sets.
You
know
the
high
level
that
each
of
the
SDKs
is
providing.
You
know
around
versioning
or
or
ways
in
which
it
deals
with
the
data
data,
payloads,
etc.
We
should
understand
what
those
feature
sets
look
like,
so
that
we
can
rationalize
what
are
the
features
of
each
of
the
SDKs
and
of
the
language.
D
D
You
know,
as
the
SDK
calls
become
a
recurring
thing,
I
recommend
at
least
using
that
as
a
starting
point,
because
we
establish
some
pretty
good
alignment
there
and
I
think
that
the
go
version
was
actually
following
that
now,
of
course,
our
you
know.
On
our
side,
we've
been
trying
to
follow
that
as
well,
while
also
trying
to
focus
on
features
that
help
meet
our
company's
priorities
and
I
think
that's
kind
of
where
we
left
off
on
those
SDK
calls.
It
was
hey.
Look.
D
E
D
B
Yeah
since
I
normally
are
us
for
the
a
sharp
flavor
of
this
I
had
a
conversation
with
our
engineering
team
last
week
when
I
was
in
Redmond,
and
it's
just
for
us
just
a
schedule
I'm
in
thing
nuts
willingness
to
do
the
work
so
I'm
gonna
try
to
make
that
happen
within
relatively
short
time.
Cool
sounds
good.
Thank
you.
A
Excellent
cool,
thank
you
guys
all
right
moving
forward,
then
Kathy
I
don't
see.
Okay,
I,
don't
see
Kathy
on
the
call,
but
I
don't
think
anything's
happened
with
the
work
flow
subgroup,
so
I
don't
think,
has
anything
to
update
their
coop
concessions,
so
I
actually
I
think
I
could
probably
delete
this
link.
The
slides
are
out
there.
Clemens
Kathy
myself
been
working
on
it.
The
slide
link
right
here.
A
Please
take
a
look
at
you
if
you're
interested
there's
an
intro
and
a
deep
dive
session
we'll
be
presenting
at
if
you
have
any
feedback
commentary
on
the
slides,
please
let
us
know
relatively
soon
I
believe
officially
we're
supposed
to
submit
the
charts
by
tomorrow.
That
date
is
it's
kind
of
important
for
just
the
Shanghai
one
in
particular,
because
they're
gonna
be
doing
translation
on
the
slides
in
advance
into
Chinese.
A
B
A
That's
good
yeah
I
wasn't
sure
whether
they
were
gonna
translate
speaker
notes
or
not
so
I
figure,
it's
probably
save
us
or
just
stick
it
inside
the
slides,
like
you
did
so
that's
good
now,
since
Cathy
isn't
on
the
call
and
Clemens
you're
technically
a
vacation,
we're
supposed
to
a
phone
call
right
after
this
one
to
continue
discussions
about
it,
but
come
as
I
assume
you're
not
going
to
make
it.
If
Cathy
does
not
join,
then
there
will
be
no
phone
call
for
anybody
else.
That
was
thinking
about
joining
that
call.
A
So
it
all
depends
whether
Cathy
makes
it
or
not.
You
know
just
give
you
guys
the
heads
up
all
right,
kook
on
Seattle
I
have
a
feeling.
Most
of
us
probably
gonna,
be
really
really
busy,
but
I
thought
I'd.
Ask
the
question
anyway.
Do
we
want
to
try
to
have
a
formal
working
group
meeting
during
Kuk
on
Seattle?
We
will
have
an
intro
and
a
deep
dive
session
there.
But
do
you
guys
want
to
have
a
real
working
group
meeting.
A
Anybody
had
any
desire
to
try
to
set
one
up:
okay,
I'm,
not
hearing
any
I,
don't
think
we
have
any
really
large
issues
to
discuss
so
I.
Don't
think
it
warrants
a
face-to-face
for
that
purpose,
but
not
hearing
anybody
really
jumping
up
and
down
for
it.
I'm
gonna
assume
that
well,
we
will
not
have
one
if
everybody
works.
E
A
Basically
a
sentence
is
going
to
be
picked
at
random,
with
some
missing
words
like
nouns
verbs
adverbs
send
out
an
event
to
all
the
nodes,
saying.
Basically,
what
kind
of
words
are
missing?
Those
guys
are
falling
back
with
the
words
they
randomly
chose
and
then
the
the
controllers
I'm
calling
it
will
sort
of
display
the
sentence
with
all
the
words
filled
in
and
hopefully,
they'll
be
funny
from
me
from
a
technical
perspective,
all
we're
really
looking
at
is
for
the
nodes
or
its
company
wants
participate.
A
All
they
really
need
to
do
is
create
a
function
that
just
picks
a
random
word.
We
do
have
a
list
of
words
available.
It's
easily
downloadable,
and
it
has
you,
know
nouns
adverbs
everything
in
there,
so
really
all
you
can
to
do
is
generate
a
random
number
and
index
into
the
array.
For
that
type
of
word,
it
should
be
really
really
easy
for
just
about
anybody
to
join
and
participate.
A
I
do
have
an
intern
working
on
the
actual
UI
piece
of
this
itself.
I
could
show
you
guys
that
if
you're
interested
it's
as
of
right
now,
it's
this
is
two
or
three
I.
Think
it's
three.
It's
something
similar
to
this
we're
not.
He
needs
to
work
on
it,
but
it's
basically
gonna
be
a
little
bit
graphical
things
moving
back
and
forth,
so
it's
not
as
boring
as
just
showing
sentences
and
stuff,
but
that's
the
current
thought
process.
More
work
needs
to
go
on.
A
You
need
to
be
done
in
the
UI,
but
everything
is
dynamic,
so
people
can
easily
join
at
the
last
minute.
How
we
need
is
their
icon
to
display
their
bubble
or
their
circle,
but
that's
the
current
plan
going
forward.
If
you
have
any
suggestions
or
comments,
you
want
to
do,
or
you
want
to
make
just
mention
it
on
the
cloud
Interop
select
slack
channel,
that's
what
mostly
discussions
will
be
happening.
A
Okay,
any
questions
or
comments
on
that
we
were
originally.
We
were
talking
about
doing
this
in
time
for
cupric
on
Seattle,
but
given
the
how
easy
or
lightweight
it
should
be,
for
people
to
create
a
function
to
just
basically
generate
a
random
number,
it
would
be
really
nice
if
we
could
actually
get
this
going
in
time
for
Shanghai
I
would
love
the
dough.
B
A
B
G
B
A
A
A
A
A
A
Okay,
anybody
else
have
any
questions
or
comments
on
this
side.
I
definitely
don't
want
to
rush
it,
but
at
the
same
time,
if
no
one
thinks
that
they're
worthy
of
keeping
open-
and
we
always
can't
reopen
them
if
we
really
want
to.
But
if
you
need
more
time
or
want
more
time
to
speak
up,
I'm
gonna
ask
if
we
can
close
them
all.
A
A
A
Don't
think,
there's
anything
semantically
different
about
his
original
PR
versus,
what's
in
there
right
now,
but
because
the
changes
were
made
over
the
over
within
the
last
day
or
so,
I
did
want
to
get
people
a
chance
just
to
do
a
quick
review
of
it
and
raise
any
concerns
if
they
have
just
before
I
merged
it.
So
has
anybody
taking
a
look
at
this
and
have
any
concerns
about
the
merging
just
want
to
give
people
one
last
chance.
J
A
I,
don't
believe
Fabio
is
on
the
call,
but
this
PR
has
been
out
there
for
a
little
bit.
I
think
he
made
a
very
minor
change
just
the
other
day,
but
I
don't
think
it
was
really
significant
hide
some
of
this
stuff
here.
So
he
made
a
minor
change
to
our
examples.
Basically,
what
he
want
to
do
is
to
show
real.
You
are
eyes
in
there
because
I
don't
think
our
example
is
actually
using
a
real
URI
and
then
the
source
he
actually
put
a
real
URI,
because
this
is
not
a
real
one.
K
A
K
A
All
right
cool,
thank
you
guys.
Next,
the
versioning
scheme
for
our
specs,
this
one's
been
out
there
for
a
little
while
I
think
people
wanted
a
little
bit
more
time
to
think
about
it.
Are
there
any
new
questions
or
comments
about
it?
I,
don't
think
I've
changed
it
for
at
least
two
weeks
or
so
I
think.
A
What
I
ended
up
doing
was
going
through
all
open
issues
and
pull
requests
or
actually
issues.
I
should
say
all
the
requests
are
gonna
get
in
whenever
they
get
in
for
the
issues,
I
went
through
and
tried
to
take
a
guess
as
to
whether
I
thought
that
they
were
significant
design
decisions
that
need
to
be
made,
but
for
that
particular
issue
or
whether
they're
minor
minor
type
of
clarification,
kind
of
things
and
so
I
went
through
all
open
issues
and
if
I
thought
it
would
be
needed
to
be
about.
A
If
it
was
a
major
design
decision,
then
they
would
a
good
candidate
for
zero-point-two,
because
our
roadmap
40.2
basically
says
all
major
design
decisions,
except
for
security
related
ones,
and
this
is
basically
the
list
that
I
came
up
with
right
here.
So
what
I
wanted
to
do
was
first
ask
if
anybody
had
a
chance
to
look
through
the
issues
themselves
or
to
look
at
my
analysis
to
see
if
they
thought
I,
either
added
some
finishing
or
miss
something
along
the
way.
Basically,
does
anybody
want
to
make
any
changes
to
this
list.
A
Okay,
I'm
not
hearing
any
in
that
case
I'm,
going
to
assume
that
this
list
is
at
least
a
good
starting
point.
We
can
obviously
change
it
as
we
keep
moving
forward
over
the
next
couple
weeks.
The
I
would
I
did
it
that
before
the
call
is
I
actually
classified
these
or
group
them
a
little.
The
first
two
actually
are
PRS
that
are
already
out
there,
which
have
now,
basically,
both
been
approved.
So
we
can
skip
those
these
next
three
are
kind
of
interesting
Clemons.
A
These
are
late,
okay,
so
Clemons
these
next
three
are
abouts
our
data
model
and,
in
particular,
they're
very,
very
focused
on
the
data
attribute
itself.
I
was
wondering
if
you
could
take
a
look
at
these
three
in
bulk
when
you
get
a
chance,
because
I
think
that's
kind
of
important
thing
to
get
right
to
make
sure
there
isn't
a
confusion
around
what's
allowable
inside
the
data.
Okay,
okay,.
A
A
So,
let's,
why
could
these
one
at
a
time
Jim
I,
believe
you're
on
the
call?
This
is
one
that
you
opened
up.
I
was
wondering
if
you'd
be
willing
to
drive
this
one
forward,
perhaps
maybe
generate
a
PR
to
force
the
discussion
and
just
pick
a
direction
based
upon
your
preference
or
comments
in
there.
I'd.
L
L
A
So,
given
how
quickly
flew
through
the
agenda-
and
we
have
35
minutes
left-
let's,
let's
do
this-
why
don't
you
talk
to
the
polls
are
very
quickly
and
let's
just
see
what
the
sense
of
the
group
is
at
least
for
the
people
on
the
call,
and
that
may
give
you
a
sense
of
which
direction
your
PR
should
go.
Sure.
L
I'm
and
my
original
drive
for
this
was
a
comment,
I
believe
somebody
from
AWS
quite
a
few
calls
ago,
and
that
caused
me
to
look
at
the
current
definition
and
we
seem
to
just
not
be
very
consistent
in
the
way
that
some
of
the
context
items
were
named.
So
you
know
a
more
a
wse
style
approach
would
be
to
sort
of
drop.
The
word
event
from
everything,
because
we
know
we're
talking
about
an
event
we're
actually
in
an
event,
so
it's
already
contextualized.
L
M
L
A
D
D
A
D
A
Believe
we
have
at
this
point
in
time
now
that
might
be
a
good
thing
to
have
so.
Okay,
I'll,
raise
my
hand
speaking,
that
is
moderator.
Group
I,
definitely
agree
with
everybody's
idea
that
shorter
is
better
and
if
these
things
were
already
contextualized
and
from
that
perspective,
I
do
like
option
one.
A
However,
what
concern
to
me
is
that
when
we
start
talking
about
extensions,
we
ask
people
to
give
a
a
descriptive
name
for
their
extension
to
avoid
the
risk
of
it
being
overlapping
with
something
else
going
forward
and
when
I
start
thinking
about
some
of
our
things
or
buy
some
of
our
properties
like
say,
ID,
right
or
even
version
or
type
or
whatever
I
think
we
should
have.
We
should
be
forced
to
follow
the
same
rule
as
extension
authors,
because
I
don't
think
lesion
as
they
treat
ourselves
is
special.
A
So
when
I
see
something
like
ID,
it's
like
well,
what
is
it
the
ID
of
and
I
guess
when
I
get
a
little
worried
right?
So,
for
example,
if
someone
else
decides
that
an
extension
with
their
own
ID,
they're
gonna,
follow
it
foo
ID
or
something
like
that
right.
So
they're
gonna
see
or
two
things
in
the
message:
foo
and
I'm
sorry
fill
ID
and
ID.
A
That
doesn't
seem
as
descriptive
to
me
and
useful
as
event
ID
versus
foo
ID,
and
so
from
that
perspective,
I
tend
to
prefer
adding
the
word
event
in
front
of
everything.
Just
so
it's
a
little
bit
more
descriptive.
I
could
go
technically
other
way,
but
I
have
a
slight
preference
for
adding
the
word
event
in
front
of
everything.
I
just
want
to
put
that
out
there,
but
anyway,
anyway,
anybody.
L
Else
have
any
comments,
so
my
only
other
observation
is
recently
we
decided
to
adopt.
Did
we
all
vote
for
lower
lower
case
only
or
lower
case
yeah?
We
just
to
prove
that
a
lower
case
right
so
again,
you
know
this
is
a
very
personal
thing.
You
know
so,
presumably
you
know
this
event
type
would
all
be
in
lower
case
yeah.
So
that's
three.
What
were
what
the
proposal
would
be
in
that
situation
right
nor
case
T
on
this
one?
Yes,.
N
This
is
lada
Mira
I
have
one
comment
regarding
the
naming
in
the
past.
I
have
been
forced
to
use
a
scheme
that
followed
the
pattern
like
where
we
add
events
in
front
of
everything,
and
sometimes
one
emerges
the
definition
from
several
things.
So
then
becomes
a
pattern,
a
+
pattern,
B
plus
pattern
C
and
then
the
actual
name
of
the
thing,
and
it
become
very
tedious
to
use
some
kind
of
in
the
favor
of
the
shorter
version,
like
type
version
IB
and
time.
N
J
It's
a
bit
of
a
contextual
argument
because
not
to
overload
the
context
too
much,
but
if
we
are
in
the
context
of
acquired
event,
we
know
that
it's
type
version
etc.
If
we're
flattening,
then
we
want
to
push
that
context
down
into
the
name
of
the
field
and
then
in
other
specs,
you
see
that
kind
of
reserved
reserved
field
sometimes
start
with
an
underscore
or
something
like
that
to
imply
that
they
they
have
some
kind
of
namespace
separation
I'm
in
favor
of
shortening.
J
O
O
Yeah,
so
as
a
spec,
are
we
not
the
things
explicitly
pulled
out,
I
suppose
not
inherently
special
in
some
way
where
they
could
avoid
having
the
event
I
mean
favor
the
first
one
I
knowledge
that
that's
not
what
we're
asking
other
people
local
extensions
to
do.
The
underscore
might
be
an
option,
but
I
feel
like
what
to
call
that
respect
is
inherently
special.
A
D
Still
in
favor
of
the
the
first
one,
the
shorter,
if
I'm,
a
developer,
looking
looking
for
the
tool
that
I'm
gonna
use-
simplicity,
always
appeals
to
be
you
know,
above
all
and
also
I
think
is,
the
emphasis
should
could
I
think
should
probably
be
on
documentation.
I'm,
just
you
know,
I,
don't
think
we
need
to
establish,
in
my
opinion,
I
think
we
need
strong
patterns
here
or
to
kind
of
over
engineer
some
patterns
to
how
we
do
the
key
teams.
D
As
long
as
we
have
great
documentation
that
just
says
exactly
exactly
which
each
one
of
these
is,
except
for
the
one
one
thing
I
feel
is
if
I'm
a
developer
I'm
just
jumbling
across
this
I.
Just
look
at
the
word
version,
I'm
gonna
think
that
that's
the
event
type
version
and
not
and
not
the
cloud
events
version
so.
D
A
A
It's
kind
of
up
to
you
and
how
you
want
to
move
forward.
You
could
choose
to
open
to
PR,
so
people
can
look
at
both
options
or
you
could
just
choose
one
of
the
options
and
open
a
PR
for
that.
It's
kind
of
up
to
you,
I
have
a
feeling
that
one
PR
with
a
choice
might
be
better
just
from
a
process
perspective,
but
it
is
completely
up
to
you
from.
L
D
Have
one
other
one
of
the
comment
on
this?
Well,
it's
actually
on
versioning
and
I've
been
doing
so
much
context.
Switching
and
I'm
in
the
car
right
now
heading
to
a
meeting,
so
I
can't
actually
look
at
the
spec,
but
when
we
settled
on
versioning
on
how
to
do
a
bent
type
versioning,
do
we
settle
on
a
specific
format?
Are
we
forcing
like
a
specific
versioning
format?
There?
Are
we
letting
it
letting
the
user
decide
I
believe.
A
D
Well,
I'll
throw
out
this
suggestion
you
may
have
discussed
into
passing.
I
can't
remember,
but
is
there
a
possibility
that
if
we
settled
on
like
a
strict
way
of
versioning,
we
invent
types,
we
could
actually
have
a
space
in
that
version
number
for
the
cloud
event
specification
so,
like
you
know,
like
thinking
of
semantic
version,
versioning
are
where
there's
just
like
three
different
spaces
for
versions.
We
can
have
the
initial
space
always
indicate
the
version
of
the
cloud
event
spec
and
then
everything
that
perhaps
follows.
D
That
could
be
the
version
of
the
event
type
to
consolidate
these
things
into
one
single
version.
It
seems
like
the
version
of
the
event
type
as
well
as
the
cloud
event
specification
version
are,
should
be
considered
together
and,
along
with
the
actual
event
type
together.
That's
what
that's!
What
the
total
schema
actually
looks
like
so
there's
doing
that
out
there
having
haven't
thought
it
through
but
curious
what
you?
What
y'all
think.
L
D
D
So,
but
we
have
two
versions.
Of
course
we
have
the
cloud
event
specification
version
which
is
all
about
the
metadata.
Then
we
have
a
version
of
the
actual
event.
Time
schema
and
I.
Think
these
things
perhaps
could
be
designed
with
a
clever
single
versioning
implemented,
but
we'd
have
to
get
strict
and,
of
course,
people
to
use
that
which
might
might
be
good,
not
sure.
A
D
P
I
wanted
to
comment
comment
on
that.
I.
Think
the
reasoning
for
dropping
the
event
type
version
was
very
solid.
Female
start
talking
about
how
yes,
7th
evolution
or
a
data
evolution
would
be
is
a
big
thing,
but
the
only
situation
where
you
would
actually
change
that
urging
number
is,
if
you
make
breaking
changes
and
then
you
might
as
well
change
the
Evan
type
anyway,
and
that
was
a
very
good
point
in
my
opinion,
for
why
the
Emmett
type
version
is
not
needed.
D
P
What
well
yes,
the
point
was
that
if
you
are
making
a
breaking
change
that
the
the
event
type
version
field
doesn't
serve
any
purpose
as
you
might
as
well
change
the
Eventide
string,
but
I
think
that
precludes
making
a
complex
versioning
scheme.
That
includes
an
event
type
version,
because
it's
already
there
in.
A
Yeah,
and
not
only
that
I
think
I
think
we
also
looked
at
the
schema
URL.
Excuse
me
as
an
example
of
why
you
could
put
it
both
into
one
because
many
times
the
schema
URL
expresses
not
just
the
type
of
data
you're
looking
at,
but
the
version
of
that
type
of
data.
It's
indeed,
usually
the
version
strings
encoded
in
there
as
a
date
there.
Something
like
that.
D
We
we
dug
into
this
for
a
long
time
how
about
I
just
put
out
a
PR
quickly
and
if
it's
interesting,
we
could
discuss
it,
consider
it.
You
know,
if
not,
let's,
just
let's
just
before
you
get
this
thing
stable,
so
we
can
start
building
back
that
you
system
around
there,
which
I
think
is
the
ultimate
bigger
priority.
Yep.
K
D
A
I
Well,
I
think
it
was
at
coop,
Corning
and
Copenhagen,
and
we
had
an
idea
of
having
multiple
property
back,
so
one
for
annotations
being
added
by
routing
an
event
and
and
one
for
the
initial
extensions.
So
that
was
just
that.
What
we
discussed
back
in
May
and
so
I
was
when
we
were
discussing
now
extensions
being
top-level
attributes.
A
Okay,
I
tend
to
think
of
middleware
is
nothing
more
than
another
event
source
in
a
sense
or
an
event
producer.
So
whether
a
piece
of
middleware
adds
another
attribute,
that's
perfectly
fine,
you
can
add
it,
but
we
don't
need
to
necessarily
put
them
into
special
buckets
they're,
just
ditional
properties,
regardless
of
who
added
them.
A
Because
to
me
the
end,
the
producer
ups
are
the
receiver
of
this
doesn't
really
matter
or
doesn't
really
care
who
added
any
particular
property.
All
he
cares
about
is
what
properties
are
there
and
what
their
values
are
where
they
came
from
is
kind
of
irrelevant
for
the
most
part,
especially
when
you're
talking
about
having
proxies
in
the
middle,
you
know,
are
they
allowed
to
add
at
a
top
level,
because
that's
what
they're
supposed
to
as
proxies
or
you
know,
are
they
middleware
or
no?
A
B
A
B
I
agree
and
I
think
ultimately,
we'll
have
to
go
and
figure
out
what
you
know,
how
we
think
about
routing
and
whether
we
want
to
make
routing
a
first
level
concept
and
want
to
go
and
tie
into,
but
that's
also
discussion
to
have
with
relationship
to
some
context.
I
in
the
in
the
slack
channel
I
put
something
a
link
in
to
blog
posts.
That
kind
of
discusses
some
of
those
things.
B
Q
Hi,
this
is
John,
I.
Think
one
of
the
angles
I
mean
I
have
a
particular
opinion
about
the
bags
or
not.
But
the
angle
we're
talking
about
is,
is
readability
and
and
there's
issues
around
that
in
terms
of
security
right
so
I,
don't
know,
you
know
how
people
are
thinking
around
security
issues,
authentication,
validation
of
the
payloads
as
well
as
tampering.
Q
B
Right
and
that
and
I
think
that's
that's
actually
where
it
really
matters.
When
you
want
to
make
sure
that
you
got
the
message
as
it
was
as
it
was
emitted
by
the
sender,
then
you
first
need
to
have
a
rule
about
the
immutability
means.
You
can't
touch
this
and
second,
you
then
need
to
have
a
way
to
ensure
that
and
that's
by
putting
a
signature
somewhere.
A
D
J
B
I
think
signing
signature
is
the
minimal
thing
we
have.
You
need
to
go
and
take
a
stance
on,
and
it's
not
clear
that
we
need
to
go
in
in,
but
I
think
we
should
stay
away
from
inventing
something
because
that
smells
like
w
security
and
I
don't
want
to
go
there.
I
think
I
mentioned
that
earlier,
but
we
need
to
take
a
stance
on
how
we
think
about
you
know
it's
louder.
It's
relative
to
existing
security.
I
A
Let
me
ask
you
this:
how
do
you
want
to
move
forward
on
here?
Would
you
like
to
leave
the
issue
open
for
a
while
and
try
to
solicit
more
feedback,
or
would
you
like
to
force
the
discussion
by
putting
some
poor
requests
out
there
is
that
all
requests
tend
to
force
most
discussions
right,
I?
Guess
it's
actual
proposal
to
change
the
spec?
I
A
I
B
A
D
Dad
can
I
squeeze
in
a
quick
comment
in
that
quick
question.
Sure
of
course,
okay,
first
off
I'm,
not
gonna
spit
that
PR
for
a
proposed
version.
Change.
Sorry
about
that
I
I!
Think
right.
Now
we
just
kind
of
stabilized
this
thing
and
focus
on
reaching
that
stability.
So
we
could
focus
on
building
the
ecosystem
around
it.
The
tools,
the
SDKs
that
make
it
accessible
and
usable
so
that
developers
can
put
their
hands
on
and
start
building
it
into
their
applications,
and
we
can
get
that
real-world
feedback
that
helps
drive
the
specification
forward.
D
D
We
have
done
a
lot
of
work
to
transform
popular
AWS
events
to
cloud
events,
format
for
an
experimental
thing,
we're
doing
in
our
new
version
of
the
serve
list
framework
and
we've
written
these
manually
just
in
JavaScript,
but
it
would
be
great
to
figure
out
a
way
where
we
can
basically
create
transformation.
Mappings
store
it
in
some
format.
That's
language,
agnostic
that
all
the
SDKs
could
could
could
basically
optionally
load
and
do
transformations
based
on
based
on
those
mappings
and
I.
D
D
But
if
anyone
has
any
other
thoughts
or
ideas,
please
let
me
know
I
think
if
we,
given
all
the
great
people
who
are
in
this
group,
all
the
resources
we
have
together.
If
we
could
start
collaborating,
if
we
could
figure
out
how
to
start
mapping
out
these
transformations
for
very
popular
events
in
the
ecosystem
and
put
them
in
this
language.
Agnostic
format,
which
a
whole
bunch
of
tools
could
optionally
load
as
they
deem
necessary
I
think
we
can
make
a
lot
of
a
lot
of
progress.
Getting
people
onto
cloud
events
pretty
quickly
also.
E
D
D
That's
a
good
question:
I'm
I
didn't
write
that
code
and
I
wasn't.
I
was
the
one
who
did
that
I'm,
not
I,
can't
answer
that.
But
from
my
experience
a
lot
of
the
same
obvious
formats
are
consistent
and
they're,
not
changing.
So
it's
it's.
It
should
be
relatively
easy,
but
again,
I
didn't
I,
didn't
dig
into
that
site.
I!
Don't
can't
give
an
informed
answer
here.
I.
J
D
A
Right
cool.
Thank
you.
Thank
you,
a
question
all
right
next,
so
this
person,
I
Lenny
I,
believe
his
name
is
not
on
the
call
he's
basically
wondering
how
we
send
multiple
events,
an
HTP,
binding
now,
I
believe
Clemens.
You
may
have
made
a
comment
in
a
previous
issue
or
request.
I
think
basically
saying
that
we're
gonna,
let
it
fall
on
these
should
be
transport,
decide
how
to
do
that
and
it's
outside
the
scope
of
us
I.
Believe
that's
what
you
said.
B
So
the
binary,
so
the
binary
mode
can't
do
that
because
we're
mapping
that
to
HD
headers
and
so
therefore
there
was
no
independent
way
of
doing
that,
and
that
said
for
the
structured
mode
were
it's
all
in
the
payload.
We
could
do
that
and
factually
in
our
actually
event
grid
with
the
current
proprietary
format
that
we
have.
We
are
doing
that
so
effectively
the
we
deliver.
We
currently
deliver
Jason
only
in
in
our
product,
and
so
we
have
an
outer
array,
which
means
we
can
do
so.
B
If
you
want
to
so
batching
is
something
we
can
go
in
at,
but
the
complex
that
makes
things
more
complex,
so
that
then
you
know
puts
up
the
question.
If
we
want
to
go
and
add
batching,
which
is
not
terrible,
then
the
the
map
into
the
header
thing
becomes
a
little
bit
harder
and
then
the
question
there
is:
you
know
how
many,
how
many
complexities
do
we
need?
So,
basically,
I
would
firm
from
from
a
complexity
perspective,
I
would
say
either
we
do
batching
or
we
throw
away
the
binary
mode.
K
Yeah
I
agree
with
everything
the
planet
just
said:
we're
having
the
same
issue,
we're
also
putting
an
array
at
the
top,
so
we
can
actually
batch
multiple
messages
into
the
same
thing,
but
we're
also
the
only
doing
JSON
in
the
structure
format,
not
the
binary
things,
so
I
don't
see
much
use
for
binary.
In
my
use
case
of
just.
B
R
B
B
But
that
you
can,
you
can
do
that
with
with
protocols
that
support
that,
like
you,
you
can
do
that
with
a
MTP.
You
can
arguably
do
Nats
and
you
can
do
that
with
MPT
as
well
like
HTTP.
Http
is
a
terrible
asynchronous
for
asynchronous
protocol.
That's
just
that's
just
the
the
issue
with
that
one
potentially.
B
A
So
let
me
ask
this:
questions
is
running
a
little
low
on
time
here.
Let's
say
we
decide
to
do
some
sort
of
battering
things.
Obviously.
Well
they
turn
this
around.
If
we
decide
not
to
do
batching,
then
obviously
no
change
to
the
specs
are
needed.
But
if
we
decide
to
do
some
sort
of
batching
thing,
do
you
guys
think
that
is
strictly
additive
to
what
we
have
now
or
do
you
think
that's
going
to
potentially
fundamentally
change
what
we
have,
because
it's
not
going
to
fundamentally
change
what
we
have
then
I'm
thinking?
A
B
Think
batching
is
a
substantial
addition
and
batching
changes.
The
way
how
we
think
about
you
know,
mapping
the
events
to
the
infrastructure
and
because
because,
if
you
now
carry
multiple
events
in
the
payload,
then
you're
effectively
hiding
the
details
of
the
those
events
to
the
to
the
intermediaries.
This
is
a
mirror.
You
can't
assume
that
intermediaries
can
go
open
and
go
and
crack
open
a
bag
of
events.
B
Q
R
B
So
I'm,
leaning,
I'm,
really
kind
of
from
I've
been
thinking
about
this
for
a
while,
because
I
you
know
making
the
binary
part
of
the
story
was
something
that
I
did
based
on
feedback
that
was
given
early
and
I
think
there
might
be
a
middle
here
where
we
will
preserve
some
aspects
of
the
binary,
which
means
you
know,
promotion
of
properties,
it's
a
header
so
that
middleware
could
see
it
but
also
introduced
batching.
But
I
don't
have
a
clear
picture
of
that
just
yet,
and
certainly
in
under
two
minutes.
B
A
Well,
we
have
one
minute:
left:
I'm,
not
gonna,
force
a
decision
that,
whether
it's
zero
point,
two
look,
let's
everybody
think
about
it.
On
the
next
week's
Cobo
will
decide
whether
they
wanted
40.2
or
not,
but
in
the
last
30
seconds
there
is
one
other
issue.
This
type
reserve
point
it's
another
transport.
Please
take
a
look
at
this
one.
When
you
get
a
chance,
we
can
decide
whether
we
want
to
pursue
that
or
not
I.
A
Don't
think
we
decide
to
have
the
transport
in
place
for
so
point,
but
I
think
we
per
mode
for
our
roadmap.
We
have
to
decide
where
they
want.
To
put
it
in
zero
points,
are
e-40
points
we
have
to
decide.
If
we
want
to
do
it
or
not
we're
not
this
I.
Do
it
for
zero
point
two,
but
we
just
decided
we're
gonna.
Do
it
so
look
if
that
want
to
get
a
chance
when
you
get
a
chance,
so.
B
A
A
A
No
well
who
is
aw,
there
was
an
aw
in
the
attendee
list
or
employee
kind
of
funny
name:
okay!
Is
there
anybody
on
the
roll
call
that
I
missed
all
right
cool?
Thank
you
guys
know
each
other
I
apologize
for
running
over
one
minute,
but
this
was
a
good
call.
We
made
a
lot
of
really
good
decisions
today.
Thank
you
guys
very
much
and
we'll
talk
next
week
and
I've
Clement
I,
just
remembered
Kathy
said
she
wasn't
gonna,
be
here
today.
So
that's
why
she's
not
gonna
call
actually
Clemens
dropped
anyway.