►
From YouTube: CloudEvents - Intro, Deep-Dive a... Doug Davis, Clemens Vasters, Klaus Deissner & Vladimir Bacvanski
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
CloudEvents - Intro, Deep-Dive and More! - Doug Davis, IBM; Clemens Vasters, Microsoft; Klaus Deissner, SAP; & Vladimir Bacvanski, PayPal
In this session the we'll summarize the history and status of the CloudEvents project. We may even have a major announcment! We'll then talk about what our future plans are. Finally, there's will be a more indepth discussion around how people are using CloudEvents in production and how it has helped address the pain points people were experiencing.
https://sched.co/Uak1
A
We
have
various
products
there
and
I'm.
Also
leading
our
standardization
efforts
around
messaging
and
cloud
events
is
one
of
the
things
that
I
do
they're
called
events.
So
what
we're
going
to
talk
about
history?
We're
gonna?
Have
a
nice
demo
I'm
going
to
talk
about
the
the
plans,
some
of
the
plans
that
we
have
that
we
talked
about
yesterday
at
what
we
might
do.
There's
no
decision
about
this
yet
and
we
are
certainly
open
for
further
participation
and
then
I
said
we're
gonna
have
some
real
production
showcases,
including
some
announcements.
A
So
we
decided
it
will
be
good.
Send
good
idea
to
harmonize
that,
so
there
was
a
detective
over
Oversight
Committee
initiated
that
then,
as
an
effort
based
on
input
from
various
participation
of
participating
companies,
IBM,
who
will
Microsoft
others,
and
we
then
started
to
on
this
journey
to
work
on
this.
We
overall
I
think
we
had
over
30
companies
represented
in
the
effort
and
I
am
on
standard
committees
quite
a
bit,
and
the
fact
that
we
have
you
know
by
average
I
would
say.
A
A
A
They
generally.
We
have
a
set
of
base
protocols
that
we
use
in
in
enterprise
systems
and,
in
you
know,
systems
of
all
kinds
that
is
fairly
popular
and
fairly
established,
and
we
didn't
want
to
add
a
new
protocol
right.
Harmonization
doesn't
mean
that
you
need
to
go
and
add
new
protocols,
but
there
are
there's
a
family
of
protocols
that
exists,
that
everybody
is
fairly
happy
with.
A
Let
let's
talk
about
why
cloud
events
makes
sense
in
today's
systems
that
are
getting
more
complicated,
more
grumbling,
even
more
complicated
events
take
a
journey.
They
start.
If
we
look
at
an
IOT
solution,
they
start
at
some
device
and
some
device.
Actually,
if
that
device
is
a
machine,
then
the
story
already
is
fairly
complicated
because
you
have
a
drive
that
is
inside
of
a
component
that
is
inside
of
a
machine
that
is
inside
of
a
cell
that
is
on
shop
floor
in
a
factory.
A
So
you
already
have
five
levels
of
you
know,
event
routing
that
happened
there
until
that
gets
into
the
factory
level,
and
then
it
goes.
It
goes
out
and
goes
through
further
stages.
So
we
see
more
and
more.
If
you
look
at
solutions
that
you
might
be
building
or
your
customers
might
be
building,
we
see
these
chains
of
event
flows,
an
event
gets
sent,
gets
put
into,
let's
say
an
event
story
broker
like
Kafka
or
event
tops,
maybe
gets
pushed
into
a
function,
but
then
the
event
propagates
from
there
gets
stored.
A
So
how
can
we
go
and
accomplish
that?
So
what
cloud
events
does
is
that
it
assets
binds
to
existing
protocols
and
it
does
so
via
encoding.
So
we
have
a
cloud
event.
It's
really
a
data
structures
and
information
sets,
as
you
would
say
that
in
parlance
of
older
encoding
format
and
you
have
event
data,
that's
the
core
information
that
you
want
to
go
and
carry
that.
We
want
Express
to
someone
else.
A
You
have
context
attributes
that
describe
what
that
data
is,
so
that
the
infrastructure,
the
event
broker,
can
go
and
see
it
and
then
can
go
and
and
handle
it
can
go,
apply,
filtering,
etc,
etc,
and
then
there
are
user,
extensions
and
custom
extensions
that
you
may
add
to
the
event
also
to
make
visible
to
infrastructure
to
intermediaries,
so
they
can
go
in
handle
the
event.
So
the
basic
idea
here
is
like
with
messaging
everywhere
else.
The
event
data
is
your
payload
that
you
decide
what
the
format
is
you
decide
what
the
encoding
is.
A
A
At
the
start,
a
set
of
rules
for
what
the
contacts
attributes
are,
what
their
role
is,
and
they
are
designed
so
that
generic
infrastructure
can
go
and
reason
about
the
event
and
that
he
can
go
and
create
diagnostics,
traces
that
you
can
go
and-
and
you
know,
describe
the
journey
of
that
event
through
the
system-
and
you
have
enough
information
without
having
to
know
what's
inside
of
that
event
data.
So
there
is
first
information
about
what
is
the
type
of
that
event.
A
So
spec
version
refer
the
version
of
cloud
events
which
is
1.0
now
and
which
we
hope
will
not
change
for
quite
a
while
and
then
the
second
is
the
type
and
the
type
describes.
What
that
event
is.
That
might,
for
instance,
be
Microsoft,
thought,
storage,
dot,
blob
created.
That
is
the
kind
of
event
that's
being
raised,
and
that
tells
you
that
in
the
Microsoft
storage
system
there
was
a
block
raid.
That's
the
kind
of
that's
the
kind
of
event.
A
A
Then
that's
your
source
and
then
the
subject
actually
describes
the
concrete
file
which
is
about
which
that
event
is
that's
the
split
between
source
and
subject.
Then
there's
a
unique
identifier
for
the
event.
So
we
can
get
distinguish
one
instance
from
the
other
and
then
there's
information
that
is
on
the
frame
about
the
event
data.
That's
inside
of
the
event,
which
is
the
data
content
type
which
maps
to
content
to
the
proper
content
type
header
in
HTTP.
A
When
you
use
the
binary
encoding
as
we
call
it
I'll
get
to
that
in
a
second
and
then
there
is
a
schema.
Actually,
data
schema
typo.
There's
a
data
schema
field
which
allows
you
to
put
a
URL
into
a
URI
into
the
event
which
points
to
some
external
schema
that
you
can
then
go
use
fetch
to
go
and
decode
the
data
that
is
inside
of
it
or
where
you
can
get
some
in
semantic
information
about
it.
That
schema
is
optional.
A
You
don't
have
to
use
it,
but
it's
something
that
we
thought
makes
sense
to
go
and
standardize
the
event
data
can
be
anything
I
said
so
the
event
data
can
be
any
binary.
Can
be
any
encoding,
we
don't
that
the
system
doesn't
or
and
the
implementations
don't
take
any
tone
take
a
look
into
the
payload.
They
don't
have
any
rules
around
it.
A
A
Messages
are
a
events
are
somewhat
special
types
of
messages.
If
you
will
but
messages
are
carrying
commands,
they
have
intense,
they
create
a
coupling
between
two
parties
right,
you
send
someone
a
job
to
do,
and
then
that
means
only
one
party
can
get
it.
That
means
that
you
may
want
to
get
a
reply
when
that
up
when
that
job
is
done,
you're
creating
a
more
complicated
relationship
between
two
parties.
Events
have
none
of
that
events.
A
You
basically
just
raise
the
information
about
a
particular
fact
and
then
whoever
subscribe
to
the
event,
whoever
can
get
it,
whoever
can
get
obtained
a
copy
of
it,
can
go
and
react
to
it.
That's
a
very
different
concept,
even
though
principally
right,
they're,
both
messages,
so
we've
we've
focused
very
very
specifically
on
the
event
on
telemetry
or
on
alerts
or
on
you
know,
other
statements
of
fact
we
didn't
be
scoped
out
all
the
complexity
of
you
know
multi-party
relationships,
because
that
ends
up
being
much
harder
to
model
with
all
the
transports
that
we
have.
A
That
makes
a
whole
story
much
harder,
because
now
you
need
to
have
experience,
explain
what
what
the
relationships
are
so
cloud
events
is
about.
Eventing,
you
raise
an
event
from
a
publisher.
You
can
go
and
put
that
into
an
intermediary.
The
intermediary
will
go
and
broadcast
that
information
further,
and
then
you
have
subscribers
at
the
end,
some
information
that
is
interesting
for
multiple
parties
in
the
system,
but
basically
that
is
the
intent
behind
cloud
events.
It's
enabling
publish/subscribe.
A
What's
missing,
is
our
contracts
like
to
reply
to
topics
queues
any
of
those
things
because
they
create
these
kinds
of
relationships?
If
I
have
a
reply
to
and
I'm
sending
a
message
over
and
published
an
event
and
it's
sending
that
over
HTTP
and
now
that
gets
transposed
into
ATP
that
gets
transposed
into
MQTT
gets
gets
sent
into
a
you
know:
fenced
off
VPNs,
environment
and
now
there's
a
reply
to
address
in
there.
That
is,
you
know
whatever
mqp
and
MPP
address.
How
do
you
reach
back?
A
A
We
have
Jason,
that's
the
default
that
we
also
support
Avro,
and
we
support
also
AMQP
and
the
model
is,
is
completely
pluggable
and
if
someone
were
to
come
and
create
a
event
format
for
message
pack
or
for
sea
bore
or
for
any
of
the
other
things,
we
would
happily
be
adding
this
as
an
extension
to
the
repo,
and
it's
just
that
nobody
has
done
the
work
yet.
But
the
goal
is
that
we,
you
can
use
effectively
every
kind
of
encoding.
A
There's
a
there
was
a
protobuf
encoding
in
here,
but
that
was
pulled
out
because
they
in
the
end,
the
program
of
team
wasn't
happy
with
it.
Now
we're
gonna,
rework
it
and
recon
tribute
it.
So
we're
gonna
have
effectively
encodings
that
are
compact
and
that
Express
Cloud
events
correctly
in
all
of
those
forms.
A
cloud
event,
then,
is
bound
to
a
transport
and
here's
the
example
for
HTTP.
We
have
a
binary
event
and
what
they
see
is
that
the
binary
event.
A
That's
just
a
normal
HTTP
POST.
So
that's
not
not
not
very
exciting.
The
way
how
so
the
binary
means
the
event.
Payload
is
just
your
payload
and
what
cloud
events
adds
here
is
now
the
metadata
information.
So
now
we
have
some
common
information.
The
common
information
is
expressed
as
HTTP
headers,
with
a
c
e
prefix,
so
spec
version
type
source
ID
and
when
you
go
and
you
know
take
it,
take
that
request
and
you
filter
out
or
everything
else
with
c
e.
You
also
get
all
the
custom
extensions.
A
So
if
someone
creates
an
event
with
a
custom
extension
any
property
that
they
want,
that
what
gets
prefixed
with
C,
which
means
you
pick
up
the
event
in
your
code
and
you
take
everything.
That's
prefixed
with
C,
E
and
you'll.
Have
your
your
cloud
events
metadata?
That's
how
we
map
that
and
then
we
have
a
self-contained
model
and
that's
the
structured
format.
The
structured
format.
Bc
has
all
the
information
inside
of
it.
So
all
the
metadata
is
inside
of
an
an
object
in
this
case
for
jason.
A
That
are,
then,
has
all
the
definitions,
and
then
that
also
has
the
data
than
in
lines
and
the
data
here
we
have
that
cost
was
quite
a
bit
of
discussions.
The
data
here
can
also
contain
binary.
So
if
it's
Jason
then-
and
it
has
a
data
content
set-
that
is,
that
indicates
a
binary
type,
then
that
will
be
basically
four
encoded
and
we
have
a
special
escape
effectively.
Your
data
underscore
base64
that
clearly
indicates
that
the
data
is
basically
four
encoded,
so
you
can
carry
then
basics
before.
A
So
the
the
options
that
we
have
is
HTTP
1
1
and
with
that
also
HTTP
2
HD,
because
what
we've
done
here
is
we've.
We
took
effectively
this
cloud
event.
We
map
that
onto
the
message
structure
that
is
defined
by
and
the
semantics
that
is
defined
by
RFC
3272
31,
so
7230
is
the
spec
that
defines
how
HTTP
1
1
looks
on
the
wire
and
7231
is
suspect
that
that
talks
about
what
the
message
model
is
of
HTTP
independent
of
this
and
the
trick
that
HTTP
does
and
H
should
be
2
or
3,
though
do.
A
Is
they
take
that
spec
and
that's
that
one
so
on
to
a
brand
new
protocol,
either
the
htv-2
protocol
or
quick
in
the
case
of
H
to
be
3.
So
we've
effectively
done,
we've
really
layering
on
top
of
that
semantic
model,
and
that's
how
we
buy
these.
Our
binding
is
not
specific
to
get
our
set
or
you
know,
push
put
or
pose
or
or
anything.
A
A
Things
that
we
didn't
do
are,
and
we
haven't
tackled
yet
our
signatures
and
to
end
encryption
any
of
these
things,
because
some
of
us
have
worked
on
prior
efforts
like
the
older
of
us,
have
worked
in
things
like
ws-security,
with
the
soap
stack
and
there
the
security
stuff
sunk,
the
ship
like
a
stone,
and
so
that
was
not
a
good
idea
to
start
with
that.
We
will
eventually
probably
get
to
it,
but
it
was
a
good
idea
to
scope
that
out
because
we
have
TLS
to
start
with
and
that's
not
a
bad
start
overall.
A
A
We
have
no
intention
to
go
fast
and
Rev,
and
you
know
creative
one,
one
rare
version
and
a
2o
version
very
soon
if
I
certainly
want
to
go
and
touch
that
spec
for
another
year,
at
least
and
and
let
and
and
more,
if
possible,
because
the
goal
for
here
for
this
is
to
have
stability,
we
will
do
extensions,
we
have
an
accessibility
model,
but
the
goal
is
for
that
to
be
stable.
So
what's
next,
we
have
now
a
format
we
have
ways
to
map
onto
protocol.
A
We
have
a
web
hook,
definition
for
how
this
can
be
used
together
with
web
hooks
together
with
a
protection
mechanism.
So
we
have
a
protocol
foundation.
One
of
the
things
we
haven't
haven't
solved
yet,
for
instance,
is
how
we're
going
to
do
subscriptions
because
it's
a
pop
sub
model.
So
how
can
we
find
out?
Who
is
offering
which
events?
How
can
I
go
and
initiate
a
subscription
to
it?
How
we're
gonna
make
that
work
with
a
polyglot
world
where
you
have
not
only
HTTP
but
also
have
other
protocols,
so
so
finding
out?
A
A
A
A
Seek
a
native
is
very
popular,
so
you're
all
trying
to
get
Canaan
of
coffee
I
see.
So
what
this
does
effectively
is
a
little
of
simulation.
That's
based
on
an
air
that
that's
based
on
a
fairly
serious
airport
scenario
where
you
have
suppliers
up
here:
warehouses
who
have
coffee
and
cups,
and
then
you
have
have
you
know
transport
logistics
companies
which
go
and
carry
those
things,
and
as
you
order
coffee,
there
is
some
certain
stock
in
the
stores
and
those
that
stock
is
then
being
replenished.
A
This
then
being
reported
hey
I'm
out
of
order,
coffee,
coffee,
mugs
and
that
thing
gets
reported
out
into
the
warehouses.
The
warehouses
then
say:
yeah
your
order
is
ready.
Then
the
car
comes
and
also
we're
doing
all
this
with
loud
events.
So
when
you
look
at
this,
I
can
go
and
pick
like
here's
an
order.
That's
the
order
status.
The
order
has
been
that
order
has
now
been
released
from
the
retailer.
A
You
know.
Oh
that's
the
same
one.
So,
but
the
amazing
thing
about
this
is
you
see
that
there
are
all
kinds
of
different
participants?
So
the
in
the
back
of
this
is
a
message
broker
and
that
message
broker
speaks
ATP
and
has
a
topic,
and
so
everybody's
publishing.
To
that
thing,
cloud
events
and
then
their
subscribers
would
show
up
from
all
the
various
companies-
and
this
is
using
the
K
native
stack
this.
That
is
using
the
cost
of
the
Oracle
function
of
slack.
A
A
A
It
was
mostly
flawless
because
we
had
agreed
on
something
we
have
as
the
SDKs
if
we
can
all
use,
and
so
this
is
a
multi
cloud
solution
where
the
the
UI
is
hosted
by
IBM
and
Doug
did
most
of
the
work
for
all
the
one
of
those
wonderful
visualizations
and
then
all
the
other
participants
are
in
various
clouds
and
it
all
works
really
wonderfully
together.
So
as
a
it's
beautiful,
it's
a
beautiful
little
showcase
of
how
the
interoperability
works.
A
Cloud
events
and
production,
so
some
folks
have
cloud
events,
so
we
just
got
done
as
I
said
what
three
weeks
ago,
four
weeks
ago,
but
there
is
already
production
news
and
since
I'm
already
talking,
I
will
be
talking
about
what
we
do
at
Microsoft
and
I
have
one
slide
and
a
bit
of
a
demo
for
it.
So
we
have
event
grid
as
your
event
grid
is
our
Universal
pops
up
engine
that
is
part
of
the
Azure
cloud
and
what
it
is
is
a
broker.
That
is
a
push,
push
push
broker.
A
That
allows
you
to
publish
events
subscribe
to
them
and
we
will
go
and
push
into
particular
different
destinations.
So
you
can
go
and
push
to
a
queue
and
then
he
has
more
like
a
pub
like
a
classic
pop
sub
system,
but
you
can
also
push
into
you
know
an
event
event
and
gesture.
You
can
push
into
logic
apps
for
work.
You
can
push
into
a
storage
queue.
You
can
push
into
any
web
hook.
A
You
can
push
into
a
tree
function,
so
you
can
go
effectively,
raise
events
and
then
you
can
go
and
have
them
routed
to
either
messaging
destinations
or
destinations
where
you
can
go
and
do
compute
on
based
on
them.
That
exists
in
two
forms.
There's
event
grid
in
the
cloud
which
exists
in
all
data
as
our
data
centers
and
there's
event
grid
on
IOT
edge.
Now,
which
is
something
that
we
just
prop
just
released
a
few
weeks
ago.
A
Iot
edge
is
a
containerized
cloud,
managed
environments
for
IOT
devices
or
IOT
gateways,
and
so
grid
also
exists
in
that
now,
that
is
not
true.
Burnett
is
based,
and
you
should
expect
that
that
little
event
grid
on
IOT
edge,
which
is
a
containerized
Linux
workloads,
will
eventually
go
and
grow
out
of
that
little
container,
that
is
in
in
IOT
edge
and
will
also,
you
know,
go
elsewhere,
but
we
have
effectively
a
group.
We
have
an
edge
offering
and
we
have
a
cloud
offering
and
those
things
also
integrate
with
each
other.
A
A
My
portal
I
have
a
file
store
here,
so
that's
in
the
azure
portal
in
in
my
file
store.
So
this
is
a
storage
account
where
I
can
go
on
store
files
and
here's
a
my
event
configuration
so
here
you
can
go
and
add
event
subscriptions
to
a
storage
account.
What
you'll
do
is
so
you
see
that
event
grid
is
actually
a
feature
of
the
respective
platform
features
so
go
and
create
this
event
subscription,
and
you
can
see
here.
I
can
give
that
thing.
A
Your
name
that's
funny
foo,
and
here
you
can
now
select
the
cloud
event
schema
and
then
you're
gonna
get
cloud.
Events
pushed
to
you
with
the
full
with
the
web
book
specification,
compliance
which,
which
means
also
including
the
pre
validation
hook.
I,
have
already
created
that
for
you,
so
I'm
gonna
abandon
this
and
I'm
gonna.
Have
this
rule
here?
A
I
set
this
up
and
I
have
a
little
app
that
I'm
running
here
and
that
app
is
using
the
the
azure
relay,
which
means
this
is
a
asp.net
server
application
that
runs
on
this
machine
and
it
projects
out
a
listener
endpoints
into
the
azure
cloud.
So
the
endpoint
that
we're
gonna
hit
is
in
the
ad
for
cloud
and
then
the
request
gets
gets
down,
pushed
to
this
machine
so
and
we're
gonna
do
this
with
this
tool,
because
we
have
now
created
a
trigger
on
when
a
blob
has
been
created
on
that
storage
account.
A
A
And
you'll
see
that
I
just
got
that
event.
You
know
here
that
is,
we
have
a
new
block,
a
new
blob
was
put,
a
new
club
was
played,
uploaded
and
I
could
now
go
and
and
act
on
that
event
and
say
you
know,
push
that
new
file
into
a
you
know.
Cognitive
services
thing
for
for
category,
for
cattle,
categorization
I
could
go
and
recoated
I
can
basically
go
and
turn
that
no
into
a
picture
library,
alright,
and
that
is
what
I
had
for
you
from
Microsoft.
C
C
Customers
still
want
to
have
their
own
special
things
and
one
extended
with
their
own
logic.
They
they
may
need
some
additional
validations.
All
those
things
are
not
no.
Two
businesses
are
really
alike
and
yes,
oh
that's
done
by
extensibility,
and
those
extensions
of
course
need
to
know
whenever
they
have
to
get
active.
They
need
to
be
triggered
somehow
and
that's
done
by
business
events.
So
in
our
case
these
really
have
some
business,
some
antics
and
so
they're,
not
as
technical.
C
It's
really
something
happening
in
the
business
in
this
case
and
the
other
direction,
then,
is
API
calls
I.
Guess
that's
quite
common,
but
this
is
the
overarching
scheme
also
over
the
next
slide.
So
you
have
always
events
an
API
is
and
how
this
now
looks
like
in
SMP.
We
provide
this
club
platform
extension
Factory,
and
that
is
then
the
job
to
wire
extensions
together
with
all
of
our
applications.
C
We
have
different
runtimes,
where
you
can
provide
extensions
depends
on
the
flavor
you
prefer.
So
there
is
the
kheema
runtime,
which
is
based
on
an
open
source
project
on
on
kubernetes.
We
have
a
service,
runtime,
basically
functions
and
also
application
runtime,
it's
called
here,
it's
basically
Cloud
Foundry
and
also
our
classic
programming
language
called
ABAB,
and
all
of
this
is
running
on
different
infrastructure
providers.
That's
also
important
because
some
more
interoperability
is
needed.
We
run
actually
on
Google
on
Azure
and
AWS,
and
many
more
actually
also.
We
have
our
own
data
centers
so
and
yeah.
C
C
Interoperability
is
really
important,
as
we
have
all
those
applications,
some
of
them
rigea
nating
from
companies
that
got
acquired
and
developed
by
different
teams.
All
around
the
world
so
to
really
have
events
from
all
of
those
applications
handled
the
same
way
is
a
real
advantage
for
us
and,
as
I
mentioned,
if
the
infrastructure
provider,
as
we
have
seen
before,
is
also
using
cloud
events,
that's
of
course,
another
interesting
advantage.
C
Standardization
brings
not
only
interoperability
for
us.
It's
also
helping
us
to
provide
consistent,
tooling.
There
might
be
open
source
tools,
I
mean
we
have
already
the
SDKs
in
our
own
project,
but
we
can
also
be
we
also
able
to
write
our
own
very
specific
tools
for
our
developers
and
developers
who
come
and
extend
SOP.
Software
can
also
then
might
already
know
cloud
events,
even
though
they
might
not
be
really
accustomed
to
any
ap
specific
things.
So,
there's
open
standard
here
is
really
an
advantage,
and,
last
but
not
least,
the
inventing
infrastructure.
C
We
only
have
to
provide
one
eventing
infrastructure
for
our
applications,
and
so
essentially
you
could
say
that
a
unification
here
also
saves
us
money
and
so
one
example
from
an
actual
application
where
we
use
cloud
events,
this
application
is
called
subscription
billing
and
it's
about
and
yeah.
So
actually,
our
customers
can
handle
their
customers
subscriptions
in
there.
So
that's
what
the
event
is
telling
and
a
subscription
has
been
created.
You
can
see
that
attributes
we
have
already
seen
also
in
Clements
presentation
and
I'd
like
to
bring
your
attention
to
those
two
fields.
C
C
C
We
have
mqp,
we
have
MQTT
and
also
as
web
hooks,
are
really
quite
common.
We
also
support
HTTP
and
a
real
example.
I
mean
a
combination
of
technologies
that
might
occur.
We
have
an
application
that
emits
an
event
in
MQTT
and
then
you
might
have
an
function
that
wants
to
act
upon
that
event.
So
we
have
a
message
trigger
and
the
trigger
receives
that
event
over
AMQP
and
triggers
the
function
using
HTTP.
C
You
could
see
in
the
demo
before
so
we
already
added
the
cloud
even
attributes
to
the
signature
of
the
function
so
that
the
function
developer
can
just
use
those
fields
without
further
doing
any
protocols
with
specific
things
and
yes,
well,
you
see
I
I
did
this
switch
statement
for
the
type
and
also
looked
at
source
and
subject
in
some
cases,
and
also
you
in
the
function.
You
can
then
just
send
an
event
without
really
dealing
with
protocol.
That's
in
this
case
doing
this
the
functions
runtime
for
you.
C
So
for
someone
who
who
likes
to
do
a
bit
more
complex
things
or
to
do
it
in
a
more
open
way
on
kubernetes
we
have
project
kima,
and
so
this
is
an
open
source
project.
Everybody
can
can
download
it
and
install
it
on
any
kubernetes
cluster
internally.
We
would
of
course,
run
it
on
our
own
infrastructure
called
gardener.
C
C
So
what
did
we
learn
so
far
from
using
cloud
events?
So
one
thing
is
that
maybe
existing
messaging
infrastructure
has
usually
is
usually
working
on
things
like
topics
to
work
efficiently
and
a
lot
of
those
of
the
share
products
we
have
in.
There
have
some
limitations
for
those
topics
like,
for
example,
the
topic
length
being
around
250
bytes,
or
something
like
this,
or
only
allowing
special
characters
in
there
and
so
doing
this
routing.
C
I
think
if
you
start
using
cloud
events
or
defining
them
for
your
organization,
you
should
think
carefully
about
sauce
and
type
to
make
it
consistent
throughout
your
organization.
In
our
case,
it
will
hopefully,
in
some
case,
be
dozens
or
even
hundreds
of
event
types
overall
applications,
so
we
thought
carefully
I
think
and
he
has
very
specific
experience.
Jamie
s
and
cloud
events
doesn't
really
fit.
C
Well,
as
JMS
is
an
API
standard,
it
doesn't
really
define
what
what's
the
outcome
on
the
wire
and,
of
course,
if
you,
if
you
rely
on
a
specific
Jamie
as
driver,
then
might
work.
But
if
you
want
to
have
this
possibility
of
JMS,
then
doesn't
really
work
well
with
cloud
events
s.
You
can't
really
rely
on
what
is
on
the
wire
and
that's
what
cloud
events
finally
does
with
the
protocol
bindings.
So,
yes,
we
had
some
discussions
already
in
the
working
group
yesterday
and
about
what
we
are
doing
in
the
future.
C
D
All
right,
thank
you
class
all
right,
so
I'm
going
to
talk
about
K
native
a
little
bit
of
IBM
and
they're,
mainly
about
K
native,
even
though
it's
about
the
suspect,
most
you
are
in
ok
native,
is
just
in
case
there's
some
of
you
that
don't
you
can
think
of
K
native
as
a
simplified
developer
experience
on
top
of
kubernetes.
That
has
two
main
components
to
it,
serving
for
obviously
hosting
applications.
But
then
it
also
has
an
eventing
component,
which
of
course,
is
why
we're
talking
about
cloud
events.
D
So
what
Canada
does
in
terms
of
leveraging
cloud
events?
Is
it
basically
normalizes
all
the
events
coming
into
the
system
and
turns
them
into
cloud
events?
And
it
does
this
mainly
so
that
you
can
do
everything
that
these
guys
already
talked
about,
which
is
process
the
events
without
actually
having
to
understand
the
business
logic
within
the
events
right,
because
if
you
can
normalize
it
into
a
shapee
into
a
cloud
event
formats,
then
you
could
have
all
this
middleware
inside
of
K
native
processes
without
having
to
be
specialized
code
for
every
single
type
of
event.
D
Every
type
of
format
that
came
in
and
stuff
like
that,
so
let's
look
at
very
concrete
example
here
in
terms
of
what's
available
inside
of
a
key
native
eventing.
So
let's
say
you
haven't
done
producer
and
what
can't
even
ask
you
to
do
or
help
you
do
is
actually
subscribe
to
the
producer.
You
could
say:
go
subscribe
to
say
get
up
for
me:
I
want
all
events
related
to
pull,
request
and
stuff
like
that.
D
D
However,
they
also
have
this
notion
of
brokers,
so
if
you
tell
Kay
native
to
send
the
event
not
directly
to
your
service
but
to
a
broker
that
allows
you
to
do
start
to
do
some
fan
outs
and
a
little
bit
of
orchestration
of
the
events,
so
what
you
can
do
is
have
your
service
subscribe
to
the
broker
through
a
trigger.
Now
the
broker
may
have
some
persistence
in
there.
D
Maybe
in
memory
that's
kind
of
a
that's,
not
the
point,
but
the
point
here
is
that
you
could
have
multiple
people
subscribe
to
the
broker,
so
you
get
that
fan-out
mechanism.
Now
the
trigger
is
acid,
which
can
take
a
filtering
mechanism
and
you
can
filter
on
the
cloud
event
metadata.
So
what
this
means
is,
you
could
technically
have
a
broker
that
subscribes
to
a
producer
like
github
and
ask
for
basically
all
events
on
an
entire
organization
or
repo,
but
then
you'd
out
the
service
level.
When
you
subscribe
to
the
trigger
that
you
can
actually
say.
D
Oh
I
only
want
on
this
particular
service
to
get
in
events
about
pull
requests
another
one
to
get
information
about
events.
That's
the
trigger
can
do
that
filtering
based
upon
cloud
event
metadata
the
type
field
in
particular,
or
the
source
field,
if
you
actually
subscribe
to
more
than
one
goetaborg
right
and
that
trigger
can
get
its
job
done
without
knowing
anything
about
the
event
itself,
meaning
that
it's
came
from
github.
What
the
syntax
from
github
looks
like
or
anything
all
it
has
to
know,
is
basically
regular
expression
type
processing
on
the
cloud
event
metadata.
D
Okay,
so
that's
the
best
huge
benefit
right
there,
because
now
we
can.
You
can
start
to
produce
generic
infrastructure
for
managing
events
without
understand
the
business
logic.
Just
to
complete
the
picture,
though,
when
the
service
or
if
the
service
has
a
reply,
you
can
also
tell
the
broker
to
send
it
on
to
someplace
else.
D
Some
other
sync
and
just
mention
that
for
something
later
on
now,
they
also
have
other
types
of
tools
in
the
toolbox
in
terms
of
how
to
manage
and
orchestrate
these
events-
and
this
very
case
they
have
something
called
parallel,
which
you
can
think
of
sort
of
like
a
fan
out.
One
of
them
comes
in
gets
sent
to
multiple
conditions.
If
it
condition
passes,
then
it
gets
sent
on
to
the
sync
associated
with
the
condition.
Well,
that
condition
is
basically
a
filtering
mechanism.
D
Now
in
this
particular
case,
though,
it's
actually
running
a
container,
so
you
could
do
a
very
complex
filtering
thing
if
you
want,
but
you
can
also
filter
on
cloud
events,
if
you
don't
want
to
understand
the
actual
business
logic,
ok,
so
another
place
where
the
abstraction
helps
us
and
finally,
again
just
to
sort
of
compete.
The
picture
for
those
you
don't
know
about
Kay
native
there's.
D
Also
this
thing
called
sequence,
which
has
nothing
to
do
a
cloud
offense
or
filtering,
but
you
can
send
multiple
the
event
through
multiple
hops
or
multiple
syncs
and
the
point
of
all
this
is
candy.
This
gives
you
the
basic
infrastructure
to
define,
inventing
workflow,
orchestration
type
of
mechanism
and
nothing
inkay
native
is
event-specific
right,
doesn't
understand
it's
getting.
Events
from
github
versus
get
lab
versus
anything
else,
or
even
the
transport
it
comes
in
over.
D
All
it
knows
is
after
the
adapter
it
gets
converted
into
a
cloud
event
over
HTTP,
and
then
everything
else
can
work
magically
and
cloud
events
is
an
integral
part
of
that,
so
enable
things
like
the
automatic
routing
and
filtering
and
stuff
like
that.
So,
in
my
mind,
cloud
events
was
specifically
is
a
perfect
fit
for
something
like
a
native.
In
this
event,
think
of
the
structure-
it's
like
oh
perfect,
one-to-one
match
in
my
mind
and,
of
course,
because
I
work
for
IBM
I
have
to
mention.
D
E
All
right
how
many
of
you
have
been
using
PayPal
last
month,
almost
everybody
very
good,
so
PayPal
is
very
much
like
this
Airport
demo.
Instead
of
moving
coffee
and
real
Goods,
there
is
money
flowing
between
different
areas.
So
I
would
like
to
show
you
a
couple
of
examples
of
how
do
we
use
cloud
events
at
PayPal?
E
So
the
emergence
of
cloud
events
was
kind
of
natural
place
for
us
to
try
to
organize
all
of
these
different
teams
and
align
on
the
structure
and
syntax
of
events
that
exchanged
between
the
systems.
So
originally
the
interaction
started
between
zoom
and
ephemeral
and
PayPal,
so
the
things
that
are
happening
in
zoom
and
when
loaded
PayPal
needs
to
know
about
are
published
as
events
and
there
are
consumed
by
PayPal
and
their
various
processing
and
analytics.
That
is
happening
there.
E
Currently,
as
you
can
see,
the
arrow
goes
from
the
partners
to
the
PayPal
and
not
necessarily
the
other
way
around.
The
other
way
would
mean
that
something
happens
that
PayPal
the
other
partner
would
need
to
know
about
that,
and
we
will
fire
a
cloud
event
and
they
would
react
on
that.
Currently,
this
is
not
happening
for
one
specific
reason,
and
that
is
that
most
partners
have
already
well-established
integrations
with
PayPal
and
that
they
are
just
using
their
already
existing
channels,
but
for
a
new
partner,
this
is
definitely
an
interesting
option.
E
So,
let's
see
what
is
happening
inside
so
when
you
have
a
producer
which
is
firing
cloud
events,
they
are
going
to
do
that
here
using
HTTP
and
then
the
event
will
reach
PayPal
and
the
way
how
that
works
is
the
event
will
reach
our
first
endpoint
for
authentication
and
authorization.
This
is
the
part
of
our
standard,
PayPal
gateway
that
is
dealing
with
different
parties.
So
basically
you
have
here
the
basic
checks.
If
the
other
party
is
allowed
to
talk
to
us,
then
there
will
be
compliance
in
the
compliance
section.
E
We
are
going
to
look
into
event.
We
are
going
to
see.
Is
this
something
that
we
expect?
There
will
be
the
authorization
we
are
going
to
look
if
this
part
is
supposed
to
send
such
event
to
us.
So
you
have
a
more
kind
of
semantic
checks
based
on
the
relationship
that
we
have
with
the
partner
and
then
there
will
be
dispatch.
I
will
talk
about
this
patch
in
a
moment
from
there
you
have
the
event
that
is
delivered
to
variety
of
services
that
then
actually
consume
the
event
and
do
something
with
it.
E
The
integration
of
functionalities
in
the
Gateway
is
basically
happening
in
two
areas.
One
is
the
API
proxy,
which
performs
a
variety
of
authentication
authorization.
There
is
the
essential
routing
that
is
happening
there,
and
then
we
have
a
component
that
is
doing
the
event.
Dispatching
that
one
is
going
to
go
inside
the
events,
it
is
going
to
check
that
they
are
well
formed.
According
to
the
contract,
they
are
going
to
decide
on
authentication,
observer
authentication
based
on
the
contract.
They
are
going
to
determine
what
needs
to
be
done
and
then
from
there.
E
There
are
two
things:
one
is
the
traditional
synchronous
delivery
through
HTTP,
and
you
have
also
another
type
of
delivery
for
us:
synchronous
processing
where
events
are
sent
into
the
queues
and
then
the
handlers
will
be
consuming
the
events
from
there,
and
that
is
the
current
aspect
of
integration
of
cloud
events
in
the
financial
space.
We
have
a
couple
of
forthcoming
areas
which
are
actually
in
the
area
of
software
development
life
cycle.
E
B
A
Yeah
so
resources
you
can
help.
While
we
are
done
with
cloud
events
core
specification,
we
are
not
done
with
the
code.
We
are
not
done
with
extensions.
We
are
not
done
with
all
the
encoding.
We
are
not
necessarily
done
with
transports,
even
though
we
would
prefer
to
be,
but
certainly
we
have
a.
We
have
a
slot
where
you
can
go
and
put
you
know,
custom
bindings
for
proprietary
transports.
If
you
really
must
have
one
you
can
put
them
in
there.
So
the
the
core
spec
is
locked.
A
All
the
specifications
that
we
have
all
the
bindings
are
effectively
locked,
but
we
are
open
for
new
things
as
well
and
I
said
the
the
the
the
codes.
Certainly
contributors,
pull
requests
to
make
the
SDKs
better
are
certainly
welcome,
and
then
we
have
work
over
all
in
the
server
list.
Working
group
that
will
leverage
cloud
events
that
will
extend
cloud.
Events
like
the
subscription
API
that
we
just
talked
about
the
Aventa
catalog
that
are
interested
where
we
need
to
have
helping
hands.
You
can
the
repo.
A
If
you
go
to
the
org
cloud
vents
under
spec,
you
will
find
the
specification,
including
enormous
amount
of
you,
should
go
and
take
a
look
at
the
the
close
pull
requests.
If
you
have
a
if
you
have
a
day
when
you
want
to
learn
a
little
bit
of
about
distributed
systems,
history
because
lots
of
very
interesting
discussions
in
there-
and
then
you
find
also
the
SDKs
under
this.
So
that
is
what
we
hadn't.
We
have
time
left
that
we
yeah.
We
have
tons
of
questions
time,
so
go
right
ahead.
There's
a.
F
You
showed
before
hours.
You're
already
starts
accepting
cloud
events.
Yes,
but
I
think
do
you?
Are
there
any
other
public
clouds
that
work
with
child
events
and
other
as
well?
You
only
allow
pushing
cloud
events.
What
about
the
other
way
around?
All
of
the
azure
services
that
today
image
to
the
to
the
azure
functions
yeah
and
we
intercept
them
ourselves
with
cloud
events
so.
A
A
So
as
as
so
in
a
Truffaut
as
or
if
as
a
farce
is
bind
to
binds
to
event
grid
and
you
can
in
a
natural
function,
you
can
get
a
cloud
of
it
so
that
all
works
with
so
event
grid
is
kind
of
the
pops
up
engines,
that
is
in
the
middle.
All
the
Microsoft
services
that
are
currently
publishing
grid
events
are
now
speaking
cloud
event
willow
and
you
can
go
and
hook
up
to.
You
can
push
it
into
a
queue.
You
can
push
it
into
a
national
farm.
F
A
Just
using
HTTP,
ultimately
so
so
it's
just
your
code
that
so
you
can
go
and
take
any
of
the
SDKs
if
you're
writing
code
in
and
go
if
you're
ordering
coated,
C
sharp.
If
you
writing
code
in
Java,
you
take
our
SDK
and
the
SDK
will
basically
take
the
request
and
crack
it
and
and
give
you
the
cloud
event.
Alright.
Thank
you.
A
Well,
the
maturity
level
is
that
we're
doing
it?
What
we
can.
This
is
an
open
source
project.
If
you
find
bugs
you
can
you
can
file
a
PR
and
help?
No,
but
the
so
I.
Can
you
know
the
the
various
teams
would
go
and
have
to
speak
for
themselves,
but
I
think
there
is
now
as
we're
now
done
with
the
speck.
H
A
Spec
and
if
the
an
extension
is
suspected
defines
attributes
that
you
can
also
put
under
that
cloud
events,
so
generally,
the
rule
is
that
you
can
go
and
make
you
can
add
any
attributes
that
you
like
to
the
outer
to
the
outer
level
of
a
cloud
events,
there's
no
restrictions.
We
have
some
naming
restrictions,
so
they
must
be
all
lowercase
that
can't
be,
and
must
only
be
letters
but
otherwise
they're
effective,
no
restrictions.
There
can't
be
any
complex
types
inside
of
them,
so
only
values.
A
If
you
have
not
multiple
values,
you
need
to
make
multiple
attributes,
but
otherwise
we
don't
put
any
restrictions.
An
extension
is,
in
our
parlance,
is
a
specification
that
that
that
describes
exactly
what
that
extra
attribute
does,
so
that
multiple
parties
can
implement
it
in
the
same
way.
So
we
have,
for
instance,
an
extension
for
a
sequence
number.
We
have
extensions
for
tracing
for
open
trade,
for
the
open
tracing
standard
and
some
other
extensions
that
effectively
give
you
a
common
concept
of
that
and
there's
a
rule
inside
of
the
spec.
A
That
says,
if
you
see
an
attribute-
and
you
don't
know
what
that
attribute
is
you
must
forward
it.
So
it's
always
guaranteed
that
if
you
drop
an
attribute
into
the
cloud
event
somewhere
over
here-
and
it
goes
through
multiple
hops
that
will
appear
at
over
on
the
other
side
through
all
the
through
all
the
converses
through
protocols
etc.
So
the
extension
for
an
extension
to
work,
it's
sufficient
for
both
ends
to
know
it,
because
the
all
the
middle
infrastructure
in
the
middle
is
obliged
to
go
and
carry
to
carry
that
further.
So.
A
So
that's
the
so
that's
the
intent
you
can,
you
can
go
and,
and
just
as
you
would
do
with
any
messaging
system,
you
can
go
and
take
out
of
your
payloads.
Three
four
five
important
metadata
element
promotes
them
out
into
the
cloud
event,
so
that
then
infrastructure
which
operates
on
the
cloud
events
context
attributes
will
then
be
able
to
filter
on
them.
So,
as
you
would
do
that
with
with
JMS
or
with
some
other
major
structures.
A
A
The
event
format
is
useful,
so
you'll
see
that
and
we
have
in
the
industrial,
where
we're
having
some
collaboration
talks
with
standardization
efforts
in
the
industrial
space,
where
there's
a
lot
of
time.
Serious
data
and
a
lot
of
you
know,
event
information
that
then
gets
aggregated
stored
or
hauled
around
and
that
we're
also
recommending
in
those
talks
that
they
also
switch
from
their
model
to
to
plot
events.
So
yeah.
B
J
A
So
the
w3c
context.
For
that
specific,
we
have
the
tracing
extension
and
we
have
so
so
you
would
use
you
would
use
and
some
of
the
SDK.
So
the
sharp
SDK
has
that
I
don't
know
what
the
status
of
the
other
ones
is,
but
the
c-sharp
SDK
has
a
first-class
sterilizer
effectively
for
the
well-known
extensions,
including
the
trace
context
that
you
can
then
that
you
can
then
use.
But
you
would
the
trace
context
will
propagate
just
like
just
like
it
does
on
HTTP,
but
the
so
at
the
at
the
event
level.
A
Now,
there's
a
there's,
an
interesting
kind
of
duality
which
we've
also
been
discussing.
There
is
because
the
question
was:
when
do
we
map
from
the
extension
to
the
HTTP
context,
and
we
had
this?
There
was
a
long,
drawn-out
discussion
of
whether
we
should
where
they
shouldn't.
We
ended
up
with
saying:
no
we're
not
gonna,
go
and
do
any
mapping,
but
we're
gonna
let
and
let
that
extension
leave
that
extension
alone
effectively.
You
have,
if
you
think,
about
the
transport
levels.
A
That's
a
different
trace,
trace
path
than
the
end-to-end
relationship
between
the
apps
and
it's
effective,
your
choice,
whether
you
want
to
root
both
of
those
contexts,
the
event
per
se
and
the
HTV
transport
in
the
same
in
the
same
context
route
you
can
do
that
and
then
you
have
two
different
paths.
You
can
basically
pick
from
so
we
we
chose
not
to
do
any
magic,
but
let
you
effectively
put
a
context
into
the
event,
and
so
the
event
can
do
the
events.
A
A
I
Across
a
large
in
ill-disciplined
company
thinking
about
how
to
stop
multiple
units
emitting
the
same
even
time
would
the
controls
for
that
be
basically
around
the
schema
registry.
So
you
would
tag
up
events
with
a
schema
and
control
who
owns
that
particular
schema
believe
in
what's
what
stops
kind
of
multiple
units
limiting?
You
know
well,.
A
What
stops?
What
stops
you
know?
Three
departments,
hijacking,
WW
your
company
comm.
So
there
is
there,
are
there?
Are
there
always
naming
and
and
naming
rules
and
and
ways
to
go
and
create
a
resource
graph
across
the
system
and
decisions
are
made
about
who
owns,
which
domain?
Who
owns
which
sub
side
of
your
corporate
corporate
side?
So
that
is
effectively
the
same
problem,
but
what
we
did
in
in
cloud
events
for
the
type.
A
The
suggestion
is
that
it
is
used
for
event,
types
use,
reverse
DNS,
which
means-
and
it's
the
same
thing
with
like
how
can
I
make
sure
that
nothing
that
the
other
team
over
there
doesn't
publish
the
same
package
with
the
same
name.
You
know
for
Java
that,
whatever
on
our
internal
repository
right,
they
have
a
name
and
that's
the
name
that
they
use
so
event.
A
event.
Here
is
the
same
thing
you
use,
you
know,
calm,
Microsoft
thoughts,
and
then
you
know
team
name
whatever,
and
they
can
go
and
create
those
events.
A
D
A
H
A
A
D
H
A
And
I
think
that's
a
perfect
case
for
accessibility,
because
because
it
seems
like
from
your,
this
might
be
something
that's
fair
custom
or
in
your
in
your
particular
model
that
you
have,
and
so
that's
what
accessibility
is
for.
But
if
you
have
a,
if
you
want
to
make
a
case
that
that's
something
that
everybody
should
be
doing
and
should
be
using,
then
the
proposal
extension
yeah.
D
Actually,
we
had
very
long
discussions
around
correlation
IDs,
yes,
and
we
ended
up
not
doing
them
exactly
because
what
Clement
said
there
was
so
many
different
reasons
for
the
correlation
it
would
seem
like
it
would
be
endless
possible
things
and
agree
on
the
semantics
and
it
just
seemed
like
an
entirely
different
ball
of
wax
and
I
thought.
Like
some
and
said,
let
it
start
out
as
an
extension
if
it
becomes
so
popular
that
everybody
has
this
particular
correlation
ID
and
with
the
very
well
defined
meaning,
we
could
add
it
to
a
specification
editor.
D
You
know
it
would
always
be
optional
anyway,
and
that
same
thing
as
an
extension,
so
would
just
be
formalizing
the
name
that
everybody
knows
it.
They
don't
the
Krays
are
all
named
for
it,
but
we're
very
open
to
those
kind
of
things.
It's
just
like
security.
Oh
my
gosh,
do
you
want
to
tackle
this
and
please.
K
B
B
Documentation
actually
so
one
of
the
things
that
I
like
about
REST
API,
is
that
we
have.
We
have
nowadays
an
agreed-upon,
open,
API,
spec
format
that
we
can
use
to
describe
the
entire
API
and
know
what's
possible
and
know
what
the
relevant
data
types
are
and
so
on
and
so
forth.
Have
there
been
discussions
within
the
service
working
group
around
developing
a
similar
way
of
presenting?
So
let's
say
I'm,
you
know
as
your
event
hub
and
or
let's
say
that
I'm
somebody
that
wants
to
you
know
consume
events
from
a
particular
source.
B
A
Yes,
yesterday,
so
we
had
a
we
had
a
meeting
yesterday,
both
in
future
directions
and
the
event
catalogued
together
with
the
subscription
mechanism,
is
something
that
that
came
up
and
as
something
that
people
would
want
to
work
on
and
Klaus
also
had
had
that
on
this
in
these
slides.
So
that's
certainly
one
of
the
areas.
What
we're
gonna
have
a
we're.
A
Gonna
have
a
discussion
about
this
in
on
the
regular
meetings
and
then
basically
make
a
decision
on
what
we're
going
to
work
on
next
and
that's
one
of
the
areas
that
we'll
go
and
tackle
next
now,
it'll
be
a
little
different
from
what
open
API
is
because
the
open,
API
ultimately
describes
a
contract
for
a
relatively
constrained
surface
area
and
an
event
event.
Metadata,
store
and
description
store
needs
to
be
a
little
bit
different
because
you
have
events
flowing
into
all
kinds
of
directions.
A
So
where
were
you
know,
you've
seen
the
exact
example
of
Canada?
If
you've
seen
the
example
of
atrovent
cred
and
s,
AP
is
building
infrastructure
pieces
as
well,
and
those
infrastructure
pieces
are
built
such
that
they
can
handle
called
events
generically
and
you
know,
depends
on
what
the
capabilities
are
and
how
far
they
can
filter
on
things
that
are
not
just
source
and
type.
A
But
you
know
it
makes
no
sense
to
go
and
promote
something
out
if
there
is
no
code
that
will
go
and
act
on
it
and
that
code
that
will
act
on
it
should
be
code
that
you
haven't
written,
so
everything
that
you
need
just
for
the
last
dispatch
that
stage
where
you
can
already
know.
What's
inside
of
that
event,
you
can
look
inside
of
the
event,
but
generic
infrastructure
can't
afford
to
look
inside
of
your
event
data
because
it
doesn't
know
what
that
is.
A
It
doesn't
know
your
encoding,
it
doesn't
know
your
schema,
it
doesn't,
and
it's
actually
compute
intensive
to
go
and
go
through
that
data.
So
it
can't
afford
that
so
anything
that
you
want
to
show
external
infrastructure
to
go
and
write
a
rule
to
go
and
route
things
left
or
right
that
should
go
in
there.
I.
K
Have
a
quick
question
in
regards
to
subjects
so
currently
you
only
allow
for
like
0
or
1.
Was
there
any
thought
given
to
allowing
multiple
subjects
like
let's
say,
for
your
blood
I'm,
creating
a
file
having
the
subject
being
the
file
name,
and
also
possibly
the
user,
who
created
the
file
for
cases
where
there
is
more
complex
information
where
you
want
to
filter
on
and
so
just
a
simple
string
matching.
So
we.
A
A
If
you
want
to
distinguish
by
file
extension,
they
put
the
file
name
in
there
and
then
you're
gonna,
say
JPEGs
go
here.
Raw
cr2
go
here,
jiff
go
here,
so
you
were
basically
going
and
make
that
distinction.
You
can
go
in
that
from
the
routing
perspective,
but
if
you
want
to
go
more
differentiate
it
then
you
know
cramming
that
all
in
that
one
subject
field
is
probably
not
the
best
idea,
but
if
you
have
an
intermediary,
you
know-
and
now
this
goes
into.