►
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
Intro: CNCF Serverless WG / CloudEvents - Doug Davis, IBM & Cathy Zhang, Huawei
Provide an introduction to the CNCF Serverless Working Group, the CloudEvents specification and the new Workflow sub-group. More details later...
To Learn More: https://sched.co/Grcc
A
B
A
You
alright,
let's
get
started
okay,
so
basically,
gonna
do
here
is
talk
about
very
quickly,
some
of
the
histories
of
where
we
got
or
how
we
got
to
where
we
are
today
between
the
service
working
group
in
the
C,
&,
C,
F,
and
then
the
cloud
event
specification,
which
is
an
offshoot
from
the
service
working
group
and
as
part
of
that,
we'll
talk
about
what
we're
doing
in
the
cloud
events
working
group
like
talk
about
SDKs
status,
a
cloud
events
demo.
Actually
the
order
here
is
a
little
mixed
up.
A
We
changed
the
last
second,
so
I
apologize
that
this
taxi
doesn't
line
up
with
the
order.
I
apologize,
but
I
blame
Clemens.
It
was
my
fault.
Yes,
so,
let's
start
with
the
service
working
group,
so
around
mid
2017,
the
technical
Oversight
Committee,
which
is
sort
of
the
governing
board
of
the
governing
boards
right,
were
the
technical
oversight
board.
If
you
wanna
call
it
committee
of
the
CNC,
F
was
sort
of
sort
of
providing
the
technical
direction
for
the
CNC
F
started.
A
Obviously,
hearing
about
service
like
everybody
else
did,
and
they
basically
wanted
to
figure
out
what,
if
anything,
should
the
C&C
F
do
about
service?
Maybe
nothing
maybe
get
more
involved.
Try
to
write,
find
projects
to
bring
it
into
CN
CF
whatever.
So
what
they
decided
to
do
was
to
form
a
working
group
whose
purpose
in
life
was
to
basically
help
answer
that
question.
A
So
there
they
were
chartered
to
produce
a
white
paper
that
basically
provided
an
overview
of
the
service
technology
itself,
state
of
the
ecosystem
and
then
recommendations
for
next
possible
steps
and
that
the
result
of
that
is
a
PDF
document.
You
can
see
it
on
the
website
itself,
under
the
CN
CF
service
working
group
and
basically
does
everything
I
listed
there
right
tells
you
everything
you
need
to
know
about
service,
comparing
it
with
other
asses.
You
know
comparing
faz
versus
server
list
versus
paths
vs.
A
containers
of
service
when
you
should
use
each
one
anything
you
might
want
to
know
about
server
lists,
including
the
architecture
or
popular
ways
to
implement
it,
and
we
also
included
in
there
a
landscape
document
which
is
really
as
a
fancy
way
of
saying.
What's
out
there
today,
what
are
the
open
source
versions
of
serval
is
or
function
of
service
frameworks?
What
are
the
proprietary
ones?
A
What
are
the
popular
languages
that
are
supported
things
you
might
want
to
know
when
you're
going
to
pick
a
particular
service
framework
or
what's
served
what
services
you
want
to
use
with
your
service
framework,
just
general
information
about
what's
out
there
in
the
industry,
but
the
key
thing
here
for
us
anyway,
was
the
last
bullets.
That's
nested
under
there
is
recommendations
for
next
possible
steps.
So
what
we
basically
did
is
we
said
service.
A
You
know
here
it
is
it's
all
its
glory,
but
in
terms
of
next
steps,
we
really
should
look
at
possibly
standardizing
or
harmonizing
some
of
the
efforts
here,
because
a
lot
of
people
are
doing
the
same
type
of
thing,
but
the
way
the
application
developer
or
user
is
using.
It
is
different
for
each
platform.
A
So
are
there
some
things
we
can
standardize
on
just
to
make
the
life
easier
right
now
we're
not
trying
to
constrict
what
they're
trying
to
do
from
a
functionality
perspective
just
make
things
a
little
more
portable
or
interoperable
for
the
end-user
right.
It's
all
about
the
end-user
here,
and
so
one
of
those
sort
of
low-hanging
fruits
that
we
came
across
was
the
events
they're
actually
coming
into
the
system
that
kicked
off
these
functions.
A
We
thought
well,
a
lot
of
these
things
could
benefit,
for
these
events
could
benefit
from
some
level
of
standardization
here,
not
enough
so
much
in
the
terms
of
standardizing
what
the
event
itself
looks
like
from
a
soup
to
nuts
perspective,
but
just
in
terms
of
routing
it
to
the
application
and
we'll
go
to
little
more
details
there,
but
that's
what
it
was.
One
of
the
recommendations
was
cloud
events.
Where
are
the
recommendations
around
education
and
stuff
like
that,
but
that
was
really
one
of
the
bigger
ones
was
the
cloud
event
spec.
A
The
other
thing
that
we
decided
to
do
later
on
was
to
look
at
work
after
cloud
events
which
is
function
workflow
and
I'll.
Talk
very
briefly
about
that
later
on
in
the
presentation,
but
that's
sort
of
what
the
service
working
group
was
done
and
we're
now
that
same
group
people
is
now
shifted
focused
to
the
cloud
event
specification.
So,
while
the
service
working
group
isn't
actually
producing
whole
lot,
it's
not
like
they're
dead
or
anything
it's
just
their
everybody's
focused
on
cloud
events.
A
When
that
one's
sort
of
done
cloud
events,
the
service
work
group
will
spin
back
up
figure
out
what
we're
gonna
do
next
and
then
move
on
to
the
next
thing.
So
let's
talk
about
cloud
events,
because
that's
actually
the
more
interesting
one
to
me
right
now,
so
around
2017
December,
2017
cloud
ovens
project
started
with
the
goal
of
trying
to
see
if
we
can
standardize
to
some
degree.
A
The
events
that
come
into
these
function
of
the
service
platforms
or
service
platforms
now
keep
in
mind
we're
not
trying
to
produce
yet
another
cloud
event
structure
to
rule
them.
All.
We've
worried
done
that
of
before
many
many
many
times.
Ok,
what
we're
trying
to
do
is
figure
out
what
is
the
minimum
set
of
metadata
needed
by
the
infrastructure
receiving
the
events
to
just
route
it
properly
within
the
infrastructure,
whether
it's
to
the
application
or
to
the
next
layer
middle
layer
doesn't
matter?
A
What
is
the
bare
minimum
need
it's
just
to
do
some
routing
and
if
you
look
at
the
little
nested
bullets
here,
the
four
that
are
in
bold
are
basically
the
four
required
attributes
that
we
decided
and
are
needed
to
get
that
job
done
level
of
the
specification,
meaning
the
cloud
event
spec.
Just
so
people
know
what
properties
are
expected.
That's
it's
sort
of
an
easy
one,
but
type
of
the
event
right
is
this.
A
For
example,
a
github
issue
create
type
of
event,
that
type
of
thing
source
who
produced
the
event
itself
and
then
a
unique
ID.
Just
so
you
can
do
things
like
deduping
or
stuff.
Like
that,
you
know
you
need
some
sort
of
unique
identifier
for
this
particular
event
or
you
correlation
those
type
of
things.
Now
we
do
have
other
optional
properties
like
the
time
of
the
events,
content
type
and
schema
URL.
Those
are
they're
very
similar
to
what
you
might
see
in
HTTP
headers
that
describe
the
event
data
itself.
A
Just
in
case,
you
need
that
information
to
help
your
processing
of
it
but
notice
the
bare
minimum.
That's
required.
It's
really
type
source
and
ID.
That's
it
right
with
that
basic
information.
You
should
be
able
to
get
the
message
off
the
wire
through
the
infrastructure
and
hopefully
to
the
next
layer
in
the
processing
model,
application
middleware,
whatever
that
may
be
right
notice,
we
don't
get
into
what
does
the
event
structure?
Look
like
meaning
the
application
data.
Just
these
headers
are
these
views
of
actual
properties.
A
Now,
in
my
mind,
I
tend
to
think
of
this
very
similar
to
HTTP
right,
if
you
think
about
HTTP
HP
defines
some
common
headers,
but
then
the
bodies
of
the
application
to
figure
out
what
it
looks
like
and
to
do
with
right,
but
those
minimum
number
of
headers
allow
the
infrastructure
to
receive
a
message
and
pass
it
on
to
the
application.
That's
a
very
similar
model
of
what
we're
doing
here,
because
if
you
look
at
this
list,
it
acts
doesn't
seem
that
exciting.
A
If
you
look
at
it,
but
with
that
minimum
amount
of
data,
we're
hoping
to
you-
have
a
large
amount
of
benefit
relative
to
Portability
and
era
of
ability
going
forward.
Now,
with
that
basic
understanding
or
basic
set
of
properties
in
front
of
us,
we
then
said:
okay,
that's
great
got
these
properties.
We
need
to
actually
do
something
little
bit
more
with
that
to
get
some
interoperability.
A
So
we
did
we
defined
how
these
things
are
going
to
be
serialized,
not
just
in
terms
of
formats
like
Jason
and
stuff
like
that,
but
also
what
do
they
look
like
on
the
wire
again?
It's
all
about
interoperability.
If
we
don't
agree
to
that,
you're
not
going
to
get
that,
so,
let's
keep
moving
forward
then.
So,
let's
take
a
very
concrete
example.
A
Let's
say
you
have
this
particular
event
flowing
into
your
system
right,
it's
just
you're
posting
it
to
some
URL
that
ends
and
slash
events,
and
you
have
inside
the
HTTP
body
action
new
item
with
some
ID.
Ok,
application
data,
nothing
special
about
this.
So
what
does
cloud
events
actually
do
here?
What
it's
going
to
look
like?
Take
those
four
properties
mention
the
previous
slide.
They
appear
here
right,
we're
looking
at
cloud
events
specification
0.2,
the
type
of
the
event
in
this
particular
case,
a
unique
URL
that,
uniquely
it
describes
the
event
itself
so
yeah.
A
A
To
say,
oh
I
need
that
throughout
this
to
the
functions
that
are
gonna,
handle
repo
dot,
star
type
of
events,
it
can
now
write
it
for
route
it
properly
much.
In
the
same
way,
the
posts
on
the
top
with
the
URL
is
used
by
routing
by
the
HCP
server
itself.
Ok
minimal
the
amount
of
data
just
to
help
that
your
ability
of
routing.
Now
in
this
particular
format,
we
call
this
the
binary
format,
because,
basically
it's
you-
you
don't
really
touch
much
in
terms
of
the
data.
All
we
do
is
added
some
additional
HTTP
headers.
A
A
We
are
not
trying
to
touch
the
business
logic,
we're
not
trying
to
define
common
event
structure,
just
the
minimal
metadata
and
again
it's
all
about
first
steps
towards
interoperability,
because,
as
I
said
once
we're
done
with
this
we're
gonna
in
the
service
working
group,
we're
gonna
go
back
and
figure
out
what
we
want
to
do
next
in
terms
of
what's
the
neck.
The
next
pain
point
for
users
on
this
in
our
ability
and
portability
field,
a
problem
space
out
there,
okay,
so
the
deliverables
for
the
cloud
events
working
group
itself
or
project
itself.
A
Obviously
we
have
the
specification
itself
which
defined
the
properties
we
have
the
serialization
rules.
I
talked
about
the
formats,
the
transport
bindings
and
you
can
see
them
listed
up
there
in
binary
or
in
black
I'm.
Sorry,
bold.
We
also
have
a
primer,
which
is
basically
there
for
educational
purposes.
A
Right
tells
you
what
the
specifications
about
where
it's,
how
you
should
use
it,
some
of
the
design
decisions
we
made,
because
we
made
some
very
interesting
design
decisions
that
I'm
not
going
to
go
into
here,
but
some
people
may
think
they're
actually
kind
of
funky,
but
we
do
explain
why
we
do
it
and
we
tried
to
have
really
good
reasons
for
it,
but
we
don't
want
to
that.
People
have
to
guess
as
to
why
we
did
it
and
think
we're
just
insane.
A
We
actually
tried
to
write
down
our
logic,
and
finally,
we
have
some
SDKs
to
make
life
easier
for
people
to
actually
use
this
stuff,
even
though
the
number
of
things
we
have
in
the
specification
just
those
properties,
a
relatively
minor,
we
figured
an
SDK,
might
help
people
in
jump,
start
the
process
and
actually
using
these
things
and
Clemens
will
talk
more
about
the
SDKs
in
a
minute.
So
with
that
we're
doing
the
time.
A
Okay,
let
me
actually
do
a
demo,
because
for
us
it's
much
more
fun
to
actually
see
things
actually
flowing,
actually
helps
verify
that
actually
what
we're
producing
can't
actually
work.
So
how
many
here
know
the
game?
Your
child
called
mad
libs?
Okay,
most
people
not
but
everybody.
So
the
point
of
this
game
is
that
we
have
at
least
two
people.
One
person
is
given
something
like
this:
a
sentence
with
missing
words
below
the
missing
words.
There's
the
type
of
word.
That's
goes
in
there
adjective
adjective
now
now.
A
In
this
particular
case,
the
person
who
gets
this
asks
other
people
or
the
other
people
playing
the
game
to
just
randomly
pick
a
word
of
that
category.
Now
those
people
cannot
see
the
sentence,
so
they
have
no
clue
what
how
these
words
going
to
be
used
in
the
final
sentence,
and
the
point
here
is
they're
going
to
come
up
with
some
random
words.
You
fill
it
in.
You
get
a
funny
sentence
and
the
kids
all
laugh.
It's
a
lot
of
fun.
A
Okay,
so
we're
gonna
do
the
same
thing
here,
okay,
so
what
we
have
is
a
cloud
event
controller.
Basically,
the
the
brain
of
the
thing
who
actually
understands
the
sentence
is
going
to
be
asking
for
the
words.
So
it's
gonna
choose
a
random
sentence,
figure
out
the
missing
words.
It's
going
to
then
create
an
events
in
this
bigger
case.
The
type
is
word
that
found
that
noun
and
that's
put
their
case
or
adjective
or
whatever.
A
It
is
then
going
to
send
that
event
out
to
all
of
these
various
of
function,
platforms
out
there
who
have
subscribed
to
receive
this
event.
You
have
all
I'm
out
there,
let's
see
IBM
key
native
itself,
which
is
not
company,
specific,
obviously,
oracle,
open,
faz,
part
of
vmware,
a
VMware,
proper
Microsoft,
huawei,
SCP
and
PayPal
okay.
So
each
one
of
those
is
going
to
receive
the
events
pick
a
random
word
of
that
particular
category
type
and
then
it's
going
to
produce
another
event
on
the
outbound
side.
Event
type
word
picked
noun.
A
Each
of
those
are
going
to
send
it
back
to
the
controller,
and
then
the
controller
is
going
to
pick
one
of
those
words
from
all
the
people
that
responded
for
each
word
category
and
then
displayed
on
the
screen
kind
of
hokey.
But
still
fun
again,
it's
to
prove
out
the
point
here
of
in
or
out
building
all
right.
So
let's
go
ahead
and
show
it
did
you
that's
very
pretty.
It
also
is
very
pretty
yes
all
right.
So
here
you
see
the
cloud
controller
in
the
middle.
A
We
have
all
the
functions
are
there
and
hopefully-
and
this
is
ice-
a
little
scary,
the
actually,
the
events,
the
whole
system
here
is
actually
driven
by
the
browser.
So
if
the
network
here
fails
me
we're
dead
yeah,
don't
laugh
it!
Yes,
okay!
Here
we
go
well
the
entire
presentation,
so
you
saw
them,
go
out
everybody's
respond
back
each
one
got.
What
is
it
three
four
words
and
there
you
go
so
for
dessert.
Joseph
is
bringing
a
love
pie
with
apartment,
I'm
feeling
safe
already.
A
Okay
did
goofy
fun,
but
the
point
here
is:
you
saw
the
events
go
out,
everybody
responded,
the
events
come
back
and
you
guys
you
see
there
will
be
actually
can
actually
read
that
Michael.
You
guys
can't
snot
that
bad
yeah,
so
the
words
in
red
are
the
words
that
the
controller
actually
picked
when
it
was
done.
Okay,
just
so
you
can
see
it
again.
You
can
actually
see
the
events
flowing
back
and
forth
right,
actually
I
kind
of
goofed
up
a
little
here.
A
I'm
sorry
I'd
actually
read
it
as
far
as
you
know,
the
Easter
Bunny
loves
to
oh,
never,
mind
it.
Moving
on
okay,
so
sava
see.
Some
of
these
may
not
be
safe
for
work.
I
knew
it.
Yeah
I
actually
was
a
little
afraid
of
that,
but
you
know
live
on
the
edge
I,
actually
I
messed
up
a
little.
What
I
should
have
done
is
shown
you
the
words
before
you
could
actually
see
here's
the
sentence
with
the
at
with
the
down
went
over
the
word
types
in
there
before
it
actually
does
it.
A
A
A
Okay,
so
you
can
actually
see
in
this
particular
case,
the
event
that
was
sent
across
binary
mode
is
being
used
here.
So
you
can
see
the
cloud
event:
headers
the
C
Eid
source,
spec
version
time
and
type
sent
the
cross
received
by
the
K
native
infrastructure
and
when
it
responded,
you
could
see
this
one
at
time
it
picked
up
in
as
its
word,
because
it
was
looking
for
a
noun
and
you
can
see
the
cloud
event,
properties
or
HP
headers
on
the
way
back.
Okay,
I
guess,
I
kind
of
a
goofy,
the
sample
and
stuff.
A
A
B
B
The
goal
is
to
provide
access
to
cloud
events
in
a
very
easy
way
and
for
most
languages
in
a
way
that
is
allowing
you
to
use
your
favorites
current
toolset,
with
which
you
do
use
HTTP
or
AMQP
or
MQTT
we're
not
none
of
the
SDKs
are
aspiring
to
create
yet
another
HTTP
client,
but
rather
help
that
HTTP
client
do
inter
inter
operate
effectively
with
called
events
and
also
do
the
same
thing
on
the
server
side.
So
for
this
I
have
now
been
taught
that
I
need
to
do
this.
B
Yes,
so
here
I
thought
slides
would
be
interesting,
but
showing
you
the
github
repo,
would
be
more
interesting.
So
when
you
go
to
github
cloud
events,
what
you'll
find
is
a
bunch
of
repos
and
we
filtered
here
on
sdk
you'll
find
the
sdk
for
go
and
for
jobs
for
JavaScript
or
Python
or
Ruby
c-sharp,
the
the
layer,
the
the
level
of
that
code
is
alpha.
It's
we're
confident
enough.
B
In
that
code,
that
is
worth
your
time
looking
at
it,
you
should
not
bet
the
farm
on
it
and
it's
an
open
source
effort,
which
means,
if
you
find
a
bug,
then
you
have
the
choice
between
reporting
it
or
giving
us
a
PR,
and
the
latter
is
probably
preferred
and
for
all
those
so
I'll
give
you
a
flavor
of
that
code
using
one
that
I'm
familiar
with
and
that's
c-sharp,
because
I'm,
a
Microsoft
dude.
So
here's
how
all
of
the
SDKs
give
you
an
om
when
object
model
for
what
a
cloud
event
is.
B
So
we
make
that
an
extension
you
can
go
and
at
that,
in
terms
of
how
you
send
and
receive
here
for
sending
that's
the
example
for
the
HTTP
client,
you
create
a
cloud
event
as
as
previously,
and
then
you
create
in
in
with
the
system
net
HTTP
clients
you
create
these
content
objects.
The
content
objects
is
effectively
the
the
data
you
send
with
an
HTTP
request.
So
we
have
here
a
cloud
event:
content
which
is
a
specialization
of
the
binary
content,
and
then
you
sniff
this
stuff.
B
The
cloud
invent
their
event
in
there
you'd
select
what
content
mode
you
want.
Is
that
projected
on
th
to
be
free
it
down
to
the
HTTP
frame
or
is
it
contained
in
the
HTTP
frame?
And
then
you
choose
the
formatter,
and
then
you
use
the
completely
normal,
regular
HTTP
client,
as
it
comes
out
of
the
box
in
the
dotnet
framework
and
go
and
sent
on
the
server-side.
B
This
is
the
code
that
actually
runs
in
the
demo
for
the
azure
function.
I'll
show
you
that
so
here's
the
function
and
that
function
implements
a
function,
matte
lips
and
it's
effectively
constructed
the
UI
that
I
give
to
Doug,
and
it
will
first
check
whether
that
incoming
request
is
a
webworker
evaluation
request
here,
in
this
case,
we're
using
extensions
to
c-sharp
classes
to
do
this.
So
this
is
there's
in
the
web
hook
spec.
B
We
have
a
validation
request
that
allows
a
server
to
opt
into
whether
it
gets
pushed
to
and
also
allows
the
the
pushing
agent
to
kind
of
have
a
handshake.
So
that
it
doesn't
get
abused
as
a
distributed
denial-of-service
machine,
and
so
that's
the
implementation
of
that
two
lines
and
then
effectively
you
get.
You
take
the
request.
B
You
turn
that
into
a
cloud
event,
and
then
we
go
and
handle
that
cloud
event
in
the
end,
at
the
bottom
of
this,
once
we
constructed
one-
and
these
are
the
various
categories
and
I
made
them
explicit,
I
could
have
made
them,
but
I
want
to
make
them
explicit,
and
then
you
basically
post
back
using
the
regular
HTTP
API,
encapsulating
the
event
content.
Now
that
was
the
c-sharp,
the
c-sharp
version.
Now
the
go
SDK
has
a
very
similar
model.
B
They
have
here
a
notion
of
a
marshal
or
so
what
I
do
in
the
c-sharp
SDK,
with
extension
methods
to
the
base
classes,
request
classes
is
done
here
with
an
explicit
class
called
the
marshal
ER,
and
so
you
create
you,
use
this
marshal
or
and
then
the
martial
art
can
go
and
extract
from
an
incoming
request,
a
cloud
event,
and
then
you
can
go
and
print
that
out
and
here's
the
go
version
of
how
to
create
one
of
those
cloud
events.
That's
the
OM.
So
again
you
see
that
echo.
B
You
see
the
principles
echo
here,
it's
the
existing
HTTP
stack,
you
have
an
om
and
then
here
when
you
create
an
HTP
request
again
you
create
one
of
those
requests.
Then
you
turn
effectively
that
marshal
with
the
marshal.
You
turn
it
into
a
request.
You
can
then
send
with
a
normal,
regular
HP
stack.
The
JavaScript
SDK
again
brings
you
an
om
for
the
cloud
event,
and
then
it
allows
you
to
go
and
format
the
payload
here.
B
So
you
can
actually
go
and
get
the
payload
in
a
string
format,
and
if
you
want
to
emit
an
event
which
means
you
want
to
send
it
over
HTTP
here,
the
JavaScript
API
is
API
is
a
little
different.
It
has
a
binding
to
a
particular
format,
and
then
you
call
that
and
then
you
basically
with
that
binding
you
emit
and
that's
how
you
send
that
with
HTTP
again
there's
a
few,
you
know
differences,
flavor
differences,
I
would
say
between
the
different
kinds
of
SDKs,
and
none
of
this
stuff
is
final.
B
If
you
find
that
you
need
to
have
more
coverage
for
more
AP
is
please
do
so.
One
thing
I'd
like
to
point
out
is
that
scoring
a
little
bit
further
down
what
the
c-sharp
SDK
does
it
already
supports
nqp,
so
you
can
go
and
make
this
work
with
mqp
compliant
brokers,
and
it
also
supports
empty
TT
so
that
you
can
go
and
use
the
same
event,
but
you
can
send
this
to
different
systems
and
you
can
build,
and
that's
also
one
key
goal
that
we
have.
You
can
build
intermediaries.
B
You
can
receive
an
event
from
via
HTTP.
You
can
extract
that
turn
that
into
this
abstract,
om
and
then
map
it
out
into
HTTP
it
to
AMQP,
so
you
can
make
an
HTTP
gateway
that
then
routes
those
events
further
over
a
name
QP
broker
and
as
we
get
you
know,
final
with
specs
for
Kafka,
etc
and
that
implementations
for
them.
You
can
see
that
we
you
can
draw
you
can
create
these
multi-layer
event,
flows,
which
then
traverse
protocols
as
needed.
For
you
know
routing
in
the
infrastructure,
which
is
not
all
HTTP
so
now
do
I.
A
Okay,
yeah
say
something:
I
was
gonna,
say:
okay,
anyways
so
set
us
a
cloud
events,
so
last
Thursday
December
6.
We
actually
voted
and
approved
version
0.2
of
the
specification,
while
the
number
is
actually
really
really
low.
This
is
just
me
speaking.
I
actually
think
we're
probably
closer
to
a
point
nine
to
be
probing
honest
because
the
road
map
actually
says
four
point:
two:
we
need
to
try
to
finalize
the
set
of
core
properties
or
required
properties
of
the
specification,
and
we
haven't
had
a
new
one,
really
pop
up
in
quite
some
time.
A
So,
in
my
opinion,
I
think
we're
actually
really
really
close
to
the
point
where,
once
we
finalize
a
couple
of
optional
properties,
that's
being
that
are
being
discussed
right
now,
I
think
we're
going
to
start
entering
the
stage
of
testing
and
verifying
the
specification
itself,
which
is
what
we
expected
to
do
between
0.9
and
1o.
So
don't
let
the
0.2
number
scare
you
a
little
yeah
now
we're
0.2
of
the
specification
and
all
transport
bindings
that
we
actually
agreed
to
one
other
thing
that
we
just
produced
recently,
which
goes
along
with
the
SDK
stuff.
A
Clemens
was
talking
about,
is
we
actually
produced
a
sort
of
overriding
specification?
Maybe
a
little
bit
stronger
word
more
like
a
design
document,
it's
sort
of
a
guiding
principles
for
all
the
SDKs,
because
we
wanted
to
try
to
make
sure
that
there's
a
similar
and
consistent
look
and
feel
across
all
the
SDK.
So
as
people
go
from
language
to
language,
they
don't
feel
like
they're
doing
cloud
events
in
a
completely
different
way.
A
Obviously
there
will
be
some
differences
because
languages
are
different,
but
we
try
our
best
to
try
to
get
some
level
of
consistency
across
them
again,
just
make
it
easier
for
the
user.
So
as
I
sort
of
talked
a
little
bit
about
already,
what's
left,
reverse
or
1.0,
you
know
agree
that
we
actually
did
finalize
the
list
of
core
properties.
I
think
we're
pretty
much
there
right
now,
but
we
need
to
get
a
formal
vote
that,
yes,
this
is
it.
You
know
finalize
the
set
of
protocols,
there's
one
or
two
that
are
sort
of
lingering
this.
A
We
need
to
sort
of
decide
on
that.
People
are
proposed
finish
up
documentation
right,
maybe
a
developer
guide,
user
guide
type
stuff.
As
I
said,
we
have
a
primer,
but
that
was
more
of
a
philosophy,
design
type
document,
maybe
something
a
little
bit
more
technical
in
nature.
And
then
we
new
start
testing.
A
This
thing
out
right,
more
Interop,
demos,
verification
get
people
that
to
start
influencing
that's
in
their
products
to
actually
make
sure
this
thing
works
beyond
cool
demos
like
mad
libs
right
now,
obviously
complete
the
SDKs
and
any
additional
tooling
that
we
may
think
may
be
necessary
for
the
community
to
really
jump
on
board.
Here
we
have
toyed
with
the
idea
of
some
sort
of
conformance,
checker,
I,
think
in
the
repo
itself,
under
one
of
the
webpages,
we
have
a
list
of
open-source
projects
that
use
cloud.
A
Events
to
some
extent
in
there
is
actually
some
sort
of
cloud
events,
sort
of
verification
tool
where
you
can
send
it
a
cloud
event,
and
it
tells
you
whether,
yes
or
no,
it
complies
to
the
spec.
Something
like
that
is
a
good
starting
point
for
maybe
a
more
formal
compliance,
checker
tool
that
we
can
look
at
going
and
in
the
future.
So
after
1.0
I
already
touched
on
this
a
little
what's
probably
gonna
happen
is
we'll
kick
everything.
A
I
mean
the
the
though
the
the
group
of
people
probably
kick
everything
back
up
to
the
service
working
group,
to
figure
out
what
we're
gonna
do.
Next,
we've
already
started
looking
at
workflow
itself
and
I'll
go
about
that
in
a
second,
but
we
need
to
figure
out.
Okay,
he's
workflow
the
next
thing
we're
only
going
to
do
or
there's
something
else
want
to
do
it
in
addition
to
it,
we're
still
trying
to
figure
that
out.
That's
what
the
group
needs
to
decide
now.
A
Workflow
itself,
Kathy
who's
sitting
over
there
from
Huawei
will
actually
go
into
this
more
detail
on
Thursday,
or
maybe
it's
tomorrow
or
wherever
they
tomorrow.
Whenever
the
deep
dive
is,
but
basically
you
think
you
can
think
of
workflow
as
defining
the
the
the
amazingly
the
flow
of
what
happens
to
the
various
functions
as
events
come
in.
So,
for
example,
you
have
event
one
coming
in
it's
one
function.
A
Do
it
justice
at
all,
I,
probably
butchered
it
so
Kathy
would
have
completely
explained
it
for
real
tomorrow
during
the
deep
dive,
but
with
that
we're
basically
at
the
end,
have
some
interesting
links
here
for
the
service
working
group,
the
workflow
document,
which
is
technically
part
of
the
service
working
group,
not
cloud
events.
It's
just.
We
talked
about
in
the
same
group
because
it's
all
the
same
people
links
for
the
cloud
event
specifications
themselves,
and
then
tomorrow
we
have
the
deep
dive
session
again
at
4:30
and
thank
God
I
put
stickers
on
there.
A
B
Services
editors,
lamda,
Amazon,
I'm
bored
with
this
Amazon
has
been
participating
in
the
calls
yes
in
in
in
how
far
you
know.
Anybody
implements
that
in
their
services
we'll
see
but
I
said,
WS
has
been
participating
in
the
calls
they
don't
participated.
A
lot
of
standards
calls
so
I'm
optimistic
yeah.
A
A
B
That
is
suggested,
it's
not
required
because
you
might
be
building
something
that
is
literally
just
for
your
own
system,
so,
for
instance,
in
in
Azure,
all
of
our
events
are
qualified
with
Microsoft,
so
there
are
Microsoft
that
assured
that
blog
whatever
we
happen
to
to
own
the
TLD
Microsoft,
so
they're
compliant.
So
that's
kind
of
you
know
it's
it's.
B
D
You
know
say
at
Microsoft:
you
have
the
dynamics,
group
and
the
dynamics.
Group
creates
a
whole
set
of
events,
it
has
to
be
to
enable
Interop
and
then
the
customer
goes
and
they
implement
that,
and
they
take
one
of
those
events,
and
there
are
custom
attributes
that
they
want
to
put
in
the
payload.
Do
they
still
use
the
Microsoft
name
or
do
they
extend
the
event
or
they
create
essentially
an
event?
B
My
personal
stance
on
this
and
we've
had
a
long
discussion.
Long
discussions
about
this
in
the
working
group
is
that
it
is
always
in
the
interests
of
the
event
producer
to
produce
an
events
in
a
way
that
they
don't
clash
with
the
rest
of
the
world.
So
there's,
if
you
I,
think
you
can
trust
in
a
lot
of
implementation,
discipline
and
and
design
discipline,
rather
than
creating
some
really
onerous
requirements
in
the
standard
itself
on
developers
who
might
build
a
smaller
scope
solution
and
then
you're
forcing
them
into
something.
That's
enormously
complicated.
So.
A
So
my
take
on
that
is
it's
up
to
the
producer
to
decide
right
because
they
could
obviously
roll
their
own
new
event
type
with
their
own
URL
or
whatever
you
want
to
call
it,
and
but
then
it's
basically
incompatible
with
what
they
were
sub
classing
basic.
Very
we
do
allow
for
extensions.
You
can't
extend
things
and
I
would
recommend.
A
You
actually
do
do
that,
because
if
you
want
your
event
to
be
picked
up
by
somebody
who
doesn't
know
about
the
extensions
you
know
you
want
the
old
event
type
to
be
passed
around
okay,
but
it
is
up
to
the
producer
decide
where
they
create
a
new
event
type
or
use
the
existing
one
plus
Accenture
right.
Any
other
questions.
Yes,.
E
B
So
how's,
your
event
grid
is,
is
already
it's
compliant
with
version
10.1
and
we
have
not
so,
as
we
announced
0.1,
we
did
made
an
extra
effort
to
have
something
that
allowed
us
to
do
this.
We're
gonna
we're
gonna,
do
the
work
of
implementing
0.2
in
the
near
future
as
it
fits
with
the
with
the
schedule,
but
we'll
pick
this
up
and
as
soon
as
the
final
version
comes
out,
we're
also
going
to
support
this.
So
that
means
effectively.
You
can
get
all
events
across
the
entire
Azure
platform
that
supports
event
grid.