►
From YouTube: CNCF Serverless WG 2020-05-28
Description
CNCF Serverless WG 2020-05-28
B
E
F
G
I
E
In
comments,
while
we're
waiting,
I'm
getting
hanging
from
the
scene,
see
of
folks
who
are
running
one
of
the
conference's
in
Japan
I,
don't
know
which
one
it
is
actually
may
not
be.
Cn
CF,
maybe
still
gonna
condition.
One
I
don't
know
one
of
the
guys.
They
keep
thinking
me
asking
me
whether
we
want
to
do
a
maintainer
session.
Obviously
that's
the
usual
thing.
E
You
know,
there's
a
deep
dive
and
as
an
intro
I
was
thinking
about
saying
yes
and
just
just
doing
the
intro
that
we
were
thinking
about
doing
for
the
coup
Connie,
you
yeah,
if
it's,
if
it
ends
up
being
at
a
time
slot
that
you
can
make
do
you
want
to
present?
If
you
can't
that's
fine
I
can
do
it
myself,
but
I
just
wondering
if
you
wanted
to
be
considered
to
present,
if
it,
if
the
time
zone,
if
the
time
slot
works
for
you,
so
that.
F
E
A
E
E
E
E
E
E
E
Alright,
sick
update,
no
update
as
of
right
now,
if
anything
happens
that
I,
let
you
guys
know
SDK
call,
so
we
do
have
a
call
after
this
one.
Just
let
you
guys
know
who
would
normally
join
that
I,
don't
believe
slinky
is
gonna,
be
able
to
join
us
just
so
you
guys
know
I
think
some
of
the
issues
may
revolve
around
him,
so
those
would
have
to
wait,
but
we
could
slow
see
what's
on
the
agenda.
Alright,
workflow
Timur.
L
A
E
All
right,
in
that
case,
a
couple
of
hopefully
smallish,
PRS
I,
believe
this
one's
mine
I
just
noticed
that
subscriber
or
event
subscriber
is
actually
not
used
in
the
spec
right
now.
This
is
in
Discovery,
so
I
just
wanted
to
do
a
little
cleanup
and
remove
it.
Obviously
we
can
add
it
back
in
if
we
do
want
to
talk
about
at
some
point,
any
comments
on
that.
M
E
E
Oh
I
see
what
I
did
I
apologize.
Yes,
so
for
the
most
part,
what
I
was
doing
here
was,
on
certain
terms,
I
added
a
pointer
to
the
connivance
spec.
If
it's
a
duplicate
definition
from
that
spec
I
tried
to
make
sure
the
texts
the
same
but
I
also
added
language
here
that
talks
about
how,
if
it
is
copied
from
that
other
spec.
E
If
for
some
reason,
there's
a
difference
between
the
two
definitions,
the
cloud
of
inspect
takes
precedence
in
terms
of
the
definition,
and
the
reason
this
jumped
out
of
me
is
weird,
as
I
forgot,
I
actually
did
some
reordering
of
the
terminology
itself,
I
decided
to
present
in
the
Orion.
That
was
there,
which
looked
a
little
bit
random
to
me
and
I
apologize
if
it
wasn't,
but
it
looked
that
way
to
me.
I
tried
to
make
it
in
the
order
of
from
the
server
back
to
the
client
perspective.
E
So
you
start
out
with
service
and
source
producer
intermediary
consumer
kind
of
thing,
just
to
get
a
little
bit
of
a
flow
there
for
I
thought,
better
understanding,
but
I
think
that's
about
it
now
and
I
had
to
fix
the
link
checker
today
to
cast
that
new.
This
funky
formatting
thing
I,
don't
think,
is
any
semantic
change
in
here.
It's
more
syntactical,
mainly
just
adding
these
little
pointers
to
the
cloud
of
gun,
spec
any
questions
or
concerns
about
that.
E
Okay,
thank
you
this
one
actually
should
apologize
for.
This
I
should
have
actually
done
this
before
we
merge
the
other
PR
for
the
provider
service
change.
This
actually
just
goes
through
the
rest
of
the
spec
and
gets
the
other
provider
uses
two
usages
and
converts
them
to
service
strictly
synced
ethical
change,
I
believe
I,
don't
think
I
did
anything
with
semantic
change
unless
I
just
really
screwed
up
and
messed
up
any
questions
or
concerns
about
that
any
objection.
E
Okay,
thank
you
all
right.
Okay,
just
want
to
bring
this
to
your
guys,
attention,
cuz,
slinky,
pointed
or
binding
yesterday
to
mention
he
did
update
this
PR
I
think
he
updated
it.
A
couple
days
ago,
though,
23rd
yeah
been
there
I
guess
three
days
ago.
So
technically
it
could
be
reviewed
and
voted
on
today,
but
I.
Don't
think
anybody
noticed
so
I
wanted
to
bring
it
up
to
everybody's
attention
today
to
take
a
look
at
this
when
you
get
a
chance,
this
is
a
change,
I
believe
in
the
cloud
events.
E
Space
just
wants
to
add
a
streaming
proposal
for
Jason.
So
take
a
look
at
it
when
you
get
a
chance.
Well,
talk
about
in
a
future
call.
Obviously,
if
you
have
questions
or
comments,
go
ahead
and
mention
it
in
the
PR
itself:
okay,
but
he's
out
on
the
call
to
take
any
questions
but
I
guess
if
someone
wants
to
raise
one
right
now,
you're
welcome
to,
and
maybe
someone
else
can
answer
it.
E
F
I
yeah
yeah
there
are
so
I
mean
I'm
I'm,
expecting
there
to
be
a
few
more
runs
of
discussions
that
have
refrained
from
updating
the
documents
before
this
call,
because
there
are
outstanding
questions
and
I
want
I
didn't
want
to
override
them
with
you
know,
then
it's
easy
to
lose
track
on
github
once
you
do
significant
changes,
so
on
so
I
acknowledged,
I
acknowledge
things
where
I'm
gonna
make
changes
with
thumbs
up
and
most
many
of
yours
and
then
I
made
some
other
further
comments
so
yeah.
This
is
what
this
does
is
affect.
F
File
store,
if
you
will
for
schema
documents,
so
the
idea
is
that
schema
documents
are
typically
text.
Text
documents
schema
formats,
maybe
by
but
they're
of
the
rarer
kinds,
and
this
basically
has
a
structure
where
you
have
a
schema
group,
which
is
a
organizational
bracket
around
the
set
of
schemas
that
are
typically
belonging
to
an
application
or
to
a
particular
topic,
and
the
reason
why
the
schema
group
exists
we're
driving
this
from
from.
So
this
this
this
proposal
doesn't
come
from
thin
air.
F
And
also
to
create
you
know,
a
notion
of
separate
in
a
global
registry
for
applications
and
potentially
even
tenancy,
and
then
inside
of
that
schema
group
we
have
schemas
and
schemas
are
that
they
can
be
concrete.
So
there
I
have
a
note
in
here
at
the
start,
and
then
we
should
go,
probably
go
and
take
a
look
at
the
note.
F
First
I
have
this:
if
you
go
scroll
a
little
further
down,
there's
this
nodes,
so
there
are
two
ways
and
I've
implemented
effectively
both
of
those
ways
in
this
proposal
and
they
can
go
together,
but
we
can
also
just
opt
for
one
where
either
there's
two
ways
to
look
at
a
schema.
You
can
go
and
look
at
the
schema
as
a
concrete
document
and
basically
have
a
schema
for
I'm
gonna
make
this.
Let
me
make
this
concrete.
You
have
a
schema
that
is
for
storage
events
Avro.
F
So
the
entity
is
really
an
abstract
concept,
where
you
have
an
event
of
some
sort,
the
body
of
an
event
in
our
case
of
some
sort,
but
that
body
of
an
event
can
really
is
an
abstract
data
data
structure
and
that
data
structure
can
now
be
rendered
in
multiple
ways.
So
it
can
be
rendered
in
Jason.
It
gave
me
the
rendered
in
XML.
It
can't
be
rendered
an
Avro.
F
It
can
be
rather
than
protobuf
and
so
schema
in
that,
in
that
view
really
represents
the
abstract
data
structure,
and
so,
instead
of
managing
documents,
you're
really
managing
managing
the
schemas
that
define
the
representations
of
that
abstract
data
structure
and
the
abstract
data
structure
is
the
thing
that
gets
versions
here.
See
the
abstract
data
structure
is
something
that
exists
not
in
this
registry,
but
exists
effectively
as
a
document
somewhere
else,
and
here
you're,
just
managing
the
the
the
the
the
schemas
that
belong
to
it.
F
So
so
in
that
way,
so
in
that
in
that
in
that
world-
and
this
is
case
one
here-
it's
a
truly
it's
a
restful
service
in
the
sense
that
you
can
go
and
apply
multiple
schema
documents,
which
means
multiple
representations
or
to
a
meta
meta.
The
meta
descriptions
effectively
of
a
data
structure
under
the
same
version.
Well,
you
simply
are
doing
a
put
on
the
version
number
with
a
content.
F
Type
of
you
know
for
the
appropriate
media
type
for
the
JSON
schema,
the
appropriate
media
type
for
an
a4
schema,
the
appropriate
media
type
for
an
XML
schema
and
all
of
those
under
the
same
version
describe
the
same
exact
same
data
structure
so
that
you
can
you
can
then
from
a
if
you
want
to
go
and
fetch
another
schema.
You
walk
up
to
the.
F
Url
and
then
you
submit
the
accept
header,
as
you
are
doing,
an
HTTP
request
where
you
say
these
are
the
schemas
and
willing
to
accept
here,
and
then
you
know
by
your
order
of
preference.
You're
gonna
get
the
best
matching
schema
back,
and
then
you
know
what
serializer
needs
to
leave
its
load
so
that
then
everybody
can
go
and
understand
the
the
respective
message.
So
that's
that
would
be
the
truly
restful
way
of
of
making
a
Skiba
registry,
but
it's
a
little
more
complicated.
F
So
what
I'm,
trying
to
do
here
is
to
you
know,
satisfy
this.
A
little
bit
more
is
at
Eric
desire
for
having
the
ability
to
to
represent
a
abstract
theater
structure
in
multiple
ways,
but
kind
of
in
in
multiple
formats
and
store
the
schemas
all
along
side
under
the
same
version
version
number
and
also
satisfy
the
much
simpler
need
of
just
storing
you
know
a
sequence
of
documents
that
are
describing
effectively
just
one
form
at
all,
all
together
and
we're
still
debating
so
on
in
Microsoft,
we're
still
debating
on
which
of
those
two
choices.
F
F
F
This
definition
here
doesn't
say
what
that
should
be,
doesn't
doesn't
see
what
those
rules
should
be
because
the
rules
can
be
different
depending
on
what
the
format
is,
and
it's
also
not
constraining,
which
formats
you
can
store.
So
you
can
do
this
for
Avro.
You
can
do
this
for
protobuf
and
if
you
have
some
other
schema
formats,
including
XML,
or
something
else
that
you
want
to
go
and
store
the
store
in
here.
That
should
also
work.
F
So
that's
the
goal
of
this
is
to
really
have
a
very,
very
open
base,
spec
that
can
accommodate
whatever
scheme
us
you
like
and
then
potentially
in
an
implementation
nodes.
You
can
go
and
constrain
that
further
and
say
you
know
here's
my
my
Avro
lens
on
this.
So
that's
the
idea
behind
that
specification
so
goal
is
that
the
universal
interface
for
a
simple
as
possible,
but
then
as
flexible
as
possible
schema
registry
and
everybody
can
implement.
B
Sure,
Clement
sorry
you're
talking
about
supporting
you,
know
multiple,
multiple
content
types.
Are
you
like?
How
is
that
being
managed
like?
Are
they?
Are
you
saying
that
I'm
gonna
build
the
prototype
version
of
the
schema
and
the
Avro
version
of
the
schema
and
the
JSON
version
ever
and
the
registry
is
just
gonna,
accept
those
and
assume
that
they're
the
same?
Yes?
B
F
B
F
Ought
to
be
disciplined
so
when
you
do
when
you,
when
you
do
this,
so
there's
no
I'm
not
this
is
just
the
interface
and
you
can
go
and
put
a
lot
and
you
can
put
logic
at
the
back,
which
basically
said
which
basically
evaluates
the
the
let's
go.
Let's
say
you
you
admit
you
have
you
add
a
protobuf
spec
and
the
protobuf
spec
is
now
the
first
spec
that
is
under
version
3
and
now
you're,
adding
an
Avro
spec.
That
is
also
under
version
3.
It's
basically
putting
you're
putting
a
new
one.
F
Then
you
can
obviously
create
some
logic
at
the
back
in
in
a
particular
implementation
that
goes
and
and
basically
creates
the
projection
of
what
the
add
row
of
the
data
structure
that
the
that
the
protobuf
spec
describes
and
then
checks
that
against
the
the
structure
that
the
Avro
spec
describes
and
if
there
are
Mitch
mismatches,
you
can
go
and
reject
that.
So
there's
it's
it's
perfectly
possible
to
do
logic
at
the
back,
which
goes
and
matches
all
those
things,
but
I'm
not
demanding
here
in
this
in
this
specification
that
you
have
to
do
this.
F
B
That,
then,
then,
given
that
I'll
take
the
rest
offline,
but
given
that
relative
to
this
spec,
you
should
call
out
that
you
know
this
distinction
that
you're
making
of
the
spec
versus
even
these
other
logical,
quality-of-service
kinds
of
issues
and
in
terms
of
doing
that,
you
know
in
in
some
commentary
or
something
because
yeah
that
that's
obviously
a
key
issue
in
terms
of
the
implementations
and
the
consumers.
Yeah.
F
So
so
this
mo
in
under
version
and
at
the
in
the
intro,
even
though
prescribed
in
the
specification
and
implementation,
might
choose
to
impose
compatibility
constraints
on
versions
following
initial
version
of
the
schema,
for
instance
I'm
already
calling
that
out
there,
and
then
we
have
some
of
that
in
the
also
from
access
control
for
access
control
rules.
I'm.
Also
making
incumbent
implementations
of
the
specification
may
associate
access
control
rules
with
schema
groups.
There
was
a
comment
that
we
should
also
go
and
allow
that
for
schemas
themselves,
for
versions
potentially
and.
F
E
Okay,
Ryan
I
think
my
hand,
that's
before
you
nice,
to
have
a
quick
question,
so
Clemens
I,
like
the
fact
that,
for
the
most
part
you
describing
this
is
just
sort
of
a
blob
store
with
a
nice
file
interface
on
top
of
it
yeah
and
and
leaving
the
semantics
up
to
either
an
implementation
choice
or
if
they
won't
do
nothing
at
all,
that's
great.
But
then
we
sort
of
talk
about
the
version
stuff.
E
That's
when
I
start
getting
a
little
confused,
because
that's
almost
adding
semantics
I'm
wondering
why
you
just
don't
say:
okay,
you
know
this
particular
user.
They
owned
this,
maybe
URL
or
this
URLs
group,
and
then
they
could
put
ever
they
want
there
right
if
they
choose
to
use
if
they
only
choose
to
have
one
URL
and
they
just
keep
updating
that
one
version
every
single
time,
that's
up
to
them.
If
they
won't
have
multiple
versions.
It's
up
to
them.
F
F
So
there's
no
compatibility
rules,
you're,
okay,
with
breaking
changes,
but
then
you
want
to
have
differentiation
between
the
stuff
that
you
have
already
sent,
which
means
now
you
have
a
you
know
ultimately,
you're
you're
walking
up
to
the
registry.
You're
posting
your
schema.
What
you're
doing
in
what
you're
doing
is
you're
you're
you're
doing
a
post
you're
getting
a
URL
back?
That
is
the
URL
that
you're
gonna
use
and
give
to
everybody.
And
then
it's
gonna.
F
That's
gonna
have
the
version
number
right
and
now
you're
going
to
walk
up
to
the
same,
to
the
same
name
and
you're
posting
the
new
version
of
the
schema
and
you
get
another
URL
back.
Then
it's
the
the
permanent
URL,
the
permalink,
basically
to
that
to
that
new
schema
and
you're.
Okay
with
breaking
changes
that
that
versioning
right
of
I
know
just
posting
the
diversion
that
is
making
things
for
the
simplest
kid
for
the
simplest
case,
arguably
simpler,
because
I'm
not
even
forcing
you
into
thinking
the
you
know,
the
management
of
versions.
F
You
basically
just
get
a
consecutive
stream
of
history
of
those
of
those
versions,
1
2,
3,
4,
5,
just
numbered
through
you,
don't
need
to
think
about
semver.
You
don't
need
to
think
about
all
any
of
those
other
things
as
soon
as
you
start
as
soon
as
you
start
thinking
about
the
as
soon
as
you
make
the
version
management
explicit.
E
F
E
K
Yeah
I
know
it
made
a
comes
in
the
PR
and
I
haven't
followed
up
on
on
all
of
your
responses.
Clemens
I'll
try
to
do
that
this
week,
but
I
think
one
big
question
that
I
have
is
like
how
how
standalone
do
we
envision
this
being
I
know.
This
is
starting
with
some
thought
events,
but
I've
seen
other
folks
come
in
from
other
groups
interested
in
some
kind
of
common
schema
registry
and
I
asked
that,
because
this,
just
in
my
experience
building,
you
know
very
generic,
you
know
platforms
or
services.
K
F
I
certainly
envision
this
envision,
this
to
be
bronc
broader
than
just
the
cloud
event
payload,
because
ultimately
this
describes
a
it's
a
it's
a
compliment,
complimentary
capability
to
any
serialization
framework
where
you
need
to
have.
We
need
to
share
schemas
between
two
parties
and
that's
true
for
all
of
messaging
and
eventing,
so
this
can
compose
with
AMQP.
This
can
compose
with
MQTT.
This
can
composed
with
cloud
Avensis
can
compose
with
effectively
anywhere
where
you
need
to
have
ski,
where
you
exchange
schema
tha's
data,
including
HTTP
transfer.
F
You
know
what
eventing
is
and
what
and
what
message
transfers
are
in
in
general,
like
you
have
a
you,
have
a
name
QP
message
and
the
AMQP
message
can
take
on
a
cloud
event
character
because
you're
just
adding
the
the
cloud
events
attributes
to
it,
but
it
runs
for
a
normal
message
broker.
So
it's
hard
to
draw
the
line
there.
So
I
see
that
here
as
a
as
a
spec
that
is
is
generally
applicable
or
that
mechanism
is
generally
applicable
for
for
messaging
in
in,
in
general,.
F
Okay,
many
other,
that's
also,
that's
also.
Let
me
let
me
just
add
one
or
more.
That's
also,
why
I
think
the
the
this
is
just
for
the
payload
and
then
this
actually
hooked
this.
This
is,
gets
integrated
or
complemented
by
the
discovery
mechanism
and
where
the
discovery
mechanism
really
that's
the
catalog
of
the
the
events
that
can
be
emitted.
That
talks
about
all
the
various
properties
of
cloud
events,
and
then
this
here
is
really
about
the
the
the
schema
that
we
leave
out
of
cloud
events
intentionally,
and
that
is
the
Payette
that
is
the
payload.
E
N
N
Having
had
that
conversation
I
think
a
few
points
have
come
up
and
somebody
I'd
like
to
toss
out
a
little
group.
So
the
issue
of
gr
PC
has
been
raised
and
I
guess
that
definitely
needs
to
if
we're
going
to
support.
That
needs
to
be
a
different
document.
But
do
we
consider
GRP
seem
to
be
a
transport
I?
Guess,
that's
a
question.
N
N
N
D
N
N
Okay,
so
that
they'll
do
so
when
I
originally
put
this
PR
together,
I
just
record
did
all
the
attributes,
as
a
man
yeah
much
like
Avro
does
and
I
was
sitting
there
mulling
over
whether
that
was
a
particularly
idiomatic
way
to
do
stuff
in
proto,
so
I
then
switched
over
to
this
other
representation.
Where
you
know
I've,
you
know
explicitly
listed
the
required
and
optional.
You
know
attributes
as
they're
defined
and
then
left
them,
essentially
a
map
for
any
any
additional
or
extensions
I'm.
Now
time
we
going
back
to
the
other
representation.
N
The
issues
of
you
know
how
durable
does
this
become?
You
know
this
now
would
be
something
that
would
only
work
for
v1
yeah.
If
we
had
ever
added
a
new
required
field
or
attribute,
then
you
know
would
that
indicate
you
know
a
new
version
of
this
schema,
so
I'm
told
me
the
idea
of
just
going
back
to
a
straight
map
of
attributes
and
not
formally
representing
them.
The
question
around
time
stamps
was,
and
part
of
this
I
think
was
my
sort
of
speedy
reading
of
the
spec.
N
C
N
I
used
a
native
prototype
for
that,
but
somebody
pointed
out
to
me
that
the
spec
actually
indicates
that
the
timing
stamps
need
to
be
sent
as
a
an
iso
string
yeah,
and
I
just
wanted
to
make
sure
that
that
was
and
that's
what
the
spec
says.
I
just
wanna
make
sure
that's
what
people
thought
it
should
be,
but
it
again
to
me
you
know
if
we
have
an
idiomatic
way
of
sending
a
timestamp.
I
am
Not
sure
in
in
a
particular
format
like
this.
Why
I
wouldn't
just
be
able
to
use
a
formatted?
N
You
know
a
predefined
type
for
that.
The
other
questions
I've
seen
were
around
my
the
way.
I'd
addressed
its
data
aspect
where
I'd
sort
of
allowed
it
to
carry.
You
know
a
proto
buff
message
or
you
know,
textual
data
or
binary
data.
Now
again,
my
understanding
from
reading
the
spec
is
that
this
is
sort
of
a
loud
in
the
spec.
The
spec
allows
for
different.
You
know,
representations
yeah
and
in
fact,
in
you
know,
in
the
JSON
schema
we
allow
a
JSON
object
to
be
data
in
the
Avro
schema.
I.
N
Think
we
allow
an
Avro
record.
Is
that
the
right
term
to
be
a
data
so
again?
For
me,
this
was
more
idiomatic
if
I
have
a
event
payload,
which
is
actually
you
know,
defined
by
a
proto
schema
it's
much
more
idiomatic
for
me
to
just
inject
that
you
know
explicitly
as
a
proto
object.
You
know,
rather
than
externally
marshaling
it
into
a
string
just
to
be
able
to
jam
it
into.
You
know
the
your
Marshall
it
into
bytes
to
be
able
to
then
jam
it
into
you
know
a
byte
buffer
inside
another
proto
object.
N
It
just
didn't
seem
very
efficient
to
me.
So
that's
that's!
Really!
Where
I
stand
at
the
moment,
as
I
said,
I'm
probably
going
to
go
back
and
switch,
you
know
the
attributes
back
to
a
simple
map
where
and
again
following
the
model,
if
we
scroll
down
a
bit
more
Doug
where
I'd
sort
of
come
up
with
this
model
of
allowing
all
of
the
types
that
we
define
in
cloud
event
to
be
sort
of
formally
carried
in
proto
without
losing
any
of
their
type
information.
N
E
G
So
the
question
was
using
a
map
versus
having
these
types
in
proto
having
these
types.
The
way
they
are
now
is
the
right
way.
Using
a
map
to
define
the
attributes
would
not
be
protocol
buffer
idiomatic,
you
know
adding
adding
new
fields
to
and
versioning
proto's
is
a
well
understood
thing
at
least
internally
at
Google.
We
do
it
all
the
time.
So
it's
yeah
I
mean
I.
Ask
you
know
having
the
extension.
There's
a
map
is
fine
cuz.
G
N
G
N
G
N
Right,
no
a
side
y'all,
just
gonna
say
I,
because
we
were
using
paper.
We
were
using
proto
two
and
switched
to
three
and
I
think
we
were
one
of
the
the
people
that
was
pushing
for
the
unknown
fields
to
to
be
put
back
in.
You
know,
because
it
was
something
that
changed
between
two
and
three
and
I
thought
that
was
becoming
the
default
behavior
rather
than
Oh
configured.
Okay,.
N
It
did
raise
another
interesting
question
for
me,
though,
whether
these
schemers
themselves
need
to
be
versioned
yeah.
So
the
name
spacing
on
the
not
just
the
java
package,
but
probably
the
proto
itself,
probably
needs
to
be
included.
The
one
marker
you
know
so
that
we
can
support
multiple
versions
side
by
side
if
they
change
dramatically.
But
there
was
another
tweak.
F
I
think
the
lengthy
discussion
that
we
had
about
bags
is
coming
back
here,
because
the
we
have
this.
We
used
to
have
this
extension
extension
bucket
that
housed
the
extensions
and
then
we
went
back
to
making
everything
a
flat
list,
and
this
this
brings
back
the
extension
bucket,
which
has
the
with
the
consequence
that,
if
a
is
there's
no
uneven
support
on
either
ends
of
there's
a
there's,
a
closeted
publisher
and
the
cloud
event
publisher
gives
you
a
is:
has
a
new,
well-known
property,
so
version
1.2
or
version
two.
F
There
is
an
intermediary
which
has
the
old
knows
the
one
point
of
schema
and
then
there's
a
receiver
on
the
other
end,
which
knows
to
200
schema,
then
the
Tuo's
that'swell
publisher
would
use
the
two
old
product.
Proto
schema
would
then
publish
to
the
intermediary,
which
is
using
one
o
schema
and
then
would
probably
go
and
drop.
The
extra
tribute
on
the
floor
because
that's
no
sitting
at
the
at
the
at
the
at
the
outer
level
and
the
the
2o
receiver
would
not
get
it.
F
You
can
add
a
field
and
that
that
field
will
pass
through
the
intermediary
because
it
doesn't
know
it
doesn't
need
to
know
about
an
extra
field
here,
if
you're
making
the
fields
are
our
attributes
first
class
right
if
you're,
adding
a
first
class
element
so
you're,
adding
after
subject
or
after
time,
you're
adding
now
you
know
the
next
one,
then
an
intermediary,
which
only
understands
this
schema,
will
basically
go
and
read
the
proto
event.
Well
ignore.
F
What's
that
whatever
was
extra,
you
will
have
a
deserialized
object
now,
which
has
which
doesn't
have
that
extra
information,
and
whatever
you
want
to
pass
on
to
the
next
party
will
miss
that
extra
information
that
the
client
submitted,
because
the
serialize
ur
will
ignore
it.
So
the
old
the
old
intermediary
will
ignore
it.
So.
N
G
N
F
N
K
I
mean
I
was
just
looking
at
the
spec
and
it
does
say
an
intermediate
should
forward
optional
attributes,
it's
not
required,
so
that
would
comply
with
that.
I
think
my
brother
question
is
yeah
barone,
pretty
buffer
or
solving
you
know
the
same
or
mostly
overlapping
problems
should
we
employ
the
same
model.
It
feels
like
this
is
deviating
from
the
a
bro
that
the
implementation
of
a
bruh
that
we
already
have.
N
N
N
It
just
sort
of
smelt
better
to
me
to
define
them.
I
mean
we
could
find
him
in
the
json
schema
yeah.
Now
missing,
jason
schemas
a
bit
loose
cuz.
You
know
you
can
just
add
whatever
you
want
so,
but
we
did
go
to
the
lengths
of
actually
formally
defining
those
and
defining
which
fields
are
required
and
so
on.
So
I
think
we
already
have
a
level
of
deviation,
but
it
point
taken
okay.
So
what
would
you
would
you
advocate
for
just
a
map
or
all
this?
N
N
K
I
think
you
know
doing
that
that
halfway
solution
would
comply
to
the
spec,
but
I
think
it
probably
needs
more
thought
as
to
the
trade-offs.
But
yeah
I
was
commenting
more
to
the.
Should
we
and
I'm
not
saying
we
should
or
shouldn't
was
just
raising
question.
Do
we
want
consistency
across
the
different?
You
know
representations
or
different
ways
of
serializing,
but
events.
N
No
I've
not
been
involved
in
that
a
lot,
but
I
think
there
was
an
attempt
to
sort
of
have
a
consistent
programming
model
for
the
SDKs
and
what
those
groups
discovered
over
time
was
that
you
know
when
you
do,
that
you
lose
some
of
the
you
know
the
idiomatic
nature
of
the
languages
that
you're
working
in
so
you
know
they
they've,
naturally,
sort
of
you
know
gone
their
own
way
made
a
much
more
language
centric,
so
I
I,
don't
know
buy,
suspect.
Having
explicit
attributes
like
that
probably
is
more
efficient.
N
N
P
F
It's
it's
only
so
so
the
if
you
just
at
the
top
of
this
of
this
of
this
page.
No,
no!
No!
Stop
this
specification
so
type
system
right.
Each
of
these
types
may
be
represented
differently
by
different
event,
formats
and
protocol
metadata
fields,
so
you're,
okay,
all
right
what
this
specification
does
is
it
defines
a
canonical
string
encoding
for
each
type
that
must
be
supported
by
all
implementations.
So
if
you
represent
this
as
a
string,
then
it
must
be
this.
That's
what
that
means.
Excellent.
Q
E
C
N
Once
we've
defined,
assuming
we
can
agree
on
what
a
proto
format
looks
like
yeah.
Theoretically,
then
we
could
define
G
RPC
bindings,
which
allowed
for
not
just
proto
formats
but
other
you
know
event
formats
to
be
exchanged
as
well,
and
so
the
question
is:
where
would
that
go
or
is
it?
Is
it
just
in
a
world
of
its
own
from
a
spec
perspective?
So.
A
F
F
Arguably,
the
protobuf,
the
protobuf
binding
should
be
probably
be
part
of
a
G
RPC
binding
because
that's
the
context
in
which
it's
arguably
only
permissible,
because
because
of
the
the
proprietary
nature
of
protobuf
as
it
stands,
if
we
want
to
go
and
play
play
the
police
for
our
rules,
so
yeah
I
think
I
think
it
makes
I
think
it
makes
sense
to
have
a
G,
RPC
binding
I'm.
Just
wondering
what
the
whether
there
is
a
reasonably
generic
way
to
create
a
juror
PC
binding
for
this.
R
It's
the
first
comment:
I
wanted
to
make
and
another
one
kind
of
related
that
we
by
we
I
mean
some
forces
at
pivotal,
now
view
where
we're
trying
to
kick
start.
The
conversation
about
cloud
advanced
streaming
and
I'm.
Also
referring
to
the
latest
project
that
I
made
and
later
we
started
using
project
beef
where
we
tried
to
generalize
subscribe,
subscribe
semantics
kafka
like
semantics,
this
private
teams
RPC,
and
we
may
also
continue
the
conversation
by
merging
two,
because
that's
something
else.
We
are
trying
to
discuss
well
like
focus
on
cloud
events
streaming.
N
E
E
E
J
J
J
There
are,
of
course,
a
few
things
you
might
discuss
here.
If
this
template
format
is
the
right
one
or
this,
if
you
look
at
that,
RFC
is
also
defining
certain
levels
of
complexity.
I
would
say
for
templates
if
you
should
restrict
it
to
a
certain
level.
In
my
opinion,
in
most
cases,
even
level
one
would
be
sufficient.
So
those
are
things
we
might
discuss
or
if
it's
people
think
it's
useful
at
all.
E
The
reason
I
think
this
is
gonna
be
really
interesting
is
because
I
think
this
is
going
to
help
shape
the,
how
much
automation
we'll
be
able
to
have
right
versus
have
to
do
user
input
to
get
things
going
and-
and
you
know
once
you
have
this-
the
next
question
I
would
have
is
okay.
How
do
people
know
what
bucket
means
right?
Do
we
need
some
sort
of
schema
or
something
that
helps
to
find
what
actually,
what
one
feels
actually
mean
and
that
that's
gonna
be
even
more
interesting?
J
E
In
that
case,
like
I,
said,
I
did
want
to
talk
about
this,
but
I'll
save
that
for
next
week,
because
I
think
having
that
I
might
need
to
write
something
up
to
better
express
what
I
was
thinking
that
this
call
with
those
questions
any
other
topics.
People
want
to
bring
up
before
I
go
back
and
do
funnel
roll
call.
E
E
B
S
E
C
E
Alright,
let's
go
ahead
and
do
this
thing:
alright,
timeskip
repo,
so
Lance
correctable
wrong
here
and
next
I
guess
grant
to
ensure
I
believe
the
current
state
is
technically.
We
agreed
that
as
a
right
now.
We
do
not
need
it
and
everybody's
going
to
try
to
do
everything
within
the
JavaScript
repo
I
believe
I
did
get
permission
from
grants
to
go
ahead
and
delete
it.
However,
I
decided
to
hold
off
on
doing
that.
Instead,
I
archived
it
just
because
I
didn't
want
to
delete
any
issues
or
PRS
I
may
be
there.
E
S
S
Pretty
much
I
mean
well,
yes,
the
the
specifics
of,
for
example,
having
to
constantly
run
a
build,
which
was
not
the
case
in
the
in
the
sort
of
alternative
that
I
presented
in
that
landed
will
now
need
to
be
the
case
that
it
does
are
just
details
like
yeah
I,
think
I
think
the
the
net
result
is.
We
don't
need
a
typescript
repositories
and
we're
taking
steps
to
make
typescript
developers
happy
in
the
current
repository
grant.
Would
you
say
that's
there.
I
I
E
I
I
C
M
With
with
the
major
version
2.0
we're
gonna
go
back
to
adhering
to
strict
semver
protocols
and
versioning
and
fun
times
it.
It's
exciting.
There's
a
couple
breaking
changes
from
the
previews
in
the
RCS,
because
we
at
the
last
minute
decided
to
ship
all
the
protocol
implementations
as
sub
modules.
So
some
things
got
bumped
to
a
different
import
path,
but
the
code
is
the
same.
Now.
E
M
I
worked
around
it
there's
some
automation
that
needs
to
be
written
to
help
make
releases
happen
a
little
easier,
but
basically
like
I,
go
to
the
go.
Mod
community
and
I'm
like
yo
I
wanna,
make
sub
releases
in
go
modules
for
sub
modules
and
they're
like
yeah
I.
Don't
do
that?
That's
that's
scary,
and
so
it
turned
out
that
the
documentation
for
all
this
stuff
is
Ian
go
files
in
an
internal
full
package
inside
of
the
go
Lang
which
I
don't
understand,
and
it's
not
published
anywhere,
which
is
also
fun.
M
L
C
T
E
J
I
I
M
G
T
And
he's
muted,
no
okay,
so
yeah
I
haven't
I
didn't
got
a
chance
to
look
at
all
the
issues.
I
was
coming
just
looking
at
the
pythonic
one,
because
I
was
one
of
the
older
things
and
that's
in
like
a
good
place
for
me
to
start,
but
I
can
definitely
look
at.
You
know
what
spoken
with
the
support
which
issue
was
that
exactly
was
that
using
extensions
with
victus
yeah.
T
E
Cuz
it
sounds
to
me
like
we.
We
really
need
somebody
to
own
this
puppy
going
forward
because
I
don't
think
we
have
anybody
else,
very
active
and
the
other.
If
you,
if
you
would
like
that's,
you
know,
volunteer
for
that,
and
you
know
we
can
make
you
maintain
her
and
all
the
other
good
stuff,
because.
D
D
T
E
T
E
E
E
E
Don't
think
that's
a
problem,
because
we
we
will
make
people
maintain
errs
if
there's
no
one
else
in
the
group
to
to
say
yes
or
no
right,
because
we
need
somebody
at
this
oughta
make
sure
that
we're
not
gonna
be
stepping
on
someone
else's
toes.
If,
for
example,
Dustin
is
actually
very
active,
we
just
don't
realize
it.
Yeah.
T
E
I
D
I
Desperate
context,
so
I'm
I'm
going
to
be
working
with
going
recently,
so
our
plan
is
it's:
okay:
what
to
improve
the
Python
SDK
over
the
summer
and
we'll
be
cursed
will
be
sending
meteors
and
anybody.
That's
really
interested
can
be
involved
too,
but
it'll
be
unique.
Curtis,
Dustin,
Smith,
on
bass,
CJ
thank.