►
From YouTube: CNCF Serverless WG Meeting - 2019-01-17
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
Let's
see
where
I
okay
get
it
to
do
so.
I
have
a
couple
action
items.
Actually,
I
guess:
I
have
all
the
X
items
I'm
trying
to
find
time
to
work
on
those.
Let's
see,
I
guess
who's
on
the
call
right
now
we
don't
have
matheus,
yes,
Dennis,
Fabio
Fabio,
anything
you
want
mention
relative
to
your
STK,
anything
exciting
or
noteworthy.
You
want
to
bring
up.
B
A
In
that
case,
I
can
transact
Lee
where
this
came
up
and
some
previous
discussion
is.
There
was
some
question
about
whether
the
getter
should
say
get
even
type
versus
type
and
if
I'm
not
correct,
I,
believe
the
suspect
right
now,
just
as
type
for
the
property
name.
But
there
are
some
people
who,
like
leave,
wanted
to
keep
the
word
event
in
there
and
I
thought
this
might
be
worth
a
discussion
because
I
think
it's
important
to
have
some
level
consistency
across
the
SDKs.
A
C
A
C
D
I
can
I
can
probably
work
around
the
fact
it-it's
just
refusing,
because
I
can
call
a
property
tight,
so
I
would
envy
SDK.
Of
course,
it's
C
sharp
all
properties
are
just
properties,
all
right,
there's
no
getter
and
center
or
they're
applied.
So
they
look
like
they
look
like
fields
and
I
can
name
a
field
type
without
getting
in
the
way
of
the
type
type.
D
C
A
F
D
A
C
A
Okay,
so
tell
you
what
I'll
assume
that
a
note?
We
actually
don't
have
an
S
to
clean
mailing
list.
That
may
be
something
I
want
to
consider
it.
Something,
but
I'll
send
out
a
note
to
the
full
mailing
list
and
the
slack
channel
asking
for
people's
opinions,
but
they're
referred
choice
as
of
right
now,
so
they
just
remove.
The
word
event
will
see
what
people's
reactions
are.
Sounds
fair.
C
A
A
C
A
H
H
A
H
From
no
remember
my,
my
memory
is
a
little
fuzzy
because
I've
been
on
leave
for
a
couple
weeks,
but
there's
currently
three
gotgot
laying
cloud
event:
libraries
that
are
in
the
mix
right
and
they
all
three
took
a
slightly
different
approach
and
we
just
had.
We
are
preferring
the
current
one
that
uses
a
little
bit
of
type
reflection
and
the
callback
that
gives
me
event.
H
C
I
understand
having
an
embedded
SDK
already
in
not
wanting
to
rip
it
out,
or
you
know
you
have
understanding
of
that
I.
Would
it
would
be
nice
if
you
could
file
some
issues
with
the
current
fantastic
ion,
assuming
go
SDK
to
say
you
know
at
least
file
an
issue
that
you
need
to.
You
need
to
provide
more
tests
and
another
that
says
you
know
here
here
are
the
gaps
that
I
see
with
respect
to
what
we're
currently
using,
and
at
least
that
way
we
can,
you
know,
is
there
a
way
to
rationalize
is?
H
H
A
H
A
C
Thing
that
worries
me
the
most
is
that
if
Kay
native
goes
in
a
different
direction,
are
people
going
to
assume
that
that's
the
quote
unquote
de
facto
standard,
and
are
we
doing
the
wrong
thing
with
what
the
current
SDK
I
mean?
Really,
what
we
want
is
for
people
to
be
able
to
come
to
to
our
repo
and
pull
a
an
SDK.
That's
in
use
by
some
number
of
companies
doesn't
mean
everyone
has
to,
but
it
would
be
nice
if
we
had
some
usage
of
it.
So
I
worry
about
that.
I
think.
A
H
C
And
just
just
a
flavor
at
this
point,
I
think
it's
important
for
us
to
think
about
what
is
it
that
we
want
around
the
bending
and
go
if
we
think
about
the
usages
of
this
SDK,
it
really
has
to
do
with
you
know,
creating
event
sources
and
then
transiting
those
those
events.
So,
if
we're,
if
we're
talking
about
K
native
well,
obviously
we
want
to
make
sure
that
we
have
something
compatible
and
aligned
with
a
project
such
as
Canada.
D
I'm,
not
I'm
gonna
go
person
but
to
pop
up
ones.
I
think
one
of
the
goals
of
the
service
group
is
to
just
generally
foster
interoperability
across
platforms
and,
as
such,
I
would
certainly
welcome
if
the
core
representation
of
a
cloud
event,
not
necessarily
how
you
receive
it
and
how
you
you
know:
abundance
of
the
transport
and
all
those
things,
but
how
you
actually
represent
the
cloud
event
and
how
you,
how
you
handle
it
and
send
in
the
application,
looks
exactly
exactly
the
same.
It
is
literally
like
compile
compatible
so.
D
No,
no,
no,
the
OEM
of
the
cloud
event
itself
and
then
and
then,
whether
whether
you,
how
you,
how
you
pull
this
off
the
wire
and
how
you
kind
of
integrate
that
into
your
interior
stack
and
whether
you
you
know,
maybe
even
how
he
send
it
in
a
different
way
that
might
be
different,
but
I,
think
I.
Think
if
we
I
would
find
it
a
little
weird
really
if
Kay
native
as
a
host
of
apps
would
have
a
different
elem.
D
H
D
Your
reasons
are
to
diverge
you're,
making
a
decision
basically
just
go
away
from
a
common,
a
common
path
and
I
would
welcome
if
there
was
convergence
to
a
core
library
that
satisfies
the
requirements
that
you
have
and
satisfies
the
requirements
of
other
and
the
other
people
have
because,
ultimately,
I
don't
think
this
is
about
you.
But
I
think
it's
about
the
user
and
the
users
should
have
in
go
one
way
to
representing
the
cloud
event
in
a
web
and
on
400
yeah.
A
I
guess
that
goes
to
the
questions.
Scott,
oh,
isn't
clear
from
an
application
point
of
view
right
if
they
write
a
piece
of
code
and
they
and
the
function
itself
leverages,
the
goal
is
DK
that
I
guess
VMware
is
written
and
then
they
also
let
point
a
lever
to
the
SDK
as
part
of
Kay
native.
Would
their
code
of
their
application
need
to
change
I'm
guessing
the
answer
might
be?
Yes,
it's
probably
you
said.
I
H
A
A
H
The
SDK
is
different,
but
what
gets
produced
and
goes
on
the
wire
is
not
alright,
so
at
the
end
of
the
day,
something's
getting
to
post
from
somebody
else
and
that
body
of
that
event
gets
transcoded
back
into
the
blog
of
it,
and
that
is
compassion.
Okay,
I'm
sorry
I
was
mixing
things
up,
okay,
so
as
long
as
you're
producing
the
right
headers
and
the
body
format,
the
thing
should
smush
back
into
whatever
wacky
object.
H
D
D
J
H
D
A
A
A
H
Exactly
so
using
candidate,
you
could
actually
make
a
compelling
demo
coming
to
your
SDK,
interrupt
thing
where
you.
G
H
A
H
D
Could
quite
well
that
could
quite
well
be
one
column
in
time,
capsulated,
all
the
data
that
we
have,
which
is
ultimately
the
core
of
the
the
spec
that
we
have
right
now.
Our
core
spec
is
doing
nothing
but
defining
an
object
model
around
well
a
set
of
properties
and
and
effectively
the
the
blueprint
for
an
object
model
around
the
clock
event
type.
That's
all
it
does
yeah.
H
D
Then
there's
Jason
specs,
which
are
saying
this
is
how
we
go
and
bite
these
things
through
the
to
the
transports
and
I
can
totally
see
that
in
particular
infrastructures
you
want
to
go
ahead
and
do
the
bindings
in
a
different
way,
and
then
they
are
done
in
a
SDK
that
is
built
for
with
a
bunch
of
generic
assumptions
that
are,
must
discipline
intercepts.
I
can
see
that
so
I
can
see
that
the
bindings
needs
missing,
but
it
would
be
great
if
there
was
exactly
one
cog
event
type
that
everybody
who's
writing
something
going
uses.
A
So,
just
a
little
time
check
here
be
still
the
sharing
join
the
call
for
them
for
the
regular
service
thing,
I
think
it
I
think
Scott.
If
you
open
up
those
issues
we
talked
about
in
the
goaline
sdk,
we
should
be
able
to
leave
some
of
those
discussions
as
part
of
those
issues.
I
think
that
will
help
flush
it
out
a
little.
A
But
to
the
other
question
that
you
started
talking
about
Scott
of
demo
or
interoperable
Kay's,
that
is
a
one
thing.
I
want
to
talk
about,
but
I'm
not
sure
how
much
time
we
have
here,
but
I
do
want
to
at
least
start
brainstorming
around
whether
we
want
to
try
to
do
something
and
if
so,
what
would
that
look
like?
Is
it
some
sort
of
formal,
like
you
know
our
pack
of
fun
kind
of
a
thing?
H
K
C
C
A
A
Okay,
in
terms
of
a
demo
itself,
do
you
guys
have
anything
in
mind
that
you
think
would
showcase
things
better
than
any
of
the
demos
we've
done
in
the
past,
whether
it's
the
mad
libs
or
Austin's,
one
before
or
I,
think
we
have
one
routine
there
or
there's
just
those
two
I
can
remember,
but
you
guys
want
to
look
at
a
new
demo
or
an
existing
one.
I,
don't.
A
A
C
A
C
A
I
H
H
Sort
through
yeah,
it's
just
I,
got
a
respirator
now,
and
so
it's
all
good.
That's
interesting!
No
shoe
in
a
bunch
yeah
all.
L
C
B
I
A
A
A
Hi
William,
like
that's
okay,
thank
you,
yeah
Sachs
I
should
mention
if
you
guys
join
the
call
late
or
some
like
that
or
you
missed
the
roll
call.
It's
go
ahead
and
put
a
message
into
the
zoom
chat.
Hello
I'll.
Take
that
as
good
enough
as
long
as
obviously,
your
names
associated
with
that
hollow
host
take
that
is
as
you're.
There.
A
I
I
A
Got
everybody
all
right,
it's
3:00!
After
about?
Oh,
oh
there's,
our
person,
someone
new
I,
think
Laurie.
Are
you
there
Laurie
prickly.
A
A
A
All
right
good
look
forward,
then:
okay,
SDK
subgroup,
so
in
case
you
guys
missed
it
or
we
get
somebody
wanted
to
join,
but
they
have
the
wrong
zoom
link
in
the
invite
I
apologize
for
that
I
lived.
My
personal
zoom
by
mistake,
rather
than
the
the
service
zoom
link,
hopefully
had
a
new
invite,
was
sent
out
with
the
right
one.
This
time
I
apologize
for
that,
but
there
really
isn't
much
to
mention
in
terms
of
progress.
A
The
only
thing
that
was
brought
up
was
there
may
be.
A
split
in
the
community
are
on
the
goal
line
SDK,
because
key
native
is
not
using
the
one
we're
producing
and
so
we're
gonna
try
to
explore.
Why
and
see
if
we
can
try
to
bring
those
two
worlds
back
together.
If
not
then
no
huge
deal
but
it'd
be
nice
if
we
could
bring
it
back
together.
Also
we're
gonna
be
looking
at
a
new
Interop
demo.
Scott
has
already
started
some
brainstorming
ideas
here.
A
A
I
believe
some
people
were
advocating
for
keeping
the
word
event
in
there,
even
though
we
dropped
the
word
event
from
the
spec
itself,
but
on
the
call
we
just
had,
everybody
seem
to
prefer
aligning
with
the
spec
itself,
so
dropping
the
word
events,
but
I
was
gonna.
Send
that
no
that's
no,
unless
to
make
sure
everybody
else
is.
Okay
with
that,
since
we
had
low
attendance
on
the
call,
so
keep
a
lookout
for
that
one.
If
you
have
an
opinion
on
that,
please
speak
up.
A
Otherwise
we're
gonna
try
to
push
people
to
go
with
just
get
type
instead
of
get
event
type
to
align
with
us
back.
Okay,
anybody
from
the
SDK
team
or
a
subgroup
have
anything
when
I
mentioned
that
I
may
forgot
him
all
right
cool,
let's
see,
Cathy
I'm,
gonna
call
I,
don't
see
her
so
I,
don't
think.
There's
anything
to
mention.
Go
out
to
to
the
work
group
promotes
our
work
flow
subgroup.
Nothing
really
happened
there.
A
A
Okay,
any
objection,
then,
to
adopting
it
excellent.
Thank
you
guys.
It's
apini,
don't
think
he's
gonna
call.
A
Cummins
this
one
might
be
too
long
for
you
as
well.
I
believe
that
he
just
wanted
to
add
integer
to
the
list
in
this
sentence.
Go
go
as
in
yes
goes!
Yes,
okay!
Does
that
make
her?
Okay,
anybody
else
like
I'll,
have
any
questions
or
comments
about
this
one,
okay,
any
objection
to
that
minor
change.
What's
with
that,
Oxford
comma,
there
where's
that
oh,
this
one
is
that
bother
you
Scott
I
can
get
that
change
that
there
really
bothers
you.
C
A
Okay,
hopefully,
that's
be
easy
to
go
through
I'm,
assuming
because
those
are
all
just
some
tactical
type
things
if
those
syntax
fixes
go
in
you
guys
are
okay
with
just
approving
that
offline,
no
need
to
revisit
it
from
a
semantic
perspective.
Is
that
fair
for
say
plus
one
for
me?
Okay,
anybody
else
on
the
call
have
any
objection
to
that.
A
I
A
Thank
you
guys,
let's
see
yeah
leave.
This
was
an
action
item
from
last
week's
phone
call
inside
the
comments
here.
Basically,
this
first
one
is
just
escaping
the
the
star,
because
everything
else
appears
as
italics.
You
can
see
right
there,
so
it's
kind
of
annoying
me.
So
this
is
the
real
change
down
here
on
line
118
on
basically
just
battling
to
the
release
process.
A
That
says,
we
need
to
send
out
a
note,
basically
announcing
the
new
release,
an
obvious
thing
that
we
just
forgot
to
do
in
the
past,
so
send
it
to
the
mailing
list,
as
well
as
added
to
the
announcements
section
of
our
website,
which
is
still
under
development
as
we
speak,
such
as
the
major
change
to
our
release
process,
any
questions
or
concerns
about
that
when
we
have
a
Twitter
account,
oh,
we
do
do
I
think
we
do
yes,
okay
I
will
do
that
as
well.
So
thank
you.
A
A
Okay,
I
still
consider
that
to
be
kind
of
more
or
less
syntactical
thing
you
guys,
okay,
with
approving
this
one
conditional
to
adding
Twitter
to
the
list
working.
H
A
Whoops,
okay,
thank
you
guys
all
right.
This
one
is
a
little
bit
more
significance,
hopefully
not
too
controversial.
We
briefly
talked
about
this
last
week
about
how
I
think
there
may
be
some
confusion
about
just
having
a
property
called
content-type.
Just
some
people
may
confuse
it
with
the
content.
Type
HTTP
header,
so
I
was
suggesting
that
we
rename
it
to
be
data
type
instead,
which
is
I,
think
actually
more
accurate
anyway,
because
it
is
defining
the
type
of
our
data.
Property
is
well.
If
we.
A
But
I
believe
in
the
not
in
the
structured
format.
We
actually
have
content
type
HTTP
header,
as
well
as
the
Cee
content
type
HTTP
header,
no.
D
And
confidence
I
actually
has
encoding,
though
there's
there's
more
some
confidence.
That
is
a
fairly
rich
thing
only
says
you
know
this
is
application
Jason,
but
there
is
also
potentially
the
character
set,
so
you
might
have
application
okay,
Jason,
semicolon
charts
and
charts
at
exa,
dick
etc.
So
all
of
those
things
are
there's
a
connotation
for
content
type
and
we're
actually
literally
referring
to
the
RFC
for
which
I
don't
have
in
my
head
right
now,
oh
yeah.
G
D
Web,
that's
all
defined,
so
you
can't
rename
that,
because
there
is
there's
there's
we,
we
should
agree
that
we
want
to
go
and
and
disassociate
ourselves
from
that
entire
world
of
mind
types
and
come
up
with
something
else.
But
well.
If
we
don't,
then
we
should
stick
to
that,
because
it's
the
content.
O
A
So,
okay
them
of
your
phrase,
that's
good
I
may
be
some
misunderstanding
here:
I'm,
not
suggesting
that
we
deviate
from
using
the
mime
type
stuff
or
the
current
semantics
of
content
type.
It's
just
when
I
was
looking
at
the
camera
for
sure
which
spec
it
is
it's
one
of
the
ones
that's
up
for
discussion
and
it
may
be
the
open
messaging
one
or
babies
the
Raju
anyway,
one
of
those
two
included
the
sea
content-type
property
inside
of
their
message
and
I
believe
they
were
confusing
it
with
ACP
content,
type
header
itself
and
I
was.
D
A
D
A
I
bet
her
by
mistake
in
putting
it
there,
as
opposed
to
describing
the
data
property
itself,
and
what
I
wanted
to
do
was
to
avoid
any
possible
confusion
by
saying
that,
when
the
content
and
the
cloud
event
content
type
property
appears,
regardless
of
where
it
appears,
it
would
cause
less
ambiguity
or
confusion
if
we
actually
call
it
data
type
instead
and
let
the
HTTP
binding
still
map
it
to
the
content,
type
HTTP
header.
But
it's.
O
A
L
H
A
A
Okay,
okay,
so
what
do
people
think
about
data
content?
Type?
Has
the
property
name?
Yes,
okay,
I'm
gonna,
pick
on
somebody
here
is
I
know
who
had
an
opinion
in
the
past
about
this
gem.
K
I
guess
I
will
clarify
this
in
an
example
would
be,
and
people
will
hate
it,
but
a
binary
so
cloudy
lens
Jason
transport
with
an
XML
payload
in
the
data,
so
you've
got
a
JSON
document
carrying
XML
data,
so
I
guess
in
that
case
your
HTTP
header
would
say
it's
Jason
and
a
data
content
type
would
be
text,
I,
select,
XML
or
application.
Xml
yeah.
A
K
A
A
Okay,
what
I
think
I'm
hearing
is
John
consensus
to
chain
you
to
data
content
type?
What
I'll
do
is
I'll
make
that
change,
because
there's
a
change
of
property
name,
which
is
a
big
deal.
I,
don't
want
to
rush
this
through.
So
what
I'll
do
is
I'll
make
that
change
and
then
give
you
guys
a
week
to
think
about
it,
and
then,
hopefully
we
can
resolve
that
on
next
week's
call,
so
I
mean
no.
One
else
raises
any
objections.
I
don't
want
to
take
the
resolution
this
one
offline
on
it.
D
A
M
This
small
room
in
this
one,
okay
cool,
so
this
one
we
already
discussed
last
week.
Basically,
what
it
says
is
fetching
is
a
good
thing,
but
it's
handled
at
transport
layer
and
then
Tapani
I,
don't
think
he's
on
the
call.
Today
he
requested
that
we
should
mention,
which
is
basically
last
sentence.
That
I
didn't
know
that
whether
the
particular
transport
layer
supports
patching
is
a
turd
to
be
found
in
transport
bonding
or
in
the
transport
specification
itself.
M
So
as
an
example
for
Kafka
for
Kafka,
all
we
have
to
say
in
the
ending
is
basically
we
map.
This
is
a
cloud
of
end
and
this
is
how
we
map
it
to
a
Kafka
message
and
then
how
Kafka
messages
are.
Batched
is
part
of
Kafka
itself,
so
we
don't
have
to
mention
it
in
a
transport
binding.
So
this
is
what
the
last
sentence
adds.
A
M
Exactly
so,
then,
during
last
week's
discussion
we
said
it
would
be
really
nice
to
actually
have
batching
for
HTTP
and
I
agree.
So
maybe
we
can
scroll
down
to
the
examples.
So,
basically,
as
a
for
HTTP,
we
basically
have
two
modes
defined
already
the
binary
and
destructive
one
and
I
think
for
the
binary.
It's
pretty
much
impossible
to
do.
Batching,
because
we
map
the
attributes
to
headers
and
that
just
won't
work.
So
then
that
leaves
the
structured
mode
and
the
structured
mode
well
can
work
with
basically
any
content
type
so
kind
of
starting.
M
M
D
I'm
just
wondering
so
we
have,
because
we
have,
we
have
a
we
have
so
I
would
like
to
get
a
see
more
spec
still
in
right.
I
just
haven't
done
the
automate,
the
effort,
but
I
think
we
should
have
a
binary.
We
should
have
a
nice
binary
format,
which
is
as
adjacent
structures
and
Seymour
is,
is
a
good
candidate
for
this
and
also
obviously
have
protobuf
and
so
I
think
there
will
be
more
encoding
alternatives.
D
M
That's
kind
of
where
I
wanted
to
start,
but
then
I
realized
we
well.
We
we
can
discuss
it
I
think.
But
the
thing
is
that,
right
now
we
say
everybody
should
support
JSON
and
then,
if
you
make
the
batch
Jason
part
of
what
days
near,
is
then
what
we
effectively
do?
Is
we
force
everyone
also
to
accept
batches
yeah.
O
M
Something
that
yeah,
you
know
what
you're
now
saying
is
batches
are
only
supporting
Jason,
not
really
no
I
mean
it's
kind
of.
Why
I
open
up
this
pull
request,
so
we
can
discuss
it
I
in
my
comments
on
the
PR.
I
also
mentioned
that
this
is
a
shortcoming
of
it
right
now
and
if
we
find
a
good
way
to
support
betting
for
basically
anything,
then
it's
good
but
I
didn't
one
of
the
problems
I
had.
Is
that
we're
in
our
type
system?
D
D
I
think
that's
I
think
there's
a
senior
way
to
go,
because
we,
because
it
would
be
great
too
I-
think
we're
not.
We
haven't
seen
the
end
of
encodings
coming
from
XML
I
now
have
to
believe
that
even
Jason
I'm,
not
gonna,
not
gonna,
be
the
end
thing
for
everybody
and
so
having
a
bit
flexibility
and
they're
not
bolting
a
particular
format
into
into
the
transport
specs.
It's
probably
good.
Okay,.
M
M
So
if
you
scroll
a
little
bit
back
up
there
in
the
beginning
in
section
2
or
1
or
something
we
talked
about,
how
the
I'm
sorry
a
little
bit
back
down,
yeah
this
this
section
here,
sorry
so
the
receiver
basically
based
on
the
header,
the
receiver-
can
sting
wish
between
which
mode
it
is
getting
so
I.
Think
that's
why
I
think
we
need
a
new
header
value.
M
D
K
M
K
K
A
M
No
I
think
we
talked
about
everything
then
I
do
one.
Other
thing
is
that
I
made
this
mode
optional,
I
think
all
right,
I,
don't
because
I
don't
think
we
want
to.
We
say
everyone
should
support,
binary
and
structured,
but
I'm
not
sure
I
want,
should
support
batching,
for
example,
in
a
function
as
a
service.
If
you
got
a
single
HTTP
request
through
the
single
event,
that
is
pretty
nice
because
it
Maps
perfectly
onto
the
semantics
of
a
function
as
a
service.
M
A
M
M
C
A
A
Ok,
I'm
not
hearing
any
concern,
so
that's
good.
Ok,
so
we'll
get
those
chains
in
there.
I
assume
Christoph
overview
those
again
next
week,
right,
yep
excellent!
Thank
you
all
right,
cool
size
limits.
This
one
should
be
interesting,
yep
yeah!
Then
we
started
this
one
last
week,
but
let's
see
well
far,
we
got
we
can
go
wanna
refresh
people's
memory
on
this
one.
M
Yes,
so
I
think
the
oval
issue
is
that
if
we
look
at
basically
all
messaging
technology
out
of
there,
we
know
that
they
have
limits
in
one
way
or
the
other
and
I'm
mostly
coming
from
the
producer
side.
Basically,
what
I
want
to
know
is
what
are
the
limits
if
I
send
out
a
cloud
event,
is
it
guaranteed
to
reach
its
destination?
Even
if
it
starts
I,
don't
know
on
HTTP
then
goes
into
a
cough
clock.
You
think
I
was
into
I,
don't
know,
overload
above
and
then
goes
through.
M
It
should
be
binary
to
the
final
consumer.
I
want
to
know
that
whatever
event
I
sin
today,
either
I
know
that
it's
go
through
all
of
these
steps
or
it
sort
of
fails
slumber.
So
that's
what
I
want
to
know
is
producer
I.
Think
if
you
write
a
consumer,
you
also
want
to
know
what
are
the
things
you
have
to
expect
and
support
or
things
you
maybe
can
write,
push
back
and
not
accept
yeah.
A
A
K
And
I
think
Christophe
was
a
really
good
job
tempering
the
conversation
on
the
on
the
thread,
as
he
mentioned,
I
think
you
might
have
his
comments
on
that
thread.
I'm
more
leaning
personally
to
the
fact
that
we
really
want
to
say
that
an
implementation
must
support
messages
up
to
a
certain
size,
but
may
support
stuff
larger
than
that.
So,
if
you
want
to
guarantee
and
to
end,
then
you
make
sure
your
messages
are
below
a
certain
size.
K
K
E
G
K
Think
John
that
was
was
more
leaning
to
a
minimum
yeah.
You
would
rather
mandating
that
you,
as
a
producer,
always
produce
events
of
up
to
a
maximum
size.
What
we're
really
saying
is,
if
you
want
to
guarantee
and
to
end,
then,
if
you're
below
a
particular
size,
it's
guaranteed
to
work
otherwise
you're
you're
at
the
request
or
the
behest
of
your
particular
service
provider,
because
people
will
vary
yeah,
I,
suspect.
G
A
M
So
the
first
discussion
point
was
basically:
should
we
have
a
limit
or
what
I
call
it
guarantee
or
a
minimum
guaranteed
slice,
so
I
think
we
cleared
that
up.
The
second
thing
I
want
to
talk
about
are
the
attributes,
so
basically
I
here
I
proposed
two
limits.
The
first
one
is
I,
think
the
more
important
one
which
is
it
says,
like
the
whole
event,
including
metadata
and
including
the
data
itself,
should
not
exceed
128
kilobytes.
Well,
then,
I
here
I
added
another
one
another
limit,
but
on
the
table
attributes.
M
So
the
reason
I
did
this
is
that
if
you
write
a
consumer
or
middleware,
the
attributes
are
different.
So
the
payload,
the
data
itself,
I,
can
sort
of
ignore
and
just
pass
on,
but
for
the
attributes
I
have
to
parse
them.
I
have
to
lower
the
memory.
I
have
to
look
at
them
and
understand
them.
If
I
want
to
do
something
like
routing
or
whatever
so
potentially
for
a
middleware,
it
will
be
bad
if
someone
would
be
128
kilobytes
of
top-level
attributes
and
I,
maybe
like
a
bite
off
or
now
real
data.
M
K
M
Length,
yes,
you
are
right
on
this.
One
I
I
think
I
put
the
zeros
proposals
and
hope
that
people
who
actually
implement
or
have
to
implant
things
like
these
would
speak
up
and
say
what
actual
image
they
want
work
before
so
yeah.
So
if,
if
you
look
at
the
binary
HTTP
binding,
then
we
already
have
in
in
some
HP
service
limits,
so,
for
example,
they
would
limit
the
size
of
in
a
new
individual
header
or
add
a
one
kilobyte
for
example.
So
we
could
think
about
introducing
these
limits
as
well
yeah.
M
A
So
I
have
a
question
on
this
because
I
don't
have
much
experience
in
this
space
relative
to
size,
issues
and
so
I'm
wondering.
Is
it
the
overall
size
of
the
HTTP
headers
in
combination,
or
is
it
sheer
number
of
HTTP
headers
I've?
Never,
because
I
was
kind
of
assumed
these
people
were
low
on
space.
They
were
concerned
with
the
overall
size
of
the
the
headers
in
aggregate,
and
it
wasn't
the
exact
numbers
of
headers.
That
would
have
been
an
issue,
but
I
guess
I.
Don't
have
a
lot
of
experience
here
so
I'm
curious.
D
A
M
The
final
one
was
one
I'd,
also
jump
caught
up,
so
there
are
I,
guess
it's
not
the
new
limits
on
the
side,
messages
and
or
patterns
to
work
around
with
this
particular
Yi
claim
my
pattern.
So
basically
what
you
do
is
you
say:
well,
my
payload
didn't
fit
into
this
message
and
you
can
find
this
message
at
this
URL
and
then,
if
you
receive
such
a
message
and
you're
sort
of
want
to
look
at
it,
then
you
go
back
and
fetch
the
message
from
there.
So
typically,
you
would
still
send
all
the
metadata
with
it.
M
It's
just
that
the
payload
itself
can
be
touched
from
somewhere
else.
So
the
question
will
be
like
it.
It
depends
a
little
bit
on
what
limit
we
choose,
but
is
that
so
something
of
interest
to
people
because
they
think
they
into
the
woods.
So
it's
the
case,
then
we
can
start
thinking
if
we
want
to
include
that
inside
the
spec
such
a
pattern
but
I'm
actually
not
so
sure.
M
If
it's
such
a
big
thing,
because
I
haven't
seen
a
lot
of
imitates
around
this,
which
makes
me
a
bit
wonder
if
it's
a
wide
issue
or
if
most
people
just
send
the
messages
of
a
few
kilobytes-
and
they
were
just
fine
and
don't
need
that
and
then
it
kind
of
well
blows
us
back
a
little
and
and
is
an
implementational
read
to
a
few
people.
Maybe
yeah.
K
Now
we
would
like
to
use
to
store
that
reference
and
that
would
sort
of
be
the
limit
of
where
I
think
the
spec
would
go
in
that
in
that
context,
because
there
are
security,
holes
and
lots
of
other
problems
with
that
pattern,
especially
we're
going
across
provider
boundaries.
So
it
was
more
just
providing
a
mechanism
and
a
path,
an
implementation
of
a
plan.
M
Yeah
exactly
so,
if
you
think
about
I'm,
storing
this
and
I,
don't
know
it
obvious,
as
free
bucket
there,
maybe
I
have
some
concerns
of
who
should
access
this
bucket
and
so
on.
So
it's
not
clear
if
I
was
a
public
URL
list,
you
right
answer
here,
but
it
like.
Even
if
we
don't.
If
we
kind
of
out
of
this
discussion
comes
out,
we
don't
want
to
do.
G
A
K
A
A
The
idea
of
having
a
a
consistent
way
to
do
a
claim
check
pattern
might
be
something
useful
for
us
to
consider,
even
if
we
don't
have
the
hard
limits
in
the
spec
rating
like
that,
but
then
there
you're
right,
but
then
it
gets
into
the
problem
that
I
think
one
of
you
mention
which
one
of
you
is.
How
far
do
we
have
to
go
down
that
path
right?
Is
it
as
simple
as
proof
at
a
URL
where
to
go
get
it
through?
A
D
A
K
A
A
Okay,
so
first
off
I'm
wondering
whether
it
makes
sense
this,
but
this
PR,
the
two
one,
is
to
pick
one
of
the
two
choices
and
and
crisp
it
up.
If
you
need
to,
but
then
open
up
a
second
PR
to
deal
with
the
claim
check
pattern,
do
you
think
they
are
individual
problems?
I
can
be
solved.
It
separately,
yeah.
A
M
So,
on
my
second
point
on
the
limitation
on
attributes:
what
is
the
general
feeling
here?
I
didn't
get
a
clear
answer,
so
we
know
that
at
HTTP
binary
for
the
HTTP
binary
transport,
it
will
be
a
problem,
but
is
that
something
we
should
then
take
on
and
make
it
a
jungle
problem?
Or
should
we
not
have
these
limits
here,
just
because
it's
basically
only
a
problem
of
the
HP
binary
thing.
K
Just
think
it,
as
said
it
just
seems
odd,
to
limit
the
number
of
attributes
without
then
also
making
statements
about
the
size
of
those
attributes.
So
I'm
not
quite
sure
if
it's
just
adding
more
more
language
that
people
are
going
to
struggle
with,
what
does
it
mean
and
what
to
do
with
it
and
I'm
wonder
if
we
just
take
it
out,
you
could
argue
that
an
SDK
could
switch
from
binary
to
structured
if
it's
or
the
payload,
you
know
if
headers
were
going
to
be
too
big
or
whatever.
D
There
will
be
limits
and
people
will
have
to
deal
with
them
and
making
a
statement
that
is
kind
of
a
should
provision
and
says:
can
I
here's
here's
kind
of
a
corridor
that
makes
sense,
isn't
terrible
and
I
have
to
say
a
hundred
28k
is
is
well
within
reason
and
most
cloud
messaging
like
if
you
work
with
any
call
messaging
or
cultivating
system,
you
will
run
into
into
some
limit
that
is
at
at
or
below
one.
My
way.
M
Yeah
still
unsure,
like
yeah,
let
me
put
it
the
other
way.
If
we
only
have
a
limit
of
128
kilobytes
is,
must
be
sort
of
accepted
that
it
means
that
I
can
send
128
kilobytes
of
HTTP
headers.
Basically,
that's
will
run
basically
every
default
configuration
of
an
HTTP
server
will
not
accept
that
which,
maybe
is
finer.
Maybe
the
whole
thing
is
that
the
other
thing
I'm
sort
of
is
in
my
head.
M
We
could
say:
okay,
the
HTTP
binary
is
more
an
optional
thing,
and
if
the
HP
server
gives
you
back
for
1/3,
this
payload
is
too
large,
then
used
to
switch
back
to
the
structured
mode,
which
you
have
to
support
anyway,
and
then
we're
kind
of
Awesome
the
out
of
that
problem.
That
would
be
another
way
to
just
solve
it.
M
A
Yeah,
okay,
okay,
I,
want
to
say
something
from
a
personal
point
of
view,
pearl
weight
and
uniformly
my
thoughts
here.
First,
okay,
anybody
else
have
any
final
comments
on
this.
One
I
think
we
sort
of
beat
this
one
to
death
on
this
call:
okay,
Christophe.
You
know
where
you're
going
wrong
with
that
and
that's
the
end
of
the
agenda.
Are
there
any
other
topics?
People
I'd
like
to
bring
up.
A
Right
and
Laurie
are
you
able
to
get
a
microphone
yet?
Okay,
Laurie,
if
you're
on
the
call
just
put
a
message
into
the
slack
Jim
into
the
zoom
Chad
not
get
you're
in
there.
Oh
hi
Laurie
do
also
do
me.
A
favor
then
also
include
what
company
reforms
I
think
you
near
the
group.
So
if
I
can
get
your
attendance
in
there
properly.
A
A
Sorry
who's
that
everyone
firoun,
oh
yes,
I'm,
sorry
I,
did
see
your
name,
never
got
to
write
it
down.
Thank
you.
Oh
yeah,
I'm
here
as
well.
Yeah
I
got
a
Dory
time.
I
got
you.
If
you
spoke
up,
I
definitely
got
to
all
right
last
chance,
any
other
topics
to
bring
up
for
the
call
today,
all
right.
In
that
case,
we
are
done.
Thank
you
guys
very
much,
we'll
talk
next
week.
Thank
you
all
for
very
good
conversation.