►
From YouTube: CNCF Serverless WG 2020-12-10
Description
CNCF Serverless WG 2020-12-10
A
A
A
E
A
F
H
A
H
A
A
A
I
know
that
to
a
lot
of
people,
they
kind
of
start
their
vacation
around
the
15th
or
so
that
gives
like
two
full
weeks
for
the
end
of
the
year,
but
the
15th,
I
believe,
is
like
tuesday
or
something
like
that.
Do
you
want.
Does
anybody
want
to
have
a
call
next
week,
or
should
this
be
the
last
one
for
the
year?
A
A
A
A
A
Yeah,
I
think,
okay,
I'm
not
hearing
anybody
really
say
but
they're
anxious
for
a
call.
So
let's
just
say
this:
is
it
okay,
cool
all
right
community
time
anything
from
the
community?
People
want
to
bring
up
all
right,
sdk
call
was
last
week.
I
think
we
just
talked
about
the
trace
extension,
a
little
plain
cycle,
questions
on
that
anybody
have
any
questions
for
the
sdk
subgroup
all
right.
Moving
on,
then
we
technically
have
a
discovery.
Interop
call
after
this
one.
A
J
All
right
I'll
make
this
quick,
yeah
we're
working
basically
currently
on
the
roadmap
for
our
0.6
release.
So
there's
a
lot
of
stuff
going
around
that
the
only
other
thing
is.
We
had
a
ton
of
contributions
for
our
go
sdk,
so
that
was
big
and
if
anybody
is
also
in
this
call,
thank
you
so
that-
and
I
also
just
want
to
mention-
we
only
have
a
couple
days
left
for
kubecon
eu
stock
submissions
right
so
kind
of
trying
to
figure
that
out.
A
A
All
right,
in
that
case
I
opened
up
a
pr.
I
apologize
that
it
was
a
little
late
on
this,
but
I
didn't
expect
too
many
people
to
care
for
version
101
and
here's
a
list
of
all
the
significant
pr's.
I
did
kind
of
drop,
all
the
ones
that
were
like
typo
in
nature
did
any.
Does
anybody
have
any
concerns
notice
anything
wrong
in
the
diff
here?
A
A
All
right
not
hearing
anything,
actually
cool.
Thank
you.
Everybody!
Congratulations
to
oneroll,
okay,
so
on
last
week's
call
we
agreed
to
rename
the
master
branch
dev.
However,
when
I
tried
to
make
the
change,
I
did
not
realize
what
would
happen
and
it
basically
closed
all
pr's
that
were
associated
with
the
master
branch.
I
kind
of
assumed
that
we
get
migrated
over
or
something
like
that.
Well,
it
didn't
so
I
recreated
master
branch
and
that
and
then
I
re-brought
back
all
those
pr's
back
to
life.
A
So
we
were
back
to
a
happy
state
and
I
did
some
looking
around
and
I
believe
github
is
working
on
some
migration
tool
or
something
to
help
with
this
situation.
I'm
assuming
they'll
do
some
sort
of
migration
thingy.
So
until
that
happens,
or
until
we
actually
close
all
of
our
pr's,
I
don't
think
we
can
easily
make
the
the
name
change
unless
you
want
to
force
everybody
to
redo
their
pr's,
which
I
don't
want
to
do
quite
yet
because
I
don't
think
that's
necessarily
urgent
to
do.
A
A
K
K
Do
a
project
to
continue
the
efforts
of
the
integration
tests,
so
I
suppose,
as
probably
somebody
of
you
recall
at
some
point,
we
discussed
about
conformance
tests
kind
of
tck
for
the
sdks,
but
nobody
had
a
chance
to
continue
that
that
effort.
So
I
don't
know,
maybe
it
might
be
something
cool
as
a
summer
core
project,
another
project
could
be
developing
a
new
sdk
with
some
language
that
we
still
don't
support.
I
I
have
some
examples
that
I
can
provide
and
I
think
that
might
be
another
interesting
project
so
well.
K
A
K
K
L
I'm
pretty
sure
that
we
can't
do
that
from
a
legal
perspective,
because
the
point
of
us
being
here
is
that
we're
a
neutral
venue-
and
it
would
be
really
weird
if
we
as
a
community-
would
be
then
contributing
to
projects
that
are
effectively
breaking
that
breaking
the
setup,
because
ultimately,
we
would
be
contributing
into
a
effort.
That's
run
by
one
company.
A
K
K
L
K
If
you
put
it
on
this
way,
I
mean
I
personally,
I
personally
don't
care.
If
I
think
yeah
the
effort
is
interesting
and
we
can
get
as
a
community.
We
can
get
something
from.
It
said
that
I
I
don't
care.
If
you
come
and
you
say:
look
I
we
wanna,
I
wanna
do
the
microsoft
thingy
about
contributing
to
operators,
so
we
wanna
do
the
redux
thingy
contributing
operators.
I'm.
L
Okay
with
that,
I
don't
care
about
that.
It's
either
my
my
question
in
those
things
is:
why
are
they
doing
that
like
like?
What's
the
end
game
here
and
there's
always
the
end
game
in
those
things,
so
google
is
not
doing
that
because
they're
they're
really
nice,
I
mean
they
might
be
doing
that
because
they're
really
nice,
but
ultimately
there's
a
motivation
behind
those
things
and
and
what
you're
contributing
to.
L
I
L
I
C
A
K
A
A
A
A
Is
that
the
so
the
first
is
friday.
I
assume
everybody
has
the
first
or
everybody's
gonna
first
off,
because
that's
new
year's
day,
where
people
will
most
people
be
taking
off
the
first
week
in
january.
The
fourth
through
the
8th,
so
the
first
day
should
be
the
14th.
Or
do
you
want
the
first
meeting
to
be
on
the
7th.
A
I
need
I
need
some
people
to
speak
up
here
because
I'm
I'm
hearing
a
little
more
towards
the
14th
but
14.
okay,
okay,
I'm
hearing
a
soft
leaning
towards
14.
Anybody
have
a
strong
disagreement
with
that
and
would
really
really
want
to
meet
on
the
seventh
okay,
we're
going
to
go
for
the
14th,
then
thank
you
all
all
right
so
back
down
to
here.
Okay,
I'll
talk
to
chris
and
see
why
this
is
okay
from
a
legal
perspective
or
you
know
even
a
perception
perspective.
L
K
H
A
K
B
K
K
L
L
K
Yeah,
but
when
I
struggle
to
see
us
how
creating
a
sql
dialect,
it's
really
using
a
standard,
because
here
we
are
just
saying:
hey,
look:
weaver
use
the
same
syntax,
the
same
grammar
of
of
another
standard,
but
in
fact
the
language
is
different
and
the
evaluation
is
different.
So
how?
How
are
we
really
reusing
sql
if
we
go
down
the
road
sql.
L
L
K
L
It
does
it's
not
about
the
code,
it's
about
the
user
users.
Okay,
if
you
put
their
stand
so
users
of
of
users
have
to
do
with
messaging
systems
which
we're
dealing
with
here
and
who
are
familiar
with
familiar
with
gms,
for
instance,
which
is
the
predominant
api
for
messaging,
because
most
people
are
using
java
are
familiar
with
message:
selectors
and
that's
using
a
sql
language,
so
you're
picking
picking
up
a
lot
a
large
number
of
users
exactly
where
they
are
with
something
that
they
know.
L
That
is
like
that's
like
do
you
want
it's
same
thing
as
with
databases
right
everybody
has,
and
I
think
I
said
that
last
time
we
went
from
sql
to
oh
sequel
is
not
a
sql
is
bad,
and
so
therefore
we
should
go
and
do
our
own
thing
for
about.
You
know
three
or
four
years,
and
now
every
database
is
doing
sql
again.
L
If
you're
looking
at
stream
analytics
everybody's
doing,
sql
spark
is
doing
sql
as
samsa
is
doing.
Sql
confluent
is
doing
sql
everybody's
doing
sql.
There
is
no
reason
why
we
should
where
we
should
go
and
invent
a
new
thing.
That
is
just
that
is
just
different
because
it's
cloud
events.
Yes,
there
might
be
data
like
differences,
but
their
sql
has
won
all
the
wars
on
the
database
front
as
well
as
in
in
is
now
winning
in
streaming.
K
I
Would
be
more
on
the
thing
he
said,
I
think,
like
jason
puff
in
a
way
is
better
than
our
distant
query
would
be
better
than
sql.
If
you
look
at
like
people
who
really
just
do
javascript
because
of
like
all
the
nosql,
I
think
they
do
less
sequel,
like
at
least
I
do
way
less
sequels
than
I
used
to
do
15
years
ago,
but
your
arguments
are
still.
L
Good
guys
you
have
to
you
have
to
you,
have
to
take
a
look
at
what's
happening
in
the
event
in
eventing
space
right
in
in
eventing
we're
having
we're
having
a
we
have
giant
fights
in
in
terms
of
who's
building
the
better.
You
know,
event
analytics
analytics
platforms
and
all
of
them
all
the
abstractions
are
all
using
sql
like
there
is
you
have
you
have
apache
beam
as
a
top
abstraction,
as
I
said,
you
have
spark
and
sensor
and
storm
and
k-sql
and
and
all
of
those
are,
and
you
have
azure
stream
analytics.
L
L
A
No,
that's
fine
because
you
guys
usually
are
good
about
this
stuff.
Just
wanna
remind
people.
So
I
have
a
question.
Would
it
be
useful
to
help
come
to
the
to
to
an
answer?
If
we
can
actually
see
examples
in
both
sql
and
the
alternatives
that
people
are
proposing,
so,
for
example,
slinky
you
were
proposing
javascript
or
some
variant
of
javascript
kind
of
thing.
A
It
would
help
me
out
if
I
could
actually
look
at
what
the
two
look
like,
because
I
obviously
understand
the
desire
for
standards.
That's
why
we're
here,
but
it
is
100
clear
to
me
how
it
would
look
and
feel
from
a
sql
perspective.
I
kind
of
guess
what
it
would
look
like,
but
I'd
love
to
know
for
sure.
Just
by
saying.
Okay,
if
you
want
to
do
a
filter,
I
want
all
cloud
events
that
have
a
type
of
this
and
another
attribute
matching
this
or
a
type
of
this,
or
not.
A
To
imagine
that
just
see
how
the
and
ors
look
in
the
choice
of
languages
just
to
see
what
they
look
like,
because
I
think
that
would
help
me
out
because
I'm
all
for
standards
when
they
make
sense
and
if
we
look
at
the
sql
one
it
says.
Oh,
my
god.
Yes,
it's
great
at
the
standard,
but
my
god
that
that
that's
painful
to
use
and
unnatural,
then
I'm
not
as
inclined
to
do
it.
But
if
it's
simply
a
minor
syntactical
difference
between
sql
versus
javascript,
then
that
worry
is
lessened
to
me.
K
K
L
L
The
next
one
is
all
the
all.
The
parentheses
are
the
same
and
then
first
name
equals
francesco
and
last
name
equals
guardiani
or
subject
equals.
So
single
equals
then
case
incident
insensitive
equals
is
a
is
a
collate,
but
that's
not
in
that's
actually
not
in
the
subset.
That
has
that
jms
has
also
because
that's
case
insensitive
case.
Extensive
comparisons
are
just
too
hard
and
that's
why
nobody's
doing
them
on
the
on
the
hot
path
time
year
would
be
daytime.
L
There's
a
daytime,
subset
operator
that
will
give
you
then
the
year.
There
is
no
conversion,
because
everything
is
utc
by
default
and
then
sequence
equals
10,
so
simple,
equal
and
there's
no
and
there's.
No,
all
the
all
the
type.
All
the
typing
is
implied
implied.
There's
there's
inference
rules
in
sql,
but
you
can
cast
you.
Can
you
can
you?
Can
you
can
type
guest,
okay.
A
L
N
L
N
B
B
So
so
I
don't.
I
don't
think
I
don't
think.
History
has
been
kind
to
people
fighting
against
squeal
for
these
kinds
of
problems,
and
you
know
I'm
not
the
biggest
squeal
fan
in
the
world,
but
that's
just
the
way
things
have
worked
so
yeah.
You
know,
I
guess
from
that
standpoint,
I'm
I'm.
I
guess
I'm
throwing
in
with
clemen's
argument.
A
A
F
Oh
I'd
like
to
propose
a
different
way
to
solve
this
problem.
I
mean,
I
don't
know
if
everybody
agrees
to
that.
So
let's
pick
it
from
usage
perspective,
so
considering
our
current
use
case
that
when
we
want
to
put
this
expression,
language
or
sql
in
terms
of
user,
we
need
to
understand
that,
where
are
we
going
to
place
it
from
the
user
experience
perspective?
F
So
if,
for
example,
we
want
to
put
these
syntax
in
the
url
of
sub
of
the
discovery
api,
the
subscription
api,
we
have
to
probably
ask
ourselves
that:
do
we
want
to
go
ahead
with
these
operator-based
syntax,
or
do
we
want
to
put
an
entire
sql
query
into
that
url?
So
I
think,
then,
that
would
give
us
a
better
perspective
that
which
protocol
should
we
follow
in
terms
of
you
know,
filter
criteria.
L
F
F
Yeah
that
makes
sense
too,
but
now
we
would
have
another
third
standard.
If
you
all
so,
I
see
your
point
as
well
like.
If
we
introduce
another
standard,
then
we
probably
bring,
I
don't
know
third
or
fourth
standard
in
the
community
for
filter
criteria
itself
like
so,
for
example,
we
have
the
sql
standards,
then
we
have
the
data
standards.
They
also
have
rewritten
their
entire
expression
logic.
F
A
J
A
A
L
I
muted
myself
in
the
most
at
least
opportune
moment
goes
to
the
start
of
section
six:
okay
yeah,
as
you
see,
defining
a
language
like
this
is
actually
hard
because
I
had
to
start
from
the
bottom,
because
I
couldn't
lean
on
the
jms
spec,
so
I
had
to
have
to
do
the
whole
thing
with
with
type
inference,
etc.
So
the
simplest.
So
the
simplest
expression
here
is
color
blue,
which
is
assuming
a
so.
L
This
is
for
an
mqp
message,
so
this
is
referring
to
the
default
section,
which
is
the
application
properties
section
and
that's
how
you
can
go
and
filter
that
you
have
a
message
where
it
has
an
application
property
and
that's
called
color
and
whether
that
is
blue.
That's
what
that's
doing
and
then
there's
special
shorthands
here
to
refer
to
the
various
sections
of
an
mdp
message,
which
is
not
the
case
that
we
don't
have
that.
So
we
would
only
have
the
simplest
case
and
then
you
can
go
and
further
down.
You
have
so
the
field
two.
L
If
that
is
equal
test
and
the
content
type
li
is
like
application.
Json,
which
means
that's
a
prefix
or
plus
json,
exists
as
an
infix,
so
you
could
go
and
filter
that,
and
then
you
can
also
say:
if
two
is
test
and
the
content
types
are
like
this
and
the
color
is
blue
or
red,
then
you
filter
that.
So,
if
you
want
to
go
and
build
effectively
subscription
filters
using
that
language
you
can
also.
You
can
also
do
that
and
you
would
only
with
cloud
events.
L
And
so
this
keeps
going
down
like
if
you
scroll
a
little
bit
further
time
stamps,
and
then
here
are
the
grammar
elements.
So
there's
there's
is
predicates
in
predicates
like
predicates
exist,
predicates,
that's
one,
the
one
that
we
had
and
then
we
have
all
the
various
operators
that
are
defined
comparison.
Operators
that
are
defined.
L
O
Yeah,
I
did
my
failure
of
sql.
I
never
liked
the
capitalized
and
then
the
whole
syntax.
I,
as
as
I
understand
it,
we're
just
using
the
conditions
here
right.
So
this
is
not
really
that
heavily
sql
based,
and
I
wonder
so
in
all
of
what
I've
seen
from
the
document
I
tried
to
open
it
myself
couldn't
find
it.
How
do
you
go
with
arrays
and
stuff
like
that?
So
if
you
have
really
complex
expressions
over
multiple
elements
in,
I
don't
even
know.
If
we
have
that
included,
I
mean
cloud
events
themselves.
L
We've
exp,
so
structures
are
flat
and
there
are
there.
There
are
some.
There
are
some
scenarios
where
you
can
go
and
drill
into
a
structure
like,
for
instance,
you
have
these
like
this,
the
you
have
these
top
el
top
top
level
elements
that
are
the
application
properties
section,
the
property
section
and
the
annotations
etc.
L
O
L
O
K
Yeah
I
wanted
to
reply
to
anish
comment
about
and
not
creating
a
new
spec.
I
mean,
if
understood
currently
what
comments
is
saying
about
sequel.
We
still
need
a
spec
like
the
one
that
now
doug
is
showing
on
the
screen,
so
we,
which
is
taylor
for
call
events,
am
I
right
clemens,
because
there
are
some
differences
so
still.
L
Yes,
absolutely
we
need
to.
We
need
to
have
a
we
need
to
have
a.
We
need
to
have
a
spec.
Clearly,
it's
just
that.
What
I'm?
What
I'm
arguing
is
that
we
should
not
go.
We
should
try
to
align
with
something
that
exists
in
terms
of
concept,
concepts
and
and
and
ideas
that
developers
need
to
deal
with
instead
of
straying
from
from
others,
and
it
should
also
be
possible
to
go
and
reuse
functionality
implemented
in
in
existing
messaging
infrastructure.
L
So
if
we
can
filter
cloud,
if
we,
if
we
can,
if
we
can
shape
this
cloud
event,
spec
such
that
we
can
leverage
those
implementations
already,
that
would
be
great.
That
still
means
that
we
have
to
go
and
write
a
spec
that
will
have
to
define
define
that
sufficiently
good
for
for
for
new
implementations.
A
H
A
I
I
I
guess
from
my
perspective,
I'm
not
seeing
much
of
a
difference
between
the
two.
I
got
to
be
honest,
slinky
aside
from
the
syntactical
difference
of
things
like
ore
versus
double
you
know,
vertical
bar
and
and
versus
double
and
sign.
Is
there?
Is
there
a
cement?
Is
there
a
semantic
difference
that
you
see
between
the
two
or
is
it
strictly
sync
tactical
to
me.
K
I
see
the
syntax
difference
as
the
big
one,
because
if
we,
if
we
then
define
our
own
dialect,
we
can
match
the
semantic
in
the
way
we
want,
so
we
can
align
the
semantic
to
the
expected
usage
of
the
language.
So
for
me,
it's
very
the
most
important
thing
here
is
the
syntactic
difference
and
also
don't
see
that
big
ability
to
reuse
stuff
later
so
I
don't
know
for
me,
it's
really
a
syntactic,
syntactical,
difference
and
and
syntax
is.
K
B
Your
hands
up
yeah,
so
I
was
going
to
ask
so
if
you're,
if
your
focus
is
primarily
on
the
syntax,
what
do
what
about?
What
do
you
think
of
clemens
arguments
around
being
able
to
you
know
I
don't
know
entice
the
the
broker
people
to
more
aggressively
adopt
cloud
events
because
they
can
reuse
stuff.
They
already
have
whether
either
it's
directly
or
very
close
that
that
seems
like
a
pretty
important
argument
to
this
discussion.
K
B
So
you
know
it's
trying
to
you
know:
how
much
are
we
trying
to
tailor
to
javascript
people
that
that
are?
You
know,
I
don't
know
very
opinionated
I'll,
say
it
that
way
versus
you
know
it
is
an
ecosystem
and
the
dominant
players
in
the
ecosystem
have
already
more
or
less
converged
on
a
solution
and,
like
I
said,
I'm
not
a
I'm,
not
a
squeal
fan.
So
this
is
not
coming
from
that
bias.
J
I
just
wanted
to
quickly
say
it
has
a
counter
argument,
not
only
for
javascript
like,
for
example,
in
the
business
automation
java,
runtimes
that
I'm
kind
of
writing
for
a
couple
of
them.
It's
much
easier
for
me
to
say.
Okay,
we
will
implement
cloud
events
and
the
cloud
events
expression,
language,
which
I'm
sure
the
sdks
will
provide
implementation
for
them,
including
sql
libraries
that
I
don't
know
who
is
going
to
actually
or
whose
library
I'm
going
to
have
to
pull
in.
I
So
we
could
also
just
say
there
is
like
two
specifications,
one
that
is
the
sequel
one
and
another
one
that
is
like
the
expression
language
and
we
just
say,
define
the
way
they
are
supposed
to
work
and
then
as
it's
optional
depending
who
wants
to
implement
what
and
then
it's
just
based
on
the
product.
No.
A
So
so
my
hands
up,
because
that
I'm
having
flashbacks
to
the
ws
star
soap
days
where
everybody
said
you
know
which,
which
security
measure
you
use
is
optional.
You
know
they're
all
optional,
pick
your
favorite
one
and
and
that's
great
and
the
problem
was
there's
zero
interoperability,
that's
right
and
and
that
personally
that's
what
I'd
like
to
avoid.
If
we're
gonna
have
a
language,
I
think
there
should
be
a
single
common
one
that
you
know.
A
A
K
A
No,
I
I
think
we
need
to
make
sure
that
for
each
one
we
show
the
full
feature
set,
that
we
want
to
support
right.
So,
for
example,
if
your
definite
your
your
language
here
supports
something
that
that
the
sql
one
doesn't
then
and
that's
important
feature
to
us
or
if
you
think
that's
an
important
feature,
then
let's
put
that
in
there
and
say
here's
what
yours
looks
like
sql
has
no
equivalent
is
that
okay
with
people
or
people
are
going
to
look
at
that
and
say
no.
A
A
L
L
A
Okay,
I
don't
know
what's
on
the
difference
on
the
down
here,
maybe
it's
a
spaces
thing
or
something
anybody
have
a
problem
with
this.
I
mean
this.
Isn't
this
in
the
scheme
of
disrespect,
so
it's
not
in
one
of
the
1.0
specs
or
anything.
Anybody
see
a
problem
with
this
typo
any
objection
to
approving,
even
though
it's
technically
a
relatively
new
pr,
it
seems
like
an
easy
one:
okay,
wait!
A
A
E
G
So
I
didn't
it's.
This
issue
was
raised
by
one
of
my
colleagues,
so
c
pierce
is
one
of
my
colleagues,
and
here
we
look
together
at
this
rfc
document
and
actually
there
it's
separate
so
the
the
sign
and
the
number
are
listed
separately.
So
if
you
just
refer
to
this
in
component,
it's
really
without
sign
without
minus.
A
Okay,
so
tell
you
what
this
one
was
just
opened
yesterday,
so
what
I'll
do
is
I'll
say
it's
conditionally
approved
I'll,
get
people
through
friday
to
to
look
it
over
okay,
but
it
does
seem
like
I'm
very
one.
Very
small
and
conditional
okay,
cool
other
ones,
are
still
working
progress.
I
think
clemens
you
have
the
bottom
two
that
are
supposed
to
be
worked
on
and
there's
some
discussions
going
offline
about
this
one.
So
we'll
talk
about
that.
So
with
that
hold
on
a
second
here,
sanjay,
are
you
still
there
yeah,
I'm
here?
A
L
L
L
A
A
Yeah,
I
don't
I
don't
honestly,
I
don't
have
any
updates
either
other
than
at
least
I
I
have
an
endpoint
up
and
I'm
waiting
for
someone
else
to
put
up
their
endpoint
that
I
can
talk
to
because
redmi's
endpoint
was
having
issues.
Scott's
endpoint
wasn't
using
valid
urls.
So
I
have
no
one
to
test
against.
A
Well,
in
that
case,
we
can
make
this
really
quick
by
me
just
asking
the
question:
does
anybody
have
any
updates
or
comments
or
anything
that
they
want
to
talk
about,
because
I
feel
like
at
this
point?
It's
just
a
matter
of
people
need
to
find
the
time
time
to
code
this
up
or
we
need
to
actually
be
a
little
more
explicit
in
terms
of
what
we're
going
to
be
testing
in
terms
of
the
interop
flow.
You
know
like
which
exact
semantics
we're
going
to
be
testing
like.