►
From YouTube: CNCF Serverless WG Meeting - 2018-11-08
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
B
A
B
Agenda
did
you
I,
don't
think
anything
too
exciting
with
the
AI
is
going
on
just
want
to
remind
people
that
per
the
discussion
we
had
a
thank.
You
is
two
weeks
ago
we
are
going
to
cancel
the
conference.
Call
the
weekly
conference
call
for
coop
con
next
week
because
of
being
in
Shanghai
and
because
the
u.s.
Thanksgiving
half
the
week
after
that,
so
the
next
two
calls
are
gonna,
be
canceled.
B
All
right
not
hearing
any,
let's
move
forward,
then
ok,
SDK
workgroup,
yeah,
Austin
I,
know
you
weren't
able
to
join
the
call
that
we
had.
The
guess
was
Tuesday
this
week.
I
think.
So
let
me
just
quickly
summarize
what
I
think
happened
there
that
you
can
chime
in
the
goal
I
in
Java
SDKs
are
well
underway.
There's
definitely
some
activity
going
on
there.
B
Clémence
said
the
c-sharp.
One
should
get
started
relatively
soon,
so
expect
some
activity
in
that
repo.
We
don't
have
a
whole
lot
of
activity.
Actually
we
have
zero
activity
so
far
the
Python
and
JavaScript
buttons
and
I
know
some
people
are
interested
in
those.
So
if
you
are,
please
speak
up
and
I'll
give
you
access
rights
to
merge
and
do
stuff
with
PRS
in
there,
but
I'd
like
to
see
those
get
started
as
soon
as
possible.
B
B
We
should
be
able
to
make
some
changes
to
align
that
and
hopefully
would
be
more
superficial,
syntactical
type
changes
anyway,
but
that's
kind
of
where
we
landed
at
that
people
are
more
focused
on
trying
to
get
something
up
and
running
first,
rather
than
looking
at
the
bigger
picture
type
stuff,
we
are
still
kind
of
hoping
to
do
an
alpha,
at
least
for
some
of
these
SDKs
by
coop
con
North
America.
Let
that
plays
that
are
not
allowed
to
see.
Obviously,
each
group
is
gonna
probably
decide
that
on
their
own,
but
that's
still
the
goal.
B
C
On
my
end,
we
have
a
we
started,
an
SDK
design
document
that
is
there
and
it
does
provide
some
suggestions,
never
meant
to
be
firm
requirements,
but
just
just
suggestions.
So
it's
there
for
guidance
but
I'm
all
in
favor
of
just
you
know,
moving
forward
getting
something
out
there
sooner
than
fast,
there's
a
sooner
rather
than
later.
So
I
think
that's
the
best
course
right
now
and
then,
if
anyone
is
curious
or
wants
to
learn
more
about
stuff,
we've
discussed,
you
could
go.
Look
at
that
document
right
and.
B
Just
let
you
know
you
and
I
got
an
action
item
from
this
week's
call.
Woops
sorry
I
did
that
wrong.
You
and
I
got
an
action.
I
was
called
to
basically
see.
If
we
are,
we
can't
produce
some
sort
of
status
or
plan
or
some
kind
of
dock,
because
you're
right
this
dock
is
kind
of
we
been
using
for
those
purposes,
but
the
problem
is
the
stock
also
seems
to
serve
the
purpose
of
a
running
notes
document
from
each
of
the
phone
calls.
B
So
it
may
be
a
little
difficult
for
someone
new
to
the
group
to
see
exactly
where
we
are
relative
to
what
they
should
be
thinking
about
if
they
wanted
to
design,
for
example,
a
new
sdk
for
a
new
language.
So
we
thought
it
might
be
good
to
pull
that
those
types
of
design
decisions
into
either
a
separate
dock
or
a
well
known
location
like
you've
at
the
top
of
this
stock,
just
telling
them
on
those
lines
there.
I
was
gonna
work
with
you
offline
about
that
one
that
makes
sense.
I'm.
D
B
One
thing
that
did
come
up
on
this
week's
call
was
whether
we're
gonna
have
a
plug
points
or
extensibility
points
within
the
SDK,
so
people
can't
create
new
transports
per
SDK
and,
if
I
remember
correctly,
I
think
there
was
general
consistence
consensus
that
that
would
be
a
good
thing.
That
way
you
don't
have
to
modify
the
repo
or
do
a
complete
recompile
of
everything.
Just
to
add
a
new
transport,
you
have
some
sort
of
plug-in
mechanism,
but
I
don't
think
we
got
as
far
as
to
say
what
that
plug-in
mechanism
would
look
like.
B
B
B
All
right
moving
forward,
then
I
don't
see
Cathy
on
the
call,
so
I,
don't
I,
don't
think,
there's
been
any
activity
in
this
workflow
subgroup,
so
I
think
we
can
probably
move
on
to
the
next
topic.
Coop
con
Shanghai,
the
slides,
are
pretty
much
done.
We
sent
them
in
for
translation
feel
free
to
look
at
them.
If
you
notice
anything,
really
bad
that
we
need
to
fix.
Let
us
know
I
think
we
can
always
make
small
changes,
but
I
think
the
basic
flow
is
there,
so
I
think
it's
pretty
much
behind
us
Interop
work.
B
We
have
four
endpoints
as
right
now,
IBM
Oracle,
a
key
native
one
and
then
an
open
faz.
We
are
definitely
shooting
to
do
something
a
time
for
Kuk
on
North
America.
However,
if
we
get
enough
participation,
I,
don't
know
what
the
magic
number
is,
but
if
we
can
have
participation
that
we
feel
like
hey,
why
not
show
this
a
coupon
Shanghai?
We
may
do
so,
but
please,
if
you're
interested
in
joining
or
if
you
have
an
endpoint.
You
want
to
include
in
there
if
you're,
not
already
ping
me
and
I'll.
B
Add
you
to
the
cloud
events
demo
slack
channel.
It
is
a
private
one,
because
we
do
talk
about
endpoint
and
stuff
like
that.
So
we
don't
want
those
advertisers
across
the
internet,
but
please
join
that
and
this
stock
that
it's
up
here
behind
this
work
URL
contains
information
about
what
your
endpoints
expected
to
do
and
we
do
make
some
design
changes
periodically
as
you
go
along.
So
you
do
want
to
join
the
slide
channel
to
keep
up
to
date
with
those
all
right.
Any
questions
on
that
all
right
cool.
B
B
So
this
one
was
mine,
there's
an
issue
that
this
I
can
read
the
gentleman
who
opened
it
up,
but
but
he
basically
was
saying
that
as
a
newbie
coming
into
our
documents,
it
wasn't
quite
clear
where
to
start
in
terms
of
which
document
to
look
at.
First.
B
Just
to
you
know
to
warm
to
sort
of
introduce
themselves
into
our
work,
so
what
I
did
is
I
added
this,
these
couple
lines
of
text,
the
readme
just
pointing
people
to
basically
start
with
the
primer
and
then
head
over
to
the
core
specification,
just
a
little
bit
of
guidance
there.
Nothing
too
exciting,
definitely
not
normative.
It's
just
the
readme,
but
I
want
to
make
sure
people
are
okay.
With
this
general
text,
obviously
we'd
be
tweaking
later
needed.
B
B
Alright,
any
objection
to
approving
excellent
cool
Doug,
his
last
name,
but
they
start
with
an
M
he's
not
on
the
call.
Unfortunately,
he
had
some
minor
changes
to
some
of
our
documents.
I
think
he
was
just
trying
to
get
consistent,
for
example,
using
the
words
producer
and
consumer
throughout
the
entire
doc
or
throughout
all
our
Docs,
but
that
was
probably
the
biggest
change
minor
wording
changes
here.
I,
don't
think
he
any
of
his
changes
are
noted
at
all
or
if
he
did
make
any
more
changes,
it
was
by
accident.
B
B
B
B
Any
other
questions
or
comments
any
objections
to
adopting
this
PR
excellent.
Thank
you
guys,
whoops
all
right,
this
one
I
think
I
did
because
of
you
Austin.
You
had
mentioned
something
about
how
oh
yeah,
when
we
had
dropped
the
the
event
aversions
property,
you
were
wondering
about
whether
it
made
sense
all
right
with
our
decision
to
include
as
part
of
the
event
type,
the
string
itself
made
sense
and
you
thought
maybe
some
guidance
around
how
you
might
include
a
version
string
or
some
sort
of
version
type
of
information
within
the
within
the
event
type
itself.
B
C
C
B
B
G
B
G
B
Cuz
I
know
schema
URL,
at
least
in
my
experience.
Often
times
does
include
a
date
string
somewhere
in
there
or
some
sort
of
version
string
in
there.
So
I
think
it
may
have
been
mentioned
in
context.
That
is
that
an
example
of
this
type
of
stuff
being
done
before,
which
is
Lobby,
felt
comfortable
using
a
vent
or
sticking
the
version
string
inside
the
event
type
may
just
been
used
as
an
example.
I
B
If
someone
thinks
we
need
to
do
additional
word
smithing
around
schema,
you
are
obviously
we
could
do
that
and
if
you
don't
feel
comfortable
creating
a
PR
for
it,
then
you
know
go
ahead
and
open
up
an
issue
and
someone
else
will
pick
it
up.
So
they're
in
the
club
feels
like
we
need
that
feel
free
to
us.
I.
I
Would
say
one
thing:
you
know
we
silent
because
I'm
not
feeling
so
strongly
about
this
one,
but
that
calm
path
is
a
hey.
Here's
Microsoft,
so
a
backward
compatibility
is
a
bit
is
it
might
be
a
big
thing
where
you
have
clients
that
are
writing
to
the
type
to
the
certain
event
site.
The
block
created
amends
write,
the
one
that
we've
used
and
now
that
block
created
event
changes
slightly
because
it
asks
further
information,
so
that
should
have
a
new
version
number.
I
But
now
the
question
is:
are
you
willing
to
break
all
the
existing
clients
amid
all
the
existing
subscriptions
that
are
based
on
that
old
event?
If
you
are
just
making
a
small
and
effectively
ignoring
change
in
the
schema,
so
that's
something
that
I'm
generally
worried
about.
So
even
if
that's
a
rule
here.
I
Our
approach
to
that
approach,
so
that
might
be
to
go
and
just
include
a
special
version
number
in
the
message
spot
in
the
in
the
body
or
if
we
have
a
URL
to
have
that
reflected
in
the
URL,
because
I'm
really
worried
about
existing
existing
infrastructures
and
the
existing
applications
that
are
assuming
that
they
have
the
suit
that
they
have
subscribed
to
the
event
and
that
they
expect
a
certain.
You
know,
event
type
that
they
dispatch
on,
and
then
you
make
a
menu
change
and
you
effectively
breaking
their
entire
employee
infrastructure.
That's
that's!
B
I
I
wonder
a
wonder
one
that
edition
that
were
that
we're
adding
here
is
sending
people
down
a
path
that
might
have
consequences
that
they
might
not
see
if
they're
reading
that,
because
because,
if
you
only
really
make
it
and
then
added
a
change
in
the
schema,
you
really
usually
would
not
care.
And-
and
so
you
know
that
now
puts
people
into
the
into
the
conflict
of
when
am
I
really
gonna
change.
I
The
version
number
only
if
I
have
a
breaking
change
and
that's
probably
justified,
but
if
I
do
you
know
appoint
or
at
least
I'm
just
adding
data
which,
ideally
by
principles
of
ours,
always
keep
setting
the
same
Ruby.
You
know
it's
okay
to
add
things.
Then,
then
you
never
do
a
version
with
revision
and
just
keep
things
to
say
so.
I
said
for
many
people
in
this
perspective,
I
know
how
to
go
and
deal
with
that.
I
B
B
Thought
you
were
trying
to
speak
on
this
one:
okay,
sorry,
okay!
Well,
so
let
me
ask
you
this
clemens.
Would
you
prefer
if
we
hold
off
on
this.
B
Well,
like
I
said,
I
was
hoping
to
get
the
easy
ones
out
first
and
this
one
sounds
like
you're
a
little
nervous,
so
I
don't
want
to
rush
it.
So,
let's,
let's
table
this
once
right
now
as
that,
and
then
we
can
revisit
it
to
see
whether
we
just
killed
the
whole
thing.
Add
additional
text
either
here
and
the
primer.
But
let's
just
talk
about
that
later
is
that
fair
Magister
comment
on
that
Clemens.
G
Since
you
talked
about
attitude,
changes
that
we're
talking
about
it
more
I
think
originally
in
the
discussion.
The
point
was
that
it
would
be
major
version.
Changes
would
be
part
of
the
Evan
type
string,
so
breaking
changes
and
additive
changes
would
be
dealt
by
having
the
schema
change
anyway,
because
if
you
have
anything
changes,
you
should
be
changing
your
schema,
URL,
probably
with
a
date
or
something
as
Doug
was
talking
about
so.
I
So
I
would
propose
that
we
have
a
versioning
discussion,
so
you
can
use
the
event
type.
You
can
use
that
that
event
ID
attribute,
as
as
you
like
right.
Obviously
you
can
use
it
for
version.
You
can
use
it
for
everything,
so
I
think.
Instead
of
putting
this
here,
we
can
make
a
version
section
that
says
and
here's
three
ways
you
can
think
of
our
versioning
and
really
how
you
deal
with
them.
I
Is
it
really
up
to
you,
but
that's
kind,
so,
basically
making
a
guidance
thing
but
I'm
not
making
that
necessarily
a
it
can
be
even
in
the
normative
part,
but
I
think
we're
standing
alone
is
complicated
because
schema
URL
placed
into
that,
and
and
as
we
said,
you
know,
you
want
to
have
a
major
change.
Where's,
the
minor
change
and
I
think
that
needs
to
have
a
little
bit
more
explanation.
I
mean
just
weren't
bird
about
it
from
an
education
perspective,
not
sending
people.
I
B
Well,
like
I,
said,
let's
hold
off
on
this
one:
I
don't
want
to
rush
this,
especially
if
you
are
correct
Clemens
and
that
it
may
lead
people
down
the
wrong
path.
I
def.
That
is
definitely
not
my
intent.
I
thought
it
was
mine
that
was
mindless
text
and
if
it's
not
and
I
want
to
take
a
step
back
and
think
about
it,
some
more
so,
let's
take
this
one
offline
and
see
if
we
can
address
your
concerns
and
then
come
back
to
the
group
with
them
more
with
the
Durham
proposal,
how's
that
right.
C
Also
I
just
want
to
chime
in
real
quick
I.
Think
Cummins
Clemens
has
a
great
point
and
if
we're
gonna
sure
in
this
is
event-driven
future,
we
really
have
to
give
some
pretty
good
guidance
as
to
how
cloud
events
can
help
data
evolution
and
I
think
Clemens.
Suggestion
of
just
writing
some
of
that
guidance
in
here
as
like
an
initial
step
until
we
get
this
out
just
market
it
and
learn
more
and
see
how
people
are
approaching.
The
problem
seems
like
a
good
one,
so
I'd
encourage
you
see
anything
in
that
direction.
B
B
Clemens
dick
is
it's
time
we
start
sort
of
rushing
through
somebody's
PRS
I'm
doing
it
mainly
because
we
only
meet
once
a
week
and
I
want
to
make
sure
we
get
through
as
much
as
possible,
but
even
if
you
have
just
a
nagging
feeling
like
Clemens,
did
feel
free
to
mention
it
and
that
will
slow
us
down
and
we
can
take
it
offline
and
discuss
it
definitely
don't
mean
to
rush
things.
So
thank
you,
Clemens
for
done
that
I
also.
G
B
J
So
we
had
a
PR
that
we
discussed
on
last
week's
call
from
Fabio
and
basically
he
came
and
said:
I
took
your
Jason
example
and
I
tried
to
pass
it
by
the
adjacent
schema
and
it
didn't
validate
and
it
didn't
validate
because
he
used
their
relative,
your
I,
but
actually
you
say
it
should
only
be
your
I
and
then
there
were
multiple
people,
including
me,
who
said
yeah
you're
right.
We
only
support
your
eyes,
but
actually
then
Doug
found
out.
This
is
not
true.
J
So
if
you
scroll
down
to
the
spec,
you
would
see
that
we
actually
said
all
the
time
here
that
is
string
expression
conforming
to
your
I
reference.
Well,
then,
we
go
and
name
it
your
eye
and
then
everyone
is
confused
by
them
and
then,
if
you
look
at
the
json
schema,
you
can
see
that
the
mistake
was
applied
there.
So
in
the
json
schema,
it
actually
said
your
eye
where
it
should
have
said
your
eye
reference.
J
G
I
Many
years
ago,
yes-
and
so
this
this
was
the
we
had
a
long
discussion
about
new
references
versus
your
eyes,
and
we
literally
do
our
air
france's.
We
can
open
that
box
of
Pandora
again,
but
there
are
cases
where
you
are
acting
so
so
the
argument
was,
if
you
are,
if
you're
acting
wholly
within
the
scope
of
a
single
system,
then
further
qualifying
the
the
uriah
might
not
be
necessary.
I
Example,
a
sure
the
events
that
we're
raising
from
the
after
platform
all
have
relative
paths,
because
they're
relating
to
Azure
calm,
because
it
is
the
azure
platform
that
is
raising
those
events
and
affecting
the
event
paths,
are
all
ending
up
being
unique
because
they're
anchored
on
our
resource
structure.
So
so
for
a
juror.
We
don't
need
to
have
absolute
your
eyes,
but
we
would
want
to
go
and
distinguish
between
these
and
your
eyes
that
are
not
part
of
our
scope.
I
I
Yes,
because
the
event
type,
so
the
event
type
is
meant
to
be
to
make
qualified
and
actually
and
actually
it.
So
you
can
already
tell
from
the
event
type
what
that
is
where
that
comes
from.
So
you
have
that
you
have
that
qualification,
but
yeah.
If
we,
if
we
think
about
Federation,
if
we
think
about
Federation
across
systems,
then
we
might
go
and
consider
adding
the
or
I
we're
having
some
but
I.
I
Don't
like
expand
the
scope
here
all
at
much
in
that
discussion,
but
there
is,
there
are
some
thoughts
we're
having
in
a
different
realm.
That's
kind
of
related
to
this
probably
going
to
bring
this
here
because
we
have
atp-binding
about
addressing
in
general,
and
you
know
thinking
about
what
a
logical
identifier
is
verson
versus
actual
event
where
addresses
and
that
kind
of
plays
into
that,
because
a
juror
calm
in
that
sentence
would
be
really
just
a
name
and
then
the
question
is
you
know
what
is
the
right
name
for
these
sources?
I
I
These
probably
shouldn't
be
your
ends,
but
then
you
know
what
is
there
are
no
rules
governing
the
uniqueness
of
the
authoring
portion
if
you
don't
have
a
have
a
scheme
that
matches
that
so
richer,
so
in
ABP,
specifically
we're
trying
to
we're
trying
to
go
and
resolve
some
of
those
concerns
about
multi-level
routing,
etc,
and
once
we
have
a
have
a
model
for
that,
then
we
will
probably
want
to
bring
that
here
more
obviously,
you're
all
invited
to
come
to
aces
all
right.
So.
B
B
I
It
was
noted
that
when
we
added
the
integer
type
to
the
Astrotech
system,
that
it
wasn't
in
the
mappings-
and
that
was
correct,
so
I
just
added
that
and
for
the
Jason
Furman,
since
we
only
allow
integers
and
I'm
trying
to
keep
the
at
least
I
am
trying
to
keep
our
Texas
and
compact
I'm,
literally
making
the
constraint
that
you
can
look
at
the
Jason
number
there.
But
you
can
only
really
use
the
minutes
and
if
you
look
at
the,
if
you
look
at
the
Jason's
expecting
you,
we
don't
have
to
go.
I
I
made
the
text
a
little
bit
more
robust
at
the
bottom,
like
flight
81,
where
I'm
saying,
basically
it
can
be
any
valid
type
so
that
then
I
got
out
of
the
enumeration
and
have
to
go
to
adjust
at
all
time
and
then
above
I'm,
making
the
same
change.
Mapping
the
our
integer
type
to
be
able
to
be
long
for
the
incompetech,
nothing!
What's
the
other
one
that
we
have
yep
and
that's
up
there.
So
there
are
no.
There
should
be
no
surprises
and
for
a
QP
I
didn't
have.
B
Excellent
Thank,
You
Evans,
alright
protobuf
I,
don't
think
Spencer
is
on
the
call.
Now
this
one
has
been
out
there
for
quite
some
time.
I
think
there
was
some
I
in
my
opinion,
I
thought
relatively
minor
updates
recently,
but
at
least
three
days
ago
or
more,
let
me
ask
the
Googlers
Rachel
or
Scott.
Is
there
anything
you
guys
would
like
to
add
on
this
one
before
I?
Ask
there
any
questions
or
comments.
Thank
you.
How
much
you
guys
want
to
make
I.
K
L
K
L
So
I
mean
I
saw
my
whole
when
I
look
to
this.
It
was
more
around
okay.
You
know
when
you
pair
this
with
the
other
transport
bindings,
and
now
you
say:
okay,
you
know,
look
at
the
media
type,
that's
going
to
tell
you
what
what
the
payload
is
yeah
and
given
that
there
isn't
a
registered
one
for
protobuf.
What
I
really
was
looking
for?
Was
this
standard
to
say-
and
this
is
the
media
type
we'll
use
you
know
to
actually
make
it
explicit
mm-hm.
K
B
Three-Peat
stuff,
that's
the
language.
I
was
asking
okay,
so
so
Jim
I'm,
trying
to
figure
out
if
okay,
so
you're
asking
for
that
change,
I
didn't
I'm
gonna
hit
hesitating
here
is
I
know
this
Pierre
has
been
out
there
for
quite
some
time
and
I
feel
bad
that
we
haven't
merged
it.
Yet
cuz
I,
don't
think,
there's
anything
major
that
needs
to
be
done
to
it.
I'm
not
at
this
kind
of
your
your
content.
Type
thing.
Obviously,
do
you
think
that's
important
I
guess
what
I'm
kind
of
wondering
is.
K
I
Did
in
the
in
Jesus
vet
spec
a
Jason
format
in
the
envelope
section,
it
says
such
a
representation
uses
the
media
type
application,
slash
positive,
that's
plus
Jason,
so
this
one
basically
you'd
be
pretty,
will
be
plus
prospero
plus
pro
love,
because
that's
what
that's?
They
were
using
this
plus
notation
format
where
we
basically
have
a
base
type.
We
still
have
to
register
that
one
by
the
way
and
then
we're
effectively
adding
the
encoding
format
at
the
end
of
that.
B
B
L
K
B
Works
for
me,
yeah,
like
I,
said
I
just
feel
guilty.
Cuz
I
know
Spencer
spent
a
lot
of
time
in
this,
and
it's
been
lingering
for
a
while
I
don't
want
to
nitpick
it
to
death.
Okay,
so
look
the
proposals
out.
There
is
to
try
to
get
this
one
in
its
arena
cruise
it
and
if
it
is,
you
will
quickly
follow
on
PR
to
adjust
gems
content
type
question.
B
L
To
this
one
sure
so
yeah,
so
this
was
one
that
I
rather
foolishly
promised
to
do
last
week,
just
really
to
reduce
and
simplify
the
property
and
attribute
naming
and
I.
Think
the
only
one
that
was
sort
of
questionable
at
the
time
was
whether
people
wanted
to
reduce
the
attribute
called
cloud
events
version
to
version
or
spec
version.
So
this
change
is
actually
to
reduce
that
to
spec
version.
E
L
So
my
my
I
think
my
response
that
was
I
had
no
strong
opinion.
I
think
I
prefer
to
stay
as
ID,
because
it
keeps
it
consistent
with
everything
else,
but
you
know
I'll
go
the
flow.
If
the
group
wants
to
to
change
that,
then
I'll
do
that
I'm,
not
wedded
what
it
would
say
and
apologize
in
advance
to
the
people
working
on
a
katka
transports
map,
because
if
this
gets
merged,
then
your
spec
will
need
to
change
as
well.
B
B
M
B
M
B
B
Okay,
so
yeah
Roberto
I
think
you're
kind
of
out
number
two
that
one,
but
it
would
say
it's
interesting
that
you
mentioned
it,
though,
because
this
is
this
is
the
exact
example.
I
think
I
used
last
week
on
why
I
thought
prefixing
everything
with
event
might
actually
be
good
and
I,
because
I
said
you
know,
ID
versus
foo
ID
become
annoying,
but
anyway,
so
I
think
the
general
consensus
so
far.
Is
that
keep
it
with
ID
without
prefixing?
It
is
that
fair
conclusion,
or
is
it?
My
team
is
read
in
the
group:
okay,.
A
N
Yeah
I
agree
with
that.
It
would
be
way
cleaner,
but
if
that
one
has
defense
in
front
of
it,
all
of
them
shoot
like.
We
can't
have
event
just
on
one
it.
We
would
definitely
get
peers
and
people
would
get
confused
if
just
one
of
them
pacified.
That's
why
ok
time
it's
the
time
diamond
will
generate
it.
Is
it
the
time
of
the
event?
Is
the
time
of
actually
sending
the
event?
So
if
what
has
event,
all
of
them
should
have
event
in
front
of
it.
B
B
Okay,
not
here
any
objection,
so
this
means
that
once
those
things
merged,
we
got
to
change
our
demos
and
the
Kafka
spec.
We
just
broke
the
world.
We
did
just
break
the
world.
Yes,
Thank,
You,
Jenna
I
appreciate
that
yeah
you're
welcome,
yeah
I
mean
I,
mean
it's
0.1,
so
I
know
it's
safe.
It's
just
funny.
B
D
Sure
I
mean
it
flows
in
line
with
the
other
transport
bindings.
There's
been
a
discussion
about
halfway
down
where
we
talk
about
the
head
of
mapping
and
or
prefix
everything
with
cloud
events
underscore
Yahtzee
there
and
we
weren't
sure
so.
I
asked
Loki
and
also
asked
Clements
and
I.
Think
the
interesting
thing
is
that
the
bottom
Clements
has
said
it
looks
like
we
might
be
going
for
a
C
underscore.
My
concern
is:
if
we're
propagating
cloud
events
between
multiple
transports,
we
don't.
D
I
Effectively
what
this
prefix
does
it
gives
you
a
name
spacing
within
your
transports
the
year
two
days,
if
you
transport,
space
properties
and
stuff
that
is
necessary
for
routing
and
Henry
someone
at
your
transport
level
and
then
we're
effectively
taking
the
metadata
that
then
called
events
breeze,
certainly
for
the
binary
for
the
binary,
nothing
we're
kind
of
overlaying
this.
So
since
we
now
make
our
world
very
easy,
very
compact,
but
you
just
did
with
with
ID,
we
know
needs
to
go
in
these
space
things
right.
I
So
so,
if
you,
if
we
now
say
for
the
cut
for
Kafka,
you
make
C
e
underscore
IDE
and
C
II
under
score
time
and
C
and
all
those
then,
if
you're
presenting
is
up
in
an
SDK,
then
you
would
basically
go
and
toss
all
those
prefixes
out
and
you
would
simply
serve
as
the
normal
names
for
out
of
it.
And
if
we're
doing
these,
if
we're
mapping
stuff
onto
the
in
under
the
transport
frame
as
we're
doing
with
that
binary
mode,
then
you
already
need
some
code
that
sits
in
the
middle.
I
That
kind
of
does
the
translation
between
transports
and
the
logical
way
of
doing
that
is
to
go
through
the
SDK
and
the
SDK.
Well,
therefore,
going
and
present
you
normalized
names,
and
then
you
go
with
those
normalized
names
back
to
the
transport.
Well,
the
other
transport,
the
next
one
HTTP,
where
they
will
again
be
prefix
so
that
they
don't
clash
with
the
wire
reality
in
HTTP.
D
I
You
can
so
for
480p
I'll,
probably
go
and
change
this
disease
go
on
because
that's
the
idiosyncratic
way
to
represent
this
because
a
if
he
uses
as
a
kind
of
implied
namespace
and
model,
and
then
we
have
seen
that
C
dash
or
HTTP
because
idiosyncratic
there.
We
don't
need
to
have
those
seams
look
alike,
I!
Think
because
we,
the
assumption,
is
that
will
normalize
off
the
transport
into
the
normal
names.
I
D
That's
great
and
the
other
thing
was
these
there's
a
dependent
PR
here
with
the
event
key
and
obviously
we
can't
put
data
into
Kafka
without
it
belonging
to
the
correct
partition.
I
am
going
on
that
as
well,
yes,
I,
say
I,
think
J,
raper
or
John
broken
opened
a
PR
a
while
ago.
It's
been
open
for
some
time
and
I
know.
You'd
have
to
comment
earlier
today
about
exposing
transport
binding
dependency
up
the
that
the
to
the
event
model.
D
The
question
is:
if
we
do
hide
it
within
the
the
data
payload
and
that
data
payload
is
binary
or
it's
encrypted
or
its
secured,
then,
for
whatever
is
actually
trying
to
look
at
that
to
extract
out
the
the
event
key
is
its
it's
a
fair
bit
of
overhead.
It
also
might
break
some
security
concerns,
which
we
haven't
kind
of
got
you
yet
that's.
I
True
but
then,
if
you
have,
if
you
have
pelo
specific
information,
I
would
argue
that
you
then
have
a
header
that
you're
promoting
out.
It's
already
have
effectively
an
attribute
that
you're
promoting
out
of
your
payload,
which
is
able
to
dissipate,
which
is
yeah,
because
then
that
is
then
an
extension
and
I
think
what
the
the
Kafka,
but
the
Kafka
binding
ought
to
do.
It
ought
to
have
a
an
expression
effectively
that
can
define
how
you
fish
some
element
out
of
the
event
that
he
can
then
go
and
use
as
the
event
key.
I
Then
you
need
to
have
a
mechanism
I
think
to
go
and
construct.
You
need
to
have
a
rule
to
go
and
construct
a
partition
key
for
Kafka,
because
it
always
needs
one
from
the
content
of
the
message,
and
it
might
mean
that
you,
you
know,
map
from
an
existing
attributes.
That
might
mean
that
you
go
and
do
a
query
into
the
into
the
into
the
payload,
but
I
think
you'll
effectively
have
to
do
a
reference
to
a
to
an
attribute.
That's
in
the
message.
I
Without
that
attribute
and
the
message
being,
you
know
predestined,
to
become
a
cuff
turkey
like
token
central
body,
you
could
do
whatever
he
wants,
but
from
from
a
conceptual
perspective,
I
think
that
the
custom
bindings
should
have
should
be
referred
to
stuff
in
the
message
and
then
make
that
the
key,
rather
than
for
us
to
have
a
preconceived
notion
of
key
from
the
start
of
the
event
flow
until
it
potentially
sometimes
hit
the
proper
end.
Point
yeah.
D
D
I
See
next
and
that's
why
that's
what
my
concern
is,
because
our
events
house
works
the
same
way
right.
We
we
just
released
the
fighting
for
that
as
well,
so
we
have
the
same
problem
the
way.
How
are
you
choosing
your
partition?
Your
partitions
really
also
depends
on
the
use
case
right
you
might
go
and
want
to
create
partitions
based
on
event
type
you
might
have
want
to
create
Perdition
based
on
the
source.
I
You
might
I
mean
there's
all
kinds
of
criteria
but
which
you
want
to
go
in
and
partition
your
event
stream
up
for
processing
and
having
some
kind
of
mechanism
that
allows
you
to
say
you
know
in
my
binding
I
can,
in
my
implementation,
I
basically
said:
I
basically
select
a
criteria,
it's
like
affecting
the
expression
whatever.
That
is
that
then
points
to
the
connivance
message
it
doesn't
transform
and
that
transform
yields.
A
key
is
I.
I
Think
better
because
you
can
you
have
you
have
more
flexibility
that
if
you
have
to
put
a
key
in
a
priority
into
the
message,
even
though
the
ultimate
sender,
the
senator,
might
not
even
know
what
your
partition
criterion
is
because
because
there's
always
the
case
of
you
know
the
single
device
since
out
in
the
edge
sent
stuff
in
and
then
you
have
in
a
concentration,
concentrator
concentrators
this
that
and
then
in
the
second
level,
concentrator
step.
That's
when
he
wants
to
have
some
bit
of
partitioning
that
the
device
has
no
concept
of
so.
B
J
J
To
give
them
options
of
what
they
can
route
on
when
type
this
are
my
source
or
I
might
be
going
to
put
a
bit
more
data
than
is
strictly
necessary.
I
may
introduce
extra
attributes
so
and
then
the
consumer
or
the
middle
Bearer
can
decide
where
and
how
it's
going
to
route
based
on
these
attributes
and
I
think
the
same
should
be
true
for
the
partitioning
I'm
just
providing
attributes
and
then
whoever
sets
up
their
Middleburg
can
decide
what
they
want
to
partition
on.
This
is
for
me
as
an
event
producer.
N
Yeah
all
my
committee
is
on
the
same
line.
What
about
the
producers
that
can't,
for
some
reason,
generate
the
partition?
Key,
that's
not
ideal
and
having
this
as
a
required
field
is
not
ideal
and
I
do
believe.
This
would
be
perfect
as
an
extension
like
if
it's
there,
if
the
partition
key
is
there
use
it,
if
not
we're
gonna,
combine
it
in
this
way
or
generated
by
concatenating
these
three
fields,
its
source,
ID
event,
idea,
whatever
okay.
G
To
continue
from
Clarins
comment,
the
producer
cannot
know
the
partitioning
strategy
for
all
the
consumers,
it's
just
not
possible.
So
what
I
actually
want
to
comment
on
is
who
doesn't
make
a
difference,
whether
it's
an
expression
in
the
field
that
points
to
another
field
or
just
duplicating
that
data
from
that
field
into
the
event
key
field?
Well,
why?
Why
do
you
prefer
a
path,
expression
or
something?
G
B
Just
for
a
second
to
make
sure
that
we're
we're
talking
about
this
only
within
the
context
of
the
trend
of
the
conference
transfer,
binding,
I,
don't
think
I
didn't
want
it
as
I
go
into
PR
or
issue
or
PR
to
1/8,
yet
unless
it
has
to
be
solved
before
the
transport
for
the
conflict
transport.
So
let
me
ask
that
question
video.
I
B
G
Yeah,
it
was
mainly
just
a
clarification
that
the
producer
will
not
be
setting
that
key
anyway,
because
he
can't
know
what
that
value
should
be.
It
will
be
the
middleware
or
something
else
that
actually
does
the
partitioning
and
knows
the
strategy
that
you
should
be
partitioned
by,
but
I
just
wanted
to
ask
Clements.
Why
do
you
think
a
plat
expression
brings
some
advantage
over
just
if
you
have,
if
you
want
an
reference,
why
are
you
not
just
copying
the
dating
that
in
your
bank
key
extension
field
or
whatever
no.
I
You
could
you
could
say,
but
it's
a
it's
a
subscription
operation.
So
so,
basically
the
event
exists,
the
event
exists
and
now
you're
having
the
Kafka
transport
provider.
However,
the
implementation
happens,
and
now
that
thing
needs
to
get
gets
configured
to
go
and
look
at
that
event
and
now
pick
out
something
from
that
event.
That
then
becomes
the
key,
so
I
think
the
point
is
mostly
the
producer.
I
I
So
I
I,
don't
think,
there's
necessarily
a
path
expression
there
might
be,
there
might
be
I
just
said,
there's
some
some
kind
of
expression,
some
kind
of
mechanism,
but
with
which
you
can
go
pick
something
out
of
the
vet.
The
point
is
the
point
I
was
trying
to
make.
Is
we
can't
assume
that,
a
priori
there
will
be
something
key
like
or
a
khakhra
specific
key
like
in
an
event
that
shows
up
at
the
the
client
that
goes
and
takes
the
event
than
and
renders
it
on
takaka?
I
I
That
is
the
first
time,
I
think
what
we
really
talked
about.
Some
idiosyncratic
needs
configuration
needs
of
the
transport,
but
I
think
that's
the
case
here,
like
we.
We
really
need
to
write
down
in
the
end.
This
is
this:
it's
a
little
weird
because
we
don't
prescribe
a
particular
format,
but
we
would
probably
describe
a
particular
mechanism
or
washing
course.
I
We
describe
mechanism
that
basin
says
you
need
to
have
a
key
and
it
will
be
called
events
message
showing
up
here
and
how
you
drive
that
she
doesn't
matter,
but
the
key
really
needs
to
be
there.
I,
don't
I
would
have
to
think
about
how
to
express
it
in
a
normative
way,
but
that's
ultimately
what
it
is.
The
key
needs
to
appear
for
its
be
put
in
some
Kafka,
but
the
implementation
of
the
contract
transport
needs
to
construct
that
from
the
message
and
it
might,
it
might
use
existing
data.
That's
that's!
B
With
that
I'm
gonna
have
to
call
it
angle
there
at
the
top
of
the
hour,
but
it
does
sound
like
we're
in
agreement
that
we
can't
address
okay,
think
about
merging
the
Kafka
transport
until
we
resolve
to
one
eight.
So
please
can
you
discuss
to
Hyundai
in
the
PR
itself.
These
presidents
were
not
gonna,
be
meeting
for
the
next
two
weeks.
B
H
B
B
B
B
Alright
cool
in
that
case,
thank
you
guys
very
much
and
we'll
talk
in
two
or
three
weeks.
I
guess
and
let's
see
some
of
you
in
Shanghai
have
a
good
one.
Hi
everybody.
G
You
write
down
even
just
a
short
description
of
what
we're
talking
about
in
the
issue,
since
you
actually
have
the
idea,
and
you
clearly
have
more
of
a
clear
idea
what,
if
what
that
is
so
would
you
show
the
two
one,
one
8dm
a
key
issue
about
how
it
might
not
be
an
extension
in
the
actual
it
might
not
be
an
extension
attribute,
but
rather
a
configuration
of
the
transport.
That's
a
very
yeah.
I
G
G
I
That's
what
the
transport
bindings
do.
Is
they
basically
prescribed
by
that
software
all
to
operate,
and
we
now
make
an
extra
prescription
here
that
says,
and
you
also
need
to
have
a
way
to
go
and
harvest
information
from
the
the
mess
from
the
input
events
to
go
and
generate
synthesize
effectively
that
key,
and
that
might
be
an
extension.
But
that
might
you
know,
however,
that
might
be,
but
it's
in
something
that
is
in
the
obligate-
is
an
obligation
of
the
Kafka
transport
implementation
to
go
and
create
that,
oh
sure,.