►
From YouTube: CNCF CloudEvents Meeting 2020-10-01
Description
CNCF CloudEvents Meeting 2020-10-01
A
A
D
A
G
H
A
It's
wonderful,
I
have
to
admit
I
keep
hearing
about
them.
Turning
on
security
features
or
all
these
other
conference
calls
and
stuff,
because
you
know
bad
things
happen
at
times
I
get
to
be
on
one
that
actually
does
something
weird
just
once
I'd
like
to
actually
see
it
for
myself,
not
that
I
actually
really
want
to,
rather
than
just
just
get
a
morbid
curiosity
kind
of
more
than
anything
else,.
F
B
F
K
A
No
see
see
that'd
be
different
right
because
that
then
you're
going
to
get
rid
of
some
really
sick
stuff.
But
you
know
stuff
that
you
got
from
a
cncf
call.
I
was
hoping
wouldn't
be
too
bad,
you
know
the
normal
stuff,
you
might
expect.
You
know
swearing
or
just
interrupting
or
even
even
porn.
You
might
almost
expect
but
clement.
It
sounds
like
you're
talking
about
stuff.
That's
even
more
disgusting.
F
A
A
A
All
right
not
hearing
any
excuse
me,
we
do
have
an
sdk
call
this
week.
Let
me
just
double
check.
I
don't
think
we
have
anything
on
the
agenda,
but
let's
just
still
see
yeah
nothing
on
the
agenda.
So
if
we
don't
have
anything
by
the
end
of
this
call,
we
may
just
cancel
that
call.
Although
I
do
wonder
whether
this
question
here
from
grant
is
an
sdk
issue
or
not
so
we'll
talk
about
that.
One
later
discovery
interop
not
this
week,
just
a
reminder:
we
did
agree
november,
2nd
for
interop.
I
I
So
I
want
to
thank
scott
nichols
also
for
saying
that
the
logo
looks
like
an
open
source,
usb
logo
that
was
funny
actually
but
other
than
that
from
the
spec
site
itself.
We
are
kind
of
trying
to
enforce
open
api
for
some
sort
of
a
service
invocation,
so
we're
going
through
that
and
trying
to
figure
out
if
we
should
start
preparing
or
not
for
the
kubecon
n
a
stuff
if
we're
getting
project
officers
again
and
stuff
like
that,
so
that's
it.
A
All
right
before
we
jump
into
ppr's
and
stuff
any
other
topics,
people
want
to
add
to
the
agenda
or
that
we
should
that
should
be
talked
about
before
this
all
right,
let's
jump
into
it,
wait
a
minute
okay!
So
this
one
is
for
me.
I
don't
want
to
vote
on
it
today,
even
though
it's
it
was
put
out
there
before
tuesday,
mainly
because
I
think
it
needs
a
lot
of
thought
put
into
it.
A
Basically,
what
I
did
is
first,
I
tweaked
the
asynchronous
text
to
make
it
a
little
bit
more
generic
there's
a
little
too
much
logic
in
there
about
what
to
do
in
certain
situations,
and
I
found
myself
repeating
text
that
really
was
already
described
in
the
synchronous
response
case.
So
I
basically
just
said
the
async
should
look
almost
exactly
like
the
synchronous
case,
you're
just
getting
the
results
from
a
different
endpoint,
so
I
tweaked
that
a
little.
Hopefully
I
didn't
mess
anything
up.
So
please
take
a
look
at
that.
A
I
did
change
it
so
that
post
can
take
a
list
of
services
instead
of
just
one
and
I'm
very
nervous
about
this,
because
I
think
doing
a
post.
One
at
a
time,
especially
if
you're
doing
some
sort
of
like
mass
import,
is
just
a
real
pain
in
the
butt.
I
think
having
the
ability
to
do
a
batch
upload
is
very
important.
A
However,
that
introduces
a
whole
bunch
of
interesting
problems
like
what,
if
one
of
them
fails,
you
know,
do
you
kill
the
whole
thing,
or
do
you
just
determine
or
just
say
that
one
failed
and
let
everything
else
go
through.
I
took
a
very
much
all
all
or
nothing
kind
of
approach
to
it,
because
I
didn't
want
to
get
into
partial
error
reporting
type
stuff,
but
even
aside
from
that,
you
then
have
to
figure
out.
Well,
how
do
you
tell
the
recaller
what
the
various
ids
are
for
all
the
things
that
were
created?
A
So
I
have
a
mechanism
to
return
that
in
the
response,
but
I
had
to
worry
about
whether
the
response
is
gonna
be
too
large
or
not,
because
then
you
get
into
pagination,
so
I
decided
to
go
with
just
returning
the
list
of
ids
in
the
same
order
which
the
post
came
in
on
so
lots
of
interesting
choices.
I
made
I'm
not
convinced
that
they're
all
necessarily
right,
so
please
look
that
section
over
in
particular,
I'd
like
to
get
some
feedback
on
it.
A
I
also
explicitly
pulled
out
the
support
for
import
to
be
separate
from
the
normal
put
and
post
operations.
I
think
before
this
pr
I
basically
said
you
could
do
a
put
or
a
post,
and
then
you
could
put
like
a
query
parameter
there
and
inside
that
same
description,
I
described
how
you
handle
import
versus
a
normal
post,
and
I
found
that
I
was
jumbling
up
the
text
a
lot.
I
thought
it
was
a
little
bit
hard
to
follow,
so
I
decided
to
pull
out
the
import
logic,
meaning
the
query
parameter
into
completely
separate
apis.
A
That
way
we
can
talk
just
about
import
separate
from
a
normal
put
or
post,
and
I
think
that
makes
it
easier
to
read.
Okay.
If
people
want,
I
can
obviously
scroll
through
this
and
and
and
talk
to
anything
in
particular.
But
let
me
just
go
ahead
and
stop
there
and
ask
if
there
are
any
high
level
questions
and
keep
in
mind.
Like
I
said,
I
don't
want
to
vote
on
this
today.
I
think
we
need
a
lot
more
thought
process
put
into
this.
Besides
just
this
quick
review,
so
let
me
pause
there.
A
A
F
F
It's
a
little
strange
to
me
and
I
would
rather
want
that
service
to
go
to
the
source
and
pull
so
I'm
not
sure
whether
I
like
the
whole
notion
of
kind
of
this
bull
push
at
all.
But
if,
if
but
that's
that's,
I
will
admit
that
that's
taste,
and
so
I
think
the
solution
you
have
here
to
say
there's
a
way
to
go
and
do
inserts
where
you
are
assigning
numbers.
And
then
you
do
effectively
replication
where
you
keep
the
all
the
numbers
where.
F
A
Okay,
that's
fine!
I
didn't
I.
I
did
notice
your
comment
about
the
the
push
versus
pull
and
I
thought
that
was
interesting
cause.
I
hadn't
thought
about
that.
Do
you
think
that
in
all
cases,
where
there's
going
to
be
the
equivalent
of
some
sort
of
batch
upload
of
stuff
that
the
discovery
endpoint
will
always
be
able
to
reach
out
to
the
to
the
source
of
that
bulk.
A
Yeah,
that's
the
one
thing
that
worries
me
about
that,
because
it
certainly
would
be
easier
if
you
could
pull
it
right.
They
don't
have
worry
about
partial
success
and
partial
failure,
type
stuff
right,
okay,
but
something
to
think
about
because
I
I
it
is
an
interesting
approach.
I
haven't
thought
of
okay,
any
other
comments,
questions.
A
Okay,
so
I'll
just
assume
people
need
time
to
review
it,
which
obviously
was
my
plan.
So
please
in
particular,
you
know
read
over
the
batch
stuff.
That's
the
part
that
worries
me
most,
I
think
most
everything
else
is
fairly
straightforward.
At
least
I
think
if
I
remember
correctly,
okay,
I'm
not
hearing
any
other
questions
comments,
we'll
move,
we'll
keep
moving
through
the
agenda.
C
A
Yeah
so
my
mind,
so
let's
ignore
the
import
case
for
a
sec.
In
my
mind,
I
keep
it
very
simple
to
me.
Post
is
for
create
and
put
is
for
update
okay,
because
if
you
ignore
the
import
case,
then
you're
when
you're
talking
about
a
brand
new
service
being
added
to
the
discovery
endpoint.
My
assumption
is
that
it
does
not
have
an
id
yet.
So
it's
a
brand
new
thing
and
you're
just
sticking
in
there
and
therefore
post
is
the
right
way
to
go
put
is
when
you
already
have
an
id
associated
with
it.
A
So
you're
just
going
to
be
updating
that
resource
now.
Import
throws
an
interesting
twist
into
that
whole
thing
right
because
with
import,
you
want
to
keep
the
id
that
you
had
before
and
that's
why,
as
part
of
my
pr
here,
the
difference
between
put
versus
post
for
import,
I
think,
is
very,
very
slim.
They're,
almost
the
exact
same
thing,
I
think
in
most
cases
and
that's
something
else,
that
I
wasn't
100
sure
to
be
perfectly
honest
and
the
reason
I
I
kind
of
did
it.
A
That
way
is
because
I
was
trying
to
make
it
as
easy
as
possible
on
the
user
of
the
system
right.
So,
for
example,
somewhere
in
here,
I
talked
about
how
on
a
post
for
yeah,
I
think
on
a
normal
post,
not
for
the
import
case.
You
you
can
include
an
id
and
an
epoch,
value
and
they'll
be
ignored
right,
even
though
they're
going
to
be
ignored.
A
I
want
their
life
to
be
easy,
so
I'm
not
sure
I'm
completely
answering
your
question,
but
those
are
the
kind
of
things
that
run
through
my
head,
as
I
was
going
as
I
was
writing
this
up
and
to
your
original
question,
though,
to
me
put
versus
post
is
create
versus
update.
That's
what
really
comes
down
to
it!
For
the
most
part,.
C
C
If
it's
the
client
that
needs
to
be
able
to
maintain
stability
of
that
id
across
a
set
of
masters,
then
the
the
notional
object
is
being
created
by
the
client
and,
of
course
put
is
item
potent,
and
so
I
can
put
that
id
over
and
over
and
over
again,
I
don't
end
up
creating
multiple
things,
even
when
I'm
doing
that
across
multiple
masters
and
in
a
distributed
scenario.
I
just
wonder
if
that
wouldn't
simplify
some
of
the
challenges
for
reconciling
and
things
like
that
and
and
yeah.
A
I
think
I
do
support
that
notion
where
basically,
what
you're
saying,
if
I
understand
you
correctly,
is
the
client
kind
of
picked
the
id
right,
and
I
think
you
can
do
that
today
with
what
I
have
here
even
through
a
put,
but
you
have
to
tell
us
it's
an
import
right,
because
by
default
I
I
assume
put
is
more
of
an
update.
So
if
the
object
doesn't
already
exist,
it's
going
to
give
you
an
error,
saying
you
know
404..
But
if
you
give
us
the
import
flag,
then
then
we're
basically
saying
okay
yeah.
A
And
and
of
course,
that
then
goes
into
some
of
the
stuff
I
mentioned
in
slack
around
the
stuff.
Right
as
I
was
coding
this
up,
I
kind
of
did
scott's
little
sample
that
he
showed
us
last
week
or
the
week
before.
Where
right
we
had
a
ring
of
discovery,
endpoints
each
treating
the
the
next
guy
in
the
chain,
as
is
upstream
right,
so
he
keeps
querying
his
list
and,
and
you
can
see,
services
propagate
through
the
ring.
A
Well,
you
know,
depending
on
how
you
choose
to
do
the
propagation
or
who
chooses
to
query
who,
at
what
point
in
time
you
can
get
into
really
weird
situations
where
somebody
deleted
a
service
from
one
endpoint,
but
then
that
that
service
doesn't
get
deleted
through
the
entire
ring.
Rather
it
gets
recreated
because
because
the
one
you
just
deleted
it
from
ends
up
queering
another
guy
that
says
hey
what
do
you
have
and
he
says?
A
Oh,
I
don't
know
about
that,
one
that
you
have,
because
I
don't
have
it
even
though
it
just
got
deleted,
so
he
ends
up
recreating
it
thinking
the
other
guy
recreated
it
or
the
other
guy
created
it
fresh
right.
So
you
get
into
really
weird
situations,
and
I
wasn't
I
don't
know
what
to
do
about
those
things
yet.
So
those
are
things
I
want
to
talk
about
at
some
point.
A
Okay,
so,
as
I
said,
please,
please
look
this
one
over,
I'm
not
so
much
concerned
about
getting
this
one
soon,
because
of
anything
other
than
I
want
people
to
know
what
to
code
up
for
the
interop,
because
I
know
people
are
very
short
on
time
and
very,
very
busy,
so
I'm
trying
to
keep
the
spec
changes
down
to
a
minimal
or
get
them
in
as
soon
as
possible.
That's
my
reason.
A
A
A
E
So
the
the
the
the
situation
is
that
it's
possible
to
receive
an
event
that
has
a
database
64
property,
indicating
that
the
data
itself
is
binary
and
has
a
data
content
type
of
application.
Json,
so
is
it
legitimate?
Is
it
against
the
spec
for
an
sdk
to
recognize
that
it's
binary
data
decode
the
binary
data
in
javascript
that
then
it
is
just
a
buffer
which
can
be
a
string,
and
I
can
then,
if
I
know
the
data
content
type
is
application
json?
I
can
parse
that
json.
E
J
But,
having
said
that,
I
don't
think
an
sdk
should
ever
produce
events
like
that,
because
that
doesn't
seem
to
be
in
the
spirit
of
of
of
the
spec
right,
whether
that
suspect
guidance-
I
don't
know,
but
I
think
for
completeness
it
should
accept
stuff.
That
looks
like
that
that
that
would
be
my
opinion.
A
F
Sorry,
I'm
I'm
not
good
with
the
end
and
raising
yeah.
So
that's
a
that's
a
legitimate
way
to
to
encode
anything
that
is
not
encoded
in
the
same
encoding,
so
I
mean
there's
jason
jason
needs
to
be
in
utf-8,
etc,
but
you
could
have
the
situation
where,
but
it's
representable
in
all
kinds
of
different
character
sets.
So
you
could
have
a
situation
where
the
outer
and
the
inner
character
set,
don't
don't
match
and-
and
the
same
is
true
for
if
you
want
to
carry
xml
data,
that
might
also
be
while
that's
text.
F
F
Something
is
wrong
with
my
network,
so
let
me
say
that
again,
so
if
you
find
that
the
the
binary
that
you
have
binary
and
you
have
a
an
encoding
for
the
payload
or
data
content
type
that
indicates
that
text,
then
you
run
that
through
a
character,
character,
encoding
or
decoder,
presumably
utf-8
unless
the
content
type
says
something
else.
And
then
you
deal
with
the
text.
So
that's
a
legitimate
representation,
just
as
just
as
data
is.
G
So
if
it
gets
a
message
in
binary
mode
and
has
to
determine
then
for
forwarding
it
in
structured
format,
it
sometimes
may
have
to
to
guess
or
apply
some
kind
of
heuristics
or
something-
and
I
discussed
this
with
ellen-
I
think
last
year
around
that
time,
and
so
there
might
be
cases
when
you
have
to
be
ready
to
to
receive
events
where
the
payload
is
either
in
binary
or
in
text
form
depending
on
the
heuristics.
The
according
sdk
has
applied.
D
L
D
F
A
F
H
E
And
and
like
in
the
spec,
it
says
you
know:
if
the
data
is
binary,
there
must
be
a
base
database,
64
property,
then
in
the
next
sentence.
If
I
remember
correctly
it's
the
next
sentence,
it
says,
if
there's
a
data,
property
and
data
content
type
that
is
of
a
type
that
the
sdk
knows
how
to
parse.
It
should
be
parsed.
So
as.
E
E
A
A
Json
is
interesting,
but
does
not
change
the
fact
that
this
thing
came
across
as
binary
data
and
therefore,
if
the
sdk
has
the
notion
of
of
of
a
binary
blob
just
being
passed
on
as
a
binary
blob,
then
it
should
as
the
bare
minimum
whether
it
then
tries
to
be
smart
and
say:
oh
because
the
content
data
content
type
is
application.
Json,
I'm
going
to
try
to
parse
this
as
json
and
then
pass
it
on
to
the
text
thing
or
as
a
json
object.
E
J
Another
side
issue
here,
I
believe
for
us
to
claim
compliance
with
this
spec
as
a
as
a
service
provider.
We
have
to
support
json
format.
Yeah,
that's,
I
think,
one
of
the
sort
of
ground
rules,
so
I
I
guess
it's
very
non-idiomatic
for
for
me
to
expect
us
to
be
able
to
process
json
payloads
where
jason
is
not
in
the
data.
It's
it's
been
funkily
put
into
some
base64
scheme.
J
A
A
Json
everything's
fine,
but
when
the
user
gets
that
data,
it's
going
to
be
a
json
object,
but
there's
really
no
guarantee
that
that
json
is
formatted,
the
exact
same
way
that
the
user
or
the
client
sent
it,
and
by
by
that
I
mean
spaces
and
everything
right.
So
what
if
the
use
case
here
is
someone
wants
to
guarantee
that
the
exact
formatting
for
their
json
payload
space
for
space
new
line
for
a
new
line
is
the
exact
same,
but
the
receiver
is
going
to
get.
E
E
A
J
J
J
L
J
F
I
I'll
observe
that
there
are
overwhelmingly
server
plumbers
in
here
and
we
try
to
be
really
smart,
there's
an
intent
expressed
by
the
publisher
of
that
event,
and
they
and
the
the
publisher
says
this
is
binary
and
and
then
they
use
the
data
content
type
as
the
hint
for
what
that
binary
contains,
and
that
hint
is
for
the
ultimate
receiver
of
that
event.
And
I
don't
think
the
middleware
has
any
business
in
fixing
with
that.
F
F
F
Yeah
absolutely
because,
because
we're
converting
we're
converting
from
we're
converting
this
into
binary
in
our
kind
of
in
in
memory
model,
that's
why
we
have
types
and
then,
if
you're
sending
this
on
as
as
http
as
an
http,
binary
type,
then
you're
just
mapping
the
binary
into
the
into
http
binary.
And
then
you.
G
G
G
J
Different
scenario:
well,
I
I
that's
an
interesting
scenario:
yeah,
because
when
it
when,
if
it
comes
in
in
binary
mode
and
it
wants
to
go
out
in
structured
mode,
you
know
you've
got
two
options.
Then
you
can
either
just
jam
it
into
the
binary
field
or
you
can
look
at
it
and
go.
Oh
it's
json.
Therefore
I
can
drop
it
in
the
data
attribute
directly.
A
F
F
The
yeah
we
can
for
that.
However,
we
can
leave
the
js
on
the
json,
spec
and
say
well.
Jason
is
exactly
what's
in
the
spec
and
then
and
whether
you
encode
that
as
binary
or
whether
you
encode,
that,
like,
like
the
the
preserve
character
by
character
thing
and
with
the
right
indenting,
is
not
json
right
that
is,
it
doesn't
preserve,
it
doesn't
preserve
the
the
new
lines
and
etc.
By
by
default,
you
can
reformat,
it's
still
the
same
document.
A
But
I
also
feel
like
the
center
of
the
class
is
talking
about.
There
is
almost
out
of
scope
for
us
in
the
sense
that
it's
really
up
to
that
piece
of
code.
That's
doing
the
conversion
from
binary
to
structure
to
make
that
decision
on
its
own
and
whether
it
made
the
right
choice
or
not.
Isn't
for
us
to
decide.
A
A
A
E
Incoming
message
with
database
64
set,
I
I'm,
I
think,
I'm
leaning
towards
that
too
doug
and
I
need
to
go
back
and
change
my
pr
that
that,
like
that,
well
someone
mentioned
earlier
the
intent.
I
think
it
was
you
clements
like
what
is
what
is
the
the
person
or
the
system,
that's
creating
an
event,
they're,
creating
an
event
with
a
certain
intent,
and
if
that
intent
is
that
the
data
is
binary,
it
doesn't
matter
what
the
content
type
is.
If
they
express
it
as
binary,
we
should
leave
it
as
binary.
L
L
L
L
M
J
J
You
know
the
those
sdks
that
are
facing
the
client
or
the
application
code
are
not
going
to
try
and
monkey
around
with
representations
to
that
extent
yeah
and
then,
when
you
have
these
translation
or
transformation
scenarios
of
structured
to
unstructured
or
whatever
structures,
a
binary
role.
Sorry,
that's
where
these
sort
of
principles,
I
think
come
into
play.
B
A
B
H
A
Okay-
okay,
this
one,
this
one,
the
first
grant
you're
on
right,
yeah
so
grant
when
you
first
opened
this
one.
I
thought
this
was
going
to
be
a
trivial
thing
that
I
could
treat
as
a
typo
grant.
Why
don't
you
introduce
this
one,
because
I'm
not
convinced
which
way
to
go
on
this
one?
So
I'll?
Let
you
talk
to
it.
H
Otherwise,
if
it's
data,
then
it
must
be
in
data,
so
I
thought
it
made
a
little
bit
more
sense,
especially
in
the
first
case
where
data
is
not
in
in
my
code
quotes,
because
I
think
it's
trying
to
represent
data
in
terms
of
just
the
concept
of
a
cloud
event:
data
field
which
might
be
in
base64
and
so
so
yeah.
I
made
the
pr
to
remove
the
quotes
because
we
also
use
the
code
quotes
right
after
and
the
member
name.
G
Yeah,
so
I
think
that's
actually
just
a
leftover,
because
data
was
an
attribute
earlier
and
I
think
in
the
last
weeks
before
we
we
did
the
1.0
release.
I
rewrote
some
of
this
to
make
it
clear.
Maybe
I
just
it's-
it's
probably
really
just
a
leftover,
and
I
agree
that
this
change
makes
it
a
bit
more
clear.
C
A
A
Okay,
thank
you
all
like
I
said.
I
don't
know
why
this
one
got
me
concerned,
but
I
wanna
make
sure
I
didn't
just
blindly
accept
it.
Okay,
just
double
check
you
open
this
one.
When
did
you
open
this
18
hours
ago?
Tell
you
what
yeah
I'll
wait
till
friday
to
make
sure?
No
one
else
brings
up
any
issues
with
it
since
technically
it
was
opened
up
after
tuesday,
but
if
no
one
mentions
anything
by
friday,
we'll
go
and
emerge
it.
Okay.
A
F
Yes,
I
actually
made
a
comment
today
into
this
into
the
pr.
I
imagine
that
I
did
some
work
there.
We
go
there
we
go.
That
was
this.
Oh,
he
already
made
change
amazing.
So
I
said
I
I
think
last
time
we
discussed
this.
I
said
this
section
seems
a
little
iffy
and
I
still
think
it's
iffy
to
have
different
sub
protocols
for
different
encodings.
F
F
You
can't
give
any
of
the
fancy
other
headers
and
you
can't
say,
here's
the
extension
and
that's
what
I
would
usually
use,
but
you
can
really
only
give
a
protocol
so
they
have
the
websocket
interface.
That's
in
the
browser
is
dumbing,
this
down
quite
a
bit,
and
so
that's
really
our
only
option
to
go
and
make
wishes,
and
so
you
would
in
this
interface
you
would
say
I'm
willing
to
use
the
protocol
cloudevents.json,
comma
cloud
org,
yes,
convention
jason,
come
on
cloud
events,
dot,
avro
and
then
the
the
server
will.
F
B
F
So
frame
type
text
and
battery,
so
that
was
that's.
What
I
was
looking
for
so
now,
I'm
now
be
would
be
happy
with
with
the
spec
as
it
is.
That
was
my
only
only
objection
to
that.
The
rest
is
basically
just
the
the
necessary
things
you
have
to
say
to
you
know,
make
the
mapping
work
it's
it's
really.
Just
ultimately,
it's
just
you
know,
put
structured
events
onto
websocket
frames
and
the
rest
is
all.
A
D
Yeah,
I'm
happy
too
so
when
I
read
through
it
actually
today.
Sorry
about
that,
I
was
wondering
why,
first
of
all,
what
do
you
mean
by
all
implementations
so
was
it?
Was
it
meant
to
be
the
client
and
the
server
side
or
the
intermediary
or
whatever
is
meant
by
this?
But
I
think
this
is
a
phrase
which
comes
from
the
other
protocol
bindings
as
well,
and
then
the
second
thing
was:
why
does
the
json
event
format
is
necessarily
to
be
supported.
B
D
D
F
D
B
A
D
A
A
A
Oh
I'm
sorry,
no
phrases
right
for
optional
attributes.
In
almost
every
single
case
we
say
if
it's
present,
it
can't
be
things
like
a
non-empty
string,
which
implies
it
can't
be
null
and
all
the
required
attributes
are
defined
to
be
values
that
can
never
be
the
null
value.
For
example,
timestamp
can't
be
null
it
has
to
conform
to
some
rfc,
or
something
like
that.
A
So
I'm
not
sure
this
is
actually
an
issue,
but
I
wanted
to
bring
this
up
because
I
think
clemens
and
klaus,
you
guys
and
lance
too
you
guys
all
had
comments
on
this
space.
So,
let's
I
wanted
to
get
a
brief
discussion
on
this
to
see
what
bitterway's
thinking
who
want.
Does
anybody
want
to
go?
First,
I.
M
L
L
F
What
so
see
when
you
have
you
have
strongly
typed
schemata
schematized
records
like
in
the
database
or
or
in
the
programming
language.
The
the
way
how
you
say
there
is
no
value
in
this
thing
is
no,
so
that's
that's.
How
that's
how
I
look
at
it
like
you
create
a
cloud
you
create
a
database
table
that
contains
a
cloud
event
right.
The
only
way
how
you
can
say
that
field
has
no
value
is
by
putting
it
all
into
it,
but.
L
No
sorry
like
it's
it's
a,
I
don't
know
how
to
handle
nils
in
properties
because
the
the
cloud
event
spec
says
it
must
be
a
thing.
It
must
have
a
value,
and
it's
not
the
string
nil,
that
I'm
getting
it's
it's
the
the
json
nil
which
doesn't
translate
like
that's
that
translates
to
a
null
pointer
in
go.
F
Yeah,
but
you
since
so
you
can
treat
if
if
the
value
is
absent,
you
can
trade
the
the
indicator.
Now,
as
you
put
as
you're
pulling
the
value
off
the
wire,
you
will
see
that
in
the
json
there
is
a
is
a
null
value,
which
means
you
can
go
and
ignore
that
field
completely.
You
don't
have
to
map
it
into
anything
in
your
in
your
in
your
goal.
In
memory,
representation.
J
L
B
L
J
A
F
But
if
you
say
nobody
said
anything
here,
which
means
the
field
is
absent,
you
use
now
we
have
the
special
we
have
now
special
case
in
in
some,
and
the
same
is
true
for
for
would
be
true
if
we
were
expressing
our
events
in
strongly
typed
in
in
proto
or
an
avro
any
of
those
those
models
which
prefer
strong
typing.
We
made
other
choices
here
because
we
want
to
have
the
flexibility,
but,
but
otherwise
just
knowledge
says
it's
not.
There.
M
Yeah,
I
I
think,
the
more
restrictive
we
are
in
our
client
implementations,
the
more
assumptions
we're
making
about
how
all
of
the
upstream
producers
work-
and
I
I
think,
just
for
robustness
sake-
I
would
prefer
to
make
them-
handle
these
cases
as
gracefully
as
possible
unless
there's
a
really
good
reason
that
we
can
quantify
that
something
like
you
know
this.
This
is
going
to
create
more
garbage,
I'm
not
convinced
of
that,
but
I
just
prefer
to
earn
the
side
of
handling
these
cases
gracefully
than
being
draconian.
A
Okay
and
with
that
we're
gonna
have
to
call
it
a
day
on
that
one,
obviously
it's
not
over
yet
we'll
have
to
discuss
it
because
I'm
either
way.
I
think
we
may
need
to
put
something
into
the
spec
or
primer
to
talk
about
this
particular
case,
whether
it's
to
reinforce
what
some
people
believe
is
ordinary
spec
or
it
needs
to
loosen
things
up
to
allow
for
null
be
to
be
interpreted
as
empty.
I
think
something
may
need
to
be
said,
so
that's
it's
a
good
thing
that
someone
brought
it
up.
A
A
A
A
Excellent
and
usual,
I'm
not
sure
how
to
pronounce
that
I
apologize
if
I'm
butchering
it
yeah
hey,
that
is
perfect,
yeah!
Okay!
This
is
the
first
time
I'm
joining
cool.
Well,
welcome,
which
company
are
you
with
by
the
way?
Sorry?
Which
company
are
you
with?
If
you
want
to
be
associated
with
the
company
yeah.
A
A
I
don't
know
about
that.
You
guys
are
much
nicer.
Put
it
that
way.
Okay,
so
if
you're
not
interested
in
the
sdk
call
feel
free
to
drop,
have
a
good
rest
of
your
day
and
then
actually,
I
should
ask,
while
we're
switching
over
where's
my
sdk
thing
here
we
go
so
do
we
have
any
other
topics
to
talk
about
on
the
sdk
call,
because
if
not,
we
can
end
the
call
really
quickly.
D
B
D
A
H
Okay,
yeah
so
just
for
context,
so
I'm
I'm
working
on
creating
lots
of
samples
for
using
cloud
events
with
a
new
api
and
in
our
documentation
like
we
have
a
lot
of
copy
and
pastable
samples,
different
programming
languages,
so
folks
can
get
started
and
yeah.
Some
of
these
samples
use
the
sdk
some
don't
for
various
different
reasons,
and
I
noticed
like
with
the
sdks
themselves.
H
Some
of
the
repos,
like
javascript,
ruby
python,
have
like
full
samples
in
the
start
that
you
can
just
copy
and
paste
and
get
started,
especially
if,
like
you
don't
know
about
cloud
events
or
are
it's
sort
of
not
not
the
focus
of
the
product,
but
some
sdks
don't
so
I
was
wondering
like
do
we
want
to
consistently
like
have
samples
in
our
readme?
Should
I
point
developers
to
our
readmes,
or
is
that
really
not
the
best
place
so
yeah
they're
trying
to
get
thoughts?
H
H
K
K
A
H
B
H
That,
like
the
last
bit,
was
sort
of
good
summary
of
like
well,
where,
where
do
we
want
these
samples
to
live?
It's
like
yeah,
so
google's
gonna
have
our
own
documentation
of
like
how
to
get
started
with
a
hello
world
basic
minimal
sample
or
or
can
we
have
like
some
of
these
hello
world
samples
be
in
the
sdk
themselves.
A
K
L
B
K
K
So
it's
more
so
it's
more
like
you
know,
do
we
have
like
a
standard
for
our
readmes
rather
than
you
know,
we
guess
we
can
request
specific.
You
know
things
import
in
individual
pull
requests,
but
if
we
don't
have
an
overall
expectation,
then
you
know
individual
pull
requests
can
go
out
of
date.
They
can
be
inconsistent.
Can
we
can
we
coordinate
all
of
this?
I
guess.
H
This
issue
so
yeah,
I
created
a
github
issue
and
then
provided
like
some
sample
code
of
what
down
below
like
of
what
would
be
nice,
but
I
guess
it
depends
like
yeah.
I
guess
it
depends
on
like
what
we
want.
I
mean
do
we
want,
but
I
I
guess,
should
we
assume
some
proficiency
in
like
the
programming
language
or
like
getting
started.
H
H
A
So
so
grant
I
use
so
grant.
Are
you
suggesting
that
while
we
have
picking
on
the
go
sdk
it
well,
we
have
samples
in
the
go
sdk
and,
as
scott
said,
maybe
there's
some
additional
documentation
needs
to
be
created.
Are
you
saying
that,
while
those
are
nice,
it
would
be
better
to
have
in
the
actual
main
readme
full
snippets
of
code
itself.
H
B
A
L
L
L
A
Because
I
I
just,
I
find
it
hard
to
believe
that
if
you
open
up
an
issue,
sorry,
if
you
open
up
a
pr
to
add
additional
documentation
someplace,
I
can't
imagine
one
of
the
sdks
would
actually
say
no.
Unless
the
argument
is
well,
it's
not
necessarily
appropriate
to
put
all
that
into
a
readme
as
opposed
to
a
dedicated
samples
directory
like
scott
was
pointing
to.
I
could
see
an
argument
there
right.
You
don't
read
me
to
get
too
big
or
something
right.
H
L
B
A
Yeah
I
mean
well
what's
interesting,
though
is
I
mean
there
is
one
thing
I
I
remember
for
you
for
sure
whether
it
was
you
or
daniel
said
something
along
the
lines
of.
Should
there
be
some
consistency
across
the
sdks
and
in
general,
you
know.
Consistency
is
nice
sure
whether
we
need
to
be
formal
about
it
and
say
in
the
sdk
dot
markdown
document
says
every
sdk
must
have
xyz
in
this
particular
order
or
this
particular
format.
A
We
could
certainly
explore
that
as
an
option,
if
that's
what
people
want,
but
I'm
not
sure
whether
whether
that's
reducing
the
freedom
that
each
sdk
team
wants
to
do
the
right
thing
for
their
own
project.
Now,
if
we
come
across
one
sdk,
that
is
slacking
and
they
have
poor
documentation,
poor
examples
and
the
things
completely
unusable,
except
by
the
people
that
wrote
it.
Then
I
think
that's
a
separate
issue.
We
should
bring
that
up
and
say
this
guy,
you
know
say
you
know
guys.
This
is
not
being
maintained
properly.
A
Something
needs
to
happen
here,
but
whether
we
need
consistency
across
the
sdks,
that's
something
worthy
of
a
discussion.
I
just
don't
know
whether
any
how
people
feel
about
that.
I
mean
do
people
feel
like
we
need
to
have
that
level
of
consistency
across
the
stks
relative
to
documentation
and
samples.
H
F
A
H
I
guess
like
from
a
user
perspective,
if
we
link
called
it
like,
I
guess,
when
we're
preparing
docs,
we
were
just
linking
to
the
sdk
readmes
for
getting
started,
and
I
don't
think
that
would
provide
like
a
uniform
experience
right
now.
But
but
I
mean
the
more
I
think
about
this-
I
think
I
don't
think
there
needs
to
be
really
any
changes.
A
Okay,
because
because
because
my
suggestion
would
be
two
things,
one
is
if,
as
you
said,
you
you
guys
want
to
point
to
the
sdk
readme's
as
the
place
to
offer
documentation.
So
you
guys
don't
have
to
duplicate
it
inside
google,
and
that
makes
perfect
sense
to
me.
So
if
one
particular
sdk's
readme
or
samples
or
we
want
to
call
it,
isn't
good
enough
for
a
novice
to
come
in,
and
I
think
that's
a
problem
in
general
and
we
should
get
prs
opened
against
those
sdks
to
beef
up
their
documentation
and
samples.
A
I
think
once
the
sdks
are
at
an
appropriate
level
right
where
they're
all
good
enough,
then
I
think
it's
fair
to
come
back
and
say:
hey
I've
been
looking
at
all
the
sdks
and
they
all
kind
of
had
the
same
information,
but
they
presented
in
a
very
different
way,
and
this
isn't
a
language
difference.
This
is
a
stylistic
difference,
or
this
is
some
have
you
know
samples
embedded
in
the
readme?
A
I
think
we
should
have
a
consistent
approach
and
here's
my
proposal
to
be
consistent.
What
do
you
guys
think
about
being
consistent?
All
the
sdks,
but
I
think
it's
it'd
be
fair
to.
I
think
it'd
be
fair
to
have
that
discussion
after
we
do
the
first
step,
which
is
make
sure
each
sdk
at
least
have
has
appropriate
level
of
documentation
in
their
readme
right.
So
if
I
were
you
I'd
focus
on
that
first,
so
you
guys
don't
have
to
duplicate
it
in
google.
A
A
Because
I'm
not
hearing
a
whole
lot
of
excitement
about
out
of
the
gate,
mandating
consistency
across
sdks
and
I
think,
if
you
wanted
to
get
there,
we
may
be
able
to
get
there
at
some
point
in
the
future.
But
I
think
we
first
need
to
take
the
first
step
of
forget
about
consistency.
Do
we
even
have
the
right
documentation
right?
Even
if
it's
inconsistent.
A
Yeah,
I
don't
think
hopefully
no
one
wants
that,
but
at
least
yeah,
but
if
one
sdk
went
really
farther
than
all
the
others
in
terms
of
educating
people
like,
for
example,
let's
say
they
did
that
insane
thing
and
I
said:
hey
I'm
going
to
teach
you
java
right
then
at
least
we
can
look
at
that
sdk
and
say
man.
Those
guys
are
nuts
that
they
did,
that
there's
no
way
in
heck.
We're
gonna
do
that
for
go,
or
we
could
look
at
that
and
say
hey.
You
know
what
we're
getting
tons
of
praise
from
java.
A
We
should
do
that
for
all
of
them
right,
but
at
least
at
least
then
we
can
have
a
discussion
and
compare
the
sdks,
because
they're
inconsistent
and
say
you
know
what
let's
make
them
more
consistent
and
what
they
did
over.
There
is
really
really
good,
and
we
have
concrete
example
of
something
to
look
at
right
now.
I
don't
feel
like
we're
at
that
point
to
even
have
that
discussion.
A
I'd
rather
focus
on
the
immediate
problem
of
is
the
documentation
in
any
particular
sdk
good
enough,
and
if
not,
let's
get
someone
to
open
the
pr's
to
fix
it
and
so
grant
that's.
Why
I'm
coming
back
to
you
and
say:
look
if
you
found
as
you're
doing
your
work
that
some
particular
sdk
if
their
documentation
is
not
good
enough
open
some
pr's
against
that
to
get
that
fixed
and
not
necessarily
worry
about
your
higher
order,
question
of
consistency.
H
L
H
L
F
Very
rarely
and
yeah,
I'm
not
I'm
not
sure.
I'm
not
sure
this
would
help
me
all
that
much
because
I
would.
I
would
rather
have
a
snippet
that
that
explains
how
that
works,
and
then
I
would
if
I
didn't,
have
a
sample
to
look
for,
and
I
would
always
look
for
the
samples
then
I
would
go
and
just
create
a
baseline,
go
app
somewhere
else
and
and
then
go
and
try
to
try
to
put
that
in.
F
A
So,
graham,
maybe
you
should
do
a
pr
to
show
what
you're
thinking
of
in
terms
of
how
to
change
the
golang
sdk,
whether
it's
just
a
you
know,
large
change,
the
readme
or
whether
it's
a
tutorial
directory.
They
that
that
really
handle
the
person
from
nothing
to
a
friend
and
go
program.
And
you
point
to
that
from
the
readme.
You
know.
That's
your
call,
but
maybe
a
pr
would
help
solidify
the
discussion
and
make
it
less
abstract.
F
F
That's
perfectly
fine,
but
then
it
should
be
possible
for
any
any
of
the
three
of
them
to
go
on
vacation
and
nominate
someone
else
who
can
go
and
do
the
work
or
you
know
if
they
get
sick
or
whatever,
so
that
there's
still
three
people
from
google
being
able
to
go
and
work
on
this.
That's
that's
my
that's!
That's
the
goal
that
I
have
here.
B
A
F
There
was
a
yeah,
so
he
is
he.
He
wanted
things
to
be
a
little
bit
more
like
apache,
and
I
think
he
mostly
misunderstood
my
intent
that
I
had
like
I
didn't
want
to.
I
didn't
want
to
make
it
like
one
company,
one
developer,
that's
I
think
that's
what
he
understood
and
because
he
said
you
know
I
didn't
have
I've
had
a
hard
time,
finding
traction
with
others.
F
What
I
wanted
to
what
what
I
don't
like
about
the
apache
model
is
that
a-
and
this
is
what
happens
in
the
apache
project-
is
that
some
vc
funded
company
shows
up
and
rotates
their
entire
staff
through
the
project
and
now,
even
though
only
four
people
are
factually
working
on
it,
they
have
a
super
majority
of
50
people
with
committer
status,
who
will
go
and
basically
just
dominate
the
project
on
votes,
and
so
that's
something
that
I
want
to
that.
That's
something
that
I
would
avoid.
A
F
A
Okay,
so
let
me
ask
you
this:
in
your
particular
case,
what
was
the
guy's
name,
josh
right,
josh
love
what
would
be,
and
I'm
not
I'm
not
necessarily
pushing
back
what
you're
suggesting
I'm
just
playing
devil's
advocate
here.
What
would
be
wrong
with
saying,
okay
josh?
I
need
you
to
take
over,
go
ahead
and
start
submitting
a
whole
bunch
of
pr's
as
necessary
to
get
the
job
done
and
you
come
in
as
the
basically
one
of
the
only
maintainers
in
there.
A
F
B
F
Where
projects
accumulate
maintainers,
which
then
also
translates
into
kind
of
voting
rights,
kind
of
on
on
contested
issues
where,
if
you
can
stop
the
project
successfully,
and
you
can
have
80
people
on
it,
just
by
rotating
people
through
everybody
has
then
then
retains
maintainer
status
and
all
of
a
sudden,
they
have
a
super
majority
where
they
can
cancel
out,
particularly
smaller
entities
and
smaller
entities
might
quite
well
be
because
we
amongst
us,
middleware
people
right
there
are
no.
There
are
no
5
200
developers
in
in
microsoft
who
are
caring
about.
F
F
A
vc
funded
startup,
which
is
making
eventing
or
messaging
their
only
thing
and
our
2000
people
right
and
so
so,
even
even
though
we're
at
the
trillion
dollar
company,
you
know
we
we
run
there.
We
run,
we
run
far
tighter
ships
on
those
things.
So
there's
there's
a
there's,
a
there's,
a
natural
ill
distribution
and
then-
and
then
individuals
are
even
in
a
worse
situation,
because
they
they
I
mean
they
try
to
contribute.
F
F
A
A
Now
it's
gonna
in
our
past
standards
days.
It
was
always
the
exact
opposite
right.
It
was
always
ibm
microsoft.
The
worlds
would
dominate
those
groups
and
and
now
we're
hearing
about
little
startups
doing
it
to
us.
It's
just
amusing,
but
I
also,
but
I
also
agree
with
you
that
I've
always
thought
that
that
there
should
be
some
rule
for
maintaining
your
maintainership
right.
Like
you
have
it,
you
know
you
at
you
earn
a
certain
rpr's
means
you
get
to
be
nominated
to
be
a
maintainer.
A
F
A
Okay,
so
let's
get
a
little
more
concrete
here
in
terms
of
the
problem,
so
it
seems
to
me
we
may
need
to
take
the
situation
into
account
and
I
don't
know
how
we're
going
to
do
it
in
terms
of
changes
to
the
governance
talk,
but
it
does
seem
like
the
situation
you
brought
up
is
valid
and
unless
someone
on
the
call
or
in
the
group
like,
I
should
say,
veeamily
disagrees
insane
wants
to
say
clemens
you're
full
of
it.
If,
if
josh
wants
to
be
a
maintainer,
he
needs
to
do
this
time
and
do
prs.
A
Unless
someone's
going
to
say
that,
then
I
think
we
need
to
figure
out
some
way
to
accommodate
this
type
of
situation
and
there's
two
things
about
that.
That
I
think
we
need
to
think
about.
One
is
changes
to
the
governing
stock
and
how
to
deal
with
the
sort
how
to
deal
with
situation
immediately
because,
as
you
said,
you
need
to
get
this
off
your
plate
now
right
and
you
may
honestly
need
to
wait
for
a
government
stock
change.
A
L
A
E
A
E
E
A
K
A
Okay,
okay,
so
let's
do
this
since
we're
out
of
time
and
I'm
getting
really
hungry
for
lunch.
Let's
do
this
just
to
make
sure
okay,
so
I
would
say
this
right
so
technically
we're
not
following
the
rules
here
and
I'm
hearing
that
people
are
okay
with
that,
because
this
is
a
not
only
a
special
case.
It
makes
sense
whatever
you
want
to
call
it.
So
let
me
do
this.
Let
me
post
a
comment
in
the
sdk
slack
channel,
saying,
explain
the
situation
saying
it
at
least
for
this
particular
case.
A
It
makes
sense
and
if
I
don't
hear
any
objection
by
say
end
of
day
friday
that
we're
going
to
go
ahead
and
make
joshua
maintainer
in
the
c-sharp
sdk.
However,
we
also
need
to
then
look
at
changing
the
governance
dock,
because
I
don't
like
the
idea
of
the
governing
stock
not
being
accurate
to
match
reality.
Okay
and
so
I'd
like
to
then
have
us
work
on
an
update
to
the
government
stock
to
allow
for
these
types
of
situations,
and
it
could
be
as
simple
as
hey.
B
A
A
Okay,
anything
else
you
guys
want
to
talk
about
on
today's
call
anybody
else,
all
right
cool.
We
are
done.
Thank
you
guys
and
we'll
talk
again
next
week.
What's
for
lunch,
I
have
no
clue
food
at
this
point
I'll,
take
anything
all
right!
Thank
you
guys,
we'll
talk
again
next
week
have
a
good
one.
All.