►
From YouTube: CNCF Serverless WG 2020-08-27
Description
CNCF Serverless WG 2020-08-27
B
A
B
A
B
C
D
B
But
john,
I'm
right,
though,
that
the
fires
were
all
started
because
of
lightning
right:
it's
not
like
the
normal
brush
fires
or
someone
being
careless
with
a
match
or
something
right.
A
No,
it
was
hours
of
of
lightning
which
we
we
got.
What
two
two
weeks
ago,
almost
two
weeks
ago,
yeah.
A
B
E
B
B
B
B
Hello
good
morning,
klaus,
yes,
I'm
here,
hi,
doug,
hello,
scott,
hey!
B
So,
just
a
heads
up,
it's
very
possible
that
next
thursday
I
may
not
be
able
to
make
the
first
30
minutes
of
the
call
and
so
mark
will
be
running
it.
So
you
get
the
joy
enjoy.
C
B
H
B
C
B
I
guess
not!
Okay,
let's
get
started.
It's
actually
last
chance
sammy
there.
Oh
okay,
let's
see
okay
community
time
anything
from
the
community
that
people
want
to
bring
up.
That's
not
on
the
agenda.
B
All
right,
kubecon,
north
america
still
looking
for
volunteers,
just
a
nagging
reminder:
okay,
sdk!
We
had
one
call
last
week.
I
can't
remember
for
sure
what
we
talked
about.
Anybody
from
the
sdk
team
want
to
mention
anything
for
the
group
to
think
about
or
to
know
about.
B
Okay,
I'm
not
hearing
anything.
We
do
have
a
call
right
after
this
one
to
talk
about
the
interop
discovery
stuff.
I
don't
think
anything's
really
changing
the
docs
since
last
week,
but
we
can
talk
about
it.
I
don't
think
we've
actually
had
a
formal
discussion
on
the
doc
yet
so
we'll
do
that
right
after
this
call,
I
don't
see
tumor
so
nothing
from
the
workflow
group.
So,
okay,
before
we
jump
into
the
one
pr
that
we
have
is
there
anything
on
the
agenda.
People
like
to
bring
up
before
we
get
to
prs.
I
It
was.
Klaus
had
an
interesting
idea
to
change
types
inside
of
services
to
events
which
then
allows
to
remove
the
stutter
inside
of
the
type
object
from.
Did
I
miss
one?
Oh
yeah,
oh
no.
We
changed
it
back
so,
instead
of
so
it
used
to
be
types
and
type
which
is
weird
because
it's
the
type
of
the
type
instead
of
now,
what
it
could
be
is
it's
this
list
of
events
and
the
event
has
a
type
which
makes
sense
again
and
doesn't
stutter.
B
I'm
just
making
sure
there's
nothing
else,
nope.
I
think
that
was
it.
There
was
one
question:
oh
yeah,
you
would
remove
this
section
or
this
what's
it
called.
I
B
J
I
Okay,
yeah,
I
think
that
use
case
gets
re-introduced
when
we
add
the
the
the
higher
fidelity
searching.
J
B
No
concerns
no
questions,
any
objection
to
approving
them
cool
all
right.
Thank
you,
scott.
I
think
that's
actually
going
to
really
clean
things
up
quite
a
bit,
so
that's
really
good.
Thank
you.
Okay.
I
know
jim
has
started
to
work
on
his
protobuf
stuff,
but
unfortunately
he
can't
make
the
call
this
week,
but
he
actually
may
be
looking
to
do
a
dedicated
phone
call.
Just
let
you
guys
know
that
that
may
be
coming
up
and
that's
actually
it
for
our
entire
agenda
today.
B
Is
there
anything
else,
people
would
like
to
bring
up
and
brian
did.
Are
you
trying
to
say
something.
B
Yeah,
I
don't
know
I
you
can
assume
that
at
least
the
slack
channel,
but
I'll
also
try
to
make
sure
you
send
that
note
to
the
mailing
list.
B
K
Yeah,
we
don't
need
to
discuss
it
here
unless
people
really
want
to,
but
I
I
posed
a
question
in
the
cloud
events
slack
channel
and
I
appreciate
some
feedback.
If
anyone
is
interested
in
that.
K
Okay,
yeah
in
the
javascript
sdk,
we
are
currently
pretty
strict
about
validating
events
and
in
fact
you
can't
create
an
invalid
event.
If
you
try
to,
it
throws
an
exception
in
the
constructor
we're
looking
at
having
a
boolean
value
as
a
parameter
to
the
constructor
that
tells
it
to
be.
You
know
strict
or
loose
and
there's
some
debate
over
whether
or
not
it
would
make
the
most
sense
from
the
sdk
perspective
to
have
the
default
be
strict
or
the
default
be
loose,
validate
or
no
validation.
E
K
We're
validating
everything
that
we
can
per
the
spec,
so
basically
all
of
the
required
fields
are
there
and
whether
or
not
the
types
for
the
refer,
the
required
fields
are
correct.
Whether
or
not
the
names
for
the
extensions
conform
to
the
specification.
Whether
or
not
the
values
for
the
extensions
conform
to
the
specification.
E
Yes,
yes,
yeah.
Well,
then,
then,
I
think
what
you're
doing
there
is
to
ensure
that
you
have
a
valid
cloud
event
and
I
think
the
the
other
most
of
the
other
sdks
are
solving
that
by
ways
of
using
the
languages
type
model
and
I
think
in
javascript
you're,
in
the
place
where
you
are
dealing
with
a
bit
of
a
weaker
type
model.
K
K
Yeah
the
the
type,
if
you're,
using
typescript,
that
actually
does
help
some
of
that
yeah
yeah.
Of
course,.
E
K
Right,
I
I
tend
to
agree.
I
guess
my
concern
is
that
you
know
when
I
think
about
friction
that
developers
might
have
when
they
first
pick
this
stuff
up.
They
may
not
realize
that
the
default
is
strict
and
they
may
you
know
malformed
an
event
and
throw
it
to
the
sdk,
and
you
know
like
get
really.
E
K
Right,
well
I
mean
we
would
still
have
a
validate
capability
right.
You
would
still
be
able
to
validate
the
function.
I
mean
validate
the
event,
and
I
think
it
also.
I
hear
you
I'm
just
going
to
play.
The
devil's
advocate
a
little
bit
it
in
a
scenario
where
you're
just
receiving
events-
and
you
don't
know
exactly
where
those
events
are
coming
from,
or
what
the
what
systems
are
generating
those
events
that
those
systems
could
be
generating.
K
Events
that
don't
conform
to
the
specification
should
it
be
that
you
are,
you
know
just
by
default,
gonna
throw
an
exception.
Every
time
you
try
to
receive
one
of
those
events
over-
let's
say
http.
E
But
if
you're
creating
a
cloud
event,
then
that
cloud
event
should
be
precise,
as
it
goes
on
the
wire
so
receiving
so
with
receiving
when
you're
just
parsing,
something
that
comes
off
the
wire.
I
think
there's
you
can
be
a
little
bit
more
flexible
and
in
the
javascript
world
for
instance,
there
is
like,
if
you
parse
a
date,
for
instance,
there's
obviously
smart
libraries
they
can
do,
can
go
and
take
multiple
formats,
and
maybe
you
you
don't
want
to
have
you
don't
want
to
impose
that
the
time
zone
offset
etc?
I
We
we
talked
about
this,
but
in
an
sdk
call
several
months
ago
for
the
go
sdk,
because
in
goads
you
can,
you
can
have
it
direct
access
to
the
struct,
similar
to
how
javascript
works,
and
so
in
go
you.
You
can
construct
an
invalid
cloud
event
up,
but
so
there's
a
couple
layers,
the
the
client
layer
won't
send.
Won't
it
won't
send
an
invalid
cloud
event.
It
calls
a
validation
method,
it
double
checks,
all
the
fields,
it
double
checks,
all
the
extension
names.
I
It
double
checks
that
everything
can
turn
into
a
string,
the
correct
way
and
etc.
At
the
at
the
binding
layer.
I
We
don't
do
that
validation
because
it's
it's
low
level
plumbing,
and
so
you
you
could
work
around
the
sdk
and
send
garbage
on
the
wire
if
you
really
wanted
to,
but
the
event
knows
it's
bad
and
it
it,
I
don't
know
will
happen
exactly
for
for
certain
cases,
we're
missing
required
fields.
Are
there.
K
Okay,
that's
interesting,
I
mean
so
you
know
receiving
a
cloud
event
in
the
javascript.
Sdk
is
just
calling
the
cloud
event
constructor
and
so
from
what
I'm
hearing
it
seems
like
receiving
an
event
it
should
be
loose.
Maybe
when
you're
actually
just
creating
an
event,
you
know
raw
or
whatever
it
should
be
strict
or
another
option
would
be
to
have
it
be
sort
of
loose
or
no
validation
upon
creation.
K
But
if
you
wanted
to
transform
the
event
into
a
message
to
send
over
the
wire
at
that
transformation
point,
it
would
be
validated
yeah.
I
That's
right
what
we're
doing
just
because,
like
there
are
cases
where
somebody
wants
to
make
a
factory
of
cloud
events
and
they
they
construct
an
archetype,
and
then
they
mutate
the
some
inner
data
but
like
technically,
it's
not
valid
to
have
a
cloud
event
that
doesn't
have
an
id
but
there's
some
magic
in
the
cloud.
The
golang
sdk
that
will
on
its
way
through
the
client.
If
the
id
is
empty,
it'll
generate
a
uuid
for
you
and
decorate
that
and
send
it
out.
I
I
K
B
H
I
was
just
checking
last
time
we
were
talking
about
that
like
clause
and
I
had
posted
something
on
the
chat,
but
I
don't
know
if
that
was
lost.
It
was
referring
to
something
from
graphql
and
I
don't
know
if
we
closed
that
issue.
B
B
B
Okay,
so
I
guess
the
the
general
comment
I
should
probably
make
is:
please
look
through,
obviously
the
specs,
if
you
want
to
open
up
pr's
against
them,
because
we
need
things
to
work
on.
Obviously
in
next
week's
call,
but
in
particular
look
at
the
open
issues
for
discovery.
More
than
anything
else,
we
have
quite
a
few
open
and
they're.
Obviously
them
begging
prs
to
be
written
against
those.
B
There
you
go.
Thank
you
comments
at
least
fake.
Listening
to
me.
I
appreciate
that.
Actually,
I
guess
one
other
thing
so
brian
you
said
that
the
last
week
and
this
week
the
aspect
ratio
on
my
screen
looks
kind
of
funky.
Now
I
did
join
through
another
computer.
It
looks
okay
to
me.
Is
anybody
else,
seeing
like
a
squished
version
of
my
shared
screen,
or
is
it
just
brian.
B
I
This
is
better
interesting.
Okay,
we
have
expand
to
meet
their
window
instead
of
show
the
native
aspect,
ratio
of
your
screen.
I
Well,
there's
zoom
has
several
view
options.
There's
the
hostile
takeover
of
your
computer
mode.
L
B
G
B
Okay,
well
either
way
it
sounds
like
I
should
make
it
bigger,
no
matter
what,
because
you're
happy
with
this
size
right
here
right
yeah,
this
looks
great:
okay,
it's
just
a
boatload
of
extra
space
left
and
right
for
me,
but
that's
okay,
I'll
deal
with
it.
Okay,.
B
B
G
B
C
B
F
G
F
B
H
B
Okay,
I
don't
want
to
upset
scott
too
much,
so
thank
you
for
the
diversion
okay
before
we
let
everybody
go
and
we
jump
over
to
the
to
the
interrupt
stuff.
Let
me
just
do
a
couple
things.
Ahmed.
Are
you
there?
B
B
L
B
C
B
Okay,
so
I
did
put
this
document
out
there
I
think
almost
two
weeks
ago,
but
we
haven't
had
a
chance
to
talk
about
it
yet
on
any
phone
call.
Does
anybody
have
any
comments
on
this
in
terms
of
whether
the
overall
direction
seems
to
be
okay
so
far
or
anything
they
want
to.
B
B
Okay.
Obviously,
as
I
mentioned
last
time,
I
do
think
we
need
to
fill
out
more
information
here,
but
is
there
enough
for
people
to
actually
start
coding
against
it?
Are
there
particular
things
that
we
need
to
talk
about
now,
or
does
this
matter
people
finding
time
to
start
coding
and
finding
gaps.
I
Not
yet
because
I
I
think
I
am
personally
super
excited
to
see
those
those
things
come
together.
I
Will
this
force
it
to
some
extent
scott
yeah?
A
little
bit
I
mean
so
like
one
example,
is
the
discovery
api
leverages
the
subscription
api
and
the
subscription
api
can
leverage
the
the
registry
to
validate
that
you
know,
the
shape
of
events
are
correct,
correct.
E
E
I
Like
this
scenario,
looks
fine,
but
let's,
let's
look
like,
let's
think
about
introducing
the
other
apis
into
a
holistic
setup.
So
there's
like
this
is
the
mvp
scenario,
we're
focusing
on
discovery.
We
should
mix
in
subscription
api
and
then
once
that's
working,
we
should
add
a
consumer
that
validates
that
the
producer
actually
is
sending
events
that
are
in
line
with
what
the
discovery
api
is
doing,
what
it's
subscribed
to
in
the
shape
from
the
schema
registry
or
something.
B
I
B
M
Hey
folks,
sorry
to
join
late,
so
I
basically
added
myself
there
as
interested
participant.
M
I
will
definitely
start
looking
at
this
more
closely
on
the
native
side-
it's
probably
starting
next
week
and
what
I
think
scott
just
mentioned,
of
trying
to
tie
these
things
together
like
discovery
with
subscription
with
the
schema
registry,
that's
something
that
was
on
my
mind
and
I
was
starting
to
build
a
prototype
using
sort
of
the
k
native
primitives
and
build
these
apis.
On
top
of
that,
so
I
think
we
can
make
some
progress
on
this
and
I'll
be
happy
to
help
as
well.