►
From YouTube: CNCF Serverless WG SDK Meeting - 2018-07-18
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A
All
right,
let's
see
what
time
is
it
1:00
o'clock?
Hopefully
we'll
have
a
few
more
people
looks
like
Doug
just
joined
marks
here,
Carol's
here,
so
we
got
Carol
and
Mark
from
VMware
The
Dispatch
project
Doug,
the
infamous
Doug
from
IBM
and
our
leader
of
the
circles,
working
group
and
Simon
I'm,
not
sure,
hey
Simon.
You
want
to
do
a
brief,
intro.
B
On
the
last
call,
when
I
was
with
a
face-to-face
with
Mateus,
Matisse
is
on
vacation
today
and
the
next
two
weeks,
so
so
I
want
to
sit
in
and
contribute
where
I
can
do.
Although
a
largely
been
talk
about
the
work
that
he's
been
doing,
putting
a
Java
API
and
a
couple
of
different
implementations
of
the
cloud
events
back
together,
cool.
A
Fantastic
great
to
have
you
and
Matias
everyone
over
at
Red
Hat.
Let's
just
go
ahead
and
get
started
with
the
people
who
are
in
the
call
now
I'm
going
to
do
a
quick
recap,
since
it
was
almost
a
month
ago
that
we
did
it
that
we
had
our
last
meeting
in
our
last
meeting.
That
was
our
first
conversation
around
designing
SDKs
for
cloud
events.
What
prompted
that
specific
conversation
was
the
fact
that
a
we
came
out
with
this
great
specification
for
a
common
envelope
for
event
data.
A
The
next
step,
however,
is
to
actually
make
it
easy
to
put
in
the
hands
of
developers
by
building
some
SDKs.
It
was
we
realized,
after
some
conversations
on
the
working
group,
call
that
a
lot
of
people
were
already
making
SDKs
and
we
were
kind
of
doing
it
in
an
informal
siloed
way,
and
we
said
okay,
it's
clear.
We
should
have
a
conversation
about
this
to
see
if
we
could
kind
of
align
all
of
our
implementations
on
some
common
goals,
hence
that
that
inspired
the
first
call
in
that
first
call,
which
was
on
June
25th.
A
We
drafted,
use
cases,
features
goals
for
the
cloud
events
SDK,
and
then
we
I'm
all
by
priority,
and
then
we
organized
all
those
priorities
into
SDK
versions
and
created
a
bit
of
an
informal
roadmap,
and
then
we
found
some
volunteers
for
implementations
across
a
few
languages
that
we'd
like
to
target.
We
took
that
progress
reported
it
to
the
CN
CF
service
working
group.
They
said
great,
it
looks
great
and
but
it's
up
to
us
actually
like
deliver
something
and
I
think
we're
getting
pretty
close
right
now,
so
so,
hopefully,
on
this
call,
I
was
thinking.
A
A
Well,
yeah,
we
have
been
working
off
this
cloud
events,
SDK
design
proposal,
Google
document
at
the
very
top
five
drafted,
pretty
lean
loose
agenda.
For
this
conversation,
we
should
chat
about
it,
real
quick
in
case
anyone
has
any
other
ideas,
but
I'll
read
it
as
is
I
figured.
Let's,
let's
go
ahead
and
check
in
let's
see
if
people
you
know,
we
drafted
out
some
priorities
and
targeted
a
scope
of
work
for
versions.
A
After
we
hear
what
you
know
what
people
have
done
and
where
some
problem
areas
are
where
some
ambiguity
is,
let's
identify
areas
that
we
need
to
clarify
to
clarify
further
together
and
hopefully
achieve
greater
alignment
as
a
result,
and
then,
after
that,
it
seems
like
if
it
seems
like
we
have
some
cloud
event,
SDK
implementations
that
are
almost
ready
to
go
as
is,
or
they
might
just
be,
very,
very
close
to
being
ready
to
go.
I
think
it's
time
to
discuss.
A
Publishing
these
to
the
cloud
events
github,
org
and
Doug
is
on
the
line
ready
to
handle
all
of
all
of
our
questions
about
how
we're
going
to
go.
Go
about
doing
that.
So
that's
the
agenda
written
as
is:
does
anyone
have
any
suggestions
or
ideas
for
other
agenda
topics
that
we
should
discuss
on?
This
call.
A
Good,
what's
going
twice?
Alright,
let's
do
this,
let's
go
ahead
and
check
in
with
each
other
and
review
progress.
I
was
just
chatting
with
that
Carroll
about
the
VMware
Dispatch
crews,
progress
on
doing
a
cloud
event,
SDK
implementation
is
go
and
go,
and
maybe
we'll
start
with
you
Carol,
since
you're,
already
all
warmed
up
sure
I
know
how
it's
going
I
share
problems.
D
Course,
of
course,
so
I've
been
I've
been
looking
at.
You
know,
there's
a
lot
of
existing
go
code
for
cloud
events
for
version
zero,
one
that
was,
for
example,
people
worked
on
for
the
demo
that
was
at
the
cube
con,
so
I've
been
looking
how?
How
is
this
being
used
in
different
projects,
I'm
trying
to
extract
the
common
layer,
because,
of
course
we
we
also
use
cloud
events
in
this
patch,
so
the
the
the
repo
data
that
we
created
and
that
I
posted
to
the
SDK
ticket
will
include
this
work.
D
I've
pushed
some
code,
I
would
say
the
minimum
version
of
the
even
that
is
currently
supported.
It
implements
the
basic
spec,
the
basic
structure
of
the
event
and
I
am
HTTP
bindings.
I
think
this
is
the
bed
like
the
minimum
that
I
could
do
now.
I
think
that
there
will
be
a
lot
of
work
to
support,
arm,
custom
content,
encoding
and
decoding
I.
Imagine
that
we
would
like
to
support
some
some
sort
of
encoders
registry,
but
I'm
curious.
What
what's
the
approach
for
other
languages
right
now?
D
D
With
regards
to
things
that
I've
learned,
while
working
on
that
my
initial
goal
was
to
create
a
some
sort
of
an
interface
that
would
be,
it
will
help
that
I
thought
would
be
good
to
to.
You
know,
survive
different
versions
of
this
pack
right.
So,
there's
a
there's,
a
discussion
about
removing
the
extensions
back
from
the
from
the
spec
and
have
the
extensions
to
be
a
top-level
attributes
of
the
of
the
event
of
the
even
context
and
I
was
trying
to
think
what
would
be
the
then
interface
that
could
handle
that
right.
D
So
this
this
this
is
a
I,
see
this
as
one
of
the
pain
points
in
the
future.
So
right
now
my
work
is
to
just
address
the
version
0
1
prepare.
My
goal
is
to
have
you
know
that
the
interface
or
the
API
that
works
with
version
0
1-
and
you
have
this-
you
know-
address-
have
this
being
tested
in
different
use
cases
so
have
this
work
with
dispatch,
hopefully
work
the
same
way.
No,
the
use
cases
that
I
see
already
have
tests
for
that
and
then
see.
D
If
we
can,
you
know,
create
a
bulletproof
interface
for
future
I.
Don't
think
we
can
avoid
breaking
changes
forever,
because
this
is
never
a
case,
but
hopefully
the
interface
would
be
good
enough
to
at
least
survive.
This
change
for
where
the
extension
back
is
removed
and
and
have
some
some
interface
that
that
supports
both
both
cases
where
the
extension
back
is
there
and
it's
not
there
and
yeah.
So
take
a
look
of.
What's
there
right
now,
if
you're
in
to
go
and
yeah,
that's
it.
D
Why
mark
is
looking
for
for
it?
One
thing
that
I
would
like
to
talk
to
you
guys
is:
what's
the
approach
for
different
languages
in
terms
of
extensions
or
well
and
I,
don't
mean
the
spec
extensions
but
extensions
to
to
the
SDK,
for
example,
things
like
validation,
like
extra
validation
or
things
like
I,
don't
know
all
tent
occation
for
different
protocols.
Should
this
be
in
scope
of
the
SDK?
Should
not
what
should
be
dead
like
extend?
What
about,
like
you
know,
project
specific
extensions
or
like
vendor
specific
extensions?
D
A
E
Far
like
implemented,
here's
how
you
could
define
a
visa
or
one
event,
and
obviously,
as
we
version
the
plot
events,
that
we
would
have
to
continually
modify
that
so
the
the
question
there
is
you
know
is
this:
for
the
in
the
previous
call,
we've
talked
about
meeting
to
support
version
interfaces
or
different
versions
at
the
bottom
and
spent.
Is
this
the
what
everyone
was
an
attending
for
to
look
like
as
we
go
to
implement
this
on
both
go
and
other
languages.
D
So
I
have
a
father
on
that.
So,
given
that
you
know
you
some
somewhere
when
you
produce
the
even
first
time,
you'll
have
to
pick
a
version
of
the
event
if
you
want
to
produce
so
so,
the
even
producer
will
have
to
decide
which
version
of
the
event
the
producer
wants
to
use.
But
then
the
consumer
could
do
a
lot
of
things
without
knowing
the
actual
version,
given
that
a
lot
of
handlers
will
be
there
for
him
to
do
like
a
lot
of
functions
that
can
operate
on.
D
Different
versions
of
events
are
available
for
him
in
DES
DK
itself.
So,
although
I've
created
this
package
for
v01
for
the
version
zero,
one
I
would
rather
have
it
without
versions.
Code
package
and
have
like
you
know,
like
think
I
was
thinking
about
like
how
HDPE
was
into
implemented
and
girl.
Like
you
have
HTTP
package
and
the
HTTP
to
version
support
was
added
to
this
package.
D
Without
changing
the
you
know,
there
was
no
version
package
for
it
and
there
was
the
APA
changes
were
minimal
or
even
no
changes
were
made
to
the
interface,
the
basic
interface.
There
are
some
extra
interfaces
that
you
can
take
advantage
of
if
you
need
to,
but
the
basic
interface
is
the
same
I
hope
to
have
something
in
the
same
direction.
At
the
moment,
it's
not
what
I
did
I
was
more
trying
to
implement
what
people
did.
D
Basically,
you
know
here
is
the
v01
spec
implemented,
as
it
is
exactly
with
all
the
with
all
the
details.
So
I
packages
in
in
a
package
of
v01,
but
maybe
we
can
change
the
direction
and
have
something
that
is
not
package
scoped,
but
still
is
able
to
deal
with
different
versions
under
the
hood.
A
With
a
lot
of
that,
that
sentiment,
I
have
a
few
ideas
on
this,
but
gonna
wait
until
it's
it's
our
turn
to
share
well
Simon.
Let's,
let's
hear
on
RedHat
send
have
you
guys
I
know
you
guys
have
been
working
on
a
job
implementation
how's
that
going
and
you
have
you
learned
anything
and
you
have
any
major
problem
areas
that
you
need
clarity
on.
A
B
B
Basically
one
one
was
backed
by
a
map
of
all
of
the
to
hold
all
the
attributes
within
within
the
events
and
one
that's
backed
with
a
sort
of
fate
one
field
attribute
we
were
playing
around
with
the
map
because
we
thought
it
might
be
more
extensible
and,
and
particularly
around
devotion
in
might
help
for
sort
of
volusion's
past,
be
0
1
2
for
the
for
a
client
library
to
do
something
smart
in
terms
of
generating
write
versions
for
it
for
it
as
a
client
application
to
use
the
I.
Don't
think
so.
B
I
think
that,
probably
internally,
a
map
is
the
right
way
to
go
because
of
that
that
benefit
to
to
extensibility
for
future
versions.
The
other
things
that
we've
been
playing
around
with
is
that
we've
we've
got
sort
of
the
quick
and
dirty
implementation
of
a
kind
of
gateway
that
will
route
events
based
on
the
event
type
two
different
catholic
use
use.
B
B
He
hasn't,
particularly
they
dealt
with
versioning,
apart
from
how
to
how
to
make
it
potentially
extensible
and
to
future
versions
and
I.
Guess
the
the
one
of
the
things
that
the
Carol
sort
of
touched
on
a
little
bit
was
so
that
having
things
in
future
in
future
versions,
I
can
see
how
that
straightforward
to
deal
with,
but
taking
things
away
would
be
more
difficult
to
to
deal
with
sort
of
backwards.
Compatibility
and
I.
Don't
know
that
Mateus
has
thought
about
that.
A
lot.
F
A
B
B
There's
what
the
that's,
what
the
kind
of
the
event
gateways
built.
Then
we
have
an
I/o
cloud
events,
repo
that
is
more
of
a
sort
of
a
sort
of
a
a
generic
API
with
nothing
else.
There,
apart
from
I,
think
there's
a
builder
interface
to
to
build
cloud
vents
from
from
a
java
application.
A
A
Okay,
thanks
for
sharing
I'll
jump
in
and
share
some
of
our
progress
we
haven't
made.
Give
it
me
too
much.
I
have
an
example:
application
in
which
I'm
using
cloud
events,
it's
a
is
a
purely
reactive
event-driven
service
application,
reference
architecture
which
uses
cloud
events
throughout
for
absolutely
everything
and
I
built
a
simple
sdk
just
to
serve
that
applications
needs.
A
Also
on
the
line,
we
have
a
few
ideas
for
this,
and
especially
one
one
big
learning
so
I'm
going
to
share
my
screen
real,
quick
and
just
show
off
what
we're
thinking
currently
on
this
SDK,
and
let
me
know
when
you
could
see
something
yeah,
we
got
it
cool.
This
is
like
a
basic
user
experience
that
we're
targeting
for
the
JavaScript
out
of
it
cloud
events,
SDK
implementation,
it's
something
that
should
be
ideally
as
simple
as
this
you
can
require
in
the
SDK.
You
can
instantiate
an
event
really
easily.
A
They
do
the
same,
have
a
kind
of
a
similar
pattern,
but
for
requested
response
objects.
So
anyway,
this
is
kind
of
the
customer
experience
that
we're
targeting.
This
doesn't
really
solve
that
versioning
issue
like
in
this
example.
This
would
be
I
guess
this
would
be
like
a
separate
type
of
class
with
unique
getters
and
setters.
Based
on
this
version-
and
some
of
these
again
may
not
be
there-
if,
if
that
version,
changes
in
the
specification
changes
in
those
centers
or
getters
aren't
are
no
longer
needed.
Well,.
E
A
Yeah
yeah
that
sort
of
saying
unlikely
in
this
pattern.
That
would
be
the
case.
I.
Don't
think
this
is
an
answer
to
that,
because
you
know
these
things
would
be
would
be
different
and
on
that
note
I
might
actually
Brian
do
you.
Did
you
have
any
thoughts
around
that
versioning
problem,
specifically
yeah.
F
I
mean
at
least
along
the
way
long
lines
of
people
have
approached
it
to
me.
It
seems
that
to
me
at
least
that
version
essentially,
is
that
the
code
level,
in
terms
of
like
where
you're
yeah,
just
the
version
that
you're
of
the
package
that
you
bring
in
to
begin
with
I
mean
at
least
I-
think
it's
the
publisher,
but
I
can't
imagine
that
a
publisher
is
going
to
need
to
publish
different
versions
of
the
event
unless
I'm
missing
something
unless
I.
F
A
Actually,
that's
that's
a
good
point.
I
feel
like
there
would
be
reasons
for
that,
because,
if
you're
a
publisher-
and
you
have
all
these
subscribers,
you
can't
expect
them
all
to
upgrade
their
code.
When
you
upgrade
the
event
right,
you'll
probably
have
to
maintain
just
like
in
an
API
scenario,
you
have
to
maintain
these
legacy
versions.
Fortunately,
this
is
just
at
the
event
level
and
not
at
the
entire
API
level,
but
yeah.
F
E
D
C
But
I
think
this
also
goes
to
the
conversation
that
we
keep
kind
of
dancing
around,
which
is
how
are
we
gonna
handle
either
extensions
or
future
properties
that
we
add
right,
because
if
we
can
do
it
in
such
a
way
that
it's
always
not
just
backwards
compatible
but
forwards,
compatible,
then
really
of
say
a
version
1.0
and
represent
1.1.
Even
though
1.1
may
have
additional
attributes,
they
fall
into
like
the
same
category
as
an
extension,
so
it
still
shows
up
on
a
1.0
implementation
ever
of
a
receiver.
The
only
difference
would
be
the
cloud
event.
C
F
E
F
F
F
It's
up
to
the
underlying
event
to
be
able
to
deliver
you
that
resultant
format
at
the
end,
so
I
wouldn't
want
someone
to
have
to
like
generated
about
one
event
and
then
run
through
a
bunch
of
code
to
specifically
do
things
for
that
one
and
then
do
that
same
thing
again
with
one
doc.
You
know
why
not
own
that
same
thing:
it
came
with
2.0.
Instead,
you
should
be
able
to
generate
your
your
then
apply
the
properties
and
perhaps
get
you
back.
A
Well,
that
would
be
ideal,
absolutely
and
I.
Don't
know
if
this
is
a
solution.
This
is
actually
the
next
thing.
I'm
going
to
show
is
something
that
we
came
up
with
just
because
we
felt
it
could
solve
a
lot
of
problems,
so
I
think
what's
what's
going
to
set
cloud
events
up
for
success
is
how
well
the
community
can
integrate
with
it.
How
well
people
can
build
kind
of
open
source
projects
to
extend
cloud
events?
A
How
well
vendors
can
build
integrations
into
cloud
events
so
that
it
integrates
with
their
their
service,
and
this
goes
back
to
the
extensions
topic
which
we've
discussed
briefly,
and
we
need
some
clarity
there,
but
one
thing
we've
found-
and
this
is
Brian's
idea,
but
we
think
the
extensions
experience.
The
the
big
learning
of
this
is
that
the
extensions
experience
should
be
thought
of
right
in
the
initial
versions
of
these
SDKs.
A
So
if
we
were
going
to
propose
one
change
to
our
roadmap,
it's
that
we
figure
the
extension
story,
because
we
think
extensions
in
addition
to
just
being
custom
properties
within
a
cloud
of
an
envelope
should
actually
be
an
experience.
That
is
also
incorporated
into
the
SDK,
and
an
extension
is
something
that
you
could
bring
into
the
SDK
to
add
like
a
hook
or
a
middleware
into
that
SDK,
so
that
within
that
hook,
you
just
bring
in
that
little
extension
module.
In
that
extension,
module
can
manipulate
the
cloud
event.
A
Data
can
do
all
types
of
stuff
with
it.
So
here's
kind
of
a
a
basic
experience
example
of
this
extension
might
be
something
as
simple
as
this,
where
you
just
have
like
a
function.
There's
an
action
argument.
The
event
object
is
passed
through
and
then
maybe
there's
a
next
function
that
you
call
so
you'd
read
the
action,
and
maybe
this
is
like
what
the
end
user
is
doing
with
the
cloud
event
SDK.
A
Maybe
they
just
set
some
data,
and
this
extension
you
know
you
could
say
if
the
action
is
set
like
that
means
they
just
set
some
data
and
I
want
to
like
look
at
the
events
to
do.
Maybe
one
of
the
following
enforce
an
organizational
policy
set,
a
default
for
an
app
or
a
team,
or
an
organization
maybe
do
handle,
do
some
custom
encoding
for
different
content.
Types
handling
transports
isn't
really
part
of
that
that
achill
island.
A
Light
to
manipulate
the
event,
but
also
adds
support
for
vendors.
So
again
you
read
the
kind
of
the
action
what's
going
on
in
here
and
then
you
can
modify
the
event
or
do
anything
you
want
with
the
event.
As
a
result
of
that-
and
this
is
like
a
pretty
simple
concept
again-
it
goes
back
to
like
Express,
j/s,
middleware
or
like
redux,
if
you're
familiar
in
the
front-end
I'm,
just
giving
people
ways
to
to
modify
the
event,
Douce
extend
the
SDK
and
then
within
those
extensions
in
the
SDK.
A
A
You
know
something
like
an
extend
method
pass
in
the
extension
into
it,
our
event
gateway,
extension
and
automatically
whenever
they
instantiate
a
new
event,
or
something
like
that,
that
extension
would
just
be
baked
in
all
the
extensions
would
be
baked
in,
so
that
the
developers
don't
really
have
to
think
about
a
lot
of
things.
So
the
other
example
for
this
is
in
my
application.
In
my
reference
architecture
that
I'm
making
I'm
starting
to
put
application
specific
information
within
the
envelope
within
the
cloud
events
envelope,
I
want
to
put
like
the
app
title.
A
I
want
to
put
the
stage
of
the
application.
I
want
to
put
maybe
auth
information
for
that
application
and
I'd
love
to
just
make
a
application,
some
type
of
app
extension
where
people
can
just
set
some
custom
properties
here,
like
the
name,
you
know
auth
info
stuff
like
that,
and
that
app
extension
could
always
like
prefix
the
event
type
with
like
the
title
of
the
application.
You
know
no
matter
what
it
could
do,
a
lot
of
stuff
and
add
application,
specific
properties
to
the
cloud
events
envelope,
and
it
would
be
a
very
convenient
experience
again.
A
You
know
this
that
app
extension
could
be
an
open
source
project.
People
just
bring
it
in
and
it
would
really
bring
kind
of
application
features
to
to
cloud
events
again.
They
just
pass
it
in
like
this.
You
just
add
it
in
once
and
then
every
event
you
instantiate
will
have
all
that
stuff
baked
in.
Is
this
a
solution
for
enforcing
organizational
policies?
We
think
so.
Whenever
you
set
data,
you
should
write
an
extension.
A
Your
your
org
can
write
an
extension
to
check
that
data,
make
sure
it's
formatted
correctly
setting
defaults
for
an
african
or
org
absolutely
now,
custom,
encoding
handling
and
coding
issues.
Perhaps
perhaps
extensions
could
do
this
like
on
the
on
the
publish
action,
for
example,
now
handling
kind
of
different
transports?
You
know
yeah
I,
think
on
publishing.
Absolutely,
and
perhaps
this
extension
solution
is
I,
don't
know
if
this
could
be
applied
to
solve
the
versioning
problem
too,
but
yeah,
but
I
thought
about
it,
just
just
thinking
out
loud
there,
but
anyway
I.
A
Our
biggest
learning
is
like
thinking
about
this
experience
should
be
one
of
the
first
things
that
we
consider
when
designing
the
SDK,
because
if
we
could
create
a
great
extension
extensibility
story
for
cloud
events-
and
we
have
that
in
the
specification
we
need
to
carry
that
into
the
SDK
that
is
going
to
be
fuel
for
community
growth,
for
vendor
support
for
an
ecosystem
to
grow
around
this
thing.
So
that's
yeah,
that's
it
on
our
end,
we're
targeting
this
user
experience.
We
learned
that
extensions
are
super
important.
C
Yeah
I,
like
the
idea
in
particular
I
think
it
implies,
then,
that
there's
some
sort
of
agreement
or
set
of
specifications
around
his
extension
so
that
people
who
write
the
extensions
for
each
various
language
can
adhere
that
specification.
That
way
it
work
Carlos
what
language
seems
using
they
can
get
a
similar
experience.
C
F
F
From
the
perspective
of
we
have
a
level
of
familiarity,
but
there's
also
clear
they
just
significant
differences
between
languages
that
can
make
that
relatively
challenging
and
certainly
I
think
the
way
that
a
JavaScript
developer
thinks
about
doing
these
kinds
of
things
versus
the
way
that
a
Java
developer
thinks
about
them
they're
also
in
worlds
apart
to
some
degree
and
be
nice
to
effectively
be
able
to
take
it
Leisha
form
things
in
the
way
that
those
communities
are
familiar
with.
Oh
yeah,.
C
F
D
Just
I
would
just
say
that
this
idea
addresses
a
lot
of
my
concerns
or
questions
that
they
had
at
the
very
beginning.
So
yeah
I
definitely
like
the
idea
of
having
this
into
the
SDK
and
having
this,
and
this
also
aligns
with
what
I
said.
You
know
that
in
it's
not
only
that,
if
an
specification,
it's
more
about
what
you
can
do
with
it
and
like
the
extensions
will
be
the
way
to
do
something
with
it,
so
that
different
versions
of
events
won't
matter
that
much.
A
C
B
The
other
thing
that
we
did
I
I
completely
forgot
about,
was
there's
simplice
and
technological,
the
hep
Co
event
route,
which
is
a
sa
kubernetes
something's
up
kubernetes
and
omits
events
based
on
kind
of
what's
happening.
Inside
kubernetes
we
said
we
deployed
that
an
open
shift
and
the
the
events
that
come
out
of
the
happy
event
route
or
a
little
bit
odd,
to
say
the
least,
but
we
deployed
it
as
a
watcher
for
those
events
and
then
use
the
user
layer.
B
On
the
screen
now,
is
this
an
example
of
how
we
use
these
the
Java
SDK
to
to
turn
this
for
data
event?
So
the
heavy
opens
into
into
cloud
events,
and
then
we
so
that
this
is
a
helper
class,
and
then
we
publish
those
onto
a
cargo
topic,
so
we
had
a
leaf
from
it
as
a
builder
perspective,
not
not
a
dissimilar.
A
Okay
moving
along
here,
our
second
agenda
item
was
to
identify
areas
where
we
need
clarity
and
further
alignment.
It
sounds
like
we
have
two
big
ones
and
let
me
know
if
I'm
missing
any
here,
but
just
extensions
like
trying
to
figure
out
how
the
extensions
story
carries
into
the
SDK
and
also
where
those
extension
properties
are
going
to
end
up
at
the
end
of
the
day
and
then
versioning.
How
do
we
build
this
in
a
way?
That's
future
proof
anything
else
that
we're
clear
problem
areas
that
we
need
to.
D
Have
a
question
with
related
to
the
bindings,
so
I
guess
it's
just
the
nature
of
how
the
the
standard
looks
like
right
now,
but
we
have.
We
have
spec,
which
is
0-1
version
0.1
we
have
HTTP
binding,
which
is
version
0.1.
D
To
dog,
maybe
in
mark
are
day
version
independently,
or
they
will
always
be
a
version
together
or
what's
the
idea
because
I'm
asking
because
you
know
that
the
bindings,
for
example,
HTTP
binding,
specifies
how
the
extensions
are
carried
but
I.
Imagine
that
these
extensions
are
not
in
the
the
bag,
but
our
top
level
that
the
binding
must
change
as
well,
so
they're
kind
of
they
depend
on
each
other.
So
I'm
curious
what
the
story
there
so.
C
F
A
fair
point,
Doug
but
I,
mean
I,
think
the
question
is
kind
of
interesting
because
it
leads
us
down
a
path
of
where
yeah,
the
you
may
have
a
subversion
in
the
event
that
still
adheres
to
you
know
about
one:
oh,
that's,
you
etcetera,
whereas
the
binding
in
terms
of
how
it's
delivered
has
entirely
changed.
How
do
we
reconcile
that
with
kind
of
the
Virgin's
we
meet
SDK?
F
C
This
may
be
I
honestly,
I
think
we
just
need
to
put
more
about
this
because
I
I
mean
if
we
change
the
HTTP
binding
so
radically
like,
for
example,
let's
say
we
get
rid
of
a
at
the
extensions
bag
and
they
all
extensions
now,
with
some
top-level
things
for
the
JSON
coding
or
HCP.
That's
a
radical
change.
Any
of
the
core
spec
didn't
change.
People
are
gonna
think
this
isn't
a
1.0
anymore.
This
is
a
2.0,
and
maybe
we
need
to
think
that
you
know.
C
F
I
mean
it
has
implications
on
on
the
consumer
side
as
well,
because
yeah,
you
tell
me
if
you
were
to
if
you
were,
to
get
100
events
or
less
you're,
striking
that
you
too
dot
events
that
looked
exactly
like
one,
not
events.
So
let's
say
the
binding
change
was
that,
instead
of
using
Cee
as
the
prefix
on
headers,
you
know
we
use.
You
know
the
whole
cloud
events
word
as
so.
F
This
changes
radically
the
way
that
we
think
about
the
binding,
but
the
event
and
the
exact
same
again
today,
yep
in
a
particular
case,
a
version
change
to
the
event
actually
could
be
relatively
annoying
to
the
consumer
side,
whereas
you
know
really.
The
only
thing
that
really
needs
to
know
about
that
change
is
the
SDK.
D
What
happens
if,
like
I
understand
that
expansions
at
the
moment
they
support
values
like
keys,
are
strings,
but
values
can
be
objects
how
those
objects
are
encapsulated
into
into
the
headers.
This
is
another,
it's
another
surface,
where
the
where
the
spec
leaks
for
the
transfer
binding
right.
It
causes
this
leak
that
that
transfer
has
to
handle,
and
because
of
that
it
depends
on
the
spec.
C
F
F
I
guess
the
point
is
this:
if
you're
wanting
to
to
be
agnostic
about
it
right
you're,
you
almost
lose
that
ability
or
you
need
some
method
to
effectively
be
able
to
know.
Okay,
this
endpoint
I'm
trying
to
reach
which
version
of
cloud
events.
Can
you
speak
yeah?
Are
you
speak
out
at
one
or
used
to
be
one
other,
because.
E
F
F
If,
if
I
wanted
to
be
able
to
write
codec
agnostic
Allah
that
worked
with
yeah,
the
event
gave
way
and
works
with
as
your
event
hub,
for
instance,
and
one
of
them
is
still
on
Oh
dot,
one
than
the
other
ones
on
one
dot.
Oh,
do
I
effectively?
You
need
to
wreckage
to
sever
lines
of
code,
then
switch
based
upon
where
I'm
trying
to
send
it
to,
or
is
there
a
method
that
it
can
figure
out?
D
So
I
think
this
is
an
interesting
problem
in
the
sense
that
I
think
it
seems
to
me
that
once
once
we
have
version
I
guess
we
don't
have
new
version,
one
zero.
But
it
seems
to
me
that
once
we
have
a
version
of
one
zero
version
of
of
quality
bans,
then
consumers
who
commit
to
support
those
ones
one
zero.
One,
zero
version
will
have
to
support
it
practically
forever
in
the
sense
that
transport
might
change
and
maybe
that
it
might
be
a
negotiation
and
a
transport
layer
and
probably
there'll,
be
a
transport
negotiation.
D
Because
then
we
are
talking
about
two
entities
that
can
negotiate
or
in
terms
of
HDD
binding.
We
have
this
transport
negotiation
very,
whether
it's
1
0
1,
1
or
2
0,
but
in
the
context
of
even
version
I,
think
it's
just
impossible
to
negotiate
it
because
of
the
Assam
rainiest
nature
of
of
events.
So
it
seems
to
me
that
version
1
0
of
events
like
will
have
to
be
supported
for
I,
don't
see
how
it
would
not
be
like
well.
E
It
could
be
up
to
kind
of
a
middleware,
it's
delivering
it
between
the
consumer
between
producer
and
consumer.
They
will
say:
oh
I
know
that
all
of
my
consumers
are
at
this
fact
I'm
getting
this.
You
know
potentially
a
1.0
event
coming
in,
but
my
consumers
are
0.1.
Maybe
I
need
to
down
wrap
the
event
and
be
able
to
do
translation
of
that
in
middle.
Well,
exactly.
D
So
there
is
a
middleware
right,
so
if
there
is
a
middleware
which
is
affected
by
the
transport
binding,
so
that
middleware
has
to
know
can
negotiate
the
transport
binding
or
whatever
the
transport
version
is
used
right.
It
can
negotiate
with
that
with
the
producer,
where
the
consumer
can
negotiate
that
what
they
cannot
negotiate
is
the
event
version
or
that
what
what
is
being
carried-
and
this
will
like
the
middle,
we
will
be
responsible
of
ensuring
that
whatever
it
delivers
to
will
be
able
to
it
will
be
able
to
deliver
it.
So,
in
certain.
G
D
F
That
may
certainly
make
sense
to
me:
I
mean
I,
think
it's
between
the
SDK
and
the
middle,
where
the
really
only
the
the
only
version
that
they
relieved
to
be
aware
of
there.
It's
just
how
they're
speaking
to
each
other.
So
how
they're
you
know
the
transport
binding
itself,
but
you're
right
yep,
then
the
middleware
needs
to
take
over
from
that
point
and
understanding
consumers.
Another
sandwich
version
that
the
event
they're
expecting
yeah.
D
C
Maybe
I'm
not
following
properly
but
I
would
have
thought
that
sort
of
each
hop
along
the
way
here
is
almost
like
a
completely
independent
transport
of
a
cloud
image
right
so
from
the
event
producer
tool
era,
piece
of
middleware-
that
that
events,
producers,
you
have
to
choose
some
version
of
C
and
then
some
transport
related
to
the
clap
events
and
send
it
across
and
then
that
middleware
is
gonna
have
to
accept
it
in
that
format.
And
then
it
may
do
some
translation,
meaning
that
you
can
say
it's
a
cloud
of
10
version.
C
Oh
you
know,
and
with
with
the
completer
binding,
and
that's
it's
just
Mel
and
it's
just
a
another
hop
along
the
way.
But
each
hop
does
its
own
translation.
It
needs
to
figure
out
how
it's
gonna
send
it
and
I
kind
of
view
how
it
decides,
how
it's
gonna
send.
It
is
almost
out
of
scope
for
us,
even
in
the
SDK
world.
A
To
clarify
that,
on
that
note,
I'm
just
gonna
move
along
here,
because
we're
running
out
of
time
it
seems
like
we've
identified
a
few
areas.
Versioning
is,
is
an
issue.
There's
a
couple
versioning
areas:
we
need
to
figure
out
glad
event,
spec
and
SDK
mismatch
I'm,
not
sure
if
we
found
any
solutions
for
that.
Just
yet,
and
the
spec
kind
of
in
spec
and
a
transport
binding
spec
might
be,
might
be
some
issues
there
as
well,
not
sure,
as
well
as
the
extensions
stuff
so
with
respects
to
extensions
I
just
wanted.
A
D
C
A
Right,
it
sounds
like
we
have
a
bit
of
a
scope
change
there
for
this
0.1
milestone,
so
something
for
everyone,
who's
who's,
implementing
this
to
think
about
how
to
how
to
support
that
extension.
Experience
up
front
so
I'm
going
to
add
that
into
the
cloud
events,
SDK
version
0.1
and,
at
the
same
time,
I
think
we're
at
a
good
point
we're
centralizing
these
efforts
into
cloud
events.
A
Org
would
be
helpful,
so
we
have
like
one
place
to
look
for
all
and
we'll
make
it
very
clear.
These
things
are
not
production-ready.
These
things
are
currently
works
in
progress,
but
I
do
think
having
them
in
one
place
so
that
everyone
could
kind
of
observe
our
progress
and
look
at
the
various
implementations
would
be
helpful.
Doug.
Do
you
have
any
suggestions
as
to
how
we
can
go
about
doing
that?
Yeah.
C
So,
as
you
never
talking
earlier,
I
think
if
we
create
a
single
repo
for
everybody
to
put
their
work
into
I,
think
I
might
be
a
good
starting
place
that
we
people
have
a
single
place
to
go.
Look
for
it
and
that's
irresponsible
anguish.
They're
gonna,
be
imprinting
it
or
using
I
know
that
some
people
may
want
to
have
us
have
a
repo
per
project.
C
C
E
E
F
C
C
Think
that
does
make
it
more
possible
for
us
to
do
that.
Yes,
look
at
how
to
do
some
repose,
because
then
people
are
saying.
Okay.
This
repo
for
here
adheres
to
those
specifications
to
find
in
the
common
repo,
but
since
we
don't
have
that
quite
yet
I'm
not
sure
we
could
do
that.
Quite
at
this
point
of
time,.
A
D
A
It's
up
to
you:
Doug
use
your
use,
your
excellent
judgment,
we're
screwed
right
there,
okay,
all
right
yeah!
So,
let's,
let's
just
present
our
progress,
we'll
give
an
update
tomorrow
during
the
during
the
work
group.
Call-
and
you
know
maybe
Doug
will
have
some-
have
instructions
for
us.
You
could
share
them
on
the
call
and
then
we'll
start
pushing
things
and
everybody
in
the
work
group
could
follow
along
a
bit
more
easily.