►
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
CNCF CloudEvents Project: A Step Towards Serverless Interop - Doug Davis, IBM
The CloudEvents project was started to provide a first step towards Serverless interoperability by trying to define a common set of metadata, and format, for events flowing into Serverless platforms. In this session, after a brief introduction of the project, we'll discuss the status of the project, where it's being used, how people can use it via our SDKs and where we see it going in the future. Time permitting, we'll even showcase our latest demo that shows how a key industry consortium is considering using it in their critical business workflows.
https://sched.co/NrqP
A
All
right,
it's
20
past
the
hour,
so
let's
go
and
get
started
everybody.
My
name
is
Doug
Davis
I
work
from
I
work
for
IBM
I'm,
one
of
the
co-chairs
of
the
cloud
events
project,
which
is
a
CNC
at
the
sandbox
project,
and
maybe
this
sessions
is
going
to
be
a
very
quick
overview
of
the
history
of
cloud
events,
what
it's
all
about
and
where
we're
headed
in
the
future.
After
that
all
right.
A
So,
first
of
all
a
little
bit
history
of
where
it's
how
it
got
started
about
mid
2017,
the
technical
Oversight
Committee
inside
the
CNC
F
decided
they
wanted
to
do
a
little
bit
of
investigation
about.
What's
going
on
with
serverless,
it
was
a
relatively
new
technology
and
they
weren't
really
sure
whether
they
want
to
do
anything
with
it
at
all.
A
So
they
started
up
a
service
working
group
to
basically
do
that
they
want
to
do
investigation
and
produce
basically
a
white
paper
with
the
set
of
recommendations,
and
so
the
white
paper
did
exactly
what
it
says
here
on
the
screen:
there's
an
overview
of
the
technology
state
of
the
ecosystem,
all
right.
So
what
is
service
all
abouts?
How
does
it
compare
with
other
systems
like
fat?
I'm?
Sorry,
tough
as
some
container
to
the
service
ayahs
and
those
kind
of
things.
What
is
the
state
of
the
ecosystem?
A
You
know:
what's
going
on
up
there
relative
to
open-source
community
activities
as
well
as
proprietary
activities,
and
then
what
are
the
possible
next
steps
for
the
CNC
have
to
actually
do
about
this.
If
anything
that
was
all
within
the
white
paper
itself.
The
second
piece
of
thing
we
produced
was
a
landscape
document
which
is
just
basically
more
like
a
spreadsheet
that
says,
what's
out
there
today,
both
reprise
teri
and
open
source,
just
so
the
people
who
were
actually
want
to
get
involved
in
that
can
see.
You
know
what
they
can
choose
from.
A
We
weren't
making
any
recommendations
or
anything
like
that.
Just
a
an
overview
of
what's
out
there
today,
but
what's
important
is
the
recommendations
section
more
than
anything
else,
because
in
there
we
listed
a
couple
different
things.
A
lot
of
it
revolves
run
education
to
community
and
stuff
like
that,
but
one
in
particular
was
what
can
we
do
to
help
people's
pain
points
or
derive
interoperability
around
service
and
as
a
low-hanging,
fruit
type
of
thing?
People
realize
that
service
is
really
a
been
driven
type
of
technology.
A
So
is
there
anything
we
can
do
around
the
inventing
space
and
that's
how
cloud
event,
project
I,
think
got
started
we're
trying
to
figure
out
a
way
to
make
interoperability
for
the
eventing
infrastructures
or
the
transmitting
of
events
a
little
bit
easier
for
people
in
pointing
service
or
using
server
listing.
So
in
December
2017
about
six
months
after
the
service
working
groups
got
started,
the
cloud
advanced
project
got,
kicked
off
and,
as
I
said,
of
the
sandbox
project,
but
it
wasn't
actually
made
of
sandbox
project
until
May
2018.
A
So
before
we
start
talking
about
what
the
actual
cloud
events
project
is,
gonna
be
doing
with
level
set
a
little
here.
First
from
a
terminology
perspective.
So
first,
let's
talk
about
what
are
events,
so
obviously,
events
are
things
are
representations
of
an
occurrence
right,
something
happened.
Something
gets
sent
out
to
another
system
that
says
hey.
This
thing
happened
right.
A
What
what
happens
with
that
is
up
to
that
other
system,
but
that's
all
really
an
event
is
right:
it's
a
it's
a
manifestation
of
fact
that
something
actually
happened,
so
you
got
an
occurrence,
generates
an
event
and
then
on
the
receiving
side.
Typically,
there's
gonna
be
some
action
that
takes
place
as
a
result
of
receiving
that
event
very
simple
kind
of
thing.
So
what
is
kind
of
been
trying
to
do
with
this?
A
Well,
as
you
have
these
events
flowing
from
system
to
system
you're
living
in
a
multi
cloud
in
a
multi
service
world
right,
you
got
these
events
being
generated,
they're
being
processed
by
different
people,
they're
going
from
cloud
to
cloud
or
even
within
cloud,
bouncing
around
different
middleware
lots
of
things
going
on
with
these
events
just
try
to
process
them
correctly.
Okay
and
unfortunately,
everybody
produces
the
wrong
types
of
events.
So
there's
no
standardization
right.
A
All
these
events
get
sent
out
and
they
all
look
radically
different
to
each
other
unless
they
just
happen
to
copy
one
another
which
doesn't
happen
nearly
as
often
so.
What
we're
trying
to
do
is
trying
to
make
it
easier
for
the
transmitting
of
events
from
one
from
the
sender
to
the
receiver,
even
if
it
goes
through
bunch
of
middleware
along
the
way.
Okay,
and
what
we're
trying
to
do
is
make
it
easier
to
do
that
routing
or
transmission
or
receiving
without
having
to
silly
understand
the
business
logic
within
the
event
itself.
A
Okay,
so
obviously,
then
the
goals
here
are
to
try
to
foster
interoperability
right,
facilitate
interactions
between
these
various
platforms,
and
then
this
is
just
the
first
step
towards
interoperability
around
service
stuff,
we'll
get
into
some
of
that
later,
but
first,
how
we're
gonna
do
this?
We're
gonna
define
the
minimal
set
of
metadata
to
associate
with
an
event
so
that
people
can
use
that
as
a
standardization
going
forward.
A
So
they
can
look
for
these
particular
it's
a
metadata
and
every
events
and
not
have
to
definitely
understand
the
rest
of
it
and
I'll
show
that
in
as
an
example
in
a
second,
but
the
most
important
thing
here
is
we're
not
going
to
touch
the
business
logic
of
the
event
itself.
Okay,
this
is
not
one
of
those
common
event
formats
we're
trying
to
get
the
entire
world
of
standardize
on.
This
is
what
an
event
looks
like
and
here's
the
metadata
you
need
to
fill
in
we're
not
doing
that.
A
Okay,
we're
just
trying
to
help
get
your
event
in
whatever
format
you
want
from
point
A
to
point
B
and
that's
it
and
now,
along
the
way,
though,
we're
going
to
define
some
mappings
to
common
protocols
and
C
realizations
I'll
explain
more
about
that
in
a
second.
So
let's
talk
a
little
bit
about
this
metadata
that
we
actually
define
the
first
four
you
see
their
ID
source,
spec
version
and
type
are
the
only
four
required
bits
of
metadata.
The
cloud
events
actually
requires
for
every
single
event.
A
These
are
the
four
that
we
decided
are
the
minimum.
You
need
to
get
an
event
from
point
A
to
point
B
and
understand
what
the
event
is
about
and
who
it
came
from,
so
you
can
do
very
basic
routing,
so
ID,
just
a
unique
identifier,
think
of
it
as
a
UID.
Just
so,
you
can
identify
one
event
from
another
one
and
know
whether
to
do
book
it
or
not,
very
simple
source.
Where
did
the
event
actually
come
from?
A
Basically,
it's
supposed
to
be
a
unique
URL
that
says
who
sent
it
very
simple
thing:
spec
version,
that's
just
the
version
of
cloud
event
itself,
so
it's
pretty
much
gonna
be
a
static
value
type.
This
describes
the
type
of
the
event
so,
for
example,
if
this
is
a
github
push
event,
the
type
might
be
com,
github
dot,
something
very
simple
like
that:
nothing
too
complicated,
just
the
bare-bones
minimum.
Now
these
other
fields
down
here
are
extra
bits
of
metadata
that
we
thought
might
be
useful,
but
not
necessarily
required.
A
So
for
that
what
you
may
want
to
know
at
a
high
level,
what
is
the
contents
of
them
of
the
business
logic
itself
right?
You
don't
really
understand
what
the
business
politics
says,
but
you
may
want
to
know,
for
example,
is
it
XML
versus
Jason,
because
maybe
you
want
to
write
in
different
places
based
upon
the
encoding
type
stuff
like
that,
but
again
those
are
all
optional.
A
If
they're
in
the
message
you
can
use
it,
if
you
want
the
first
for
the
key
ones
that
we
really
really
wanted
to
focus
on
now,
transport
bindings,
that's
obviously
going
to
be
how
you
serialize
that
from
say
how
you
serialize
these
things,
in
particular
format
such
as
Jason
XML,
those
kind
of
things
or
how
you
populate
these
things
on
the
wire
and
MQTT
HTP,
that
kind
of
stuff
right.
We
have
to
define
not
just
the
properties
but
where
they
gonna
appear.
So
people
know
where
to
look
for
them.
A
Okay
and
again,
don't
forget
this
is
all
about
just
helping
message,
get
from
point
A
to
point
B.
That's
it
it's
really
not
that
complicated.
So
let
me
show
you
a
little
example
just
to
show
you
how
simple
this
really
is.
So,
let's
say
here
you
have
a
very
simple
event
and
we're
sending
this
and
we're
gonna
call
binary
format.
So,
basically,
it's
just
a
generic
HTTP
message
is
getting
sent.
A
When
you
add
the
required
cloud
event.
Attributes
to
this
you'll
see
a
spec
version
so
right
now
the
cloud
event
spec
is
at
0.3
is
a
static
thing,
but
type.
So
here
is
the
the
the
the
string
that
identifies
this.
A
quote.
Newland
item
was
added
to
maybe
a
database
or
something
and
it's
associated
with
big
code
comm
right.
So
this
is
an
event
type
that
this
organization
has
defined.
Where
did
it
come
from?
In
this
particular
case
it
came
from
big
TOCOM,
slash,
repo
and
then
just
so
needy
identifier,
that's
it.
A
Okay,
that's
the
bare
minimum,
the
term,
basically
any
HTTP
message
into
a
cloud
event.
Now
what's
interesting
about
this,
is
you
may
look
at
that
and
say
big
deals,
not
that
much
and
it's
and
you're
right?
It's
actually
not
that
much,
and
that's
actually
the
point
if
you
what
I
like
to
do
is
I
think
about
cloud
of
events
as
the
exact
same
thing
as
HTTP
headers,
okay,
HTTP
headers,
really!
Aren't
that
complicated
right!
You
have.
You
know.
Where
is
the
event
going
slash
event?
A
Where
did
it
come
from
or
I'm
sorry
the
host
value
where
it's
going
to
and
your
content
type
nothing
in.
There
is
really
technically
about
the
business
logic
per
se.
You
could
put
stuff
in
there,
but
technically
don't
need
to
write.
It's
really
just
bare
minimum
metadata
to
get
the
message
into
the
processor,
and
you
knows
how
they
do
with
it
so
then
hand
it
off
to
the
real
business
logic,
which
is
gonna,
stand
the
JSON
down
below
right.
That's
what
the
cloud
event
is
trying
to
do.
A
It's
trying
to
add
the
extra
little
bit
of
metadata
to
help
the
middleware
or
the
receiver
understand
what
to
do
with
it
to
pass
it
on
to
the
next
step
in
the
processing
logic.
That's
really
all
it's
doing,
ok,
so
it's
very
simple
and
that's
actually
one
of
the
beauties.
In
my
opinion.
Is
this
not
trying
to
change
the
world?
It's
just
saying
you
have
a
message
sprinkle
with
this
data,
and
now
you
get
a
little
bit
of
we're
in
wrong
building
now,
as
I
said
earlier,
this
is
the
binary
format.
A
Now
we
also,
as
I
mentioned,
define
how
the
stuff
looks
in
other
formats
like
say
Jason,
so,
for
example,
if
for
some
reason
you
didn't
want
to
actually
add
HTV
headers,
you
actually
wanted
everything
to
appear
in
the
HB
body.
We
have
what
we
call
a
structure
format.
If
you
look
at
it,
it's
basically
the
exact
same
thing
right.
You
still
have
the
exact
same
four
header
or
bits
of
metadata
over
there.
A
The
only
difference
here
is
we
added
a
data
property
that
says
the
same
thing
over
there
right,
so
we
just
rapid
it
and,
of
course
we
added
the
data
content
type,
which
is
application
Jason,
but
notice.
That's
because
the
CP
thing
is
now
a
cloud
events.
Json
object
right,
so
all
we
did
is
just
wrapper.
It
now
I
said
earlier:
we're
not
necessarily
trying
to
define
a
global
cloud
event
or
a
common
cloud
event
for
everybody
to
use,
and
some
people
try
to
use
this
in
that
way,
and
you
technically
could.
A
But
that's
not
the
point
of
this.
This
is
just
saying.
If
you
want
to
sterilize
everything
is
Jason
with
the
cloud
of
metadata.
You
don't
want
this
separation,
you
have
the
binary
format.
We
do
provide
this
for
you
to
really
want
it.
Okay
and
that's
basically
it
it's
it's
actually
very,
very
simple
and
that's
all
that's
all
actually
we're
trying
to
do.
Is
that
bare
minimum
metadata?
So
where
are
we
as
a
project?
I'm?
Sorry,
let
me
back
up.
A
First,
let's
talk
about
what's
new
in
version,
3
version
3
was
just
released
a
week
and
a
half
ago,
or
so
so
June
13th.
For
those
of
you
who
know
cloud
events
are
following
it.
The
subject
attribute
is
new
that
basically
describes
the
the
source.
I'm.
Sorry,
the
source
attribute
describes
who
sent
the
event.
The
subject
attribute
describes
the
event.
The
the
thing
the
event
is
about
right.
So,
for
example,
let's
say
the
source
is
a
github
repo.
Maybe
the
subject
is
the
PR
right,
because
maybe
a
new
PR
got
generated.
A
That's
the
event,
that's
the
relationship
between
the
two.
We
rename
content
type
the
data
Content
site
because
there's
some
confusion
there,
especially
in
HTTP,
because
people
didn't
understand
the
difference
between
the
HTTP
content,
type
header
versus
the
cloud
event.
Content
type
header
add
the
word
data
in
the
front
of
it
to
make
it
clear.
This
is
about
the
content
type
of
the
data
attribute
itself,
meaning
the
body
a
lot
of
people
don't
like
sending
events
that
are
very,
very
large.
So
we
add
the
of
an
extension
called
data
rep.
A
So
you
can
actually
have
a
pointer
to
some
external
resource
to
carry
the
data,
and
then
we
did
talk
about
how
to
do
batching
sort
of
basically,
we
punted
and
said
a
lot
of
transports,
or
we
do
batching
use
the
transfer
of
a
batching
we're
not
going
to
find
ourselves.
So
that's
what's
new
when
cloud
events
0.3
in
terms
of
the
littles,
a
lot
of
it
is
already
talked
about.
We
have
the
base
specification
itself,
three
eventing
formats,
jason,
AMQP
and
protobuf.
A
We
also
have
a
whole
bunch
of
different
transfer
bindings
that
tell
you
how
this
thing
gets
represented
on
the
protocols.
I'll
show
you
dhcp
other
things
in
their
MPP
and
keep
MTT
those
kind
of
things
we
do
have
the
spot
where
we
call
proprietary
transports.
That's
exercising
new.
The
other
transports
are
not
proprietary
in
the
sense
that
there
are
many
different
implementations
of
those
out
there.
A
There
are
some
specifications,
though,
out
there
that,
even
though
they're
done
in
the
open
there's
really
only
a
single
implementation,
so
they're
not
really
about
your
ability
and
we
don't
want
to
sort
of
mix
those
in
with
the
other
ones
that
are
about
interoperability.
So
that's
what
the
proprietary
aspect
of
the
transfer
by
any
specs
means.
If
you're
looking
at
that
now
we
do
off
of
a
primer.
That
gives
you
some
background
in
terms
of
what
why
we
made
some
of
the
design
decisions
we
made
and
some
thinking
behind
the
specification
itself.
A
A
Finally,
we
have
the
SDK,
so
if
you
don't
want
to
have
to
generate
the
headers
yourself
or
the
JSON,
so
we
do
have
several
SDKs
and
several
languages
take
your
choice
and
we
also
define
some
extensions
so,
for
example,
the
data
ref
one
I
mentioned
earlier-
that's
not
part
of
the
kernel
spec,
it's
an
extension
to
it.
Okay,
now,
in
terms
of
status,
I
did
mention
zero.
Three
came
out
recently.
I'm
talking
point
three
key,
not
recently
point
three
is
a
very
low
number,
but
don't
let
that
fool
you
it's
actually
more.
A
Like
a
point,
nine,
this
thing's
almost
done.
We
are
just
very
conservative
in
our
numbering
scheme,
but
everybody
on
the
team
basically
says
you
know
what
let's
wrap
this
thing
up
and
we're
hoping
to
actually
ship
1.0
within
a
matter
of
weeks.
Hopefully
that's
a
goal
anyway,
we'll
see
whether
it
happens.
A
We
are
also
in
the
process
of
putting
together
a
proposal
to
go
from
sandbox
2
incubator.
Really
it
means
nothing
for
us
other
than
we
get
the
leverage
the
marketing
machine
inside
CNCs
because
they
don't
like
to
do
a
whole
lot
of
promotion
of
sandbox
projects.
So
I
think
you
ater
stage
will
be
able
to
do
some
more
mark,
that
kind
of
stuff
in
terms
of
adoption,
kudos
to
Microsoft
and
actually
get
serve
lists.
Those
are
at
the
same
time,
but
those
two
came
out.
First,
with
support
force
for
cloud
events.
A
Asap
is
another
company,
that's
been
able
that
allows
me
to
mention
they've
done
it.
We
do
have
other
people
that
have
plant
support
for
it
and
just
not
to
mention
their
names
quite
yet
because
they
haven't
announced
it,
but
in
terms
of
open
source
support,
Kay
native.
How
many
people
are
here
heard
about
Kay
native,
ok,
fair
number,
you,
if
you
played
with
their
event
things
side
of
things
they
use
cloud
events
under
the
covers
every
time
an
event
comes
in
decay
native.
A
They
convert
it
to
a
cloud
event
to
send
it
on
to
the
rest
of
the
infrastructure
that
way
when
you
do
filtering
or
you're,
using
triggers
and
stuff
in
the
eventing
infrastructure
or
when
it
gets
passed
on
to
your
eventual
service.
It's
all
turned
into
a
cloud
event,
so
they
get
a
standardization
as
it
goes
through
the
middleware
so
that
you
don't
have
to
understand.
This
is
a
you
know,
a
particular
type
of
event.
A
Therefore,
I
need
to
look
in
different
spots
from
other
type
of
event
it
or
do
filtering
right
by
turn
into
a
cloud
event.
You
can
do
a
single
filtering
language,
type
of
mechanism
inside
a
native,
and
you
don't
have
to
understand
the
contents
of
it
and
that's
the
whole
point
of
cloud
events
so
very
excited
by
key
native
thinking
about
and
as
I
said,
we
do
have
other
big
cloud
providers
that
are
planning
on
supporting
it.
A
I'm
just
not
allowed
to
mention
their
names
quite
yet,
but
there
are
some
rather
big
ones
out
there
after
one
point,
though
so,
obviously
after
1.0,
if
there
are
additional
work
items
they
want
to
work
on,
will
work
on
those.
Hopefully
they
won't
be
spec
breaking
changes,
so
we
minor
increments,
but
most
of
the
group
will
actually
switch
back
to
the
service
working
group
and
we're
going
to
start
looking
at
what
to
work
on
next
in
terms
of
interoperability.
So
example
workflows
another
one
that
we're
considering
actually
we've
already
started
to
work
on
workflow.
A
Besides
cloud
events,
look
at
the
server
list
working
group
and
if
acting
going
to
talk
about
that
later
today,
at
4
o'clock
in
this
room,
talk
about
what
we're
doing
the
service
working
group
all
right
that
one
actually
a
lot
faster
than
I
expected,
so
we're
gonna
do
a
demo,
it's
a
little
scary
because
I,
don't
trust
them
Network
here,
but
it's
an
audience
participation
demo,
so
I
need
you
guys
to
participate
in
this.
So
if
it
fails,
I'm
gonna
blame
you
guys.
Let
me
this
lets.
You
know,
though
we
have
done
done.
A
Other
demos
in
the
past,
the
very
first
one
was
actually
kind
of
cool.
We
had
two
different
than
generations:
AWS,
blobstore
and
azure
blob
store
went
through
some
middleware
that
was
sent
out
to
a
whole
bunch
of
different
functions.
Each
of
the
functions
would
maple
ate
this
image
and
then
post
it
to
Twitter
that
wasn't
yeah,
that
was,
that
was
a
Twitter
one
yeah,
so
that
was
kind
of
cool.
We
have
another
one
which
did
something
similar
I'm,
sorry,
no.
This
was
another
version
of
that
one.
A
A
Okay,
but
today
we're
due
for
a
demo
is
look
at
an
airport
ecosystem,
so
in
airport
in
many
ways
it's
almost
like
a
small
city
right.
You
have
a
lot
of
different
participants
involved
and
going
on
with
the
with
the
the
the
businesses
involved.
You
got
customers,
you
got
a
lot
of
infrastructure
involved
and
we
have
been
working
with
the
the
Accra
semantic
model.
A
For
my
camera,
the
name
of
the
organization,
of
course
it
right
now,
but
it's
an
airport
consortium,
that's
basically
trying
to
look
at
the
airport
ecosystem
and
break
it
up
into
more
of
a
micro
service
architecture.
Now,
obviously,
they're
gonna
have
events
flowing
around
and
they're
looking
at
leveraging
cloud
events
to
an
aid
to
better
enable
that
architecture.
For
this
common
event,
bus
type
of
infrastructure,
they're
doing
right.
C
A
They're
hoping
the
cloud
events
can
help
them
from
an
internal
ability
perspective,
so
our
demo
is
going
to
be
around
an
airport
ecosystem.
Okay,
now
get
out
your
phones
scan
the
QR
code
or
go
to
that
URL.
Well,
I
ramble
for
a
minute.
Basically,
the
point
of
demo
here
is
on
the
bottom.
You're
gonna
have
some
retailers,
that's
basically
be
coffee
shops,
okay,
up
top
you're
gonna
have
suppliers.
A
So
when
the
coffee
shops
run
out
of
coffee
cups,
the
suppliers
will
send
new
boxes
of
coffee
cups
on
the
right-hand
side
right
here
we
have
carriers,
basically,
trucks.
The
trucks
are
going
to
go
from
the
supply
to
the
retailer
and
then
back
home
whenever
new
coffee
cups
need
to
be
delivered
kind
of
a
hokey
scenario,
but
it
represents
the
idea
of
events
being
generated
by
based
upon
different
actions,
and
then
people
respond
to
those
events
and
notice.
A
You
have
different
icons
there,
because
every
every
participant
use
a
different
language
and
it's
from
a
different
company.
So
it's
not
all
implanted
by
the
same
person.
On
the
right
hand,
side
is
very
right
inside
you
see
the
list
of
crowd
events
as
they
get
generated.
So
let
me
go
ahead.
Did
everybody
manage
to
get
their
source
dog
calm,
slash,
Airport
yeah.
It
says
it
should
say
you're
waiting,
right,
okay,
want
you
guys
to
go
too
soon,
so
here
we
go.
A
So
let
me
just
quick
demo
of
what
it
should
look
like
so
down
here
represents
what
you
guys
should
see
so
I
said:
I
want
to
pick
the
IBM
coffee
shop
goes
there,
I'm
gonna,
take
medium,
actually
picks
small
I
get
my
coffee
and
then
I
walk
away.
Now
I
get
to
go
again.
So
let
me
do
it
again
now
what
happens?
It's
still
gonna
take
IBM
coffee,
but
this
time
should
point
out
these
little
bars
here
represent
the
supplies
inside
so
I.
A
Think
it's
like
one
through
three
or
something
like
that
when
it
gets
down
to
one
IBM,
coffee
is
going
to
say,
I
need
more
cups
and
you
see
a
little
pop
ups,
they're
saying
I
need
small
cups
or
something
like
that
and
then
you'll
start
seeing
things
flying
around
the
screen.
So
if
you
wait
too
long,
he
kicks
you
out.
So
let
me
do
that
again
hold
on
hey
IBM
coffee.
A
A
So
if
you
do
it
right,
you
should
be
able
to
flood
the
system
and,
yes,
you
can
jump
and
you
should,
as
you
get
below,
you
should
start
seeing
a
whole
bunch
of
events
or
trucks
go
flying
around
okay,
now
I
know
it's
kind
of
goofy,
but
at
least
to
get
you
guys
involved
and
actually
awake
right.
Oh
yeah,
oh
wow,
you
guys
look
good
okay,
so
let
me
just
quickly
where's.
My
first
means
click
on
one.
So
why
are
you
guys
doing
that?
Just
to
show
you
what
this
is
a
sample
cloud
event?
A
So
this
event
actually
says
it's
coming
from
a
retailer
called
story
scrip-
and
this
is
just
a
new
inventory
level,
so
he's
back
up
to
three.
So
he
sent
out
an
event
for
the
system
to
say
how
many
cups
he
has
right.
This
is
a
sample
cloud
event.
Okay.
So
the
point
of
this
is
the
customer
walks
up
places
in
order
an
event
gets
sent,
customers
order
satisfy
and
the
event
gets
sent.
Retailer
runs
out
of
cups.
The
events
gets
in
the
the
supplier
says,
I'm
going
to
take
all
right.
A
I'm
gonna,
I'm
gonna
satisfy
the
event
that
said
we're
running
out
of
cups,
so
he
sends
an
event
saying:
I
have
a
path
to
get
picked
up.
This
guy's
going
to
respond.
Saying
I'm
gonna
go
get
the
package
we're
gonna
get
to
deliver,
you
send
another
event.
All
these
events
are
generated
by
different
people
slide
different
formats,
but
cloud
events
makes
it
interval
because
they
can
all
just
look
at
the
metadata
to
figure
out
how
to
receive
it
and
route
it
to
the
right
infrastructure.
A
Then
process
the
business
logic
that
says
what
to
do
next
and
obviously
something
isn't
quite
going
right
because
there's
a
long
line
with
nobody,
ain't
served
I
apologize.
This
is
a
demo
code.
I
want
to
blame
the
network,
but
I.
Don't
know
for
sure,
anyway,
now,
with
the
demo
just
trying
to
quickly
show
cloud
events
actually
in
action
and
again
you
can
actually
see
one
of
them.
So
actually
it's
this
on
the
screen.
A
All
right,
and
so
just
to
wrap
it
up
some
useful
links,
the
service
working
group,
our
parent
project.
Originally,
then,
it's
amend
links
about
the
cloud
events
project
itself.
We
have
our
dedicated
webpage,
github
repo
link
to
the
SDKs.
We
do
have
weekly
calls
that
are
at
noon
eastern
time
every
week,
if
you're
interested
in
joining
everybody's
free
to
join,
you
don't
have
to
be
a
regular
member.
Just
join
come,
have
some
fun
and
I
dis
reminds.
A
A
All
right,
so
the
question
is
in
order
for
you
to
get
the
interrupt
there,
we're
looking
for
you
have
to
have
some
little
I'm
gonna
wrap
the
values
of
the
field
that
we
define
right
great
question.
Unfortunately,
that's
not
something
we're
gonna
be
tackling
yet
because
that's
that's,
really
business
processing
specific,
basically
right.
What
we're
hoping
to
do,
though,
is
to
get
popular
event.
Producers
make
github
as
an
example
right
to
get
them
to
either
support
cloud
events
natively
because
they
already
send
that
HTP
events.
A
Why
not
just
add
three,
three
or
four
more
headers
and
they're
done
right?
That
way,
people
can
process
getup
events
without
having
to
understand
that
it's
actually
really
good
of
events
right.
They
say
all
get
up.
Events
go
over
here
right,
but
to
your
specific
question,
I
I
don't
know
if
we
actually
can
standardize
too
much
around
that,
because
every
every
every
business
applications,
for
example,
type
is
gonna,
look
different
right
and
so
I'm
not
quite
sure
how
you
can't
standardize
around
that
right.
Github
events
is
gonna,
say
github
or
com.
A
Github
push
gitlab
is
going
to
be
com,
get
lab,
merge,
request
or
something
like
that
right.
So
they
may
not
necessarily
be
much
you
can
do
in
terms
of
your
ability.
They're,
the
closest
you
can
get
is
possibly
say
everybody
has
to
do
reverse
DNS
name,
something
like
that.
At
least
you
can
maybe
figure
out
whether
it's
under
the
github
or
kind
of
thing,
but
even
then
I,
don't
know
I
I.
Just
let
me
have
a
look
that.
B
B
A
A
Think
what's
interesting
is
well,
this
isn't
event
specific
we've
talked
about
doing
things
like
trying
to
standardize
function,
signatures
which
is
something
similar
right.
You
try
to
standardize
what's
coming
into
you
or
how
to
talk
to
something
and
there's
a
little
bit
of
resistance
to
that,
not
because
it's
not
a
good
idea,
but
people
thought
oh
a
little
bit
too
soon.
So
I
think
the
idea
you
have
is
actually
really
good.
I
would
love
it
because
I
agree.
A
If,
if
it'd
be
great,
if
say
I
in
your
example,
all
load
balancers
spit
up
the
same
of
events,
you
can
all
react
consistently.
I
would
just
worry
that
people
would
be
a
little
nervous
about
doing
it,
because
a
lot
of
people
think
of
standardization
as
handcuffing
creativity
put
it
that
way
right
and
we
don't
want
that.
So
at
some
point,
I
would
love
to
be
able
to
do
that
and
I
think.
A
A
E
A
A
A
No,
no
it
it.
The
the
the
event
producer
defines
what
goes
in
their
bot
events
does
not
tell
anybody
what
to
do.
We
just
define
the
metadata
as
we
just
defined
the
metadata
names.
We
don't
define
the
values.
So
hopefully,
if
github
chooses
to
support
cloud
events,
then
they
will
define
that
that
when
they
send
events,
the
type
will
be
calm.
Github
push
calm,
github
new
new
new
issue,
or
something
like
that
right.
A
You
actually
will
see
a
poor
request
to
suggest
what
some
look
like,
so
we
actually
do
have
one
for
github
one
forget
lab
one
for
a
couple
of
AWS
events,
just
as
a
suggestion
to
get
some
commonality,
because
the
for
example,
a
lot
of
people
may
want
to
write
adapters,
for
example,
to
convert
a
github
events
into
a
github
cloud
event.
Well,
if
your
multiple
adapters
out
there,
we
don't
want
them
all
doing
different
things.
Filling
in
with
different
values,
you
want
some
consistency,
so
we
give
some
recommendations
for
what
to
do.
A
D
A
Yes
and
no,
you
are
correct
and
it's
good
observation
that
we
do
not
have
a
destination
in
there
and
that's
for
two
reasons.
One
is
we
didn't
want
to
duplicate
what
was
already
in
the
transport
right.
So
in
the
HTTP
case
it
already
has
a
host
header.
It
has
the
path
we
didn't
want
to
duplicate
that
the
transport
you
already
have
destination
information,
that's
one,
but
two,
because
often
events
will
get
passed
around
right.
A
Oftentimes
they'll
go
to
a
piece
of
middleware,
looks
at
it
sends
out
to
something
else
or
just
some
processing
to
it,
send
down
to
something
else,
or
maybe
decides
and
ID
one
do
anything
with
it.
Send
it
to
a
bitbucket
right.
We
didn't
want
to
have
a
hard-coded
destination
as
part
of
cloud
events,
because
that
destination
may
only
be
good.
For
that
one
hop
right:
it's
not
going
to
be
good
all
the
way
down
the
chain
right
so
to
your
question
about.
Is
it
just
for
subscription
versus
point-to-point?
You
can
use
it
for
either
one.