►
From YouTube: CNCF Serverless Working Group 2020-4-30
Description
CNCF Serverless Working Group 2020-4-30
A
F
A
D
A
I
A
Ian
I,
don't
know
your
camera,
your
last
name,
even
if
this
is
not
your
first
time,
man
I
apologize,
hey
there
in
you
looks
like
you're
trying
so
hard
to
theory
in
if
you
can
get
to
the
meeting
minutes,
I'll
paste
the
link
into
the
chat,
if
you
can
just
add
your
last
name
and
your
company,
if
you
want
to
be
associated
with
a
company
I
apologize
a
few
minute
before
I.
Just
can't
remember.
A
H
A
Not
hearing
any
but
oh
no,
we
have
no
updates
from
the
cig
discussions.
I'd
really
need
to
go
back
and
poke
Liz
the
chair,
the
TOC,
to
find
out
what
she
wants
to
do
next
in
terms
the
next
step.
So
I'll,
let
you
guys
know
if
anything
changes
we
do
have
a
SDK
call
today
or
right
after
this
one
we
do
I
know
we
have
at
least
one
topic
on
the
agenda.
So
please
join
that
all
right.
J
K
J
J
A
L
I
don't
know
if
any
time
yet
I
was
distracted
for
a
minute
there,
I'm
good
yeah
I
mentioned
it.
I
think.
Lastly,
that
there's
interests,
at
least
within
my
committee,
of
defining
a
binding
for
Amazon
Kinesis
for
quite
events
and
I,
know
you
pinged
him.
Doug
I
haven't
heard
from
him
at
all.
I,
don't
know
if
there's
anybody
from
Amazon
on
the
call,
but
actually
I
took
a
stab
at
it.
L
A
O
O
A
A
M
So
the
idea
is
to
create
a
very
simple
HTTP
base,
or
primarily
HTTP
based
email
registry,
which
is
really
a
repository
for
any
kind
of
serialization
or
validation
scheme
us
of
whether
you
want
to
store
JSON
schema
or
a
VAR
schema
or
XML
schema.
Whatever
you
want,
you
don't
want
to
store
with
a
very
simple
mechanism.
The
there
is
a
notion
of
affecting
three
levels:
there's
a
notion
of
schema
groups,
schema
groups.
M
That
is,
that
is
not
backwards,
compatible
that
that
gets
rejected.
So
that's
a
mechanism,
that's
that
I've
also
affected
described
here
as
the
foreign
I
and
conflict.
So
that's
a
super
super
super
simple
mechanism.
I
think
that
is
a
starting
point
for
a
discussion.
We
don't
we're
not
we're
not
wedded
to
this
particular
proposal,
but
we
believe
that
a
schema
registry
that
works
cloud
events
overall
is
useful
and
necessary
because
we
have
a
data
schema
field
and
we
are
now
we're
talking
about.
No
schema
ties.
M
All
kinds
of
schema
tiles,
serialization
formats
and
having
something
that
is
supported
in
the
community
broadly,
is
I.
Think
generally
useful,
not
only
for
us
for
the
cloud
events
case,
but
also
more
broadly,
for
the
messaging
community
and
for
the
eventing
community,
and
that's
something
where
we
can
ask
the
cloud
events,
projects
or,
as
several
is
working
good
work.
So
I
think
this
is
so.
M
A
Since
this
was
just
open
yesterday,
I
think
it
makes
sense
to
at
least
let
it
sit
there
out
there
until
next
week's
call
and
I
think
the
next
step
in
the
process
might
be
just
to
take
it
over
tour,
unanimous
consent.
If
no
one
objects
to
saying
yes
or
no
to
having
this
before
my
work
stream
under
I
assume,
you
got
those
under
cloud
events,
not
service
right,
Clemens,
I,.
M
Don't
I
haven't
the
right
places,
so
we
have.
We
certainly
are
interested
in
making
that
making
that
happen
and
with
you
know,
seeking
seeking
for
a
venue
here
and
we're
coming
here
as
the
first
time
in
at
venue
believe,
because
we
believe
that
that's
the
right
place
for
to
do
this.
Whether
we
do
this
under
cloud
events
or
whether
we
do
this
in
the
circle
is
working
or
something
I'm,
not
particular
about
okay.
M
But
so
we
believe
that
this
is
urgently
needed
as
a
convention,
because
there
are
now
several
vendors,
specific
and
interfaces,
and
there
are
none
free
implementations
that
people
are
using
that
seem
to
be
very
popular
and
I
would
like
to
get
us
to
a
point
where
we
can
have
a
free
implementation,
that
everybody
can
go
and
use,
and
for
that
we
need
to
have
interfaces.
Everybody
people
support,
and
since
there
is
none
of
that
of
that
simplicity
of
the
required
simplicity,
did
everybody
can
go
and
agree
on.
I
mean
we're
just
proposing
one
here.
M
A
Okay,
okay,
because
I
do
feel
like
there
are
a
couple
of
other
process
questions
that
we
need
to
resolve,
for
example,
which
get
robbed
repo.
Would
the
proposed
spec
go
into
but
I
guess
we
could
we
could
we
can
answer
that
question
when
we
get
past
the
high
order
question
which
is,
should
this
broader
group
work
on
it
at
all
period?
Yes,.
C
A
I
think
we
should
probably
look
to
maybe
have
a
vote
next
week
unless
a
whole
bunch
of
flurry
of
activity
comes
up
and
it
get
into
a
big
discussion.
But
if
there
is
no
major
discussion,
then
we
should
push
for
some
sort
of
resolution
next
week
and
I
will
send
out
a
note
drawing
this
John
people's
attention
to
this
yeah.
M
A
A
Okay,
cool
so
I'd
mentioned
this
last
week,
but
it
was
too
soon
to
to
approve
it.
Basically,
this
is
just
adding
the
new
specs
to
the
checkers
that
we
have
and
I
fixed
a
couple,
bad
ace
refs
and
tried
to
modify
the
RC
219
wording
to
make
sure
all
the
uses
are
actually
aligned
with
that
I
believe
Mike
found
one
case
where
I
think
the
HOF
was
maybe
been
wrong.
I
fixed
that
for
him,
anybody
have
any
questions
about
this
need
more
time
to
review.
B
B
P
At
least
the
way
I
read
the
change
it
it
kind
of
it,
it's
not
the
rewording,
but
it
kind
of
smacked
the
changes,
the
meaning
of
the
extension
and
makes
it
less
useful
as
a
mechanism
for
its
propagation.
So
that's
the
reason
for
my
comment
and
I'm
also
not
quite
sure
what
the
the
motivation
behind
the
changes,
but
maybe
I'm,
not
understanding
the
change.
I,
don't
know
if
you
could
clarify
a
little
bit
kind
of
the
difference
and
the
use
case
for
this
change
extension.
P
B
B
Because,
personally,
I
didn't
I
didn't
felt.
It
was
clear
to
me
what
this
disabilities,
in
extension,
is
about
really
I,
I
yeah,
he's
working
with
me
on
implementing
this
disorders,
there's
an
extension
for
a
specific
use
case.
You
know
in
another
community
project
and
I
found
like
it
was
not
really
clear.
If
what
the
way
we
were
using,
this
extension
was
intended
to
use
that
way
like,
for
example,
middle
worship
at
the
middle.
She
chair
should
modify
the
twist
context
at
the
middle
should
modify
or
the
mid.
A
So
II
and
your
your
question
here,
especially
talking
about
using
it
for
non
HTTP
protocols,
I
think
is,
is
a
good
one,
because
I
think
implicit
in
your
question
is
that
the
tracing
value
may
change
from
hop
two
hop.
What
I'm?
Sorry,
the
C
e
value
will
change
or
might
change
as
it
goes
from
hop
two
hop
the
same
way.
They
should
be
header,
wood,
right
and
I.
Don't
think!
That's
the
intent.
P
P
A
So
Jim,
oh
I'll,
get
to
you
in
a
second.
Let
me
try
to
answer.
My
understanding
was
that
this
value
is
meant
to
represent
the
original
value
from
the
original
sender
and
that
the
real
trace
header
actually
may
change,
as
it
goes
through
all
the
various
hops,
the
c
eval.
You
is
not
necessarily
going
to
stay
in
sync
with
the
real
header
value,
which
is
why
I
can't
rephrase
it
as
the
original
header,
the
original
value,
not
necessarily
the
true
complete
value.
What
about
the
destination?
A
So
that's
why,
when
you
start
talking
about
oh
it's
supposed
to
be
used
for
non
ESP
protocols.
Well,
I!
Don't
think
it
is
because
that
implies
that
when
you
are
an
HTP
that
they're
always
in
sync
as
they
go
from
hop,
two
hop
and
I,
don't
think
that's
true
at
least
that's
my
understanding
of
it,
but
getting
honest
this
one's
always
confuse
me
so
Jim
you
want
to
jump
in
who's.
Gonna
say
this.
I
The
same
thing,
actually,
the
my
understanding
is
exactly
lines
up
with
Doug's,
in
that
this
is
meant
to
be
the
trace
from
the
sender
to
the
receiver.
In
their
context,
it's
not
meant
to
mutate,
as
it
travels
through
intermediaries,
because
you
know
it's
not
there
to
do
the
distributed
tracing
of
all
of
the
processes
that
the
intermediaries
use
yeah,
so
it,
for
instance,
if
I
have
a
sensor
that
emits
an
event
and
maybe
I
pass
it
through.
J
P
I
Think
the
only
come,
maybe
where
it
got
confusing
and
guys
back
me
up
on
this-
is
originally
when
that
extension
was
written.
There
was
no
reference
to
the
HTV
transports
back,
but
when,
but
as
that
was
being
finalized,
I
think
somebody
connected
the
dots
to
the
w3c
thing,
wherever
that
other
spec
is
coming
from
and
sort
of
proposed
it
as
a
you
know,
as
a
mapping,
for
you
know
that
particular
transport,
because
there
was
somewhere
to
put
it
because
there
was
quite
there
were
similar
questions
coming
up
about.
Well,
you
know
this.
I
A
A
Does
it
make
sense
to
even
have
this
extension
at
all?
It
guess
it's
my
question
right
what
would
be
lost
if
we
just
dropped
it,
because
I'm
wondering
whether
it's
causing
more
confusion
than
actually
helping,
because
when
it's
there
people
are
gonna,
say:
hey
it's
there.
I
should
implement
it,
but
we
can't
explain
the
use
case.
That
is
actually
useful
because
I've
heard
people
say
you
don't
need
this
because
the
rich,
the
real
tracing
header,
has
the
original
value
in
their
embedded.
A
M
This
exists
so
those
those
two
fields
exist
because
they
are
exclusive
to
the
cloud
event
which
we
are
with
with
what
we're
doing
here,
effectively
tunneling
through
different
transports.
So
the
the
their
relationship
to
the
HTTP
trace
is
only
that
the
HTTP
trace
gets
seeded
in
the
context
established
for
the
cloud
event,
so
the
cloud
event
is
being
generated
somewhere
and
from
that
application
you
affect
the
create
a
trace
context
that
trace
count.
The
context
is
now
effectively
inherited
by
the
HTTP
pipeline.
M
If
we
want
to
call
it
that
way
where
you're
starting
an
HTTP
request,
you
run
the
HTTP
request
for
a
proxy
that
goes
through
a
reverse
proxy
that
goes
to
an
application
server
and
those
are
already
three
elements
of
HTTP
processing
that
probably
for
debugging,
should
be
traced,
but
that's
only
relevant
to
the
HTTP
processing.
That
should
be
able
to
link
up
to
the
original
cause
of
this,
which
is
you
know,
the
original
request
that
has,
however,
no
relationship
that
HTTP
processing
really
no
relationship
to
the
end-to-end
handling
of
that
event.
E
J
B
Does
it
really
make
sense
for
this
back
because
tracing
systems
in
theory
are
designed
to
from
the
from
the
childhood
span
from
the
child
spying
ID,
that
I
can
go
back
up
to
your
regional
span?
So
that's
that's
the
first
point
and
second
point
is
theorem
single
turn
in
the
chat.
Is
that
you're
saying
that
we
should
have?
We
should
use
this
part
of
this
distributed
tracing
really
to
transport
trace
informations
in
non-hp
protocols,
and
my
words
that
maybe
this
is
not
the
right
place
where
it
should
happen?
B
Also
because
we
have
this
and
from
a
mere
style
from
an
implementation
point
of
view,
we
still
have
the
structured
encoding
that
needs
to
be
decoded
needs
to
be
written
to
a
really
transparent
and
so
on.
So
I'm
not
sure
the
eerily
weak
audience
is
draw
a
place
to
do
that.
Also
because
some
open
telemetry,
for
example,
radius
from
integration
Akaka,
where
they
say
things
using
cough
gliders
using
the
trace
pattern,
which
is
similar
to
ice
cream.
N
Okay,
so
one
thing
that's
weird
about
this
particular
extension
is:
if
this
event
goes
into
things
like
Kafka,
we
could
potentially
have
these
like
replay
events
out
of
that
queue,
and
now
we
have
traces
that
kind
of
branch
out
very
largely
so.
It
feels
like
what
we're
trying
to
do
is
trace
an
event
from
source
to
wherever
it's
gonna
land,
but
the
replay
event
feels
like
a
different
event.
That's
that
needs
to
be
traced
in
a
different
way
right,
so
I
wondered
what
people
think
about
that
problem.
M
Yes-
and
that
is
a
different,
but
your
your
retrieval
is
actually
it
is
not
is
about
that
event.
But
it's
not
it's
not
the
same
context.
So
the
retrieval
originates
in
you
starting
the
retrieval.
That's
your
that's
the
origin
context
for
the
retrieval
and
then
and
then
what
you
fetching
ends
up
being
one
or
many
events
which
didn't
have
their
own
trace
context,
which
is
the
one
of
the
producer.
M
N
M
Would
you
would
you
once
you
have
the
event
in
hand,
then
you
can
go
and
continue
with
that
context,
but
just
the
retrieval
you
can't
anchor
in
that
context,
because
you
don't
know
what
you're
going
to
get
when
you
start
it
like,
when
you
just
say
to
receive
you,
have
no
idea.
What
kind
of
message
are
you
going
to
get?
Which
means
you
know
you
need
to
choose
a
new
root
system
in
a
new
context
that
is
for
that
per
hero,
retrieval
operation.
N
M
With
so
with
Kafka
and
with
with
any
sort
of
cubic
system
that
doesn't
work
because
you
are,
you
are
actively
you're
actively
soliciting
messages
and
you're,
often
actively
soliciting
messages
for
good
reason,
because
you're
just
done
with
the
work
that
you've
done,
which
means
now
the
cause.
The
reason
of
why
you're
in
fetching
new
work
is,
is
motivated
by
a
different
threat
of
execution,
you're,
actually
measuring
the
performance
of
your
of
your
tasks.
Dispatcher.
A
P
P
So
you
know
it
feels
useful
to
have
a
single
way
of
doing
this.
That
can
be
once
every
week
are
called
middle
working
in
their
own
district,
complex,
so
yeah
I.
That
reason
I
think
it
is
useful
to
have
something
like
that
aspect.
So
so
my
comment
here
is
kind
of
like.
If
this
isn't
the
trace
corrugation,
then
then
maybe
we
should
have
another
extension
service
obligation.
I
Hearing
this
conversation,
I
mean
I'm,
I'm
I
am
in
danger
of
conflicting
with
one
of
my
previous
comments,
but
also
I
wonder
if
this
is
what
maybe
the
answer
here.
Maybe
this
is
what
Ian
was
saying
on
colleges,
in
fact,
if
I'm
repeating
that,
but
moving
this
into
the
transport
specs
so
use
today,
you
know
explicitly
in
the
HTTP
transport
spec.
I
This
is
how
we
propagate
tracing,
and
you
do
that
in
Kafka
and
getting
QP
and
all
the
others
and
I'm
not
sure
if
that's
feasible,
but
then
it
becomes
a
very
transport
specific
thing
now,
I
I'm
still
arguing
with
myself
about
the
whole
sort
of
you
know.
Is
it
end
to
end
and
I,
don't
care
about
all
the
intermediary
in
the
middle,
but
that
that
would
seem
to
be
a
bit
of
an
out
yeah
that
you
could
remove
it
as
an
extension
and
just
make
it
part
of
the
transport
space
as.
I
M
M
M
A
Okay
feel
like
we
need
to
call
time
on
this
one
we
don't
rattle
too
much,
but
I'm
not
quite
sure
what
the
next
step
is.
Is
it
just
to
encourage
people
to
keep
commenting
on
the
issue
or
did
anybody
feel
like
we
were
circling
around
an
answer?
I'm
not
sure
we
were,
but
if
I
may
not
understood
the
flow
you.
P
A
Okay,
so
I'm
not
hearing
any
huge
things
that
list.
Let's
take
it
back
to
the
issue
and
see
we
can
make
more
progress
there.
The
only
thing
I
would
ask
is
that
we
don't
wait
until
I
get
there
to
before
next
week's
call
to
try
to
get
a
little
more
conversation
going
and
it
thicker.
If
you
spoke
up
on
this
call
today,
please
comment
on
the
issue
itself
to
try
to
get
some
conversation
going
there
I
think
that'd
be
appreciated.
A
B
A
Fair
enough,
that's
good!
Okay,
in
that
case,
we'll
hold
off
okay
next
one.
So
this
is
not
a
PR.
It's
an
issue,
but
grant
was
proposing
that
we
have
a
PHP
SDK
and
before
I
just
went
off
and
create
the
repo
cuz.
It
sounds
like
a
great
idea
to
me:
I
figured
process
wise.
We
need
to
make
sure
the
group
doesn't
see
any
potential
problem
with
doing
so.
K
J
This
could
just
be
me,
but
do
we
see
you
know
when
you
talk
about
cloud
and
even
sources
and
those
kinds
of
things
that
you
know
PHP
is
more,
would
be
or
is
more
prevalent
and
rushed
for
example,
because
rust
is
being
mentioned
in
the
in
the
in
this
issue.
I
would
have
thought
that
you
know
languages
more
suicide,
like
you
don't
rust
and
golang
and
python
and
others
are
more
than
more
prevalent
than
PHP
I'm,
just
curious.
What
everyone
thinks.
Q
There
was
a
bit
of
delay,
so
I
started
talking
together.
Sorry,
so
what
I
wanted
to
say
is
that
we
now
have
formal
conformance
process
with
cucumber
we
already
integrated
in
the
golang.
It's
a
it's
combined
announcement
and
suggestion
for
the
PHP
SDK,
so
in
case
I'm,
not
sure
who
will
be
working
on
the
PHP
is
decay,
but
if
you
want,
I
can
also
help
you
integrating
conformance
testing
so
that
you
stick
to
the
same
set
of
tests.
We
have
for
koenkan
Java,
for
example,.
A
A
A
R
Thomas,
yes,
thank
you
for
giving
me
the
time
to
talk
about
this
one
so
actually
for
the
next
one
for
the
considering
graph
QL,
as
you
sent
out
the
notification
that
we
should
have
a
look
at
it.
I
first
tried
to
understand
what
the
discovery
and
subscription
API
eyes
are
about,
so
it
felt
like
ours.
It
might
have
been
one
or
two
read
through
discovery
and
subscriptions.
I
literally
put
both
side
by
side
and
I
figured
out
that
there
is
a
slightly
different
terminology
used,
especially
around
producer
source
and
yeah.
R
R
But
it
was
really
not
clear
for
me
that
the
relationship
in
between
that
that
was
just
my
guests
here.
So
maybe
Mike
needs
to
comment
on
that
one,
and
also
that
the
source
was
mentioned
in
the
terminology,
so
the
context
in
which
the
occurrence
happened,
but
it's
somehow
not
really
linked
to
to
the
information
model
and
then
to
the
subscription
which
I
think
it's
interrelated.
With
with
the
discovery
there.
I
R
Api
I
also
try
to
make
a
little
model
there.
We
really
have
just
this
subscription
object
and
the
settings
and
and
somewhere
on
the
outside
the
filters.
That
was
at
least
my
understanding
and
that's
why
I
brought
it
up
so
I
would
love
to
to
also
file
a
PR
but
with
suggestions,
but
if
I
don't
have
that
the
real
understanding
behind
and
what
was
the
intended,
it's
really
difficult
to
to
find
the
right
direction
where
it
should
go,
so
that
it's
at
least
for
me
better
understandable.
R
Maybe
it's
just
me
I
guess
these
two
documents
they
were
created
kind
of
separate,
since
there
are
two
authors,
surprise.
Nevertheless,
I
think
that
it
would
be
gratitude
to
align
a
bit
the
terminology
and
give
some
more
background.
How
how
are
we
supposed
to
to
use
or
how
is
a
user
supposed
to
use
those
api's?
That
would
actually
help
a
lot.
So
when
did
you
join
the
room
not
so
long
ago?
Actually,
a
couple
weeks
ago,
okay,.
M
So
that
explains
it.
We
had
we
had
formed
two
subgroups
which
were
both
discovery
on
discovery
and
on
subscriptions
and
it's
a
it-
was
some.
There
were
some
requirements
for
all
over
the
fence,
but
we
have
those
two
documents
basically
were
put
into
the
repo
as
working
rafts
for
people
to
look
at
and
do
what
you're
doing
right
now.
Okay,.
G
M
Fair
enough,
first
of
all,
first
of
all,
looking
into
the
individuals
specs
that
see
what
they
make
sense
as
they
are
and
then
also
work
on,
reconciling
them.
So
thank
you
very
much
for
a
fresh,
look
and
I
think
this
is
ideal
because
you
just
come
at
this
uninitiated
and
so
I
think
what
you're
just
doing
here
is
is
great
work,
because,
ultimately
the
documents
need
to
stand
for
themselves
and
need
to
make
sense,
then,
in
conjunction
ya,
neva.
J
J
M
That
is
what
this
is
discovery.
Spec
is
for
so
the
discovery
spec
basically
gives
you
a
catalog
of
events
and
the
subscription
managers
where
you
can
go
in
and
find
those
so
effectively.
The
endpoints
are
being
described
in
Discovery
and
then
a
subscription
gives
you,
the
mechanics
of
how
you
can
set
up
a
relationship
between
your
endpoint
and
the
subscription
manager.
So
the
subscription
manager
can
then
facilitate
giving
you
the
event.
So
that's
that's
the
relationship
between
the
two
mm-hmm.
M
We
have
done
some
work
on,
you
know
making
those
specs
and
then
we
check
them
in
and
now
we
have
I
think
we're
taking
a
breather
right
now
to
then
kind
of
resume
working
on
them,
but
also
the
idea
was
to
kind
of
have
the
space
there
and
then
for
people
to
find
cycles
to
start
proving
proving
those
out,
because
those
specification
is
certainly
needed
from
a
teacher
for
them
so
makes
sense.
So
they're
coming
exactly
at
the
right
time
and
you're
coming
exactly
with
the
right
with
the
right
level
of
information.
M
R
M
A
G
R
J
G
A
Think
it
makes
a
lot
of
sense
and
add
for
it.
This
is
not
just
for
you
Thomas,
but
everybody
I
would
actually
love
it.
If
people
just
started
opening
up,
not
even
pr's,
but
that's
that's
the
dream,
but
even
just
a
whole
boatload
of
issues
of
things
that
just
don't
make
sense
just
to
force
some
of
these
discussions,
cuz
I'm
trying
to
think
back
when
cloud
events
first
got
started.
We
had
a
whole
bunch
of
issues
and
some
of
them
made
no
sense
whatsoever.
A
There
were
just
one,
you
know,
couples
words
short
little
sentences,
but
at
least
it
helped
force
a
review
and
a
discussion
about
some
of
these
topics
in
the
spec
and
I
know
Clements
that
were
taking
a
little
bit
of
a
breather
right
now,
but
I,
don't
think
it's
an
intentional
breather.
I
think
it's
just.
Maybe
it's
because
everything
going
on
in
the
world
right
now.
People
are
just
sort
of
relaxing
or
have
other
things
on
their
mind,
but
I
think
we
need
something
to
help
force.
A
A
R
A
Well,
I
won't
I,
won't
close
this
one
I
just
want
to
make
sure
that,
ultimately,
because
I
don't
think
this,
this
issue
itself,
it's
so
broad
right,
I,
don't
think
it's
gonna
result
in
just
a
single
PR,
I
suspect
to
be
a
whole
bunch
of
PRS.
So,
okay,
cool
all
right
in
that
case,
Mike
is
not
on
the
call
but
graph
qo
I
think
there
were
couple
comments
on
this
one
within
the
last
couple
of
hours
Shh.
A
R
Yeah
basically
agree:
it
should
be
a
just
a
an
alternative
to
to
rest
API
because
we're
state
guys
are
so
common
and
so
so
used
in
the
whole
communities.
So,
but
but
just
I
added
some
thoughts
that
it
might
not
be
so
easy
to
use
the
rest,
especially
for
the
discovery.
When
you
see
the
different
resources
which
we
need
to
call
and
the
matching
and
the
search
term
and
so
on.
F
F
I
don't
have
first-hand
experience
with
it,
but
where
you
have
micro
services
or
just
services
that
only
offer
rest,
and
then
you
have
a
graph
QL
gateway
or
API
server,
whatever
you
want
to
call
it
in
front
that
takes
the
graph
your
requests
and
forwards,
then
interns
or
resolves
the
graph
QL
fields
by
making
rest
or
a
passing
or
whatever
calls
to
the
individual
services.
So
that
will
be
one
way
where
a
service
like
Clement
said
that
is
too
constrained
to
offer
graph
QL
itself
could
still
offer
it
by
having
that
in
front
of
it.
F
A
Okay,
before
we
adjourn
actually
before
I,
do
the
like
roll
call
again,
we
do
have
an
SDK
call
right
after
this
one
and
actually
after
the
SDK
call,
Clemens,
Scott
and
I
were
going
to
discuss
coop
con
and
the
reason
it's
initially
just
us
three
is
because
we
were
the
three
that
had
volunteered
to
run
one
of
the
sessions
that
we
had
a
coup
cone.
So
we
were
going
to
discuss
what
to
do
about
that
too.
Now
that
they're
going
virtual
anybody
else
is
free
to
join.
A
Unfortunately,
in
order
to
do
that,
you
have
to
hang
on
through
the
SDK
call,
because
we
don't
know
when
the
brainstorming
session
will
happen,
but
I
wanted
to
give
anybody
wanted
to
an
opportunity
to
join.
We
will
be
talking
about
with
dubaku
con
after
the
sdk
call
okay,
and
with
that,
let
me
quickly
do
funnel
roll
call,
and
then
we
you
guys,
can
go
normal
either.
A
J
A
A
A
A
A
Carolina
yeah
really
good
storm
this
morning
it
was
really
cool.
I
love,
a
storm.
The
way
down
sideways
I
was
I,
had
to
do
a
some
demos
this
morning
for
a
WebEx
call
and
I
had
this
fear
that
the
power
was
gonna
go
out
because
of
the
storm,
but
luckily
I
did
everything
good
so
just
good
day.
So
far,.
Q
A
S
J
S
For
sprinkle
of
function,
sprinkle
on
Street
projects,
so
basically
a
clock
function
side.
We
got
a
request
from
one
of
the
Google
dev
advocates
James
word
to
provide
support
for
cloud
events
within
spring
Club
function,
so
naturally
we
had
several
internal
discussions
as
well
as
external
debates
as
to
what
does
that
even
mean
so,
on
one
hand,
that
cloud
event
is
a
very
clear
and
Jason
friendly
specification
and
Asajj,
at
least
in
spring,
could
be
easily
dealt
with
using
existing
spinning
obstructions
even
right
now.
S
Discussion
is
naturally
led
us
to
the
fact
that
there
is
a
Java
SDK
and
certain
abstraction
is
defined
by
is
decay
may
be
a
value
to
us,
at
least
for
purposes
of
avoiding
defining
those
our
own
types
representing
sort
of
a
similar
things
like
cloud
event
right.
So
in
other
words,
it
really
became
about
the
difference
between
supporting
cloud
event,
cloud
events
or
supporting
cloud
events
through
Java
SDK.
S
So
for
the
sake
of
this
discussion,
we're
going
to
assume
that
support
for
cloud
events
is
through.
Java
is
decayed,
so
we
started
looking
at
some
artifacts
and
approaches
that
eventually
led
us
to
this
discussion.
So
after
these
a
lot
of
internal
discussions,
we
yesterday
I
sort
of
I've
submitted
ADR
that
simplifies
and
streamlines
cloud
event
interface
by
effectively
actually
bringing
it
back
to
the
state
or
to
a
state
similar
to
what
it
was
in
version
one
to
ensure
it
stays
clean
and
clear
of
any
assumptions
about.
S
S
S
So
basically,
what's
that
question
so
the-
and
this
is
kind
of
probably
the
most
important
slide
actually
because
the
question
is
I
want
to
make
sure
that
we
clearly
maintain
this
part
of
the
discussion
within
the
scope
and
scope
is
the
structure
of
the
cloud
event
interface,
where
we
basically
moved
several
operations
out
of
it
and
removed
one
operation
all
together?
So
let's
see
what
those
are.
So
basically
motivation
is.
You
know
some
of
the
best
principles
of
software
design,
so
single
responsibility,
interface,
segregation.
S
So
do
one
thing:
do
it
well
and
don't
force
me
to
do
something
I
don't
need
to
so
with
that
sort
of
a
moto
we
removed,
for
example,
get
attribute
removed
in
favor
of
unity
of
individual
setters
and
get
some
sorry
removed
in
favor
of
individual
getters
for
the
attributes
defined
by
this
back.
So
while
so
it
forces
want
to
implement
another
interface,
which
is
not
really
mentioned
in
aspect,
while
individual
attributes
are-
and
you
know,
for
example,
with
GSR,
3
or
5.
S
We
can
also
distinguish
from
just
the
definition
of
the
interface
very
easily
which
attributes
are
acquired
which
are
optional
so,
and
it
kind
of
makes
interface
very
clear
and
very
concise.
And
if
I,
the
one
who
wants
to
implement
the
interface
I,
don't
have
to
I,
don't
have
to
worry
about
learning
how
to
implement
cloud
events
interface,
but
also
how
to
implement,
for
example,
attributes
interface
and
then
try
to
correlate
it
to
specification.
S
Get
binary
master.
Actually
s
binary
message
as
structural
message.
Those
methods
were
moved
out
of
the
into
a
utility
class
for
now,
because
they
in
terms
of
whether
the
place
where
they
were
moved
out
to
is
a
permanent
place
or
a
temporary
place,
is
a
matter
of
separate
discussion
because
we
need
to
find
out
actually
assign
proper
responsibility,
whether
those
those
are
builders,
as
we
discussed
or
adapters
or
converters,
and
so
on
and
so
forth.
So
I
classify
these
methods
as,
for
example,
adapters
right
because
they
adapt
claude,
went
to
various
binding
transmission
storage
purposes.
S
So,
and
you
know
you
can
kind
of
read
the
rest,
so
you
know,
but
the
main
point
is
that
we-
and
we
discussed
this-
that
these
are
these
type
of
operations.
These
two
operations
belong
to
one
facilitated
from
the
optional
part
of
the
specs,
so
in
other
words,
the
cloud
event
can
exist
without
ever
being
converted
to
binary
or
structured
message
or
vice-versa
right
so
and
if,
in
my
world,
that's
the
lifecycle
of
the
cloud
event,
why
should
they
be
forced,
for
example,
to
implement
something
that
I
have
no
intentions
of
using
in
Reverse?
S
S
To
Devon
to
p3
those
are
again
I,
look
at
them
as
a
converters
and
clearly
kill
the
operations
originated
due
to
specification
change
and
therefore
optional
by
default.
In
other
words,
those
are
almost
like
accidental
operations,
because
if
there
was
no
change
that
would
govern
the
type
of
conversion,
those
would
never
exist
in
the
first
place.
Right
so
again,
I
made
shoes
in
the
new
world
saying
hey,
you
know
what
I
made
shoes
to
not
support
version
3,
that's
my
right
right.
So
why
should
I
be
forced
to
even
question?
Why
I
have
that
method?
S
On
my
interface
right,
I
may
have
utility
class.
That
provides
me
with
that
method
and
that's
fine
I
made
shoes
to
use
it
or
not,
but
on
the
interface
I,
just
don't
you
just
don't
believe
that
it's
the
appropriate
place
to
have
those
operations
and
two
more
methods
built
version
about
the
version.
Three
again
the
same
kind
of
arguments:
those
are
factories,
builders,
whatever
I
mean
I,
don't
they're,
not
really
builders,
because
their
wealth
in
my
world
builder
is
very
clear
as
a
very
clear,
distinct,
very
clear
definition
of
what
the
Builder
is.
S
So
those
are
factories
but
again
the
same
point,
but
here
it's
even
more
interesting
because
well
in
Java
world
there
are
instances
quite
a
few
actually,
where
we
have
factory
method
on
the
class
that
effectively
creates
itself.
Like
get
instance,
that's
we've
got
a
good
example
for
Singleton's
right.
However,
having
similar
operation
on
the
interface
raises,
the
question
of
which
implementation
is
it
going
to
return
this
or
that
right?
S
So,
in
other
words,
when
class
returns
that
getinstance,
it
is
clear
which
implementation
is
going
to
return
so
final
indication
of
the
same
interface,
five
classes,
who
have
the
instance
method,
we
can
call
either
one
of
them
and
yet
a
particular
implementation.
There's
no
ambiguity
there,
however,
when
it
comes
to
having
something
like
get
instance
or
build
version
1
with
version
3
on
the
interface
well,
I
can
have
multiple
implementations
of
version
1
and
version
3.
So
again,
it's
just
the
wrong
place
to
have
it.
S
S
P
Q
Sorry
I'm
just
quickly
or
just
quickly,
okay.
So
when
we
start
looking
at
the
cloud
events
as
decay,
and
here
when
I
say
we
I
mean
both
spring
set
of
projects
but
also
leak
loose,
which
is
an
event
gateway
for
Kafka,
pulsar
and
others.
Where
cloud
event
is
first-class
citizen
now,
which
is
a
which
I'm
really
happy
about,
and
when
we
started
comparing
version
1
version
2,
we
realize
that
maybe
there
was
too
much
of
a
difference
between
these
two.
There
was
some
good
ones,
but
also
some
questionable
ones.
Q
So
I
decided
to
take
step
back
and
look
at
what
we
had
in
version
1.2.
The
current
latest
release,
so
the
interface
was
very,
very
small,
like
just
four
methods,
and
it
was
good
enough.
There
are
some
issues,
but
at
least
from
the
implementation,
but
if
it
was
good
enough
and
we
were
able
to
provide
our
own
implementation
for
the
interface
for
performance
reasons,
but
also
for
making
it
easier
to
adapt
our
internal
representation
into
cloud
event,
it
is
very
well
aligned
with
the
specification
you'll
find
data
extensions.
Q
There
is
some
attributes
object,
which
is
not
something
you
find
in
the
specification.
At
least
when
you
look
at
it,
you
would
usually
expect
attributes
next
to
other
fields
like
data
and
extensions,
but
anyways
that's
version
1,
and
there
are
some
issues
with
allocations.
For
example,
in
agile,
we
have
to
pay
the
price
of
allocations
where
we
deal
with,
for
example,
optional,
class
and
Inter
located
to
return
wrapper
or
attributes,
but
it
was
lean,
and
it
was
great
because
it
was
so
easy
to
implement
it.
Q
Q
We
now
no
longer
deal
with
optionals,
it's
a
gyrus
vo5
change
he
was
talking
about,
but
now
we
also
have
to
be
0-3
to
be
one
as
binary
message,
a
structured
message,
some
static
methods
that
are
the
new
concepts
to
implement
and
you
as
an
implementer,
have
to
know
about
them
and
they
bring
some
issues
like
a
structure.
It
requires
an
allocation
because
it
has
to
capture
the
parameter
and
some
other
things
plus.
It's
not
something.
You
find
it's
a
specification
like
binary
message
and
structure
message.
Q
Okay,
I
see
the
chat
now.
So,
if
you
want
to
share
something,
yep
I'll
read
job,
so
it's
not
lean
anymore
and
it
makes
I
made
it
much
harder
to
implement.
What
Olek
proposed
in
his
poor
request
is
to
take
a
look
at
version,
one
of
the
SDK
inline,
the
attributes,
but
the
rest.
It's
basically
the
same,
so
you
will
find
some
similarities
with
version.
Q
One
interface
and
the
benefits
of
this
approach
is
that
it
Maps
101
to
the
specification
it's
easy
to
implement
and
it
does
not
contain
any
implementation
details
of
the
SDK
and,
while
all
things
that
messages
abstraction
is
a
great
one
and
it
really
helps
to
implement
the
bindings
I.
Don't
think
that
interface,
it
represents
a
cloud
event.
The
ones
that
we
potentially
may
use
in
frameworks
not
only
Muser
code
but
in
frameworks
should
expose
any
implementation.
Q
So
long
story
short.
We
think
that
during
the
version
2
efforts,
we
we
were
focusing
on
the
messages
abstraction
too
much,
and
we
brought
this
obstruction
to
the
main
interface
and
in
fact
it's
not
necessary.
We
can
keep
the
old
interface
the
old
lean
interface
and
do
the
conversion
next
to
the
interface,
but
as
the
main
interface
of
the
whole
life
burbs.
How
is
decay?
The
one
that
should
be
used
by
other
integrators
should
be
as
small
as
possible
and
as
close
to
the
specification
as
possible.
C
Q
S
Because
what
I
really
want
to
accomplish
here
is
if
we
were,
if
we
were
not
forgetting,
do
this,
then
just
passing
through
the
photographs
itself,
with
all
the
comments,
so
we're
just
taking
more
than
one
hour
to
just
deal
with
that
in
the
divisional
comments,
so
I
just
wanted
to
kind
of
say:
okay.
Well,
let's
forget
the
art
for
a
second
here's.
What
was
done
and
here's
where
we
heading
20,
here's?
Why
so?
S
And
so,
let's
yeah,
we
can
still
get
back
to
the
PR
or
like
offline
for
more
comments,
but
we
kind
of
would
like
to
gauge
what
the
rest
people
on
the
call
think
about
this
change
and
about
the
view
of
the
interface
that
you
can
see
right
now.
On
the
right
hand,
side
we
change
what,
which
is
what
this
PR
is
all
about.
This
is
the
gist
of
the
PR.
The
rest
is
just
to
make
sure
that
this
works.
In
other
words,
the
tests
of
the
tests
are
passing.
So
no
breaking
changes.
A
S
A
T
A
S
S
M
That
effectively
tracks
your
proposal,
with
the
exception
that
for
the
model,
so
first
what
I
haven't
after
we
have
a
method
that
is,
gives
you
that
can
give
you
all
the
attributes
as
a
dictionary.
So
you
get
bra
access
to
everything
without
knowing
what's
there
and
then
there
is
a
particular
extended
pattern
that
is,
that
I'm
using
this
short
SDK,
where
you
are
having
effect
these
strongly
typed
extensions.
So
that's
this
notion
of
an.
M
If
you
had
like
the
distributed
tracing
extension,
then
you
would
walk
up
to
the
cloud
event
and
it
would
say
on
the
cloud
event
you
would
say
in
cloud
event,
dots
and
then
extensions
off
on
distributed
tracing
extension.
It
would
give
you
this
from
you
type
interface
for
it,
but
otherwise,
if
you
want
to
get
an
extension
attributes,
you
simply
go
and
tap
into
the
into
the
attributes,
collection
and
that's
how
you
get
them.
N
S
N
N
It's
really
only
useful
for
the
in
consumer
functions
and
so
the
the
UX
around
how
to
build
up
these
events
and
how
middleware
deals
with
events
and
transcend
and
shuffles
it
between
protocols
is
a
much
more
telling
SDK
feature
so
I
wonder
if
we
could
I
mean,
like
I,
really
don't
see
a
problem
with
the
this
simplified
interface.
If
you
don't
want
to
have
attributes,
I
think
it
was
kind
of
nice
to
be
able
to
iterate
over
attributes,
but
it's
okay.
N
S
With
you-
and
we
are
not
questioning
that
what
we're
trying
to
do
is
say
yes,
this
is
a
responsibility
that
has
to
be
handled,
but
there
are
utilities
there
are
builders,
there
are
converters,
I
mean
we
again
from
even
from
the
spring
example.
We
deal
with
there's
math
of
issues
and
that
kind
of
a
daily
basis.
We
have
frameworks
and
extensions
around
those
issues
and
certain
instructions
that
are
been
around
and
out
for
decade.
Now.
S
So
again,
it's
not
a
question
of
whether
whether
those
which
is
saying
agree
or
disagree,
it's
definitely
agree
is
whether,
for
example,
the
Builder
methods
operations
should
be
exposed
through
the
interface,
this
cloud
event,
interface
or
whether
it
is
a
sort
of
a
utility
functionality
that,
in
fact,
as
one
of
the
slides
I,
was
looking
about
the
fact
that
in
fact,
it
is
shared
and
I'd
rather
be
able
to
go,
and
many
people
can
reuse
that
functionality
with
their
own
implementation
of
cloud
event
right.
So
that's
another
benefit
of
saying
yeah.
J
S
N
I
agree
with
that
too,
even
though
we
do
the
same
thing
where
there's
a
there's,
a
getter
interface
and
there's
a
writer
interface
ooh,
so
totally
I
think
I,
think
that
sounds
reasonable,
and
so
we
now
we
can
start
picking
these
things
apart,
where
we
can
have
message,
interfaces
and
cloud
event,
writer
interfaces
and
things
like
that,
and
if
you
really
just
want
to
integrate
on
the
cloud
event
interface
with
it's,
this
thing
that
you're
showing
that
seems
like
a
reasonable
approach,
is
well
I'm.
Getting
example.
N
S
Sparing
clock
function,
just
look
at
it
from
the
pure
function:
I
have
a
function,
clawed
event
cloud
event,
another
function,
cloud
claudio
and
so
the
reason
why
I
have
to
it,
because
I
broke
my
complexity
and
implemented
it
as
two
different,
isolated
functionality.
Now
I
want
to
reassemble
it.
How
do
I
do
it?
I
do
function,
composition,
so
now
your
function
a
and
ends
the
and
then
function
B,
so
I
compose
two
functions
into
one.
S
Well,
one
out
was
cloud
events,
another
inputs
cloud
event,
regardless
that
it
still
has
to
pass
one
internally,
but
there
was
composed
I
mean
these
types
have
to
be
passed.
So
it's
simple
by
reference
passing,
but
this
is
where
this
is
exactly
what
I
want
to
deal
with
with
nothing
else
right
and
then,
if
I
want
to
start
sending
it
to
Kafka,
rabbit
or
whatever
and
with
bindings
without
bindings,
regardless
of
how
I'm
going
to
do
it
right,
I
will
I
have
layers
and
look
what
happens
in
stream.
We
have
boundaries.
S
They
will
do
that
right.
So
again,
this
is
just
I'm,
not
questioning
whether
those
things
should
be
done.
It's
really
more
about
who
should
do
that?
Should
it
be
a
jack-of-all-trades
or
should
it
be?
You
know
everyone
has
their
own
responsibilities
and
I
just
delegate
to
that
one
guy
who
does
one
thing,
but
does
it
very
well
Oh.
A
D
B
S
B
So
the
clash
is
my
opinion
is
that
the
goal
of
DK
is
to
provide
a
core
module
which
contains
dpi,
which
rotates
the
basic
people
tations,
which
can
be
eventually
split
into
different
modules.
And
then
there
is
our
range
of
sub-modules
that
is
DK
provides
to
eventually
integrate
with
the
existing
tool
out
there,
so
the
user
can
just
download
is
decay
and
use
it
with
Kaka,
okay,
fair
enough,
but
we're
talking
about,
but
and
well.
This
really
comes
down
to
this
interface,
because
I
fully
agree
with
you.
B
First,
the
SDK,
since
the
SDK
is
really
not
working
from
a
state.
I
frankly
admit
that
I
made
some
mistakes
just
to
make
the
code
compile
like
the
building.
One
matter
should
not
be
there,
I
completely
agree,
but
about
the
conversion
to
messages.
I
think
they
should
remain
that
for
a
couple
of
reasons.
B
First,
in
in
SDK,
go.we
externalized,
the
conversion
between
event
and
message
and
the
result
is
a
huge
elephant,
called
versions:
sub
module
where
we
need
to
handle
all
the
differences
between
the
various
operations
and
I
mean
I
I
want
to
avoid
it
because
in
Java
we
just
do
in
aerica.
So
the
event
itself
knows
how
to
provide
a
bit
self
unobstructed
view,
which
is
really
what
as
binary
messages
I
mean
as
binary
message
as
binary
message
is
nothing
different
from
just
letting
go.
B
S
B
Because
you
need
to
end
all
the
different
specification
versions
if
you
move
outside.
Well,
if
you
add
inside
the
method
and
sorry
if
you
are
inside
that
the
class
implementation,
which
is
specific
to
the
cloud
event
version.
In
that
case,
we
have
attributes
but
forget
about
doctor
boots.
Let's
assume
we
have
cloud
events,
v1
cloud
events
reads
your
country,
implementation,
okay!
Well,
you.
S
Know
my
second
so,
first
of
all
again,
if
are
you
envisioning
when
we
guess
a
different
question?
Are
you
envisioning
version,
2
version,
3
version,
4
version
spire-like?
How
many
I
mean
I'm,
assuming
that
I
mean
operating
under
assumption,
that
cloud
event
is
kind
of
like
law
of
the
land
right.
So
the
fact
that
we
have
version
oh
three
and
now
version
one
they're
always
you
know
now
it
was
kind
of
expected
in
the
very
early
version
like
early
adaptors.
We
learn
something
we
created
version.
One
sure
I
expect.
S
Maybe
there's
gonna
be
few
additional
amendments
over
the
years,
but
you
know
that's
it.
That's
that's
the
cloud
event.
That's
I
mean
how
much
how
much
more
complex
can
and
yet
so
now,
with
that
in
mind,
if
I
am
correct
and
then,
if
somebody
you
know
correctly,
but
if
I,
if
my
assumption
is
correct,
then
we're
talking
about
very
edge
case
which
again
I
can
handle
in
utility
class,
with
a
simple
interrogation
of
the
actual
cloud
event
that
was
passed
to
that
cotillion
class
and
say
this
is
version
of
three.
S
B
For
I
think
we
can
make
that
assumption
that
things
won't
change,
I
mean
in
my
opinion.
We
can
do
that.
That's
a
bad
assumption
and
all
SDKs
are
designed
around
the
idea
that
there
could
be
an
order.
Spec
version
which
drastically
changes
some
stuff
and
second
moving
as
binary
message
to
another
to
toy
utility
method,
creates
a
necessary
location
which
is
exactly
what
I
want
to
avoid
in
the
message
you
guys
if.
Q
I
may,
if
I
may
Kommandant
this
one,
because
ideally
this
converters
from
cloud
event
into
messages
should
be
stateless
transformers
and
there
should
be
any
allocation.
Where
anything
is,
it
can
even
be
single
tons
if
we
don't
know,
do
not
aim
at
extending
Sam
and
and
what
I
also
wanted
to
ask
ourselves
and
educate
developers
in
particular,
is
version
one
was
capable
of
supporting
the
house
pack
with
this
interface.
Q
B
N
But
we
could
add
additional
interfaces
and
it
doesn't
have
to
be
locked
up
in
this
one
plot
of
an
interface
and
the
implementation
say
extents
this
that
and
the
other,
where,
if
you're,
only
a
reading
implementation,
you
just
provide
the
normal
cloud
event
interface,
and
if
you
are,
if
you're
a
middleware
you
you
want
to
take
an
object.
That's
a
cloud
event
and
also
a
cloud
event
to
message,
interface
or
something.
S
B
B
How
do
we
end
on
this
conversion
and
that's
the
first
question,
and
the
second
question
is
why
in
first
instance
in
first
instance,
you
should
use
called
event
if,
at
the
end
you
don't
go
to
the
wire
or
the
or
you
don't
read
from
the
wire
I
mean
why
in
first
instance
in
first
instance,
you
are
using
a
serialization
format
to
that
datatype,
maybe
to
your
business
logic.
If,
in
the
end,
you
don't
write
it
to
the
wire
I.
Q
Mean
I
think
I
think
I
can
answer
this
one.
It's
a
good
question
and
I
went
to
the
specification
to
the
SDK
documentation
and
it
says
that
cloud
vans
in
the
SDK
should
be
easily
transformable
as
an
in-memory
representation.
It
should
be
immutable,
but
it
should
be
easy
to
transform
one
cloud
event
into
another
and
that's
exactly
the
case.
We
have,
for
example,
is
between
cloud
event,
also
sorry
in
spring
cloud
functions.
Q
Sometimes
we
want
to
accept
one
cloud
event
return,
another
one
and
then
eventually
maybe
sanded
over
as
a
wire
or
maybe
just
log
it.
Maybe
it
won't
be
any
serialization
and
deserialization
at
all,
or
maybe
we
want
to
represent
internal
structure
in
spring
cloud
function,
which
is
message
has
cloud
event
to
make
it
more
hot
say
to
represent
it
as
more
widely
adopted
interface,
which
is
cloud
event
and
I
believe
that
cloud
event
will
become
a
very
widely
adopted
interface
and.
B
I
think
I
personally
think
that
on
this
particular
point,
it
could
be
wrong
for
the
really
simple
reason
that
you're
tying
your
framework
business
logic
to
something
that
is
a
serialization
format.
As
I
said
this
to
me,
it
really
looks
like
saying
I
time
I
my
framework
business
logic
to
to
a
soap
and
block
well,
a
soap
envelope
is
really.
U
M
A
thing
that
is
an
event
is
a
first-class
programming
constructs
and
serialization
is
something
that
we
do
separately,
and
that
is
your
choosing
Jason
you
choosing
Avro
and
that's
your
civilization
from
it,
but
an
event
is
a
construct
that
you
keep
in
the
earth
as
an
element
of
your
architecture.
It's
called
event-driven
architecture
because
you're
moving
events
around
that
the
events
are
driving
the
logic
of
your
application.
So
it's
not
something.
That's
just
for
the
wire.
It's
it's
a
thing
that
you
handle
inside
of
your.
M
They
need
to
exchange
information
in
in
a
way
that
is
also
useful
for
exchange
across
the
wire
convent
is
a
perfect
model
for
that,
because,
first
of
all,
you
get
you
get
a
way
to
standardize
events
across
all
of
the
models
that
you
have
without
having
to
invent
a
new
one,
and
then
you
can
also
go
and
effectively
scale
data
system
out
across
across
process
boundaries.
So
it's
ideal
for
that
degree.
S
Q
Also
wanted
to
mention
some
use
cases
like
it's
it,
it
kind
of
the
same
of
Clement
state,
but
there
is
a
real
use
case,
for
example,
DB
zoom,
where
she
needed
some
format
to
represent
events
generated
by
the
databases
in
a
common
form.
They
used
to
have
set
our
own
format,
they
just
added
integration
for
cloud
events
and
they
were
using
the
binary
representation,
so
they
have
to
parse
it
and
I've
been
asking
them
like.
Why
didn't
he
use
as
the
case?
N
S
For
that
we
thought
about
this
and
the
analogy
actually
kind
of
comes
from
we.
We
have
very
similar
interaction
model,
for
example,
sprinkle
extreme
sprinkle,
a
function,
decide
where
message
kind
of
message,
at
least
within
the
context
of
what
I'm
saying
now
as
cloud
event.
It
also
comes
in
with
a
payload
as
byte
array,
because
what
happens
is
that
the
adapters
like
Kafka
or
rabbit
or
whatever
messaging
system
using,
will
translate
the
byte
array
to
headers
and
everything
else,
but
not
to
the
actual
type,
because
we
do
like
a
type
conversion.
S
We
can
convert
byte
array
to
foodtube
art
or
whatever,
and
we
know
the
type
only
at
the
time
of
function.
Invocation
for
example
right.
So
we
need
to
know
the
attackers
I
say:
okay,
you
want
person
right
so
I
have
a
battery
content
type
application,
JSON,
so
I'm
going
to
send
it
as
a
JSON
converter
and
it's
going
to
create
a
person
fine.
So,
but
the
point
is
that
we
really
don't
know
at
the
time
event
creation
until
because
you
may
have
the
same
Jason,
for
example.
Representation
is
a
good
example.
S
If
the
method
that
you
want
invoke
is
a
string,
then
you
just
pass
the
entire
JSON
string,
but
if
it's
suppose
you'll
attempt
to
convert
it
to
the
Torah.
So
now
you
have
that
flexibility
and
you
don't
have
to
create
it
twice.
You're,
just
simply
passing
around
the
byte
array,
but
to
your
point
that
could
very
well
be.
N
S
S
N
M
S
Q
This
deserves
separate
discussion
because
I
think
we
all
agree
on
this
topic
said
by
ASCII
data
I
mean
may
not
be
as
efficient
and
as
widely
used
as
it
could
be,
but
I
believe
that
this
is
a
bit
off-topic
to
the
main
conversation
and
I
just
wanted
to
mention
quickly
that
we
also
have
James
Ward,
who
started
the
topic.
Basically
in
the
gel
world
of
supporting
cloud
events
in
spring
cloud
functions.
So
in
case
you
have
some
input.
James
I
would
love
to
hear
your
input
as
well.
V
Thanks
I
think
for
me:
I
think
the
the
big
question
around
this
is
is:
do
we
imagine
that
people
are
gonna
build
API?
Is
that
that
use
cloud
event
as
a
construct
that
gets
passed
around
and
shared
across
across
different
libraries
and
stuff
and
and
I
definitely
see
that
as
being
something
really
useful
to
be
able
to
share
cloud
event
across
libraries
and
make
that
a
foundation
that
we
that
we
build
API
is
on
top
of
I?
V
B
B
N
I
think
this
could
be
solved
with
the
the
like.
We
take
a
look
at
those
personas
and
we
we
can
think
where
each
interface
makes
sense,
and
so,
like
this
interface,
looks
like
very
simple
consumer,
but
it's
probably
inappropriate
for
middleware,
because
it's
gonna
be
too
cumbersome
and
you
don't
get
the
ability
to
let
the
object
itself
understand
how
to
turn
itself
into
the
structured
version
for
a
protocol.
N
It's
a
can
can
be
like
I,
think,
I.
Think.
The
simple
way
to
agree
here
is
that
we
say
we're
gonna,
look
at
an
interface
hierarchy
for
certain
implementations
to
implement
as
optional
and,
if
spring
would
like
to
be
to
just
use
the
in
the
cloud
event.
Interface
and
internally
do
bunch
of
magic.
That
seems
like
it's
okay,
because
it
doesn't
have
to
use
the
message
interfaces.
N
B
M
See
but
as
binary
is
weird
because
what
what
binary
really
does
is,
it
is
a
projection
of
a
cloud
event
into
a
particular
transport
message.
So
HTTP
binary
is
a
specific
encoding
of
a
cloud
event
using
the
HTTP
message
as
its
carrier,
the
same
thing
is
MVP
binary
is
using
the
ABP
message,
definition
as
the
carrier
for
a
cloud
of
it.
The
cloud
event
gets
completely
exploded
on
top
of
those
those
carrier
messages,
and
then
they
also
get
pulled
back
from
it.
M
So
there
can
be
an
implementation
of
get
binary
that
is
not
specific
to
the
transport,
because
those
representations
are
different.
Now,
similarily
similarily,
there
can't
be
a
format,
independent
implementation
of
get
structured,
because
the
jacent
implementation
and
the
jason
in
the
jason
from
its
internal
structure
differs
from
that
of
opera.
B
Now
in
documents,
I
think
I
think
in
this
case,
maybe
maybe
you
misunderstood
from
good
names
because
as
a
structured
message,
it's
really
a
view
of
the
event
but
serialized
with
the
provided
format.
Yeah
well
as
a
where
we're
with
well
as
binary
message
is
a
unstructured
view
of
the
message,
but
without
avoiding
any
allocation
of
a
map
of
us
or
over
three,
but
that's
really
what
it
is.
B
M
So
there's
a
there's,
a
there's
a
it
has
to
be
an
attribute
collection
and
that's
the
attribute
collection
you
give
to
the
seer
Iser
and
there's
two
kinds
of
Caesars
we
have
which
are
there
are
serial.
Iser
switch
turn
the
event
into
a
stand-alone
payload,
which
are
all
the
structured
ones
and
then
there's
a
second
kind
of
sterilizer,
which
turned
the
cloud
event
into
map
that
onto
a
message
of
a
particular
choice
of
transport.
But
those
both
can
feed
from
the
same
thing,
which
is
a
list
of
the
attributes
and
access
to
the
data.
Q
I'm
sorry
for
interrupting,
but
since
I
guess
we
have
other
topics
other
than
this
one,
and
this
one
is
still
important.
But
still
perhaps
we
can
I'll
conclude
it
with
something,
and
I
would
really
like
to
ask
question
and
hope
we
can
get
a
concrete
answer.
Whether
cloud
event
is
a
type
that
should
be
consumed
by
the
end
user
and
should
be
seen
by
the
end
user
or
not,
and.
Q
A
Q
S
S
S
What
should
we
do
with
this
PR,
and
should
this
other
discussion
be
discussed
as
part
of
this
country,
or
should
it
be
incrementally,
as
we
you
know,
we
also
discuss
about
making
small
tears,
manageable,
say,
okay!
Well,
if
at
some
point
of
time
we
just
like
to
add
those
operations
back
into
the
interface
for
whatever
reason,
then
that's
going
to
be
a
set
before
the
PRS
and
so
on
and
so
forth.
Like
so.
S
And
they
didn't
exist,
so
they
were
added
recently
without
actually
having
the
discussion
like
we're
having
right
now.
So
maybe
we
should
really
say:
ok!
Well,
you
know
the
the
real
change
between
version,
1
and
what's
proposed
right
now
is
the
attributes.
So
we
can
kind
of
take
a
built
in
neck
and
say:
ok,
fine!
So
what
are
we
accepting
it
or
not?
And
then
say:
ok
well,
maybe
next
week
or
whatever
have
discussion
about
variety
of
other
methods
and
whether
they
should
be
there
and
maybe
Francesca
you
can.
S
You
know,
take
the
floor.
Actually,
you
know
represent
a
bigger
argument.
There
I
don't
know
because
I'm
fairly
we've
been
sort
of
kind
of
to
control
of
this
discussion,
but
maybe
the
next
time
I
just
want
make
sure
that
we
don't
have
within
this
effort.
There's
no
PR,
that's
sitting
there
or
discuss
and
keep
changing,
changing,
changing
changing
until
the
point
where
we
don't
even
remember
with
begin
right.
So.
A
S
Is
part
of
the
discussion
already
and
I?
Don't
think
if
francesca
road
is
pretty
extensive,
there
is
probably
take
another
hour
to
discuss,
but
I
would
really
like
to
and-
and
some
something
tells
me
a
lot
of
people
in
this
call
would
like
to
you
to
sort
of
bring
this
discussion
to
a
conclusion,
some
type
of
conclusion,
because
again
we're
not
discussing
it
release
that
that
will
happen
tomorrow,
we're
discussing
okay.
This
is
what
we
agree
on.
Let's
merge
that
this
is
what
we
didn't
agree
on.
S
Let's
discuss
it
next
time,
but
let's
take
the
starting
point
as
where
we
were
in
version
one
not
where
we
were
where
we
are
intermediary
and
all
of
a
sudden,
you
know
it's
a
different
way
of
looking
at
it.
Are
we
adding
or
are
we
removing
at
this
point
of
time
I'm
saying
we
added
something
that
I
believe
we
shouldn't?
So
let's
discuss
it
and
if
we
at
some
point
of
time
do
agree
that
we
need
to
edit,
then
we'll
edit.
We
have
plenty
of
time
to
do
that
at
this
point
of
time.
S
I,
just
don't
think
we
had
enough
discussion
enough
debate
to
come
to
any
kind
of
conclusion
about
any
of
those
methods
other
than
the
ones
that
represents
the
attributes
right,
so
any
adding
it
keeping
it.
There
is
not
the
right
way
of
looking
at
it.
We
can
we
we
want
to
do
this
clean
sheet
approach
where
we're
gonna,
add
things
based
on
you
know
technical
merits,
not
throw
everything
and
then
start
removing
things.
What
we
don't
really
need.
So,
okay,.
A
N
B
J
K
J
Q
Look
I
think
taking
the
flag
is
flying
is
a
good
idea,
because
we
just
got
some
new
information,
whether
a
cloud
event
is
a
user
type
or
not
and
some
other
things.
So
maybe
you
can
just
really
late
the
pool
request
and
make
some
new
assumptions
and
maybe
get
rid
of
the
previous
ones
so
that
we
can
progress
on
the
pool,
request
and
I
really
like
the
idea
of
having
map
of
attributes
from
the
C
sharp
version,
for
example,
and
I.