►
From YouTube: CNCF CloudEvents SDK Meeting - 2018-06-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
A
B
A
A
A
Great
to
meet
you
we're
just
kicking
it
off
right
now
and
I
just
pasted
the
Google
Doc,
where
we're
putting
notes
ideas,
everything
into
yeah,
yeah
I,
see
it's
being
a
baited
life
right
now,
yep,
that's
right
cool.
So
to
start
from
the
beginning.
The
reason
why
we're
doing
this
is
because
we
came
out
with
this
great
specification
for
coming
up
with
a
common
envelope
for
event
data
and
it's
gotten
a
lot
of
attention
already,
but
we
need
to
make
it
easier
for
people
to
use
in
a
natural
step.
A
A
natural
next
step
is
usually
to
create
some
SDKs.
When
polling
the
service
working
group
and
the
cloud
events
group,
it
seemed
like
a
whole
bunch
of
people
were
already
making
SDKs.
They
were
just
going
off
and
kind
of
doing
it
in
isolation,
so
we
thought:
hey,
let's
bring
everyone
together
and
see
if
we
could
kind
of
you
know,
outline
some
priorities
and
some
design
goals
for
this
thing,
and
maybe
we
can
collaborate
on
these
things
together.
So
that's
the
you
know,
that's
the
the
premise
for
all
this:
the.
A
Great,
maybe
I'll
jump
in
real
quick.
My
name
is
Austin
Collins
I'm,
the
author
of
a
piece
of
software
called
the
surplice
framework,
pretty
popular
open
source
project
and
also
the
CEO
and
founder
of
a
company
called
surplus
ink
been
involved
for
the
service
working
group
for
a
long
time
as
well-
and
you
know
our
company
works
on
vendor
agnostic
abstractions
to
help
people
build
service
applications
across
any
service
infrastructure
provider.
We
care
a
lot
about
standardizing
some
of
the
popular
concepts
within
service
architectures,
because
we
believe
a
lot
in
vendor
choice.
A
We
want
to
make
it
easier
for
all
developers
to
use
service
infrastructure
across
providers
without
having
to
kind
of
get
familiar
with
all
the
platform
quirks
become
respected
platform
experts.
They
should
just
have
this
common
experience
for
deploying
you
know,
service
functions
or
using
other
service
infrastructure
across
providers,
and
that's
one
about
that's
one
of
our
big
goals.
F
Alright
I
could
do
next,
so
I'm,
Carla
I'm,
also
with
with
VMware
and
I,
also
worked
with
on
project
dispatch
like
like
Mart
I
was
I
was
involved
in
in
the
events.
Work
for
dispatch
and
I
actually
implemented
the
first
version
of
cloudy
beds
and
in
this
patch,
what
I'm
looking
forward
to
is
is
SDK
helping
with
first
of
all
tracking
this
back,
of
course,
to
be
able
to
you
know
version
the
decay
would
with
the
spec,
so
I
don't
have
to
follow
the
changes.
G
Can
go
next.
My
name
is
Matias
Beth
Murph
I'm
was
ran
out
today.
I
have
two
co-workers
here,
because
we
are
at
a
face-to-face
meeting.
We
started
looking
at
cloud
events
from
messaging
perspective.
One
of
the
motivations
was
also
that
in
the
Java
Enterprise
ecosystem,
there's
two
micro
profile
initiative
and
they're
going
to
start
a
new
messaging
specification.
That's
not
JMS,
and
one
of
the
idea
goes.
There
was
as
well
that
for
eventing
it
could
be
modeled
after
the
concept
of
cloud
event
yeah.
When
we
were
digging
into
this.
G
E
Probably
not
I
joined
late
klaus
here.
Oh
my
gosh
applause,
Tyson
I
work
for
sa
p.
You
are
contributing
to
uq
place
and
I
am
currently
starting
to
play
around
with
cloud
events
for
Q
plus
and
of
course,
I
am
yeah,
I.
Suppose
everybody
playing
with
cloud
events
right
now
is
starting
with
the
same
thing.
So
somehow,
working
with
those
attributes
we
defined
so
far
and
and
so
on-
and
maybe
that's
quite
repetitive,
so
yeah
I
would
be
happy
to
see
that
if
some
common
libraries
somehow
evolve.
H
A
B
A
All
right
great
to
have
you
I
think
that's
everybody.
Let's
go
ahead
and
jump
into
the
agenda
here
and
I'm
wondering
if
anyone
asked
feedback
on
this
agenda,
here's
just
kind
of
how
I
thought
this
could
work.
We
list
out
the
use
cases
for
the
SDK,
there's
already
a
pretty
healthy
list
going
on
the
Google
Doc,
and
then
we
go
through
when
we
kind
of
stack
rank
those
we
figure
out.
A
You
know,
what's
the
most
important
one
of
the
most
important
things
that
this
SDK
needs
to
do
to
actually
put
the
cloud
event
specification
into
developers
hands
tomorrow,
and
so
we
go
through
go
through
the
exercise
of
stack
rank
in
these
use.
Cases
see
what
see
where
our
priorities
are
and
from
there
we
can
start
breaking
this
down
into
some
potential
milestones
and
the
scope
of
each
milestone
with
in
respective
cloud
events,
SDK
versions
and
so
on.
The
Google
Doc
below
the
potential
use
cases.
A
A
I
think
you
know,
there's
we
there's
no
requirement
that
all
of
us
here
in
the
room
go
out
and
do
this
work,
but
we
do
have
to
figure
out
who
might
be
focusing
on
what
so
so
yeah
I
figure
we
take
it
from
there.
The
outcome
of
this
should
be
getting
some
milestones
and
scope
down
for
the
SDK
versions,
and
then
we'd
like
to
go.
Take
that
to
the
main
service
working
group.
A
Call
this
Thursday
and
just
present
them
with
kind
of
what
we're,
what
we're,
considering
and
get
some
feedback
from
them
and
and
from
there
I
think
we
might
be
able
to
get
a
few
more
volunteers
to
help
actually
implement
all
this
anyway.
Does
anyone
have
any
thoughts
on
that
agenda?
Does
that
sound,
okay
or
give
any
other
ideas
sounds
good
to
me.
A
A
Did
I
can
go,
I
can
go
through
a
couple
of
these
I
added
in
a
few
of
them,
so
maybe
I'll
provide
some
context
on
each
one.
The
first
one
here
is
instantiating
cloud
events
easily
in
code.
This
is
simply
being
able
to
require
in
the
SDK
and
do
some
type
of
good
look
like
class
based
instantiation,
where
you're
just
creating
a
new
instance
of
the
cloud
events,
class,
you're,
actually
kind
of
crafting
this
cloud
event
and
setting
the
the
values
of
the
event
itself.
This
seems
kind
of
temple
stakes.
A
If
you
want
to
actually
do
anything
with
an
event
you
know,
I
have
to
build
it.
First,
that's
what
that
is
instantiated
cloud
events
easily
via
event,
schemas,
not
entirely
sure
how
this
would
be
implemented,
but
you
know
perhaps
it
could
look,
something
like
JSON
schema,
which
you're
able
to
pass
in
a
JSON
schema
and
create
instances
of
that
do,
validation
against
the
schema
and
the
rules
that
are
baked
into
that
schema.
A
Bringing
an
event,
schemas
I
think,
could
help
out
a
lot
to
solve
problems
around
testing
events
solve
problems
around
validations
transformations
and
even
generating
mock
events.
To
help
test
out
your
your
serve
list
about
driven
architectures
number
three
assembling
cloud
events
from
various
transports,
so
there
are
different
transport
specifications
that
are
being
included
as
siblings
to
the
cloud
event
specification.
This
is
how
you
handle
cloud
events
in
the
HTTP,
for
example.
A
D
A
Additionally,
validating
cloud
events
by
including
a
schema
I
already
discussed
that
briefly
transforming
existing
events
and
the
cloud
events
via
transformation
mappings.
This
was
kind
of
an
interesting
one,
because
you
know
it's
early
days
for
the
specification,
it's
very
young
and
we
want
to
make
this
something
that
people
can
start
using
right
away
regardless
of
industry.
A
D
A
Yeah
great
question:
I'm
not
entirely
sure.
Yet
you
know
if
I'm
just
throwing
ideas
out
there,
you
know.
Could
we
investigate
some
type
of
language
agnostic
way
of
defining
these
transformations
that
the
SDKs
could
require
it
so
when
they
receive
some
events
in
its
kind
of
native
format
and
you're?
Expecting
that
and
you
could
add
in
this
module
that
already
asked
the
transformation
mapping
into
the
SDK
and
it
should
be
able
to
use
that
that
knowledge
to
do
the
transformation
automatically?
D
I
did
the
way,
I
think
you're
having
to
pull
or
wait
for
an
event
to
come
in
from
some
of
these
foreign
sources,
which
is
a
little
bit
more
than
just
transforming
the
actual
cloud
event,
and
so
by
itself.
The
having
the
transformation
is
useful,
but
not
sufficient
to
be
able
to
actually
get
the
event
in.
A
Yeah,
there's
there's
a
few
phases
to
solve
that
problem.
Getting
the
event
into
into
your
runtime,
where
the
SDK
is
is
kind
of
what
what
I've
been
focused
on
specifically,
if
the
SDK
can
help
beyond
that
I'm,
not
not
sure
how
it
would,
but
you
know
open
to
investigating
it,
but
you
know
talking
having
this
conversation.
These
are
other
adjacent
conversations
are
acting
within
the
working
group
around
event,
sources
and
whatnot.
A
B
I
was
gonna
watch
and
then
this
this
may
be
because
I'm,
a
newbie
and
I
didn't
realize
this
was
a
smaller
group
than
the
main
group,
but
yeah
I
guess
for
this
whole
area,
there's
even
a
higher
level.
Is
this
sort
of
solved
on
a
component,
slash
architecture
basis,
or
is
this
language
basis?
So
just
purely
thinking
about
it
in
terms
of
AWS,
like
is
that
is
the
vague
idea
at
the
moment
to
deploy
a
component
that
does
the
translation
or
is
there?
G
I
think
that
this
is
more
concern
of
maybe
something
else
looks
similar
to
the
event
gateway
idea
that
understands
there
are
certain
incomes
from
HTTP,
Kafka
and
QP
or
whatever,
and
then
you
can
use
a
component
that
does
a
filtering
or
transformation
and
then
it
would
convert
it
into
the
proper
format.
And
then
your
SDK
is
just
the
your
SDK
that
you
work
with
the
object
with
I
think
the
transformation
is
likely
more
component
sitting
next
to
it
like
in
order
to
trigger
the
process
and
to
get
like
the
full
payload
out.
G
A
B
A
F
I
was
about
to
say,
because
this
is
the
example.
The
example
here
is
that
actually
really
good,
because
it's
kind
of
kind
of
draws,
a
picture
system
that
can
generate
the
event
and
send
and
versus,
for
example,
a
system
that
generates
events
but
doesn't
isn't
able
to
send
it
by
itself,
and
you
need
to
do
some,
some
polling
and,
and
then
you
know,
component,
some.
F
Some
sort
of
a
component
enters
the
picture
that
will
paul
for
those
events
and
generate
actual
cloud
events,
and
and
this
component
is
then
able
to
send
them
further,
which
is
like
a
you
know,
different
use
case.
But
I
think
in
this
case
it's
not
the
role
of
sdk
and
but
the
component
will
use,
has
decay
to
produce.
Those
code
depends,
but
it's
additional
work
to
to
actually
get
those
events
in
in
some
in
some
custom
format
and
then
convert
them
to
chord
events.
A
I
think
Doug,
Davis
added
this
one
in
and
I
believe
what
he
was
talking
about
is
something
similar
to
just
having
the
cloud
events
kind
of
be
an
instance
of
some
type
of
class
that
has
getters
and
setters
for
accessing
the
data.
I
believe
that's
what
I
saw
in
neurons
early
examples
of
this
like
six
months
ago,
but
it's
been
a
while
so
I'm
a
little
fuzzy
on
this
next
step
was
generating
mock
events
from
a
cloud
event.
Schema
chat
about
that
briefly
already
cloud
events,
extension,
SDK,
add-ons
and
modules.
A
Now
this
one
is
is
pretty
interesting
in
the
cloud
of
a
specification.
There's
a
this
extensions
concept
where
you
could
just
put
in
a
lot
of
different
custom
properties,
essentially,
and
the
reason
why
this
extensions
concept
was
created
was
because
we
don't
know
what
should
be
in
the
cloud
event
schema
today.
It's
too
early.
A
F
Awesome
I
just
have
a
question
because
I'm
curious:
do
you
guys?
Do
you
guys
see
this
extensions
being
being
used
for
things
like,
for
example,
tracing
or
it's
a
wrong
place
to
put
things
like
that,
like
you
know
like
a
tracing
ID
or
something
like
that,
I'm
curious?
If,
if
you've
seen
this
being
used
this
way
or
do
you
see
it
the
proper
place
for
something
like
that
or.
A
A
A
A
Okay,
we
went
on
to
the
next
one,
transforming
lower
level
events
to
higher
order.
Events
automatically,
there's
been
a
few
people
in
the
working
group
who
have
requested
this
idea
of
getting
away
from
like
provider
platform,
specific
events
and
trying
to
come
up
with
some
some
higher
order.
Events
for
things
that
the
providers
for
events
that
the
providers
and
platforms
have
in
common,
for
example,
in
the
big
demo,
that
we
did
a
cube
con.
We
had
everyone
create
I,
think
it
was
11.
A
Different
server
list
functions
to
process
to
of
two
different
types
of
events,
so
these
functions
had
to
be
written
to
process.
Two
types
of
events
and
those
events
were
in
an
abyss.
S3
object,
created
events
and
then
a
Microsoft,
blob
storage,
object,
created
events
and
because
the
functions
had
to
write
logic
to
handle
both
these
events.
Yet
the
events
kind
of
had
the
same
properties,
the
same
ideas
in
them.
A
What
emerge
from
that
was
just
requests
for
hey.
Can
we
just
create
some
general
storage
object,
created
events?
That's
not
platform
specific,
but
maybe
an
SDK
or
something
could
take
in
a
Microsoft,
blob
storage
event
or
an
AWS
s3
object,
created
events
and
output.
This
kind
of
general
storage
object
created
events
which
has
goals
around.
You
know
just
being
easier
to
write
code
around
without
having
to
worry
about
you.
A
F
That's
actually
very
interesting
to
me.
It
sounds
I
mean
if
this
work
that
would
be
there
be
very
big
there
would
be.
There
would
be
great
I
would
say,
because
I'm
being
able
to
generalize
in
events
like
that
I'm
just
curious.
How
maybe
I'm
going
too
far
for
now,
but
I'm
really
curious
how
that
will
work,
because
each
platform
has
some,
like.
You
know
its
own
ways
of
accessing
the
actual
object
that
was
created
and
doing
something
with
it
and
probably
some
specific
identifiers,
and
so
on.
So
I'm
curious.
F
A
How
it
would
work
is
something
that
you
know:
we'd
have
to
figure
out
whether
you
know
if
it's
possible
and
what
that
implementation
would
look
like.
You
know,
going
back
to
the
s3
example
and
I
believe
you
could
take
a
cloud
events
SDK
and
if
it
had
that
transformations
concept
in
it,
you
could
just
build
in
a
transformation
that
takes
a
Tobias
s3
object,
created
and
converts
it
to
a
storage
object
created
event.
A
You
know,
but
it's
it's
early
days,
just
throwing
the
suggestion
out
there,
but
there's
definitely
a
lot
of
interest
in
this,
especially
just
to
help
people
write
more
portable
functions.
To
react
to
anything.
You
can
see
how
storage
object
created
that
pad
of
it
could
be
applied.
For
you
know,
database
record
created
or
something
like
that
and
that's
you
know.
These
things
cover
a
broad
surface
area,
but
but
anyway,
the
idea
is
out
there
we
could.
We
could
dig
into
it
for
how
to
work
and
if
it.
D
A
D
A
That's
correct:
okay,
almost
through
these
configuration
extension
for
adding
middleware,
the
SDK
can
use
to
publish
events.
Yes,
that's
right.
There's
a
few
people
who
are
offering
middleware
for
for
cloud
events,
infrastructure
to
help
with
the
general
dispatching
and
routing
of
events
to
to
whoever
they
need
to
go.
Our
company
does
that
we
have
a
product
called
the
event
gateway,
Microsoft
who's
represented
by
Clemens
in
the
service
working
group.
They
have
the
event
grid.
We
have
dispatch
a
lot
of
the
server
lists.
A
Open
source,
compute
platforms
are
doing
the
same
thing
and
it
would
be
neat
if
there
is
a
way
to
just
include
the
middleware
or
whatever
you're
using
to
help
facilitate
event
delivery
into
the
cloud
events
SDK,
so
that
the
one
the
developer
gets
with
the
experience
that
they
get
is
simply
being
able
to
do
cloud
event,
dot,
publish
they
call
the
publish
method
or
something
like
that,
and
because
the
configuration
is
already
stored
within
the
SDK.
That
cloud
event
will
immediately
be
sent
to
whoever
it
needs
to
go.
A
B
A
A
A
A
D
D
A
F
F
A
A
A
A
H
I've
done
a
lot
of
JSON
schema
work
for
OSB,
okay,
so
I
would
assume
something
like
that.
You
can
also
using
that
you
could.
You
could
inject
like
form,
schema
and
things
like
that
and
generate
UI,
so
that
you
can
have
a
producer
that
makes
your
events
that
you
can
test
your
application
based
on
what
is
expecting
mm-hmm.
A
Yeah,
our
company
makes
these
servers
framework
and
helping
out
developers
just
generate
events
easily
test
them
easily
validate
them
easily.
Is
it
something
that
we
really
want
to
solve
because
that's
that's
a
big
part
of
the
workflow
over
there,
so
this
definitely
resonates
with
me
I'm,
not
personally
sure,
if,
if
that's,
if
that's
the
first
priority,
I'm
still
leading
toward
instantiate
and
cloud
events
easily
in
code,
but
Scott,
do
you
think
this
could
actually
work
with
JSON
schema
I.
E
H
A
Yeah,
when
we
talk
about
the
cloud
events,
specification
itself
is
kind
of
the
schema
for
the
envelope
and
in
here
I
think
this
was
specific
to
the
actual
payload,
the
information
it
contains.
Okay,
we
we
already
have
in
the
cloud
of
incest
specification,
a
schema
URL,
which
I
believe
is
focused
just
on
the
payload.
E
A
F
D
A
A
G
There
was
even
a
little
bit
related
I
su
to
the
actual
implementation,
like
you
say
something
down
there
in
your
proposal,
bismillah
where,
from
a
note
perspective,
but
if
you
transport
it
to
other
languages,
you
could
completely
have
different
mechanisms
of
actually
receiving
them
in
the
system.
For
instance,
we
have
a
Java
API
and
that
basically
implements
the
spec
or
one
it's
just
a
very
tiny
jar
file.
F
A
That's
right,
that's
gonna,
be
a
challenge
we
deal
with
as
we
go
to
implement
all
this
functionality
across
the
languages
is.
Could
we
rewrite
this?
Possibly?
Would
this
be
a
little
bit
clearer?
You
know
from
what
I
remember
from
your
on
specification.
Unfortunately,
is
that
on
the
call
was
that
he
wanted
a
way
he
wanted
simple
getters.
D
G
D
A
Yeah
this
is
also
this
is
something
that's
being
discussed
and
has
been
discussed
for
many
months
within
the
cloud
events
working
group.
What
can
be
changed?
What
can't
be
changed?
I,
don't
think
we
have
a
definitive
answer
yet
largely
leaning
towards
immutability
as
much
as
possible,
of
course,
but
then
there's
a
few
different
parties
that
interact
with
events
potentially
along
the
way
and
giving
them
the
opportunity
to
set
information.
For
example,
middleware
shouldn't
it
aware,
be
able
to
kind
of
put
some
information
in
the
event
or
modify
anything.
A
Number
9
is
gone:
ok
for.
F
I
was
yeah
I'm
having
some
electric
water
at
home,
so
my
white
wife,
it
will
be
behaving
way.
Let
me
just
switch
to
cell
phone,
so
I
was
always
will
say
that
number
four
and
five
are
equally
important
to
me
because
they
define
how
I'm
gonna,
consume
and
event
and
how
I
will
be
able
to
receive
them
or
create
new
cloud
events
from
non
cloud
events,
not
events
that
are
not
cloud
events,
yet
so
I
would
say
they're
both
really
important
to
me,
so
put
them
both
of
the
other
next
item.
F
A
B
Guess
to
me
the
what
I
would
value
most
is
is
something
quick
and
easy
from
an
existing
in
that
I
can
incorporate
into
an
existing
platform
either
either
Azure
functions
or
lambda.
So
whatever
gets
me
to
that,
the
fastest
is
what
I
care
about,
even
if
it's
a
prototyping
and
being
able
to
give
it
to
some
people
to
say
how
does
this
feel.
B
A
And
by
the
way
to
know
this
is
set
in
stone,
we're
gonna
take
this
and
propose
it
to
the
surplus
for
your
group
on
Thursday
and
get
some
feedback
from
them
just
curious
mark.
What
do
you
think
our
first
step
should
be
on
on
this
on
this?
In
this
priority
assembly
cloud
of
ice
from
various
transports
and
encodings.
D
D
D
D
A
A
A
D
A
Okay
last
we
have
cloud
events,
extension
extension,
anions
and
modules
in
the
configuration
extension
for
adding
middleware
the
SDK
can
use
to
publish
events
all
similar,
isn't
it
yeah?
So
what?
If?
What?
If
numbers,
what
if
we
put
cloud
abides
extension
SDK,
add-ons
and
modules
is
number
five
and
then
the
middleware
as
a
bullet
point
of
that
sounds
good
to
me
all
right.
We've
got
something
cool:
okay,
let's
we
get,
we
have
ten
minutes
left,
let's
see.
If
we
can
break
these
down
into
cloud
events,
SDK
versions,
we've
got
a
version,
0.1
0.2
0.3.
H
H
F
G
These
milestones
could
be
release
candidates
or
of
better
whatever,
so
that,
for
instance,
the
first
alpha
version
or
first
better
version
is
version.
O
would
be,
for
instance,
item
number
one
compliant
with
specification,
oh
one,
and
so
on
that
Oh
two
or
would
be
then
like
the
next
release.
Candidate
matching
the
same
or
one
specification
is
that
something
that
could
fly.
A
Perhaps
I,
like
it
I
like
the
idea
of
being
able
to
work
with
the
different
versions
of
cloud
events.
It's
going
to
you
know,
increase
the
amount
of
work
we
have
to
do
of
course,
but
it
is
something
that
people
are
going
to
are
going
to
want.
It
almost
sounds
like
a
a
totally
different
priority
to
me
unless
this
is
just
baked
into
number.
H
C
H
C
H
F
H
A
D
A
A
A
A
A
A
However,
of
course,
all
these
things
I
think
we
need
to
more
clearly
define
the
scope,
but
at
least
we've
got
some
priorities
and
we've
got
some
some
areas
where
we,
which
we
think
we
need
to
focus
on
first
well
present,
is
present
this
to
the
working
group
on
Thursday.
At
the
same
time,
when
I
asked
there's
a
few
people
who
have
already
started
like
Matias,
and
you
guys
over
at
VMware,
you've
already
started
designing
some
cloud
event.
Sdks.
A
D
D
B
D
D
A
A
Okay,
now
put
this
as
a
comment,
a
quick
comment:
we
only
have
a
one
minute
left.
We
have
three
languages.
We
have
red
head,
working
on,
Java,
VM,
ware
dispatch
working
on
go,
our
company
would
love
to
contribute
to
the
JavaScript
implementation.
Is
anyone
going
to
work
on
any
other
languages?
Didn't.
A
A
I'll
add
them
to
this
to
this
later
cool
we've.
We
just
hit
the
time
the
time
limit,
so
we've
got
a
good
sense
of
priorities
here.
We'll
present
this
to
the
working
group
on
Thursday
and
I'll
have
a
longer
conversation
around
this
and
hopefully
narrow
in
on
a
more
clearly
defined
scope
for
some
of
these
SDK
versions.