►
From YouTube: CNCF Serverless WG CloudEvents SDK Meeting - 2018-09-18
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
Good
good
I
think
we
probably
have
everyone
who's
going
to
attend
with
a
handful
of
people
from
serverless
Inc,
so
I
think
we're
about
half
the
group
here,
but
we're
very
interested
in
this
for
doing
a
lot
of
a
lot
of
work
around
this
already
so
it'll
be
good
to
get
some
clarity
around
the
cloud
event.
Sdk
I'd
make
I,
don't
think.
We've
had
the
pleasure
of
meeting
before
what
what
company
are
you
with.
A
Okay,
fantastic,
okay;
well,
here's
where
we
left
off
last
time.
In
these
conversations
we
put
together
various
initiatives
things
we'd
like
to
address
within
the
SDK
various
groups
of
work.
Then
we
prioritized
all
of
these
and
actually
I'm
gonna
go
ahead
and
share
my
screen
so
that
it's
easier
easier
to
follow
along.
A
A
Then,
let's
go
ahead
and
look
at
the
cloud
events
version
0.1
and
usually
we
decided
were
priorities
first
and
foremost
and
again,
if
you
have
any
questions
or
comments
on
on
these,
just
just
speak
up.
So
what
we're
going
for
is
we
want
to
initially
support
at
least
three
languages.
There
are
a
handful
of
people
who
volunteered
for
this
Mathias
I
think
is
from
Red
Hat.
A
His
team
wanted
to
work
on
the
Java
implementation,
Carol
and
mark
pique
from
VMware
volunteered
to
work
on
the
go
implementation,
our
company
volunteered
to
work
on
the
Java,
Script,
nodejs
implementation,
and
then
gentleman
named
William
who
hadn't
attended
these
calls,
but
has
been
working
behind
the
scenes
on
a
cloud
events.
Sdk
wanted
to
continue
working
on
the
Python
version,
so
we
like
to
have
at
least
three
versions
and
given
if
these
people
are
still
on
board
to
to
contribute
some
work.
Hopefully
we'll
have
about
four
and
then
the
first
thing
we
want
this.
A
Payload
and
I
have
some
examples
of
that
below,
but
first
I'm
going
to
go
through
all
these
briefly
next
step
was
a
design
of
versioning
system
which
can
handle
multiple
versions
of
the
cloud
event
specification.
You
know
we
have.
We
have
a
few
different
moving
parts
here
that
all
have
different
versions
which
we
have
to
consider,
and
that
is
the
SDK
and
the
specification
first
and
foremost.
A
So
what
we
were
thinking
here
is
the
pratice
semantic
versioning
versioning,
with
the
major
the
major
number
for
incompatible
API
changes,
the
minor
number
when
we
added
functionality
in
a
backwards,
compatible
manner
and
add
in
support
for
additional
versions
of
the
cloud
events
specification.
So
the
goal
was
when
you
actually
instantiate
the
SDK.
You
specify
the
cloud
events
specification
right
at
the
right
when
you
first
configure
it
and
the
cloud
events
best
and
the
cloud
events
SDK
should
be
able
to
work
with
multiple
specs
and
then,
lastly,
patching
whenever
we
make
backwards
compatible
bug
fixes.
A
So
this
is
how
we
were
thinking
about
handling
the
SDK
and
the
specific
case
specification
versioning
issues
as
of
right
now,
however,
there's
still
some
other
issues
around
the
transport
specifications
and
now
we're
going
to
handle
that
and
then
lastly,
support
for
extensions.
You
know
we
feel
that
extensions
are
at
the
core
of
building
community
around
cloud
events.
A
B
Oh,
are
you
singing
that
theme,
at
least
for
the
major
version
numbers
that
the
SDK
itself
will
sort
of
have
a
single
version
number
for
all
the
various
languages?
So,
for
example,
what
if
say
the
go
version
makes
an
API
incompatible
change
for
some
reason,
but
the
other,
the
other
ones,
do
not.
How
do
you
see
that
being
handled.
A
I
believe
it
sounds
reasonable
to
assume
that
each
one
of
these
things
should
should
perhaps
be
version
separately
and
given
the
cloud
events,
specification
version
itself
isn't
really
related
to
this
versioning
you're,
actually
specifying
it
at
the
beginning
of
the
SDK
or
whatever
you
configure.
The
SDK
I
think
we
should
be
okay
and
allowing
these
things
to
be
version
separately.
Okay,.
B
A
D
A
A
I
think
these
are
a
good
first
steps
for
us
and
just
getting
this
done
alone
will
probably
enable
cloud
events
to
be
used
a
lot
more
easily
by
end-users.
So
that
said,
we
have
a
few
people.
Working
on
implementations
doesn't
sound
like
any
of
those
people
are
here
on
the
call,
unless
is
anyone
on
the
call
planning
to
actually
volunteer
or
contribute.
C
So
this
is
Nick
I've
been
working
on
the
NGO
version
of
the
SDK,
oh
great
and
I.
Think
for
me
the
only
thing
that
a
horn
in
my
side
at
the
moment
is
the
fact
that
the
the
defaults
kind
of
server
or
HTTP
implementations
and
go
mangle.
The
headers
right
there
is
the
hit.
The
HTTP
headers
are
supposed
to
be
case
insensitive.
So
it
essentially
assumes
that
and
canonicalize
is
what
they
call
it.
The
headers,
which
means
there's
a
particular
issue
with
extension
headers,
so
anything
that's
unknown
in
the
spec
I
can't
properly
case
the.
C
C
Cloud
event,
the
headers
that
I
get
from
that
for
all
of
the
known
properties
I
can
make
the
determination
just
lower
case
everything
and
compare
against
that.
But
if
there's
any
extensions,
there's
no
way
for
me
to
know
how
they
had
cased,
those
so
for
in
the
JSON.
If
I
were
to
do
a
change
this
to
the
JSON
encoding
I
wouldn't
be
able
to
properly
case
those
for
whoever's
going
to
consume
it
down
the
line.
B
C
At
the
moment,
I'm
just
placing
everything
into
a
map
and
assuming
that
all
of
the
keys
are
just
lowercase
anyway.
It's
when
I
want
to
then
take
that
and
produce
a
new
cloud
event
to
send
on
the
wire.
If
it's
supposed
to
be
a
you
know
a
JSON
one
and
they
whoever
wrote
the
the
extension
property
in
the
first
place
headed
you
know
intended
it
to
be
camelcase
I
before
I
even
got
to
that
point.
I've
lost
that
information.
C
B
C
Think
that
just
the
bigger
issue
in
general
is
that
headers
are
supposed
to
be
case.
Insensitive
I,
don't
know
if
maybe
a
proxy
would
get
in
the
middle,
and
you
know
change
all
of
the
headers
to
lowercase
or
you
know,
there's
any
number
of
things
could
happen
with
those
because
they're
not
defined,
as
you
know,
in
the
HTTP
spec
they're,
not
to
find
as
case
sensitive,
which
just
makes
it
a
little
bit
hard
to
assume
that
we're
getting.
C
A
D
Maybe
something
we
could
do
in
the
the
SDK,
though,
is
that
in
the
event
that
these
are
case,
insensitive
is,
to
you
know,
auto
format
before
sending
over
to
get
the
HTTP
protocol.
So
we
could,
you
know,
provide
whatever
the
guidance
is
or
or
implements
if
you
have
the
the
setting
everything
to
lower
case
the
center.
A
C
C
So
in
the
kind
of
Marshall
unmarshal
phases,
it
knows
to
search
the
event
for
the
known
types
put,
those
into
kind
of
known
struct
fields
and
then
add
anything
else.
It
doesn't
know
about
into
the
kind
of
extensions
map
and
then
just
has
a
generic
get
set
like
a
map
directly
on
the
cloud
event
that
allows
you
to
get
to
those
extra
extension
properties
does.
A
D
A
Well,
we
have
this
here
as
our
second
initiative
assembling
cloud
events
from
various
transports,
so
this
is
sort
of
covered
and
it's
expect
out
in
or
it's
prioritized
in
version
0.2,
you
know.
Perhaps
we
could
bump
it
up
to
version
0.1.
It's
my
general
opinion
that
you
know
the
people
who
are
doing
working
on
these
things
voluntarily
can
kind
of
move
at
their
own
pace
and
if
they
can
get
further
along
and
support.
Some
of
these
later
stage
features.
A
A
Yes,
that's
something!
That's
that's
very!
That's
very
interesting
and
I
know
that
we've
discussed
it
yeah.
Here
we
go
so
this
is
actually
pushed
out
to
our
fourth
biggest
priority
and
that's
transforming
existing
events
into
cloud
events
via
transformation,
mappings
and
yeah
I
think
there's
a
lot
of
interest
in
this
and
again
just
an
opinion
and
gut
feeling.
A
But
if,
if
we
made
this
really
easy
to
convert
stuff
like
s3
events
or
strike
web
hooks
or
gonna
have
web
hooks
in
the
cloud
events,
it
would
greatly
help
this
ecosystem,
but
again
I
think
that
anyone
who's
working
on
these
can
move
at
their
own
pace.
And
you
know
just
as
long
as
you
know
we
kind
of
have
some
agreement
or
some
general
acknowledgement
as
to
as
to
how
this
stuff
is
actually
going
to
work
within
the
SDKs
at
the
end
of
the
day.
So
the
experience
when
you
switch
languages
is
not
totally
different.
A
D
I
guess
yeah
I
mean
I
guess
the
way
I
kind
of
would
imagine
is
at
least
like
whatever
is
called
out
in
the
core
spec
for
protocol
purposes,
like
HCP
and
etc.
I
think
that
would
make
sense
to
have
a
core
implementation
for
and
that
the
the
SDK
would
support
this
out
of
the
box.
But
when
we
start
getting
into
things
like
your
converting
any
specific
providers,
events
that
really
starts
to
make
sense
to
me
to
leave
it
as
an
extension.
Instead.
A
Yeah
the
reason
why
I'm
suggesting
that
this
could
be
addressed,
as
extension,
is
just
because
these
things
have
their
own
specifications
and
they're
not
like
hard-coded
into
the
cloud
event
specification
itself.
There's
a
cloud
event
session.
Http
specification-
and
this
has
its
own
versioning
and
I
was
I-
was
thinking
that
perhaps
we
could
support
these
via
extensions
just
as
a
way
to
get
around
the
versioning
issue.
A
D
And
there's
also
the
site
of
I
think
you
want
to
at
least
provide
a
fair
amount
of
usefulness
out
of
the
box
for
the
SDK
without
having
to
do
much
configuration,
but
I
mean
there's
also
this
side
of
bloat
tool.
If
do
you
want
an
SDK
that,
has
you
know
every
one
of
these
things
implement
it
and
then
that
could
result
in
bloat?
So
it's
it's
got
pros
and
cons
of
both
directions.
A
C
There
is
one
thing
that
I've
kind
of
been
considering:
that's
in
the
case
that
the
this
sdk
is
going
to
be
used
in
kind
of
a
middleware
capacity
when
it
gets.
You
know,
let's
say
this
version
0.2
of
the
spec
of
the
actual
cloud
event
spec.
We
get
we're
compatible
with
1
dot
o,
but
we're
also
supposed
to
be
able
to
at
least
pass
through
the
0.1
stuff,
the
I
guess.
The
question
for
me,
then,
is
kind
of
in
doing
that.
C
C
A
And
it
has
and
it
has
backwards,
compatibility
of
concerns
as
well
right
right,
that's,
ok,
we're
probably
gonna
get
a
lot
more
older
events
and
then
perhaps
events
that
are
newer
than
the
SDK.
Although
I'm
not
sure
it's
highly
dependent
on
the
use
case
right,
then
whoever
is
updating
the
SDK
yeah
yeah.
That's
a.
D
Tricky
one
it
I
think
we
talked
about
a
little
bit
about
this.
Before
too
I
mean
you
can
spit,
you
can
specify
a
obviously
the
version
of
the
protocol
that
you're
trying
to
adhere
to
inside
of
the
SDK
but
I
think
in
reality.
It's
really,
you
may
be
trying
to
deliver
to
multiple
different
sources
and
you
may
want
it
to
be
able
to
kind
of
toggle
on
demand.
D
A
A
D
It
might
be
worth
maybe
generating
a
set
of
use
cases
from
the
SDKs
perspective,
such
as
delivering
to
a
new,
an
issue
where
it
does
not
know
the
protocol
delivering
to
multiple
different
versions.
You
know
the
protocol
yeah
just
you're
kind
of
walking
through
what
we
potentially
see
the
combination.
These
cases
are,
and
then
we
could
use
that
as
a
to
open
up
an
issue
in
the
actual
cloud
that
spec.
D
E
D
A
A
A
D
I
have
to
think
about
a
little
bit
I'm
having
to
draft
up
some
use
cases
in
this
talk
that
we
could
potentially
review
in
the
yet
the
next
call
or
whatever,
and
then
I
could
spend
a
little
bit
of
time.
Thinking
on
what
some
basic
solutions
might
be,
you
know
I
think
it
mainly,
though
I
think
this
is
definitely
an
issue
that
it's
not
just
an
sdk
issue.
This
is
a
certain
potentially
certainly
a
protocol
issue
as
well,
and
it
made
me
worth
surfacing
that
to
the
larger
group
yeah.
A
That's
what
this
that's!
Oh,
these
issues
sound
like
mostly,
and
it's
good
that
we're
running
into
these,
and
because
everybody
needs
to
be
aware
of
these
okay
Brian,
if
you
could
draft
out
a
couple
of
those
just
put
them
if
you
could
put
them
here
in
the
in
the
next
steps
section
somewhere
sure
thing
that'd
be
great
awesome,
thank
you
and
then,
as
far
as
what
we
can
actually
tackle
today,
it
sounds
like
we
could
still
do
some
of
this,
like
basic
instantiation
to
finding
getters.
Instead.
A
So
the
extensions
experience
in
the
SDK
may
not
add
metadata
it
may
or
may
not,
but
it
could
also
add
functionality
to
the
SDK
and
we're
interested
in
this,
because
we
have
a
middleware
product.
We
have
the
event
gateway
and
we'd
like
to
build
an
extension
that
allows
people
to
easily
just
publish
events
via
the
cloud
events
SDK
by
simply
adding
in
our
extension
and
if
they
do
that,
it
will
probably
also
add
some
metadata
to
the
cloud
events
envelope.
Regarding.
That's
that
that
works
with
the
SDK
and
helps
generic.
A
B
You
can
hear
me
now:
hey
Doug,
yep,
Hey,
okay,
sorry
about
that
earlier.
That
was
I
kind
of
envisioned
this
as
being
sort
of
like
the
person
who
who
invokes
or
sets
up
the
SDK
concept
at
the
list
of
handlers
for.
B
Processing
at
the
event,
and
then,
as
you
said,
it
could
do
whatever
it
wants
to
with
the
event
whether
it's
to
actually
modify
it
as
necessary
or
to
do
additional
processing
doesn't
really
matter
it's
up
to
the
hailer
designer
to
define
that,
but
the
SDK
just
to
have
the
basic
infrastructure
to
go
plug
in
a
list
of
handlers.
Both
inbound
and
outbound
mm-hmm.
D
I
agree,
I.
Think
I
really
compare
this
to
you
know
middleware,
similar
to
middleware.
That
goes
into
something
like
Express
and
in
reality,
yeah
I
think
each
handler
gets
an
opportunity
to
be
able
to
manipulate
the
event
and
then
passes
it
to
the
next
middleware
in
the
one
I
think
it's
probably
going
to
be
one
of
the
simplest
implementation,
so
you
can
come
up
with
least
for
the
JavaScript
world.
How
that
looks
in
the
other,
SDKs
I
think
would
be
a
different
question.
C
Excuse
me,
so
what
what
you're
saying
sounds
very
reasonable
kind
of
being
able
to
wrap
the
actual
kind
of
set
and
receive
in
a
number
of
middleware
layers.
I
think
the
one
thing
that
we
would
want
to
make
sure
we
do
is
is
have
a
way
of
defining
which
of
those
layers
gets
priority
right
so
which,
which
one
gets.
A
Okay,
in
my
experience,
architecting
extensible
systems
I've
never
found
a
silver
bullet
solution
to
had
a
load,
all
the
all
the
modules
that
offer
that
extensibility
in
a
way
that
they
don't
totally
conflict
I
mean
usually
the
solution
that
I've
seen
is
just
you.
You
know
the
user
can
specify
the
order
in
which
each
are
loaded,
but
as
far
as
whether
or
not
they'll
all
work
together
very
well
and
not
you
know,
create
conflicts.
It's
it's
always
a
bit
of
a
challenge.
Does
anyone
have
any
other
thoughts
on
how
we
could
approach
that
problem?.
A
D
That's
what
I
was
I
was
thinking
is
that
the
transformations
themselves
I
mean
whether
or
not
we
decide
to
make
transformations
a
core
piece
versus
making
it
a
yeah.
An
extension
I
think
this
is
also
a
question,
but
one
you
know.
One
thing
that
could
happen
obviously,
is
that
the
the
extensions
you
could
have
the
ability
to
be
able
to
plug
in
you
have
transformations
and
those
kinds
of
things
so
yeah
I
play
around
with
what
what
looks
best
there
as
we
go
through
the
SDK
implementation.
D
One
question
regarding
versioning,
so
the
extensions
are
also
going
to
have
to
be
able
to
deal
with
versioning
and
understand
which
version
of
the
event
they
are
dealing
with.
I
am
guessing
that
that
information
will
obviously
be
on
the
event
itself,
but
I
don't
know
if
there's
anything
specific
that
we
would
need
to
consider
in
our
extension
design
for
using
that
that
concern.
A
You
know
perhaps
allowing
the
extensions,
of
course,
to
inspect
the
version
on
the
cloud
event
itself
and
also
expecting
extensions
to
be
designed,
so
they
can
handle
multiple
versions.
At
the
end
of
the
day,
it
sounds
like
dealing
with
multiple
versions
of
of
cloud
events
is:
is
the
inevitable
outcome
of
a
lot
of
this
yep.
D
Totally
agree,
I
think.
The
one
thing
that
I
would
say
is
that
it
is
very
likely
that
you
might
end
up
dragging
an
extension
that
does
not
know
how
to
handle
the
version
of
the
event
that
is
flowing
through
it,
and
so
what
we
might
want
to
be
able
to
do
is
allow
for
extensions
to
indicate
which
versions
about
the
cloud
events
spec
that
they
handle
so
that
it
can.
You
call
out
just
during
initialization
that
hey
I'm
incompatible
with
the
second
version.
A
A
All
right
we
covered
we've
covered
most
of
this
and
we
surfaced
yeah
I
think
our
biggest
issue
is
just
in
handling
versioning,
that's
the
biggest
source
of
uncertainty
right
now.
It's
definitely
gonna
be
a
definitely
to
be
a
blocking
issue
until
we
until
we
figure
that
out
and
hopefully
once
we
do
so,
we'll
all
you
know
implement
our
SDKs
in
accordance
with
what
we
decide.
So
that
should
make
things
a
lot
easier
because
at
the
end
of
the
day,
there's
a
lot
of
different
moving
parts.
A
C
A
A
Okay,
good
to
know
all
right,
I'm
gonna
circle
back
to
Matias,
from
Red,
Hat,
they're,
doing
the
Java
implementation
and
then
also
tracked
down
William
who's.
Doing
the
python
implementation,
but
I
think
now
is
a
good
time
to
start
putting
these
into
the
github
org
somewhere.
So
everyone
knows
where
to
look.
Hopefully
this
will
increase
engagement
from
everybody
else.
A
Okay,
so
review
priorities,
inversions
checked
in
an
ongoing
work.
On
our
end,
our
company
wants
to
focus
on
the
JavaScript
version
of
this
we're
also
very
open
and
eager
to
put
this
into
the
cloud
events
Oregon
get
up.
So
just
so,
everyone
knows
we
discussed
gating
again
every
pose
on
github.
We
discussed
some
of
these
versioning
issues.
We
have
to
raise
these
within
the
context
of
the
the
call
on
Wednesday
we
kind
of
discussed
how
extensions
will
work
within
the
SDKs.
A
You
know
for
next
steps,
I
propose
that
we
all
go
out
and
do
an
implementation.
You
know,
based
on
the
information
that
we
have
on
the
things
that
we've
discussed
here
and,
at
the
same
time,
on
a
parallel
path.
We
try
and
figure
out
how
to
handle
the
versions
at
the
end
of
the
day,
and
hopefully
we
make
some
progress
on
that
on
Thursday
and
then
we
scheduled
another
call
just
to
check
in
on
progress
and
see
if
any
other
issues
come
up
and
figure
out
a
move
forward
from
there.