►
From YouTube: CNCF Serverless WG Meeting - 2019-07-25
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
C
B
Tough
questions
so
so
we
talked
about
this
in
the
past
and
everybody
basically
agreed.
We
want
to
get
there
as
quickly
as
possible.
I
think
we
have
two
main
issues
in
front
of
us.
One
is
how
did
to
represent
the
binary
data.
The
binary
property
and
that's
sort
of
going
back
and
forth
between
James,
Roper
and
Clemens,
unfortunately,
James
is
in
Australia
Clemens,
is
on
vacation,
makes
it
very
difficult
to
make
progress,
but
I'm
trying
my
best
through
backchannels
to
see
what
we
can
do
there.
B
B
No
I
told
understand
it
like
I
said,
though
I
did
it
kind
of
depends
on
on
this
group
right,
because
if
everybody
waits
until
the
phone
call
to
have
a
discussion
on
something,
we're,
never
gonna
make
progress
right.
So
we
need
people
to
come
in
to
review
the
proposals
and
stuff
outside
of
this
phone
call.
As
best
we
can
I
bet
I
know
it's
a
challenge,
they're
really
busy.
B
So
with
that
I
think
Eric,
you
joined
good
morning
good
morning,
I
think
that's
it
right
now
and
it
is
3:00
after
so
I
don't
know
exactly
it's
for,
after
only
going
to
get
started,
suck
Rebecca
rent
later
all
right,
but
community
time
are
there
any
topics
people
like
to
bring
up.
B
There
are
not
on
the
agenda
all
right
going
forward.
We
have
not
an
SDK.
We
have
not
had
an
SDK
call
I,
don't
even
think
we
have
one
scheduled
for
today,
so
I
think
next
week
might
be
the
next
time
we
have
one
so
nothing
new
to
bring
up
they're
still
looking
for
three
end
users,
I'll
ping,
some
people
offline,
I,
apologize
that
I
was
traveling
recently,
so
I
don't
get
a
chance
to
deny
people
like
I
meant
to.
B
But
please
send
me
your
three
end
users,
if
you
have
any
also,
if
you
want
to
be
included
a
list
of
adopters,
let
me
know
koukin
San,
San,
Diego
I,
don't
were
for
sure
when
that
is,
it
may
be.
November
I
can't
burrow
exactly
when,
but
I
did
get.
The
official
notes
just
this
week
asking
whether
we
would
like
to
have
a
intro
and
deep
dive
for
both
service
and
cloud
events,
so
ping
me
offline.
B
If
you
are
interested
in
being
part
of
that
presentation,
whether
it's
part
actually
mainly
for
the
presentation
side
of
things,
if
we're
gonna,
do
a
demo
I'm
assuming
we're
gonna
use
the
airport
one
again,
since
that's
already
out
there
and
I,
don't
think
people
unless
I
have
time
to
do
another
one.
But
if
you
want
to
be
part
of
any
presentation
at
either
the
service
or
cloud
event
stuff,
let
me
know
and
based
upon
the
feedback
I
get.
We
can
then
decide
whether
we
have
one
session
or
two
per
working
group.
Okay,.
B
B
But
I
believe
he
made
that
change.
Okay,
where
he's
in
the
process
of
making
that
change
right
now
and
I,
don't
believe
I
think
he'd
say
addressed
James
comment
here
about
whether
we
can
follow
the
same
convention
as
as
protobuf.
So
with
that
I'm
wondering
whether
people
are
okay
with
approving
this
PR
assuming.
D
B
Think
that's
actually
a
relatively
minor
change,
even
if
he
does
make
it.
So
let
me
ask
the
question:
are
people
okay
in
general,
with
this
PR
moving
forward
because
I
feel
like
it's
been
there
a
long
time
we
can
always
make
updates
to
this
and
any
other
of
the
transport
suspects
that
we
have
approving
it
now
does
not
mean
it's
perfect.
It
just
means
it's
better
than
there,
but
better
than
what's
there
before,
which
was
nothing.
B
B
Usually
can't
type
today
all
right
cool.
Thank
you
guys.
There
we
go
okay
and
I
got
you.
Tim
allowed
you
to
the
agenda
to
the
attendee
list,
bird
Tim,
sorry,
okay,
Maps,
unfortunately,
jimping
me
earlier
and
said
if
he
makes
it
he's
going
to
be
late,
so
this
may
be
interesting
having
conversation
without
him
and
evan.
Obviously,
so,
if
people
get
a
chance
to
look
over
Evans
sort
of
pros
and
cons
list
slips,
commentarial
pros
and
cons
list
about
having
maps
there,
I
was
wondering
what
people
thought
about
that.
B
B
Okay,
this
one
right
here
this
comment
right
here:
I
thought
was
the
most
interesting
one
or
the
hardest
to
deal
with
so
I'm
interpreting
this,
as
if
you
get
an
extension-
and
you
don't
know
what
it
is
because
it's
unknown
to
you,
how
do
you
return
it
to
the
user?
Do
you
return
it
as
a
string
or
as
a
map,
and
on
this
one?
B
B
People
need
to
deal
with
that.
Anyway,
you
know
SDK
writers
or
Java
or
JSON
parsers,
or
something
right
they
have
to.
They
have
to
figure
out
some
way
to
return
it
and
I'm
in
go.
Probably
the
most
logical
way
is
just
to
return
it
as
an
interface.
You
know
basically
unknown
type
and
I'm
curious
to
know
how
the
go
SDK
handles
that
and
whether
this
is
a
major
problem
or
it's
just
kind
of
an
annoyance.
So
Scott.
Let
me
pick
on
you
personally.
Yes,.
F
So
the
go
SDK
doesn't
quite
support
this
because
it's
very
complicated,
but
the
intent
is
that
you,
you
asked
for
an
own
extension
with
an
own
type
and
it
populates
it
for
you.
So
you
pass
in
a
struct
and
it
comes
back
or
you
pass
in
a
string
that
comes
back
as
a
string,
but
also
to
note
the
SDK
in
go
does
not
support
multi-level
extensions.
B
Okay,
I
think
nor
that
second
one
just
for
a
sec,
let's
just
focus
on
map
versus
string
for
unknown
extensions.
What
do
people
think
about
that
is,
for
example,
the
way
they
go?
Is
you
can't
handle
it
an
acceptable
way
that
people
think
that's
how
they're
gonna
do
it
and
hold
on
Tim
I'm
gonna
make
you
speak
up
instead
of
just
putting
a
comment
in
the
chat
so
that
other
people
can
hear
from
the
recording.
You
want
to
say
what
you
said
in
chat,
Tim.
G
For
extensions
just
make
them
scaler
and
probably
you
come
out
ahead.
You
know
I
just
haven't
seen,
you
know
they're.
Definitely
you
know
having
maps
and
potentially
infinitely
deeply
nested
stuff.
There
clearly
creates
problems
in
certain
situations
and
I.
Look
for
the
countervailing
advantages
that
with
okay.
B
B
H
My
main
take
is
I
want
to
get
to
1.0
and
then
those
big
changes
doesn't
really
help
because,
dirty,
if
you
remove
map
that
we
have
follow-on
problems
like
then
we
have
to
look
again
at
how
do
we
do
namespacing
what
are
accommodations
there?
So
don't
we
have
to
revisit?
Do
we
have
a
separator
and
so
on?
So
we
can
have
all
these
discussions
again
if
we
have
to
it's
just
going
to
delay
things
further,
that's
my
main
concern.
Otherwise,
it's
a
trade-off
decision.
I'm,
fine,.
B
E
C
No
worries
I
tend
to
agree
that
as
much
as
it
is
elegant
and
it
would
be
very
cool,
I
think
it's
gonna
potentially
add
issues,
especially
on
the
multiple
transports
and
the
you
know,
iterative
process
of
going
through
how
you're
gonna
represent
that.
So
as
much
as
that,
you
know
intellectually
and
program
wise
would
be
cool,
I
think
it
might
cause
more
grief
than
benefit
okay,
cool.
Thank.
I
B
F
F
So
it's
a
little
bit
of
processing
that
happens
so
in
an
SDK
you
could
say
I
support
this
map,
object
and
I
know
how
it
flattens
into
the
namespace
of
the
attributes
of
binary
mode,
and
you
could
unflagging
it
and
then
hydrate
that
original
map
and
then
return
it
it's
transparent
to
the
user,
but
for
the
SDK
or
sorry
for
the
cloud
events
spec
it's
it's
always
just
a
single
string.
We
remove
the
details
of
how
that
happens.
Right.
B
B
B
If
we
did
head
that
direction
of
dropping
maps,
has
anybody
actually
looked
at
this
PR
well
enough
to
know
whether
it
generally
is
going
the
right
direction
or
whether
there
are
major
changes
to
it?
Okay,
I,
don't
want
to
say
approval
right
now,
because
I,
don't
think
be
anybody's.
Looked
at
it
enough
yet,
but
I
want
to
know
if
anybody
has
looked
at
it
to
know
whether
it
seems
like
its
head
in
the
right
direction
or
whether
we
need
to
ask
Evan
to
go
back
and
revisit
it.
Based
upon
conversations,
we've
had.
B
Okay,
not
hearing
any.
What
I'd
like
to
do,
then,
is
this
everybody
look
at
the
BR.
Give
your
feedback
in
terms
of
whether
you
think
it's
sufficient
for
this
decision
of
dropping
maps.
I
would
like
to
have
a
conversation
with
Jim
either
later
in
this
phone
quality
matters
is
the
joining
cuz.
He
did
talk
about
possibly
joining
halfway
through
or
I'll
talk
to
him
offline
and
see
if
he
can
live
with
this
decision,
but
I'm
not
hearing
anybody
necessarily
go
against
it.
E
B
J
Considering
the
fact
that
we
wanna
get
this
into
the
hands
of
users
as
fast
as
possible,
and
we
want
to
get
feedback,
it
wouldn't
be
that
much
of
a
change
it'll
be
like
1.1.
If
we
choose
to
revert
the
decision
we're
taking
here
right
like
we
would
not
allow
maps
and
then
we've
actually
get
some
usage,
we
see
that
we
actually
do.
You
want
to
allow
Maps,
even
though
all
the
drawbacks
of
it
there
wouldn't
be
that
much
of
a
change
with
it.
B
Sorry
I,
I,
just
haven't
worked
through
that
and
mentally.
My
head
is
definitely
something
for
us
to
think
about,
but
at
least
from
at
least
to
address
Christoph's
concern
about
the
character
set
right.
If
we
don't
change
the
character
set
rules,
we
have
right
now
so
that
you
still
can't
use,
but
we
reserved
it
so
that
later
on,
we
could
use
it
for
maps.
F
B
B
Is
China
but
the
silence
as
to
whether
you
guys
don't
think
this
is
a
problem.
You
had
a
chance
to
review
it.
The
problem
is
so
abstract
complicated,
it's
it's!
It
hurts
your
head
that
read
them!
That's
where
I
tend
to
be
on
this
one.
So
does
anybody
have
any
comments
on
these
at
all,
trying
to
figure
out
whether
this
is
a
serious
problem
or
it's
an
edge
case
inspect
that?
Would
that
isn't
necessary
worthy
of
of
too
much
concern
you,
okay,
thank
you,
Tim
anybody
else.
B
Okay,
I,
don't
want
have
a
discussion
here
on
the
coffee.
No
one
has
any
opinions
or
reddit,
but
we
have
to
resolve
its
when
we
radio
there,
even
if
it's
to
just
close
both
of
them
and
keep
it
the
spec
as
it
is,
but
well
we
need
to
get
back
from
you
guys,
I,
don't
think
this
kind
of
decision
should
be
left
up
to
just
James
and
Clements
I
think,
and
we
need
input
from
more
people
in
that.
So
please,
please
go
read
both
PRS
and
in
particular
the
history
behind
them.
B
I,
the
only
feedback
I've
got
an
offline
I
came
here
who
was
from?
Was
they
want?
They
want
things
as
simple
as
possible
and
I'm,
not
a
hundred
percent
convinced
either
PR
actually
keeps
things
as
simple
as
possible,
but
at
the
same
time
I
don't
know
what
a
simpler
solution
is.
If
this
is
a
real
problem,
so
please
go
off
and
read
those
okay.
Anybody
else
want
to
think
about.
Speaking
up.
B
Okay
did
it
do
so
just
to
refresh
everybody's
memory
a
little
bit
my
stuff
out
of
my
way
here
it's
hard
to
comment
for
a
sec,
so
just
refresh
everybody's
memory.
This
PR
tries
to
talk
about
transport,
air
air
air
handling
in
general,
and
this
is
just
for
the
primer.
It
basically
punts
on
it
and
says
we're
not
doing
anything
about
it.
Normal
transport,
air
handling
sort
of
applies
now
Scott's.
Did
you
Kiki
where's
your
thing
Scott?
How
to
comment
in
here
and
basically
Scott.
You
wanna
talk
to
your
comment.
F
B
B
However
I've
you
would
add
a
scope
for
this
best
for
our
specification,
because
if
you
look
at
what
our
spec
says
least
in
the
readme,
all
right-
we're
here
for
describing
event,
data
and
common
formats-
we're
not
here
about
message-
transport,
we're
about
just
tweaking
the
format
but
innocence
in
the
most
basic
case
just
add
four
new
properties.
That's
it
how
the
messages
gain,
transfer,
transported
back
and
forth
between
two
endpoints
across
multiple
protocols,
for
the
most
part,
isn't
really
in
scope
for
us.
K
G
So
I'd
be
supportive
of
this
PR
I
think
it
speaks.
Truth
I
mean
it's
interesting.
The
whole
notion
of
inventing
with
pub/sub
semantics
that
you
know
you
emit
the
data
into
the
cloud
and
really
sorry
you
don't
control
or
really
influence
much
what
happens
thereafter.
You
know
I
think
it
would
also
the
setting
to
the
point
that
we
could
say
more
I'd
certainly
be
said.
Something
saying
that
you
know
if
you
receive
an
event,
it's
deeply
broken.
You
have
you
shouldn't
simply
silently
ignore
this.
You
know
you
should
raise
an
alarm
by
whatever
alarm.
G
B
G
F
Except
it's
not,
though,
because
that
there
is
a
response
that
goes
back
to
the
persistence
piece,
so
there's
a
queue
somewhere
in
here
potentially
and
then,
if
you
have
multi,
hop
and
and
both
connections
are
open
because
the
middle,
the
middleware
doesn't
take
control
over
the
the
persistence
of
the
event,
the
end
consumer
can
still
air,
and
then
you
want
to
enact
the
upstream.
So
now
you
your!
You,
have
no
idea
how
to
actually
translate
the
responses
between
transports
like
what
is
a
four
hundred
mean
to
AMQP,
for
example.
F
F
B
But
I
thought
I,
so
I
keep
going
back
to
this
idea
of
the
the
problems
that
you're
describing
Scott
are
there
even
with
that
crowd
events
and
therefore,
because
I,
don't
think
this
cloud
events
in
essence,
charter
you
can,
even
if
we
have
a
charter,
is
really
about
how
to
get
an
event
from
A
to
B.
You
know
reliably
across
whatever
transports
and
stuff
like
that.
That's
not
our
Charter.
B
B
It's
not
that
the
request
is
in
scope
to
me.
I
view
it
more
as
What's
in
scope
for
us
is
to
how
to
decorate
the
request
to
turn
it
into
a
cloud
event
right.
We
don't
tell
people
and
that's
like
how
to
use
HTTP.
We
just
say
if
you
happen
to
be
using
HTTP,
here's
how
you
decorate
it
with
the
cloud
event
stuff.
B
That's
the
difference
to
me
because
one
of
the
things
I
wear
things
I
keep
telling
people
when
I
describe
to
what
I
understand
to
them.
What
cloud
events
is
I,
always
drop
back
feet
to
the
most
basic
example,
which
is
today
you're,
sending
an
event
between
a
and
B.
If
you
happen
to
be
using
HTTP
at
4,
new
HTTP,
headers
and
boom,
you
now
have
a
cloud
event.
B
That's
all
that
we're
doing,
and
people
look
at
me
and
at
first
they're,
shocked
because
they
think
we're
defining
another
cloud
event:
format
I'm,
trying
to
get
clear
them.
We're
not
we're
just
adding
a
little
bit
of
extra
metadata
and
when
they
hear
about
how
simple
it
is
to
turn
basically
any
event
into
a
cloud
event
by
just
adding
four
new
HTTP
headers,
and
that's
all
we're
trying
to
do
the
more
often
than
not
the
reaction.
B
I
get
is
holy
crap
that
simple
and
holy
crap,
that's
brilliant
for
being
so
simple
and
that's
really
really
useful,
even
though
it's
so
simple
and
that
I
think
is
the
point
here-
is
we're
not
over
we're
not
trying
to
oversell
or
over
try
to
solve
problems
that
are
beyond
you
know
what
we
said
we're
going
to
do.
All
we're
looking
at
doing
is
making
it
easier
for
receivers
to
be
able
to
do
some
common
processing
on
it.
B
You
know
routing
filtering
that
kind
of
stuff
by
saying
here's
what
here's
some
common
attribute,
you
could
look
for.
That's
it
we're
not
going
beyond
that
scope,
we're
not
defining
an
event
that
all
events
should
look
like
like
there's
been
in
the
past
and
failed
we're
not
trying
to
tell
you
how
to
semantically
process
those
things
we're
not
telling
you
how
to
transport.
These
things,
even
it's
just
here's,
a
couple
of
little
bit
of
extra
metadata.
That
thing
you
go
along
with
your
message.
That's
it.
L
So
sorry,
this
is
John
yeah,
so
if
he
keeps
cuz
I
think
I
think
we
may
be
talking
about
a
few
things.
I
mean
if
I
take
what
you
just
said
right.
It
goes
along
with
this
notion
of
events
being
very
distinct
from
messages
right
that
they
really
are
in
essence,
fire-and-forget
from
the
spec
perspective
that
make
sense
right,
and
if
that's
the
case,
then
there
is
no
like.
L
If
there's
an
error,
that's
a
that's
a
either
a
transport
thing
in
terms
of
its
own
mechanism,
which
is,
as
you
say,
out,
of
scope
or
it's
a
much
higher
level.
Whatever
you
want
to
call
it
business
protocol
issue
somewhere
higher
up
the
stack
to
be
rectified
higher
up
the
stack
right,
which
may
be
a
quote,
unquote,
return
cloud
event
right
being
published
explicitly
to
some
kind
of
topic.
L
B
Possibly
I
think
what
you're
basically
saying
is:
there's
a
vent
thing
and
there's
messaging
and
my
mind
is
a
more
the
inventing
side
right,
yes,
yeah,
maybe
to
be
honest,
I
I
have
a
feeling
you'd,
probably
read
more
into
what
I
was
saying,
may
not
be
wrong.
My
mind.
Wasn't
that
deep,
because
because
I,
for
example,
you
know
Clemens
goes
back
and
forth
on
this
whole
venting
versus
admission
thing
and
my
simple
line
breaks
it
down
to
it's.
It's
you
know,
eventing
is
one-way.
B
Messaging
is
potentially
two-way
kind
of
thing
right
or
higher
level
processing
event
than
and
and
that
and
and
so
when
I
look
at
the
the
cot
event,
spec
I,
don't
even
look
at
it.
Nacelle
II
as
it
venting
verses,
messaging
I,
look
at
it
more
as
I'm
sending
a
chunk
of
data
across
the
wire
I
want
to
add
some
extra
common
metadata
to
it,
whether
you're
sending
it
as
a
quote
through
then
think
thing
or
you're,
sending
it
as
a
quote
messaging
thing
in
my
mind,
I
don't
actually
care.
That's
why.
E
L
Okay,
if
you
think
about
it
like
a
messaging
system
that
has
dead-letter
cues
and
things
like
that,
you're
gonna
have
to
translate
those
pieces
yourself,
because
we
don't
have
that
model
right.
So
we
don't
give
some
guidance
or
some.
You
know
whether
it's
example
code
or
whatever,
that
works
with
at
least
some
of
the
common,
tooling
and
infrastructure
out
there
when
people
are
going
to
be
just
all
over
the
place
and
I
think
that's
a
disservice
right.
L
What
even
if
it's
just
hey,
we're
just
giving
whatever
clues
or
best
practices
or
saying
hey.
Here's
an
example:
the
code
that
works.
This
is
what
we
think
is
part
of
cloud
event
itself,
and
these
are
externalized,
but
obviously
issues
you
have
to
take
care
of
right
in
failure
modes
and
being
able
to
manage.
Those,
obviously
is
very
critical
to
a
lot
of
processes.
H
He
just
takes
only
that
tries
to
implement
it,
and
then
he
runs
into
all
these
problems
and
I
see
them
coming
up,
or
this
is
like
taking
part
of
what
is
not
in
our
main
spec
or
what
is
in
the
other
bindings
we
define.
So
then
we
we
do
have
to
take
some
stance
on
how
to
handle
these
things,
at
least
for
those
things
we
define
like
the
webhooks
I.
Think.
B
So
I
did
intend
to
be
honest.
It's
been
a
while,
since
I've
looked
at
those
specs
to
know
how
far
outside
of
that,
you
know
limited
scope,
they
go
and
to
see
whether
it
is
a
concern
but
Scott
Lee.
They
pick
on
you
again
for
a
sec
if
we
were
to
ensure
that
the
HTTP
specs
did
not
leave
that
that
limited
scope
and
I
think
we're
hearing
from
most
people
that
it's
basically
just
about
to
find
the
extra
metadata
and
did
not
get
into
a
processing
model.
B
B
Don't
know
good
because
my
gut
reaction
is,
you
probably
were
not
misled
by
that
you're
you're,
a
part
of
looking
at
this
from
dammit
I
just
want
to
write
code.
I
mean
you
want
the
code
to
be
to
work,
be
interoperable
and
you're.
Looking
for
clarity
on
how
to
handle
situations
and
because
you're
in
the
cloud
events
group,
that's
where
you
thought
the
interest
should
come
from
yeah.
F
I
mean
I
think
you
know,
I've
talked
about
this
with
a
couple
people,
but
it
what
I?
What
I
really
want
is
the
ability
to
make
a
function
framework
that
can
operate
on
any
transport
and
not
care
about
the
details
of
that
transport.
Just
write
some
code
make
it
work
caught.
Events
is
close,
but
not
quite
there
right.
E
It's
just
going
to
add
the
you
know
if
we
want
something,
that's
more
prescriptive
or
in
more
detail
around
error
handling.
I,
don't
know
that
that
should
go
into
this
specification
into
this
file,
but
could
be
you
know
more
of
a
primer
or
or
a
subsequent
document
that
could
go
into
various
strategies
for
home.
B
L
So
so
let
me
ask
Scott,
then,
is
is:
do
you
see
a
two?
Is
there?
Is
there
a
simple
the
equivalent
of
what
we
talked
about
is
hey
just
add
these
four
fields
going
back,
wait
for
a
request.
You
see
a
mechanism,
that's
the
equivalent
that
would
that
would
be
the
foundation
for
hey
here's
errors.
Maybe
the
transport
can
do
something
useful
with
it.
Maybe
it
can't,
but
at
least
from
the
normative
spec
perspective,
we're
providing
the
hooks
upon
which
you
can
build
your
framework.
F
Yeah
absolutely
I
think
plot
events,
if
you,
if
you
think
about
it
as
becoming
the
conical
form
of
an
event,
payload
like
it,
defines
the
envelope
and
a
bunch
of
data
inside,
and
it
allows
me
to
process
it
that
envelope
gets
a
receipt
and
it
gets
delivered.
Right.
It'd
be
interesting
for
us
to
think
about
the
conical
form
of
what
is
that?
L
So
so
I
I
will
agree
with
you.
It's
not
my
own
personal
experience
and
and
I
think
that
I
think
that's
what
I
where
I
would
come
down
is.
Can
we
define
that
that
that
hey,
here's
four
fields
or
whatever
it's
going
to
take
the
absolute
minimum
to
be
able
to
provide
that
mechanism
as
part
of
the
normative
specs
and
then
in
the
non
normative
places
we
can
provide
whatever
examples
or
guidance
for
okay?
Here's
how
other
people
are
doing
this
absolutely.
L
B
L
I
totally
agree
and
that's
why
I
was
trying
to
make
the
distinction
of
just
it.
Just
if
you
were
talking
about
hey,
all
you
have
to
do
is
add
these
four
headers
and
that's
all
that's
where
we
stop
right,
I
think
I.
Think
what's
God's
asking
and
I
think
what
I
am
saying
myself
as
well?
Is
we
just
we're
just
talking
about
the
equivalent
of
exactly
that
and
nothing
else
right,
because
it
provides
the
mechanistic
hook
in
a
normative
way
and
then
everything
else
is
punted
to
the
the
implementations
right.
B
B
G
F
G
So
sorry,
I
can
speak
only
from
my
own
experience
here,
but
most
eventing
systems
have
some
sort
of
an
API
to
inject
an
event,
saying
here's
something
that
happened
and
and
you
either
get
a
200
meeting.
Yeah
there's
your
event
it's
in
the
system.
Now
by
or
you
know,
you
know,
if
you
could
say
you
might
get
a
500
a
few
cent
or
400
if
you
sent
like
malformed
JSON
or
something
like
that.
H
Hands
up
I
think
it
kind
of
makes
sense
or
the
question
is:
where
does
processing
model
start?
If
it's
just
like
I
delivered
the
event?
That's
it
I,
don't
know
what
happens
afterwards
or
I
did
not
deliver
it,
which
could
be
my
networked
handout
or
TRS
or
return
500.
It
does
that
already
count
as
a
processing
model.
For
you.
A
B
You,
oh
it
honestly,
I,
don't
know
because
I
think
it's
at
a
scope
of
cloud
event.
Stephen
worry
about
that
right.
However,
the
event
was
sent
without
cloud
events
and
whatever
this
isn't
it
made
based
on
whatever
error
codes,
it
may
see
do
not
does
not
change,
because
we've
now
added
four
new
attributes,
okay,
and
so
like
I,
said
in
my
opinion,
these
may
be
valid
concerns,
but
they're
not
our
problem
to
solve.
H
B
And
I
think
it
I
think
it's
incumbent
upon
all
of
us
myself,
especially
because
I
want
to
go
back
and
understand.
This
is
to
go
back
and
look
at
the
HTTP
specs
to
see
whether
we've
left
our
scope
incorrectly,
and
maybe
we
should
rip
those
things
out,
but
that
there
are
their
hands
up
duggie
of
the
club.
Yet.
M
Yeah
yeah
I
mean,
in
my
opinion
this
is
delving
into
quality
of
service,
which
is
clearly,
in
my
opinion.
Clearly
a
transport
level
thing,
and
you
know
perhaps
instead
of
enforcing
this
in
the
spec,
you
can
provide
guidance
through
a
priority
and
then
it's
up
to
the
user.
It's
up
to
the
implementer.
Whether
or
not
this
priority
warrants
you
Oh
a
subzero
just
if,
if
it's
I
lose
it,
it's
gone
or
q.s
of
to
deliver
at
least
once
or
three
exactly
once,
but
I
really
don't
think
that
should
be
in
this
back.
D
B
So
what
I'd
like
to
do
is
two
things.
One
is
hey
Scott.
It
sounds
to
me
that
relative
to
this
poor
requests,
you,
you
don't
necessary,
have
a
problem
with
this
poor
request
itself,
because
the
text
almost
says
nothing
other
than
we're
pumping.
However,
you
would
like
to
see
us
go
further,
and
so
what
I'd
like
to
do
is
the
split
okay
are
going.
This.
B
Say
what
that
okay,
it
since
you're
phrasing
it
that
way,
I
mean
that
suggests
what
I
was
gonna
suggest
that
which
was
to
do
it
in
steps
it.
If,
if
I'm,
not
hearing
a
consensus
about
whether
this
is
our
problem
or
not,
so
what
I'd
like
to
do?
Is
this
and,
like
I,
said
earlier,
nothing
goes
into
the
spend
a
lot
of
PR,
so
what
we're
gonna
have
to
do
is
get
someone
to
write
a
PR
to
just
show
people
what
your
guys
are
thinking.
B
F
B
That
I
agree.
We
don't
have
consensus
yet,
however,
and
just
does
my
opinion,
but
I
tend
to
find
that
having
a
PR
helps
solidify
things,
because
sometimes
people
think
about
an
idea
and
think,
oh,
my
gosh,
that's
so
big
in
scope.
I
didn't
want
to
touch
that
when,
in
reality
the
PR
actually
might
be
relatively
small,
and
that
may
be
the
case
here.
I,
don't
know,
of
course
the
exact
opposite
could
happen.
So
I
think
someone
could
say
it's
trivial
and
people
look
at
the
PR.
B
G
B
F
B
Okay,
Scott,
let
me
ask
you
this
question
since
you're
the
main
instigator
of
this
thing,
it
seems
to
me
that
there
are
two
different
ways
we
can
go
with
the
spec.
We
could
say
it's
not
our
problem,
which
is
what
this
PR
is
trying
to
say
or
we
can.
You
could
then
change
our
minds
and
say
yes,
it
is
our
problem
and
here's
how
we're
going
to
solve
it.
B
B
Okay,
what
I'd
like
to
do
is
suggest
we
go
with
what
I
just
proposed
and
that
some
of
them
make
it
more
formal.
My
formal
proposal
is
to
adopt
a
PR
with
Tim's
wording
change,
with
the
assumption
that
if
the
PR
comes
along
that
changes
our
mind
about
whether
we're
going
to
touch
a
reporting
or
not,
we
will
examine
that
PR.
B
B
Okay!
Thank
you
guys
with
that.
Though,
the
burden
now
is
on
Scott
or
whoever
wants
to
take
the
action
to
write
up
something,
even
though
I
kept
using
the
word
PR
I
guess
an
issue
is
fine
too,
as
long
as
I
think
it
has
to
be
descriptive
enough
for
people
to
get
a
sense
of
the
scope
of
what's
going
to
happen
here
in
terms
of
respect
changes,
one
or
two-sentence
kind
of
thing:
I,
don't
think
it's
gonna
cover
it.
B
I
think
we
need
to
be
very
explicit
about
what's
gonna
happen,
because
my
general
sense
is
this
will
be
a
non-trivial
change.
I
think
you'll
need
to
understand
that
going
in
and
I
do
understand,
Scott
you're
concerned
about
writing
a
PR
that
may
go
nowhere.
That's
a
lot
of
work
for
nothing!
So,
okay,
oops
yeah.
B
E
Doug,
one
of
the
things
that
we've
always
wanted
with
this
group
is
always
making
forward
progress
in
the
text
that
is
proposed
in
this
pull
request
is
good
good
text
to
add,
and
people
can
augment
it
in
the
future.
Like
you
said
so,
I
don't
see
a
problem
with
us.
Accepting
this
or
adding
in
Tim's
addition
additions
as
well
yep.
B
You,
okay,
I,
don't
know
time
to
jump
into
another
deep
issue,
especially
something
like
Evans.
Oh
yeah,
one
thing
I
didn't
want
to
bring
it
up
since
that'll
wantonness
like
dive
into
a
discussion
about
it,
but
I
didn't
want
to
drop
the
people's
attention
and
it
was
Scott
you
want
to
quickly.
Just
you
know,
like
one
minute
mention
this
comment
you
might,
you
may
hear,
is
I
thinking,
yeah.
B
F
Conversation
we
just
had
we're
in
HTTP
the
there
was
added
this
concept
of
batch
batching
events,
but
it
looks
the
payload
looks
like
this:
that's
you
know
it's
a
square
bracket
and
then
a
comma
delimited
event
in
structured
form
and
I.
Just
don't
understand
the
processing
model.
For
this
thing,
because
there's
no
way
to
reply
back
to
the
deliverer
I
got
a
case
cool
down
a
little
bit
done.
Yep,
so
like
I
got
a
and
C,
but
like
B,
had
a
problem.
F
B
Because
why
bring
this
to
a
close
attention?
Cuz,
even
aside
from
the
entire
discussion
we
just
had
about
whether
we
should
do
error,
processing
or
not,
I
have
heard
a
couple
of
comments
from
people
that
they
did
not
like
this,
where
the
current
format
we
have,
which
is
just
top-level
square
bracket
or
a
thing,
they
would
much
prefer
a
curly
brace
object,
thingy,
even
though
technically
it's
both
valid
Jason
I've
heard
people
prefer
this
other
way.