►
Description
This talk was part of AsyncAPI Online Conference:
- AsyncAPI Initiative website - https://www.asyncapi.com/
- You can also watch this talk as part of full conference recording with audience questions in the LiveChat - https://youtu.be/oMSzGc5bDr4?t=11964
TALK ABSTRACT
In our distributed Cloud Native world, loosely coupled services are a central architectural design point, and along with those comes the events that flow between them. Now, add in the dynamic nature of extending these systems with new components and the need to have middleware that can manage, process and route those events efficiently (without needing to understand the business logic within the events, or even who sent the events) will be critical.
The CNCF CloudEvents project has introduced a specification to help solve this problem by introducing a way to standardize key bits of metadata in the events without forcing people to adopt a ""one-size-fits-all"" common event format. Come see why this simple little specification has managed to bring every major Cloud provider together to solve these concerns.
SLIDES
https://drive.google.com/file/d/1Llv9klUf8Vm1cI6XmOxLnaqk7hkfxPZj/view
A
All
right
look
everybody.
My
name
is
Doug
Davis
from
IBM
I'm,
one
of
the
co-chairs
of
the
cloud
events
project,
which
is
a
CN
CF
project,
and
that
basically
caught
events
is
a
project
that
was
designed
to
help
people
manage
events,
basically
around
the
delivering
events
from
one
spot
to
another,
but
we
first
we
before
we
actually
start
talking
too
much
about
this
spike
itself.
Let's
talk
a
little
bit
about
the
history
in
terms
of
white
cloud
events
was
even
created
and
what
led
us
to
even
think
about
creating
or
working
on
it.
A
So
back
in
the
middle
of
2017,
the
CN
CF
technical
Oversight
Committee
wanted
us
to
take
a
look
at
its
serverless
technology.
It
was
a
relatively
new
technology
at
that
point
and
they
were
really
just
trying
to
figure
out
what,
if
anything,
should
the
scenes
you
have
do
about
service
and
so
what
they
did
is
they
started
up
a
service
working
group
whose
main
purpose
in
life
was
to
do
just
that
produce
a
white
paper
that
is
sort
of
explained.
What
is
service?
How
does
it
relate
to
other
technologies
like
functions
as
a
service?
A
Apart
from
the
service
or
containers
of
service,
you
know
the
other
as
a
service
offerings
out
there
state
of
the
ecosystem.
You
know,
what's
out
there
today
from
a
proprietary
perspective
as
well
as
open
source
perspective,
basically
just
trying
to
help
you
understand
what
is
this
space
actually
all
about
and
then
finally,
a
set
of
recommendations,
if
any
for
what
should
the
scene
see?
I've
actually
do
about
serve
lives
right?
Should
they
ignore
it?
Should
they
get
more
involved,
trying
to
promote
projects
around
it?
A
And
so
that's
basically,
what
the
service
working
group
first
did
is
just
sort
of
lay
lay
the
groundwork
for
you
know,
what's
out
there
today,
well,
one
of
the
recommendations
that
they
came
back
with,
or
we
came
back
with-
was
that
we
we
were
thinking
about.
Is
there
a
way
that
we
can
actually
help
the
end
users
out
in
this
community,
because
there
was
a
lot
of
really
great
unique
service
solutions
out
there,
but
there
really
wasn't
much
in
the
way
of
our
ability
to
make
life
easier
for
people.
A
So,
for
example,
one
of
the
things
a
lot
of
y'all
will
focus
on
around
irritability
is
well,
can
I
move
my
function
or
my
service
function
from
one
platform
to
another
easily?
Well,
not
really
right
unless
they
happen
to
share
the
same
codebase,
because
it's
open
source
more
often
than
not
they're
kind
of
proprietary
api's
around
save
the
functions,
signatures
and
stuff
like
that,
and
so
there
are
things
like
that.
A
We
sort
of
identified,
but
we
realize
some
of
those
things
that
would
really
really
be
great
to
do
would
also
be
really
really
hard
to
do
because
going
to
be
political
and
controversial
and
we're
not
quite
sure
whether
the
industry
overall
was
really
ready
to
tackle
that
space.
So
with
we
looked
around
and
said,
are
there
some
what
we
call?
A
You
know
low-hanging
fruit
that
we
can
actually
tackle
in
the
meantime
sort
of
building
up
to
that
you
know,
get
the
community
and
the
people
producing
products
in
the
space
comfortable
with
the
idea
of
inner
ability
to
help
out
the
users,
and
we
realized
a
lot
of
service
is
about
event-driven
workloads.
I
thought!
Well!
Is
there
something
in
the
inventing
space
that
we
can
help
people
here
or
we
help
out
people
with
and
we've
talked
about.
A
You
know
the
delivering
of
events
from
one
spot
to
another,
and
particularly
to
your
function
is
something
they
they
all
kind
of
do
and
is,
and
there
may
be
some
help
we
can
attack
or
something
we
can
promise
basis.
We
can
attack
there
and
help
people
out
okay.
So,
let's
talk
about
what
is
actually
the
pain
that
we
sort
of
identified
right.
A
Okay
and
the
problem
that
we
have
here
is
well
this,
this
kind
of
works
today
the
real
pain
is
at
every
single
one
of
these
little
blue
boxes.
It
has
to
understand
what
the
event
is:
that's
coming
into
the
system,
at
least
enough
to
know
how
to
route
it
appropriately
right
and
how
to
get
that
metadata
out
of
the
event
to
know.
For
example,
what
was
it
supposed
to
go
over
this
Nats,
Kafka
or
imp?
A
You
thing
to
the
event
Street
broker,
or
is
this
supposed
to
go
down
to
that
pub
sooo
cute
pub
sub-q
at
the
bottom
right,
those
kind
of
decisions
in
terms
of
routing
and
stuff
like
that
need
to
be
made
by
middleware,
but
in
order
to
make
those
decisions,
they
now
have
to
understand
the
message
itself.
Now
they
don't
necessarily
understand
all
the
business
logic
of
what's
in
there,
but
they
have
to
at
least
understand
the
syntax
of
the
message
coming
across.
A
They
know
which
bits
of
data
they're
interested
in
and
where
it
is
in
those
messages
to
be
able
to
extract
it
to
make
those
kind
of
decisions
right
and
that's
not
easy
right,
because
you
got
lots
of
different
producers
producing
lots
of
different
events
in
lots
of
formats
and
there's
no
commonality
for
the
most
part
between
them.
Right,
it's
a
free-for-all,
and
so
that
means
every
one
of
these
blue
boxes
potentially
has
to
continually
update
the
sort
of
its
understanding
of
all
the
various
messages
that
come
into
the
into
those
systems
and
then
what?
A
If
those
syntaxes
change
over
time
right,
you
got
version
1
version,
2
version.
3
of
these
events
coming
through
all
these
blue
box
have
to
understand
that
that's
a
lot
of
work
and
a
lot
of
maintenance.
Obviously
you
can
do
it
today,
but
that
is
a
that's
a
pretty
big
pain
point
for
people
right,
and
so
this
is
really.
A
The
type
of
problem
that
we
were
trying
to
address
is
how
to
help
the
event
from
point
A,
meaning
the
event
producer
to
point
B,
which
is
your
function
eventually,
but
help
out
that
middleware
to
get
it
there.
Okay,
so
in
2017,
by
the
end
of
2017
cloud
events
was
born
and,
as
I
said,
it's
an
offshoot
of
the
service
working
group
and
basically
the
goal
here
is
to
try
define
common
metadata
for
these
events
and
where
they
appear
in
messages
now
keep
in
mind.
A
This
is
not
yet
another
common
event,
format
that
tries
to
force
everybody
into
a
single
standard
for
what
your
event
looks,
like
that's
been
done
many
times
before
with
not
a
whole
lot
of
success,
and
so
we
decided
to
take
a
different
approach.
We
said,
if
you
look
at
all
the
messages
that
are
flowing
around
today.
Most
of
them
actually
have
a
lot
of
common
data
to
them.
So,
for
example,
a
lot
of
them
have
some
sort
of
type
field.
That
says
you
know.
Is
this
a
create
versus
a
delete
type
of
message
right?
A
They
have
a
unique
identifier,
so
you
can
do
D
dupe
type
stuff.
They
have
information
about
where
it
came
from
right,
source
and
subject,
write
what
produced
the
event
and
what
is
the
event
about
right.
So,
for
example,
if
it's
a
github
bucket
the
subject
may
be
the
github
repo
right
yeah,
then
we
have
the
time
right
when
was
this
event
actually
created.
So
you
have
all
this
common
metadata
that
most
events
typically
have
already.
So
it's
a
so
we
step
back.
A
We
took
a
step
back
and
said:
well
what,
if
we
take
this
common
metadata,
that
most
events
have
and
at
least
give
them
a
well-defined
name
and
a
well-defined
location
in
the
message
itself,
so
that
the
middleware
doesn't
have
to
guess
or
understand.
All
of
the
messages
are
coming
through,
where
they
just
have
to
know
where
look
for
this
particular
metadata
and
that's
basically,
all
the
spec
is
right,
comment,
metadata,
common
location
and
that's
it
and
it's
not
even
all
metadata.
A
It's
just
enough
metadata
to
help
the
routing
get
of
your
event
from
point
A
to
point
B
and
that's
it.
Okay,
it's
actually
a
really
really
simple.
Spec
with
very
simple
goals:
it
is
not
trying
to
change
the
entire
world.
It's
just
trying
to
reduce
this
one
little
pain
point
so
I
like
to
tell
people.
This
is
not
a
sexy
spec,
but
it
people
are
finding
it
incredibly
useful.
So
it's
one
of
those
specs
where
I'm
hoping
it's
sort
of
weaves
its
way
into
people's
middleware
and
it
just
sort
of
does
its
job.
A
But
it's
not
designed
to
be
very
flashy
or
make
a
lot
of
noise.
It's
just
there
to
help
you
out.
Okay,
now
I
talked
about
how
this
metadata
should
appear
in
a
common
location,
they've
been
formats
and
that's
all
true,
but
there's
actually
two
different
ways
that
it
can
appear
in
messages.
The
first
is
called
binary
and
that's
actually
my
preferred
way
because
binary
says
you
already
have
an
event
going
from
point
A
to
point
B.
You
already
have
an
event
format.
A
You
already
have
the
structure
of
the
message
you
already
have
that
you
already
know
how
it
appears
say
in
HTTP
or
whatever
transport
you're
using
all
cloud
events
is
going
to
do
in.
That
point
is
add
extra
metadata
to
your
existing
message:
you're
leveraging
the
existing
extensions
of
that
protocol.
So
let's
take
HTTP
as
an
example
in
that
particular
case,
for
a
binary
format
for
cloud
event,
all
that
really
means
is
adding
a
couple
of
HTTP
headers
to
the
message.
That
means
a
couple
of
interesting
things.
A
One
is
you
don't
have
to
crack
open
HP
by
to
look
at
the
message
as
a
router
anyway,
and
you
as
a
middleware,
know
exactly
where
to
look
for
the
message
and
third,
it
doesn't
have
to
be
break
existing
implementations,
meaning
a
receiver.
That
knows
how
to
receive
that
message,
but
knows
nothing
about
cloud.
Events
will
still
work,
because
these
these
attributes
that
appear
as
HTTP
headers
won't
affect
your
message.
A
You
know
HTP
allows
you
to
have
extra
headers
in
there
that
the
receiver
can
just
ignore
and
that's
what
I'll
do
in
this
case
as
well,
if
it
doesn't
understand
cloud
events
but
over
time,
if
that
piece
of
middleware
does
you
know,
grow
up
and
understand
cloud
events,
naviga
start
leveraging
those
it
can
stop
having
to
understand
what's
in
the
body
at
that
point.
In
time
we
could
start
using
just
the
cloud
events
headers
for
these
to
do
its
routing.
Okay.
Now
the
second
format
is
called
structured.
A
This
one
says
you
know
for
if
you
don't
have
an
existing
event
that's
flowing
around
and
you
want
some
guidance
to
help
you
out
there.
Fine,
we'll
help
you
out.
There
will
actually
give
you
a
JSON
format
that
you
can
use
for
your
cloud
event
structure
or,
for
your
event,
structured,
really
wanted
to,
and
that's
an
option
and
I'll
show
a
little
bit
more
about
that
on
the
next
slide.
But
you
have
these
two
options
for
you
and,
as
I
said,
my
preferred
approach
is
the
binary
one,
because
that
basically
means
the
existing
message.
A
Flows
do
not
break
at
all
and
they
they
can
still
be
used
with
your
existing
infrastructure
without
any
changes
at
all
until
they
want
to
actually
support
cloud
events.
So
let's
take
another
look
at
what
this
means
through
an
example.
So
let's
say
you
have
a
event
being
shown
or
been
flowing
is
shown
on
the
left
hand,
side
here
right,
very
simple,
little
HTTP
message,
nothing
too
exciting,
but
notice.
What
happens
now,
let's
add
a
couple
of
cloud
event
headers
to
it
just
for
little
headers.
First
one
tells
us
the
spec
version.
A
So
this
the
cloud
event
specification
version
that
we
adhere
to
1.0.
It's
the
faith's,
the
only
version
we
have
out
there
seee
type.
So
this
is
the
cloud
event
type.
This
basically
allows
the
receiver
to
look
at
this
one
field
and
say:
okay.
This
is
it's
a
new
event
from
big
cocom
now,
obviously,
the
the
phrase
new
event
is
a
very
you
know
could
be
a
very
popular
phrase,
so
you
may
want
to
classify
it
based
on
you
know
where
it's
coming
from,
and
this
allows
you
to
say
it's
not
just
any
new
event.
A
It's
big
chose
new
event
right,
so
you
give
a
little
bit
of
scope
in
there
right,
but
typically
I'm
sorry,
but
you
can
obviously
put
whatever
you
want
in
there.
It's
completely
up
to
you,
it's
just
a
string.
Obviously
the
more
specific
gets,
the
less
chance
of
you
having
conflicts
with
other
people
and
the
more
specific
you
can
be
also
allows
for
a
finer
grain
routing.
If
you
really
want
to
do
OK
source,
obviously
this
tells
you
where
the
event
came
from.
A
So
in
this
bit
of
our
case,
you
could
say
that
the
big
code
coms
repo
component
is
the
one
that
actually
produced
this
event
itself
and
then
we
just
have
some
unique
identifier,
as
I
said,
mainly
just
so.
The
receiver
can
do
D
duping
and
know
if
it's
seen
this
event
before
very
simple
stuff.
So
again,
nothing
about
this
message
has
really
changed
in
terms
of
a
receiver.
That
knows
nothing
about
cloud
events.
But
if
you
understand
cloud
events
now
you
can
do
routing
based
upon
these
four
little
headers
and
that's
it.
A
Okay,
that's
the
binary
format.
So,
let's
take
a
look
at
the
structured
format.
Now
the
structured
format,
if
you
look
at
it
actually
has
basically
the
exact
same
data.
The
only
difference
here
is:
we
define
what
goes
inside
the
HTP
body,
because
in
this
particular
case
the
person
who's
using
this
said
I
don't
have
a
format
that
I'm
already
adhering
to
so
give
me
one
that
I
can
do
and
just
because
they
don't
want
to
find
one
themselves.
We
said.
Okay,
here's
what
it
looks
like
here's,
what
it
look
like
in
Jason.
A
If,
for
some
reason
you
don't
have
your
own
format
or
you
don't
want
to
pass
these
cloud
event
metadata
as
HTTP
headers,
because
there
are
some
people
who
don't
want
to
process
headers,
they
would
actually
want
it
on
the
body
and
that
we
could
take
these
higher
payload
and
pass
it
on
to
the
next
component
in
one
large
chunk
of
JSON,
and
so
we
provide
that
as
well.
But
if
you
look
at
it,
it's
basically
the
exact
same
data.
The
only
change
here
is
we
define
it
a
data
content
type.
A
So
you
can
say
what
is
the
format
of
the
data
itself
which
maps
to
the
content
type
header
from
HTTP?
And
then
the
actual
body
of
the
message
that
would
have
appeared.
Hp
body
appears
nested
one
level
down
under
a
data
property,
but
you
can
see
it's
basically
the
exact
same
thing
right
so
pick
your
poison.
A
Whichever
one
suits
your
use
case,
you
know
we
got
your
comfort
basically
and
you
can
tell
the
difference
between
the
two,
because
if
you
look
at
HTTP
content
type
header
and
the
binary,
it's
still
the
original
application
Jason
on
the
right
hand,
side
for
structured,
its
application
cloud
events
Jason.
So
that's
how
a
receiver
can
know
which
format
he
has
and
we
do
I
believe
we
actually
require
both
to
be
supported
by
implementers.
That
way,
you
can
actually
receive
those
are,
as
a
sender,
send
it,
whichever
one
you
want.
A
So
as
you
look
at
those
various
components,
if
they
need
to
do
some
special
logic
like
routing
and
stuff,
they
know
it's
a
cloud
event
and
they
can
just
use
those
headers
right
so
give
that
commonality.
So
let's
look
at
that
with
a
more
concrete
example,
so
you
haven't
been
producer
who's
setting
event
into
your
cloud
native
environment
in
the
most
simple
case.
A
What's
going
to
happen,
is
it's
gonna
get
received
by
some
component
called
an
adapter,
and
his
purpose
in
life
is
really
just
as
I
said,
to
take
the
event,
convert
it
to
a
cloud
event
and
then
send
it
on
to
the
next
component.
In
the
most
simple
case,
the
next
component
is
gonna,
be
your
service
itself,
nothing
too
exciting,
and
at
that
point
technically
cloud
events
may
not
provide
a
whole
lot
of
value,
at
least
from
a
middleware
perspective.
The
service
can
still
use
it
right.
The
service
will
know
it's
a
cloud
event.
A
It
can
use
those
headers
if,
for
some
reason
it
needs
to
in
its
message
and
it's
misses
processing.
But
from
the
middleware
perspective
we
don't
have
a
whole
lot
of
middleware.
So
there's
not
a
lot
of
great
thing
out
a
lot
of
benefit,
that's
fine,
but
what?
If
you
added
something
to
the
picture
like
a
broker
right?
So
let's
say
the
broker
is
going
to
be
doing
fan-out
right.
A
So
the
event
comes
into
the
broker,
and
maybe
there
are
a
whole
bunch
of
different
services
that
are
subscribed,
meaning
they
define
these
triggers,
and
so
you
get
this
again.
You
get
this
fan
out
of
the
event
to
multiple
people.
Well,
in
this
particular
case,
triggers
can
have
filters
and
cloud
events,
I'm,
sorry
and
Kay
native.
You
can
actually
specify
those
filters,
basically
by
doing
string
matching
on
the
cloud
event
attributes
right.
So
this
particular
point
the
broker
doesn't
need
to
know
anything
about
the
type
of
event
coming
in.
A
It
doesn't
need
to
know
whether
it's
coming
from
some.
You
know
high-end
enterprise
system
or
github
versus
gitlab
or
any
other
event
producer
out
there.
All
the
broker
needs
to
know
is
I'm
getting
a
cloud
event
and
I
can
do
this
filtering,
because
the
filtering
is
processing
over
the
cloud
of
that
metadata,
okay
and
based
upon
whether
it's
true
or
false
or
then
get
passed
on
to
the
appropriate
service.
A
When
those
servers
is
done,
it
can
send
back
the
reply
to
the
broker
and
then
the
broker
can
pass
it
on
to
next
component
again
as
another
cloud
of
it.
One
of
the
other
interesting
component
tree
within
cloud-
it's
like
a
native
are
things
called
parallels
and
it's
a
different
type
of
fan-out
mechanism.
Okay,
in
this
particular
case,
an
event
comes
into
the
parallel
and
you
can
have
a
whole
bunch
of
different
conditions
and
if
any
of
those
conditions
are
true,
it's
passed
on
to
the
appropriate
sink.
A
So
it's
a
it's
a
slightly
different
type
of
brokering
type
system
or
fan-out
type
system,
but
it's
a
very
similar
concept
in
the
sense
that,
as
the
events
come
through,
these
things,
they
do
filtering
based
upon
the
cloud
of
that
metadata.
Ok,
so
again,
this
is,
in
my
opinion,
sort
of
the
classic
example
of
what
cloud
events
was
actually
designed
for
exactly
this
type
of
middleware
processing.
A
Ok,
and
so
finally,
this
will
wrap
it
up
for
the
cloud
events,
I'm,
sorry
from
the
K
native
perspective,
you
can
then
mix
and
match
these
components
to
basically
get
an
entire
inventing
workflow
completely
outside
of
your
service,
and
it's
all
based
on
cloud
events.
So
your
event
can
actually
go
through
this
entire
workflow
thrinng,
eventually
reach
your
service
and
you've
done
either
filtering
or
whatever
kind
of
work
for
the
logic
you
want
to
have
done
on
these
events
without
ever
having
to
really
understand
the
business
logic
itself.
A
Unless
you
really
want
to
do
right,
which
most
cases
middleware
you
don't
you
just
want
to
get
it
from
point
A
to
point
B
and
that's
where
the
ok.
So,
let's,
let's
talk
about
the
core,
especially
as
I
said
it's
really
just
about
the
metadata.
So
let's
look
at
what
that
metadata
actually
is.
I
already
talked
about
some
of
these,
so
you
have
the
type
you
know.
Is
it
a?
Is
it
a
create
versus
delete
type
of
action
and
whose
create
versus
delete
right?
A
So
you
get
a
little
bit
of
a
scoping
around
that
action
itself.
The
cloud
of
inspect
version
is
another
attribute
source
and
subject
combine
those
to
define
where
the
event
came
from.
In
other
words,
who
sent
it,
who
is
the
event
producer
and
the
subject
is
more
about
what
the
event
is
related
to
right,
so
example
in
an
object
store.
The
subject.
Might
be
the
entity
added
to
a
buckets
right,
so
that's
why
you
can
do
a
little
filtering
to
know.
Well,
I
only
want
to
get
events
from
one
particular
github
repo.
A
As
an
example
I,
you
might
look
at
the
subject
for
that
to
tilt
type
of
filtering
okay,
unique
ID,
or
talk
about
that
time
that
one's
easy,
our
talk
a
little
bit
about
data
content,
type
right,
that's
the
case
where
it's
a
structured
type
of
thing
or
structure,
type
of
a
cloud
event
you
that
we
had
that
filled
in
there
and
then
we
also
have
schema
I.
A
lot
of
people
want
to
understand
based
upon
the
schema
of
the
event
itself.
Being
the
schema
of
the
business
logic
do
different
processing
right.
A
A
If
you
understand
that
your
venn
producer,
is
you
guys
can't
extend
this,
you
really
want
to
do.
You
can
define
extensions
that
it
can
appear
as
other,
you
know,
caught
event
type
attributes
and
they
have
to
appear
basically
in
the
exact
same
location,
meaning
in
the
HP
case
in
the
binary
format,
has
HTTP
headers
prefixed
with
c
e.
A
That
way,
people
know
exactly
what
c
e
headers
or
event
headers
are
in
there
or
metadata
is
in
there
without
having
to
necessarily
understand
everything
in
advance,
okay
and
they
could
take
the
extensions
put
them
into
a
separate
bucket
and
that
processor
that
understands
extensions
can
go
looking
for
them
over
there.
If
they
really
want
to
do
okay,
so
that's
the
specification
so
other
documentation
that
we
have
obviously,
as
I
talked
about
before
events
could
actually
flow
over
many
different
protocols.
A
So
we
support
the
five
protocols
you
see
on
the
screen
here
you
know
a
CPM
Q
and
T
I'm,
sorry,
QT,
t
AMQP,
Kafka
and
Nats
and
basically
for
I.
Think
almost
all
these.
We
pretty
much
show
you
where
the
events
are
supposed
to
appear.
I'm.
Sorry,
the
metadata
is
supposed
to
appear
in
binary
format.
In
most
cases,
it's
either
you
know
in
the
extension
attributes
or
eight
or
heteros
type
stuff,
or
how
a
message
appears
in
the
structured
format.
A
I
mean
what
what
special
rules
might
have
to
be
there
in
terms
of
data
types
and
stuff
like
that,
as
I
said,
I
think
all
these
support,
both
binary
and
structured
I,
think
only
one
of
them.
I
think
it
might
be.
Nats
only
supports
that
I
think
the
structured
mode
and
one
harbors
insurer,
but
most
of
them
do
support
both,
and
then
we
also
define
what
the
event
looks
like
for
the
structured
mode
in
Jason
and
Avro.
A
But
if
you
read
the
primer,
will
you
be
explaining
why
we
did
it
and
hopefully
you'll
see
why
we
made
those
decisions
and
why
they
were
good
decisions
for
the
long
term
right,
it's
not
as
complicated
as
it
could
be.
For
example,
all
the
attributes
are
name
value
pairs.
We
don't
allow
nesting
of
properties
for
good
reasons,
breed
the
primer
and
you'll
understand
why
we
did
that
it
makes
life
or
a
whole
lot
easier.
When
you
dumb
things
down,
we
also
have
what
we
call
adapter
specifications.
A
This
allows
you
to
see
house
events
how
some
of
them
actually
might
get
transformed
into
cloud
events,
so,
for
example,
for
AWS,
s3
or
github
we
get
lab.
We
show
which
bits
of
metadata
from
the
existing
messages
should
get
pulled
out
into
the
cloud
of
that
metadata,
so
that,
if
you
wanted
to
write
an
adapter
that
converts
like
an
s3
message,
I'm
sorry
s3
events
into
a
cloud
event.
A
If
you
follow
our
guidance
there,
you
can,
you
can
do
it
in
a
very
sort
of
common
way,
because
the
the
s3
folks
and
and
get
that
folks
I,
look
at
this
and
they
basically
say
yep.
This
looks
right
to
us,
even
though
they
don't
formally
support
cloud
events
themselves.
Yet,
okay
document
extensions.
We
basically
provide
a
spot
here
for
people
who
want
to
extend
cloud
events
with
their
own
extent
with
their
own
attributes
to
provide
a
home
for
those
things.
These
extensions
I
have
no
official
standing
whatsoever.
A
They
may
change
over
time,
they're,
not
version
with
the
spec,
it's
more
like
a
wiki
page,
more
than
anything
else
for
the
people
to
work
together
on
some
of
these
extensions.
Now,
if
they
become
popular,
maybe
we'll
add
another
specification
at
some
point,
but
we
wanted
a
sort
of
a
testing
ground
for
people
to
have
fun
with
some
new
extensions
and
then.
Finally,
this
is
an
open
source
project.
We
didn't
want
to
put
proprietary
specifications
or
mapping
to
proprietary
specifications
or
protocols
into
our
repo
itself.
A
We
thought
that
might
look
like
people
are
trying
to
just
promote
their
particular
product.
Instead,
we
allow
people
to
do
is
to
say:
okay,
fine,
if
a
particular
primary
protocol
wants
to
do
cloud
events,
that's
fine,
we're
all
in
favor
of
that,
but
we
don't
want
that
specification
that
defines
the
mapping
in
our
repo.
What
we'll
do
instead
is
put
a
pointer
to
that
specification,
our
repo
and
then
they
could
host
every
that
specification
themselves
outside.
A
So
at
least
would
allow
people
to
find
those
proprietary
specs,
but
we
didn't
want
to
look
like
we
were
endorsing
one
prior
to
respec
over
another,
so
we
sort
of
got
out
of
that
business.
However,
if
you're
working
on
a
protocol
or
transport
binding
that
is
open,
source
or
standards-based,
then
we're
more
than
happy
to
include
it
as
part
of
our
repo.
If
you
want
to
work
on
that,
okay,
now
it's
liked
a
lot
about.
What's
in
there,
let's
talk
a
little
bit
about,
what's
not
in
there,
because
that's
kind
of
interesting
as
well.
A
So
one
thing
we
purposely
avoided
was
security.
A
couple
of
reasons
there
one
is
a
lot
of
the
transports
already
have
security
built
in
so
we
didn't
want
to
reinvent
the
wheel
and
so
that,
from
that
perspective,
that
you
know
you
can
use
what's
out
there
today,
but
then
you
might
be
wondering
well,
if
you
really
have
all
these
various
hops,
how
do
you
get
end-to-end
security
right
because
it
point
the
point
might
be
already
done,
but
not
end-to-end,
or
how
do
you
verify
that?
A
No
one's
tweaked,
the
message
you
know
along
those
paths
by
doing
some
sort
of
message,
signatures
and
stuff
all
valid
questions,
and-
and
there
isn't
a
cell
a
great
solution
out
there
today
and
we
may
actually
tackle
that
one
point.
However,
we
also
acknowledge
that
trying
to
solve
security
problems
like
that
is
non-trivial
and
probably
non,
probably
very,
very
controversial,
so
we
wanted
to
actually
produce
the
spec
in
our
lifetime
already.
A
We
didn't
want
this
thing
to
take
years,
so
he
said:
ok,
we'll
leave
that
out
for
right
now
we
may
come
back
to
later,
but
let's
at
least
get
the
base
spec
out
there
first
and
see
what
kind
of
adoption
we
get
I
think
it's
very.
Very
popular
and
people
are
clamoring
for
some
sort
of
security
story.
Maybe
we'll
produce
it
then
ok,
the
other
thing
you
won't
notice,
you
won't
find
in
there
are
sort
of
what
we
call
transport
level
metadata.
A
Things
like
where
is
the
event
attended
to
go,
who
sent
it
or
where
should
it
be
replied
to
not
to
send
it
to
reply
to
stuff?
That's
not
in
there
at
all
a
couple
reasons,
one
is
that
sure
to
be
handled
by
the
transport
level
stuff
as
well
or
already,
but
also
these
are
events.
Ok,
these
are
not
messages.
Now.
A
Events
are
typically
one-way
messages
that
can
go
to
many
different
people
and
when
you
start
talking
about
replies,
then
you're
getting
into
business
semantics
in
terms
of
when
replies
are
sent
like
that,
and
that
has
nothing
to
do
with
it.
Anything
from
our
perspective,
you
can
layer
that
on
that
stuff,
on
top
of
crowd
events,
if
you
wanted
to
but
as
part
of
a
core
cloud
events,
that's
not
where
we're
trying
to
attack.
Oh
that's
why
we
left
it
out.
This
is
just
events.
We
also
have
SDKs
for
variety
different
languages.
A
The
goal
one
in
particular
is
use
quite
heavily
in
the
key
native
project,
so
pick
your
favorite
language
and
we
help
you
produce
and
receive
cloud
events,
but
obviously
you
don't
have
to
use
those
if
you
don't
want
to.
Hopefully
your
current
misses
process
and
should
just
be
able
to
pick
up
the
the
extra
metadata
relatively
easily.
So
in
terms
of
status
and
May
2018,
we
became
a
sandbox
project,
but
just
made
us
a
little
more
real
inside
CN
CF,
but
in
October
we
did
two
things:
one.
A
We
came
to
incubate
a
project
which
gave
us
even
more
authority
and
it
more
realness
to
us,
but
we
also
released
version
1.0
to
spec.
So
now
we
feel
like
the
spec
is
ready
to
go
to
be
used
in
production
and,
at
this
point
in
time,
we're
basically
just
letting
the
dust
settle
and
seeing
how
people
feel
about
the
spec
as
they
start
to
use
it.
We've
gotten
lots
of
great
feedback
from
people
who
are
using
it
already.
They
love
it,
but
we
wanted.
A
We
want
to
see,
wait
and
before
we
actually
tackle
the
next
step
for
cloud
events,
you
know
like
security
and
those
things
to
see
what
that
adoption
looks
like.
First,
ok
and,
however,
we're
not
just
sitting
back
doing
nothing
the
service
working
groups
looking
at
what
to
work
on
next.
In
particular,
we
sat
back
and
said:
okay,
great
you've
got
these
events
form
from
point
A
to
point
B,
but
has
the
consumer
of
these
events
know
what
events
are
actually
being
produced
by
those
producers
or
how
do
I
then
subscribe
to
those
events?
A
Can
we
help
out
there
and
we
looked
at
and
said
sure,
let's
see
if
we
can
do
that
right,
let's
see
if
we
can
work
on
an
event,
discovery
spec,
so
that
a
producer
in
a
consistent
and
standardized
way
advertise
what
events
are
being
generated
for
and
before
what
protocols
and
then
can
we
standardize
how
people
actually
subscribe
to
those
events?
How
do
I
specify
filters
which
event
types
they
want
that
kind
of
stuff
and
that's
a
relatively
new
set
of
specs
they're
working
on
if
you're
interested
in
that
space.
Please
join
us.
A
It's
obviously
gonna
leverage
cloud
events
going
forward
as
an
option
because
it's
a
nice
fit
for
that,
but
it's
so
relatively
new,
so
we'd
love
to
get
your
feedback
and
with
that
I'm
basically
done
here
are
some
links
for
you
if
you're
interested
in
interested
in
it.
Obviously
the
first
four
are
all
about
cloud
events,
the
main
site
itself
and
the
repos
and
stuff.
If
you're
interested
in
the
service
working
group,
in
particular
the
the
white
paper
I
talked
about
there's
a
link
in
there.
The
working
group
is
also
has
a
sub
working
group.
A
That's
working
on
workflow
if
you're
interested
in
a
venting,
workflow
type
logic,
take
a
look
at
that
specification.
It's
still
relatively
new
as
well,
but
it's
starting
to
get
more
and
more
traction.
So
you
could
take
a
look
at
that
itself.
I
think
they
do
support
cloud
events,
but
it's
not
a
proper
cloud,
oven
specification.
It's
just
the
general
purpose,
workflows
back.
A
We
do
have
weekly
phone
calls
Thursdays
at
noon.
Eastern.
If
we're
interested
it,
anybody
is
free
to
join
and,
as
I
said
right
now,
our
main
focus
is
on
the
to
new
specifications,
meaning
subscription
and
delivery.
But
if
there's
other
things
related
to
cloud
events,
if
you
want
to
bring
up
or
find
issues
you
want
to
tackle
in,
there
feel
free
to
add
it
to
the
agenda,
and
with
that,
thank
you
very
listen
and
how
Garba
has
a
good
day.