►
From YouTube: CNCF Serverless WG 2020-09-24
Description
CNCF Serverless WG 2020-09-24
D
D
C
C
D
D
E
C
D
B
F
D
D
J
D
D
D
Webex
and
webex
just
does
not
like
me
over
the
last
week,
or
so
it's
had
this
wonderful
little
habit
where
it
would
disconnect
my
audio,
not
I'd,
still
be
in
this
conference.
I
could
see
people
do
stuff,
but
I
could
not
hear
them,
but
sometimes
they
could
hear
me
and
it
was
just
like
just
randomly
happening.
It
wasn't
like
at
the
beginning
of
meeting
like
maybe
you
just
had
connection
issues
just
like
I
was
connected
perfectly
fine
and
all
of
a
sudden
halfway
through
the
meeting.
Just
poof
couldn't
hear
anybody
so
very
annoying.
C
D
C
D
D
That's
an
excellent
question.
Lance
yeah!
I
ain't
convinced
they
hate
their
users,
although
I
have
to
admit
I
I
give
them
a
lot
of
crap
on
on
twitter
because
I
love
to
pick
on
webex,
but
the
last
update
they
did
in
terms
of
the
ui.
I
do
think
it
was
actually
an
improvement.
It's
still
not
where
it
should
be,
but
it
was
better
than
it
was
so
small
victories.
I
guess
all
right
three
after
we
can
switch
over
to
something
more
exciting
than
webex
wait
a
minute
16.
D
D
All
right
sdk,
I
don't
believe
in
an
sdk
call
last
week,
because
we
had
no
agenda
items
and
this
week
we
are
planning
on
having
the
discovery
interrupt,
call
immediately
following
this
one,
which
I
don't
know
if
you
have
any
topics
that
may
be
quick
as
well,
so
be
thinking.
If
you
about
possible
topics
for
that
and
tumor.
Anything
you'd
like
to
mention
relative
to
the
workflow
subgroup.
A
Yeah
thanks
just
just
overall
improvements
of
the
specification.
That's
what
we've
been
doing
for
the
last
couple
weeks
and
I'm
sorry.
I
missed
the
last
meeting
and
we
also
got
a
new
logo.
Finally,
so
we're
waiting
on
the
cncf
design
team
to
actually
create
us,
the
svg
images,
so
we
can
post
it
all
over
the
place.
D
D
D
Okay,
so
this
one
is
updates
to
our
rest,
apis,
just
filling
out
some
details
been
out
there.
I
think
I
made
some
minor
updates
late
last
week
or
maybe
earlier
this
week,
but
it
was
definitely
before
tuesday.
I
did
split
the
apis
into.
I
think
what
I
call
them.
I
think
I
call
them
discovery
apis,
which
is
basically
just
the
get
stuff,
and
then
I
created
management
apis
at
purse.
Scott
suggestion
where
this
does
you
know
things
like
imports
and
puts
and
stuff
like
that.
So
this
is
the
right
side
of
the
house.
D
I
think,
for
the
most
part,
though,
that
was
pretty
much
most
of
the
changes.
I
can't
remember
for
sure,
though
whether
async
processing
section
was
separate
or
merged
in
like
before,
but
if
not,
I
did
pull
out
asynchronous
processing
into
its
own
section.
This
time
I
think
I
might
have
had
that
last
time
too.
D
I
think
that's
about
it
in
terms
of
changes.
Since
last
week
now
there
was
a
question
asked
by
somebody
may
have
been
the
other
grant
asking
whether
we
should
look
at
the
log
stuff
that
eric
mentioned
last
time
as
a
way
to
handle
some
of
the
importing
type
stuff
or
epoch
processing,
and
I
asked
if
we
can
defer
that
I
didn't
hear
back
from
so
I'm
assuming
we
can
deal
with
his
issue
later,
because
we
don't
have
the
log
stuff
even
really
thought
about
yet.
But
I
think
that
was
the
only
open
question.
D
D
D
D
You
guys
can't
hear
me
right:
it's
not
pulling
a
webex
on
me.
Okay,
just
checking
nice.
Try,
though
yeah
well,
I
figured
if
it's
actually
on
mute.
Somebody
would
have
said
something
at
some
point,
but
of
course,
if
I
couldn't
hear
you,
then
it
wouldn't
do
any
good.
So,
okay,
so
silence
means
everybody's.
Okay,
all
right,
you
guys
are
killing
me.
D
I
don't
like
just
rambling
off
to
myself
all
right
website.
Protocol
now
slinky
said
he
wasn't
going
to
make
it,
but
he
also
didn't
see
any
comments
made
in
there.
So
I
guess
my
job
on
this
one
is
to
nag.
I
think
clemens.
You
were
the
one
that
had
some
possible
concerns
against
this.
Do
you
still
have
those
concerns,
because
I
think
he
did
make
some
wording
changes?
H
D
H
D
D
D
Okay,
in
that
case,
we
shall
keep
moving
forward.
Darn
it
I
was
really
hoping
jim,
would
join.
He
didn't
specifically
say
he
wasn't
going
to
join,
but
he
did
ping
me
saying
he
thought
this
one
was
ready,
okay,
well,
it's
loading.
So,
according
to
jim,
he
does
believe
this
one's
ready
to
go
now.
I
know
nothing
about
this.
I
don't
know
anything
about
protobuf,
so
I
wasn't
gonna
even
say
do
much
with
it
personally,
but
for
the
folks
on
the
call.
D
Do
people
want
to
vote
on
this
today?
We
don't
necessarily
have
to
wait
for
gem,
but
if
you
guys
think
we
should
we
can
do
people
want
time
to
review
it.
There's
anybody
on
the
call
who's,
a
protobuf
pseudo
expert
who
says
hey.
You
know
I
need
more
time
to
click
it
over.
What
do
you
guys
want
to
do
with
this,
because
I'm
okay
voting
or
waiting
it's
up
to
you.
D
D
D
So,
let's
see,
if
we
can
talk
about
this
without
him,
so
on
last
week's
call,
he
suggested
that
we
try
to
set
up
some
goals
for
timelines
on
things
which
seemed
like
you
were.
You
know
generally
in
favor
of
that.
Has
anybody
given
any
thought
to
what
kind
of
timelines
they
may
have
in
mind
for
any
of
the
specifications
or
even
the
interop
work.
C
D
D
G
D
D
Okay,
what
other
people
think
november?
Second,
I'm
not,
I
know
see
I
I
I
signed
up
to
do
some
coding,
obviously
clemens,
since
you're
hemming
and
high
and
you're
probably
do
some
coding,
I
think
sanjay
you're
on
the
call
you
were
planning
on
doing
some
coding.
I
can't
remember
who
else
pseudo
volunteered?
D
D
D
B
I
Yeah,
so
I
was
looking
at
the
pr
for
reintroducing
the
protobuf
looks
like
there's.
I.
I
definitely
don't
want
to
block
on
anything,
but
it
looks
like
there's
some
like
unaddressed
comments,
for
example
at
the
bottom.
We
we
don't
have
like
comments
per
all
the
fields
and
that's
pretty
neat,
but
there's
one
of
like
the
the
data
field
instead
of
data,
one
of
john
skeet
recommended
just
data,
so
so
I'm
imagining
like.
Maybe
someone
should
look
at
the
comments
before
getting
all
approved.
D
Okay,
tell
you
what
let
me
reach
out
to
jim
offline
and
ask
him
if
he,
if
he
thinks
he's
addressed
these
or
not,
and
if
he
thinks
he
has
maybe
I'll
reach
out
to
john
then
that
is
john
right
is
his
name
john
yeah
yeah
I'll
reach
out
to
john
to
see
whether
he
agrees
tonight.
If
john
disagrees
and
wants
to
block
the
merge,
then
I'll
I'll
I'll
block
it
because
of
that.
D
I
D
D
D
Oh
scott,
you
just
joined
so
the
current
plan.
Scott
is
to
shoot
for
november
2nd
for
interop
on
discovery
that
will
be
a
forcing
function
to
make
us
clean
up
or
finish
up
the
writing
the
interrupt
dock
and
then
code
for
the
next
couple
weeks.
You,
okay
with
that
scott
okay,
sounds
great.
Were
there
other
dates
you
wanted
to
shoot
for,
or
was
that
the
main
one
like.
K
D
K
D
K
D
F
Yes,
okay,
maybe,
if
possible,
while
we
hear
it
a
question
came
up.
While
I
was
reviewing
the
webhook
specification
and
we
do
have
a
201
created
if
an
event
has
been
accepted
and
processed
from
the
http
semantics.
I
believe
the
created
could
also
apply
if
it
has
only
been
accepted,
and
the
event
has
not
yet
been
processed
is.
Is
that
correct
or.
F
H
No
because
tool,
one
is,
is
says
that
you
have
created
an
object
and
that
will
then
usually
come
with
a
location
header
which
tells
you
where
you
can
find
that
object.
There's
a
there's,
a
there's,
a
there's,
some
implied
handshake
that
happens
with
the
tool.
One
there's
effectively
when
you
take
when
you
to
be
nitpicky
on
the
on
http,
if
you're
taking
an
event
and
you're
acting
it-
and
you
send
me,
which
means
I
have
understood
this
and
I
have
processed
the
event
which
means
you've.
You
put
it
on
disk.
H
H
H
F
A
E
I
was
not
there
when
you
guys
might
have
discussed
this,
but
so
we
are
trying
to
use
the
cloud
events
for
both
web
hooks
as
well
as
internal
events,
and
one
of
the
questions
which
came
was
that
what
about
the
reliable
messaging
qos
related
semantics?
So,
for
example,
if
you
are
trying
to
retry
how
many,
how
of
often
or
how
many
retries
are
left,
you
know
that
that
should
be
stored
with
the
event.
E
Did
you
guys
discuss
those
kinds
of
use
cases
when
the
cloud
event
structure
was
defined
and
if
you
did,
then,
if
you
can
point
me
to
you
know
the
discussion,
what
should
be
done
in
that
case?
That
would
be
great,
because
I
think
the
question
is:
should
we
have
whatever
you
want
to
call
like
reliability,
context
or
retry
context,
or
whatever
is,
should
it
be
part
of
the
event
state
which
so
typically,
you
know
the
event
is
dispatch.
Let's
say
you
are
trying
to
send
it
to
a
remote
destination.
H
C
H
H
I
think
I
think
soap
made
a
terrible
mistake
by
trying
to
do
everything
from
tls
to
reliable
messaging,
to
message
of
insecurity
and
everything
completely
ignorant
of
the
capabilities
of
the
underlying
transports.
It
basically
ended
up
treating
everything
like
it
was
a
naked
tcp
socket,
but
then
was
happy
to
kind
of
bind
to
fairly
sophisticated
protocols
on
top
and
then
layering
another
layer
of
brutal
complexity
on
top
of
it-
and
I
think
that
was
also
its
its
downfall-
was
the
the
extra
complexity.
E
H
Me
to
answer
it:
don't
you
yes,
okay,
so
the
principle
is
that
we're
gonna
have
that
we're
gonna
have
a
small
compact
standard
here,
which
is
for
which
is
just
expressing
what
the
event
is
cloud
event
explicitly
scopes
out.
Transport
concerns
such
as
re-delivery
such
as
you
know,
redelivery
account.
We
don't
have
that
in
in
the
in
the
message,
because
you
are
mapping
a
call
event
onto
a
transfer
message
or
containing
it
in
a
transfer
message.
H
So
that's
the
difference
between
the
binary
mode
and
the
structured
modes
of
a
protocol
which
then
is
suitable
for
whatever
the
transfer
path.
Is
that
you
happen
if
you
need
to
have
reliable
delivery,
we
have
four
three
options
for
you.
We
have
amkp,
which
is
a
super
reliable
point-to-point
transfer
protocol,
which
is
an
iso
iec
standard.
We
have
mqtt,
which
is
also
a
reliable
transfer
protocol
for
pub
sub,
which
is
an
iso
iec
standard,
and
we
also
have
kafka,
which
also
gives
you
reliable
semantics.
E
D
Yeah
that'll
be
my
recommendation.
I
would
take
the
event
because,
if
you're
going
to
retry
the
event,
the
way
I'm
looking
at
thinking
of
it
is
you're
going
to
store
the
event
some
place.
You
can
retry
again
later
well,
when
you
stick
that
event
into
something
with
a
database
record
or
something
right.
D
I
would
assume
you'd
probably
have
other
metadata
about
that
record
or
inside
that
record
and
the
cloud
event
itself
is
just
one
of
those
bits
of
metadata
and
so
that
other
metadata
is
where
I
would
stick
like
the
retry
count
or
whatever
your
other
metadata.
You
want
to
store,
but
I
wouldn't
necessarily
put
it
in
the
event
itself,
because
it's
not
really
a
metadata
about
the
event.
Okay,.
E
H
But
thank
just
just
to
augment
your
your
knowledge
on
this.
We
have
this.
We
have
gra
event
grid,
which
is
our
you
know,
cloud
event
based
eventing
platform
and
there
side
delivery
metadata
where
we
we
keep,
where
we
keep
kind
of
delivery
count
and
the
next,
the
back
off
and
and
when
the
next
retry
is,
and
everything
that's
kept
effectively
in
a
metadata
bucket
that
sits
kind
of
on
the
side
of
the
event.
E
H
D
C
D
D
D
I
have
nothing:
okay,
yeah,
I
don't
have
anything
either,
although
I
did,
I
will
admit
I
actually
started
doing
some
more
coding
this
week,
but
I
only
got
like
half
an
hour
worth,
but
at
least
started.
So
that's
progress,
so
okay
and
sanjay
clemens
to
pay
some
links
into
the
zoom
chat.
You
might
want
to
grab
that
before
you
exit.