►
From YouTube: CNCF Serverless WG 2020-07-02
Description
CNCF Serverless WG 2020-07-02
A
A
A
C
D
C
D
B
A
B
B
H
B
C
B
C
H
B
B
B
Okay,
SDK
call
we'll
have
one
right
after
this
one
I,
don't
think
we
talk
about
anything
too
important
last
week,
other
than
some
of
the
PRS
around
governance
and
stuff,
like
that
I
think
there
may
be
some
minor
changes
made
since
then.
It's
there
any
yet,
but
if
we
may
seek
a
sub
team,
they
could
think
of
anything
worth
mentioning.
B
E
G
G
Yeah
I
mean
also
another
thing
to
just
mention
if
anybody's
interested
or
could
help
us
with,
if
you
guys
have
any
experience
with
kubernetes
customer
resource
definitions,
we've
added
those
in
just
to
kind
of
added
a
go
type.
So
you
can
create
your
seer,
these
better
spec
based
types
that
are
based
on
our
workflow
definitions,
but
we're
kind
of
looking
just
you
know
for
help
from
individuals.
They.
G
B
B
B
D
G
B
All
righty,
in
that
case,
let's
jump
on
to
this
one
see
it
was
this,
so
this
was
Lance
if
I
remember
correctly,
I,
don't
see
him
on
the
call.
Remember
correctly,
this
one
was
more
of
a
copy
of
the
general
guidelines
that
he
had
written
up
for
the
JavaScript,
SDK
I
believe,
and
he
just
wanted
to
put
this
out
there
as
a
proposal
for
SDKs
for
the
other
SDKs
to
possibly
pick
up
I,
don't
think
it
requires
them
to
pick
it
up.
B
I
think
it's
just
sort
of
general
guidelines
that
are
good
if
they're
looking
for
a
sort
of
like
a
rough
draft
starting
point
for
their
own
SDK
work,
but
I
thought,
because
this
is
going
to
land
in
the
cloud
events,
repo
itself
and
not
an
SDK
repo
I
felt
like
it
was
from
a
process
perspective.
It
had
to
get
bumped
up
to
us
to
to
take
a
look
quick,
look
at
it.
Anythi
everybody
here
a
chance
to
review
it.
So,
even
though
he's
not
on
a
call,
are
there
any
questions
about
this?
One.
K
B
Don't
think
that's
the
SDK
specific,
but
I'm
not
sure
an
SI
applies
to
our
process,
because
the
way
we
deal
with
PRS
is
very
different
right.
We
don't
follow
a
normal
code,
PR
style
thing
right.
We
only
do
things
on
Thursdays
and
stuff
like
that.
So
it's
much
quite
sure
it
applies
to
us
from
that
perspective.
So
this.
B
That
kind
of
stuff
yeah,
you
know
how
do
you
lay
with
your
commit
messages
or
why
you
live
with
your
PRS
and
stuff,
like
that?
It's
just
things
that
I
think
are
more
important
for
PR
processes,
where
you're
merging
PRS
on
a
daily
basis,
kind
of
stuff,
yeah,
okay,
okay,
any
other
questions
comments,
any
objections
to
proving
that
one
all
right.
D
B
F
So
this
one
is
next
an
item
that
I
took
two
weeks
three
weeks
ago
and
basically
it's
basically
a
draft
that
talks
about
management,
community
management
of
the
SDK
projects.
In
particular,
it
goes
through
the
problem
of
security
patches,
ensuring
the
project
out,
even
when
the
maintainer
are
available,
and
everyone
Anglesey
to
corner
case
situations
like
an
end
of
a
project
to
a
new
maintainer
where
the
previous
containers
are
not
available
anymore.
F
B
M
F
B
B
B
Don't
see
Thomas
on
the
call
I
can
refresh
my
memory.
Oh
so
this
is
a
minor
one.
Does
anybody
know
I
think
this
is
open
API
he
according
to
the
editor
or
checker,
or
something
like
that
he
was
using.
It
was
complaining
about
missing,
quotes
now.
I
did
see
examples
where
it
showed
both
ways
with
and
without
the
quotes,
but
does
anybody
have
any
reason
to
believe
that
adding
quotes
would
be
a
bad
thing?
I
just
want
to
give
everybody
a
chance
to
speak
up
if
they
had
any
opinion
on
this
one
Francesco.
F
B
Somebody
a
camera
who
was
I,
guess
andrius,
he
well.
He
had
some
comments
about
about
the
primer
and
the
actions
that
we
were
the
the
types
in
there.
He
was
bothered
by
the
fact
that
some
of
these
things
were
in.
We
didn't
were
not
in
past
tense
in
our
adapters
and
the
adapters
are
not
formal
specification,
so
they
are
allowed
to
change
at
any
time
and
I
thought
that
one
is
the
couchdb.
One
should
probably
change
to
be
past
tense.
B
I
thought
that
seemed
to
make
a
whole
lot
of
sense,
because
when
I
looked
at
all
the
other
types
that
we
had
for
the
other
adapters
like
github
and
the
other
ones
in
there,
they
all
were
in
the
past
tense
as
well.
So
I
thought
following
that
pattern
made
a
lot
of
sense,
but
then
the
other
thing
I
did
here
is
I,
actually
updated.
B
Our
examples
from
fake
github
things
to
actually
line
up
with
our
recommended
adapter
type,
freaka
tub,
so
that's
all
these
other
ones
were,
was
just
to
align
it
and
then
I
made
this
one
past
tense
as
well.
So
these
are
just
simple
typos
kind
of
things.
In
my
opinion,
the
way
to
them
might
be
questionable
is
whether
anybody
has
an
objection
to
change
into
CouchDB
adapter
to
be
past
tense,
for
the
verbs
that
we
have
in
there
I.
K
B
B
All
right
now
on
this
one
I
came
here
why
this
popped
up
in
a
conversation
for
I
think
popped
up
in
the
SDK
call.
Someone
noticed
that
we
didn't
have
any
code
of
conduct
governance
Doc's
in
the
SDKs.
Then
we
realized
what
we
don't
actually
have
one
for
the
main
project
itself.
Oh,
why
this
came
up
I
think
I
think
is
the
workflow
I
was
going
through
sandbox
project,
they
didn't
have
a
code
of
conduct
and
that's
where
you
realize
we
didn't
have
it
for
our
stuff
over
here.
So
we
thought.
B
Okay,
every
C&C
have
project
actually
supposed
to
have
a
COC
and
we
didn't.
We
should
probably
do
that
to
give
ourselves
a
line.
So
basically,
what
I
did
was
I
copied
the
code
of
conduct,
documents
from
the
CN
CF
project
itself,
and
that's
all
what
is
done
here
and
I
just
changed.
I.
Don't
think
I
really
change.
Anything
thanks.
Wait
am
I
doing
here
contributing
video.
Oh
wait,
I'm,
sorry
what
I
did
was
I
added
a
pointer
to
the
code
of
conduct
from
the
CN
CF
thing.
B
I
didn't
actually
copy
it
in
here,
but
then
at
the
same
time,
what
I
did
is
I
did
a
whole
bunch
of
little
clean
up.
Things
just
thought.
This
whole
section
about
our
meeting
times
was
just
kind
of
ugly,
so
I
just
reformatted
that
nothing
changed
really
there,
but
then
what
I
did
is
I
moved
some
of
our
documents,
like
our
governance,
talked
into
our
community
directory.
This
was
sort
of
my
attempt
at
a
fir
phase
of
cleaning
up
our
our
directory
structure.
B
We
had
my
opinion,
or
we
have,
in
my
opinion
way
too
many
things.
The
top-level
so
I
want
to
push
as
many
things
as
possible
into
sub
directories
and
I
thought
I'd
start
with
the
governance
talk.
While
I
was
messing
around
this
stuff
anyway,
so
I
moved
the
governance
stock
into
community
and
did
some
cleanup
and
then,
when
I
was
changing,
the
links
I
had
to
reformat
this
because
it's
been
over
80
characters.
B
Most
of
this
was
reformatting
mainly
because
of
either
cleanup
or
because
things
moved
in
the
difference
directory
our
community
directory
and
I
removed
the
coming
soon
here,
because
we
already
have
a
demos
file,
so
the
words
coming
soon
made
no
sense
anyway.
The
biggest
thing
here
was
a
pointer
to
recover
in
stock.
This
section
right
here
this
is
the
biggest
thing.
There's
some
information
we
had
here,
the
CNCs
Code
of
Conduct
document.
We
just
point
start
the
Terkel
a
to
that.
B
Any
objection:
okay,
but
I'm,
probably
gonna,
do
based
upon
what
I
think
I
grew
to
last
week
and
the
SDK
call
was
I'll,
then
open
up
PRS
in
each
the
SDKs
to
point
to
something
either
our
governance
doc
or
to
the
CN
CF
COC,
but
either
way
each
SDK
need
to
see
LC
as
well,
so
I'll
open
a
PR
is
in
each
of
the
individual
SDKs
talk
about
those
or
to
add
references
to
something
all
right.
Moving
forward.
B
L
B
K
Sure
I
need
so
somebody
opened
an
issue
because
the
the
Jason
schema
definition
didn't
seem
to
be
following
the
spirit
of
the
Jason
format
specification.
So
the
way
this
team
had
originally
been
did
find
was
that
the
data
their
project
could
be
dated.
F
could
be
either
an
object
or
a
string,
but
if
you
read
the
format
spec,
it
says
that
data
could
be
about
any
valid
JSON
object,
so
I
basically
extended
it
the
type
you
know
possible
types
just
to
cover
all
the
types
that
that
Jason
supports.
K
L
E
B
B
B
Okay-
maybe
it's
not
right
here,
but
somewhere
in
our
spec
Aires,
there's
language.
That
implies
there's
only
two,
but
then
the
HTTP
spec
goes
often
defines
other
ones
in
particular
batched.
So
he
thought
we
needed
add
additional
texture
to
make
it
clear
that
other
protocol
bindings
made
to
be
defined.
Okay,
I
think
that
was
the
motivation
behind
it
and
I
see
Christoph.
You
had
a
some
comment
here
or
additional
change.
Anybody
want
to
speak
to
this.
One
have
any
concerns
or
comments.
B
I
I
also
have
the
bigger
comment
on
the
PR
itself
and
on
the
issue
itself.
I
agree.
It
is
very
confusing
and
I
try
to
explain
it
in
the
issue,
but
I
think
I
feel
that
explain
it
explain
it
properly.
So
I
think
what
the
HDP
spec
defines
is
another
mode,
but
it's
not
a
message
mode.
So
for
the
message
you
can
have
a
binary
or
a
structured
mode,
and
the
bad
thing
is
also
a
structured
mode,
because
the
definition
fits
so
in
the
batch
modes.
I
The
event
is
fully
encoded
using
a
standalone
event
format
and
stored
in
the
message
body.
That
is
actually
true
for
the
batch
mode.
So
I
think
what
is
really
confusing
here
is.
If
you
look
at
the
binary
modes,
the
binary
mode
is
then
the
binary
mode.
The
message
body
is
exactly
the
same
as
the
request
or
response
body
that
we
sent.
But
if
you
look
at
for
example
batch,
this
is
not
the
case.
If
we
look
at
other
events,
formats
like
I,
know,
Kafka
the
azure
event
creates
pops-up
whatever.
I
Then
this
is
actually
not
the
case.
So
we
have
the
key
event:
format
which
defines
I'm
taking
the
event
and
I'm,
transforming
it
into
a
message,
and
then
the
protocol
bonding
Compson
says:
ok,
here's
how
you
put
this
message
into
the
transport
and
then
add
additional
stuff
for
the
request
or
response
body
and
you
if
we
have,
if
you
see
it
as
a
two-step
process,
the
message
mode
only
applies
for
the
first
step
and
then
the
for
example.
Batching
only
applies
for
the
second
step,
I'm,
not
sure
if
I
know
lost
everybody
or
not.
If.
I
That's
basically
what
I
try
to
say
with
my
suggestion
there,
so
you
may
have
a
protocol
abiding
that
has
multiple
structured
modes.
So
if
you
you
could
have
one
that
doesn't
batch
and
you
could
have
one
that
batches.
Then
you
have
two
structured
modes
defined
which
we
actually
do
in
the
HTTP
binding
right.
B
I
J
Yeah
so
I
think
the
the
point
you
brought
up
about
the
the
logical
message
being
separate
from
how
it
is
transmitted
in
a
given
protocols
is
interesting.
That's
that's
one
thing:
I've
struggled
with
just
looking
at
the
spec
and
mapping
it
to
different
transports
is
that
the
message
is
the
same,
and
you
know
some
transports.
Don't
have
a
big
data
layer
and
only
have
a
message
layer,
but
how
the
data
is
actually
encoded
it,
regardless
of
that
10
sometimes
depend
on
the
specific
protocol,
so
I
think
that's
an
interesting
thought.
There.
B
N
I'm
not
sure
the
motivation
for
this
change,
but
I
kind
of
assumed
that
it's
related
to
pubs
a
push
over
HTTP
would
like
to
carry
a
cloud
event,
but
they
have
no
control
over
additional
headers
and
the
shape
of
the
request
is
is
that
is
the
attempt
to
include
HTTP
for
pub/sub
encoding
so
that
we
can
decode
a
cloud
event
as
as
a
pub
sub
push
format.
I.
I
N
I
B
You
may
want
to
take
a
look
at
his
original
issue.
Cuz
I
came
her
for
sure,
but
I
this
vague
recollection
that
when
I
first
read
it
I
think
he
was
just
more
bothered
by
the
fact
that
this
spec
only
talks
about
two
things
and
he
thought
there
were
three
things:
meaning
there
are
two
modes
and
then
the
HTV
spec
goes
often
defines
another
one.
B
B
B
L
L
And
then
I
realized,
like
first
that
definition
of
new
types
might
be
useful,
even
if
the
normal
SDK
just
having
the
interface.
So
what
is
a
service
which
is
a
type
sorry,
my
daughter,
eyes,
pain
in
the
background
here
we
have
no,
it's
me
and
then
I
was
like
when
I
will,
when
I
developed
new
services
I
just
like
basically
by
importing
to
the
cloud
event,
SDK
I
was
thinking.
L
It
made
more
sense
to
me
at
that
time
and
also
because,
like
I
needed
the
definition
of
course,
of
the
primary
SDK.
So
that's
why
I
did
it
this
way,
but
I'm
really
open
to
risk
it
and
also
I
try
to
minimize
the
impact.
So
when
you
look,
that
is
not
like,
there
is
no
dependency
to
express,
even
if
I
include
Express
to
make
it
run.
I
can
demo
if
you
wanna,
do
didn't
really
prepare
attack
into
that
during
the
SDK
color.
L
L
L
To
basically
filter
those
as
well,
so
it
will
send
you
the
write,
the
cat
service.
If
you
only
have
permission
for
widget
create,
you
will
display
the
cat
service
with
only
the
event
code.
Next,
we
just
create
and
remove
all
the
events
that
you
should
not
see,
which
I
guess
was
intent
of
the
of
the
specification,
but
I
wanted
to
be
sure.
F
L
L
F
L
L
Some
example,
when
you
define
like
the
schema,
the
definition
of
a
schema
inside
an
object,
it
could
be
an
interface
by
itself
that
to
extend
because
the
definition
of
a
schema
is
the
same
between
a
crowded
event
occurred,
even
type
and
and
those
things
so
I
I
think
they
are
related
to
each
other.
So
can
you
read
it
independently?
Yes,
I
guess
it's
not
that.
L
F
B
Yes,
that's
about
training,
but
something
similar
in
a
sense
that,
as
a
client
I,
could
almost
understand
a
single
SDK
knowing
how
to
deal
with
receiving
cloud
events
and
how
to
talk
to
the
discovery
service
to
find
out
what
what
services
are
there
and
how
to
subscribe
to
them.
So
I
could
almost
understand
and
possibly
merging
client
side
stuff
because
they
kind
of
go
hand
in
hand.
The
server
side,
though,
that's
a
little
less
clear
to
me,
I
can't
I
I'm,
having
trouble
struggling.
L
I,
don't
an
application
that
will
cause
events
but
never
generate
any
code
events.
So
it's
kind
of
a
change
that
will
provide
some
cloud.
Events
will
as
well
like
consumer
record
events.
So
that's
why
I
didn't
make
that
much
of
difference
and
the
thing
is
a
discovery
like
the
server
part
of
the
discovery
is
about
100
lines
of
code.
So
it's
not
like
huge,
but
that
means
the
definition
should
be
shared
in
that
case.
L
B
So
to
me,
I
think
I
can't
figure
out
whether
this
is
an
SDK
question
or
a
question
for
the
group
at
large
right
in
terms
of,
should
we
look
to
merge
any
potential
code
into
one
thing
or
get
them
separate,
I
think
I
said
I'm,
not
sure
who,
whose
best
thing
answer
that
question.
L
L
C
This
is
Lance
I,
don't
know.
I
like
I
need
to
live
with
this
for
a
little
while
and
think
about
it
and
and
stew
on
it.
It
was
I
mean
I
literally
just
saw
this
PR
during
this
call
and
I
need
to
think
about
what
the
implications
are
so
I
guess
that
doesn't
really
help
very
much
but
I'm,
like
all
I'm
saying,
is
that
I
can't
say
for
sure
yet
yeah.
N
B
L
Thing
also
is
like
it
can
serve
the
content,
but
it's
not
serving
it
by
itself.
X,
it
doesn't
include
any
service
like
server
parts.
It's
just
include
the
code
that
can
answer
to
a
server
implementation.
So
it's
like
a
helper
more
than
the
full
implementation
of
the
server-side.
Like
I
mean,
if
you
want
to
do
it,
you
still
need
to
run
your
own
or
HTTP
server
and
call
that
code.
L
C
Mean
I
guess:
I
have
a
few
just
sort
of
unstructured
thoughts.
One
is
that
like
having
these
not
in
the
SDK
repository
seems
like
it
would
just
create
a
proliferation
of
new
repositories
because
they're
really,
probably
wouldn't
it
would
be
good
if
these
were
implemented
in
more
than
one
language
right
and
then
I.
You
know,
there's
already.
B
L
F
F
But
then,
let's
not
forget
that
we
start
having
programs
like
managing
the
versioning
of
the
projects.
You
know
stuff
like
that
which
may
be
complicated
so
part.
So,
as
I
said,
he
if
discover
spec
doesn't
depend
on
cloud
events.
Then
it's
fine
for
me
if
we
put,
for
example,
in
SDK
Java,
some
sub
modules
that
doesn't
depend
on
the
cloud
events
modules.
But
then
at
that
point
you
start
having
the
problem
of
having
the
same
versioning
for
this
project.
A
D
A
B
Okay,
cool
Thank,
You
Remy,
so
as
I
was
trying
to
play
with
implementing,
discover
respect.
There
are
two
things
that
jumped
out
at
me
and
I
wanted
to
get
people's
opinions
on
these
first
of
all
is
agitation.
Support
I
realized
that
the
number
of
services
could
be
quite
large,
which
typically
then
means
sort
of
pagination
and
I
was
wondering
whether
anybody
had
any
preference
in
terms
of
how
to
actually
represent
this
on
the
wire
I
saw
a
couple
different
flavors
out
there
when
I
was
just
doing
a
quick
search
at
the
high
level.
B
I
think
there's
this
notion
of
like
what
github
does,
which
is
they
don't
necessarily
of
the
message.
They
add
additional
HTTP
headers
telling
you
how
to
get
the
next
chunk,
but
then
there
are
other
implementations
and
doesn't
show
up.
Oh
maybe
I
didn't
paste
it
here.
There
are
anyway,
there
are.
There
are
other
implementations
where
it's
actually
part
of
the
payload
itself.
So
there's
like
an
extra
wrapper
around
the
data
that
says:
here's
the
previous
here's
the
next
chunk.
B
B
Do
we
want
to
head
down
the
path
of
it
being
assuming
that
things
don't
change
very
often,
therefore,
you
don't
have
to
as
an
implementation
on
the
server
side,
you
don't
have
to
worry
about
some
sort
of
transactional
thing
right
where
you
like,
run
a
query,
and
then
people
iterate
over
the
query
set,
because
your
data
is
changing
all
the
time
you
don't
want
them
to
have
their
enumeration.
All
you
know
messed
up,
because
things
keep
changing
or
you
know
do
we
say
no,
it
doesn't
seems
very
often.
B
Therefore
we
don't
technically
need
to
worry
about
this,
but
then
the
question
is:
when
I
noticed
things
like
this.
It's
like
okay
is
the
page
size
dictated
by
this
number
here
right
and
that
gets
a
little
bit
awkward,
because
what
if
someone
passes
in
say
no
I
want
just
page
3
and
page
size
is
50.
Well,
that's
going
to
influence
your
page
sizes
and
if
the
page
size
changes
every
single
time,
you
do
a
query.
How
does
that
you
know?
How
is
that
going
to
work?
B
You
know
it
could
get
kind
of
funky,
then
I
thought
well.
Ok,
maybe
it's
more
of
just
an
opaque
string
that
passes
along
and
then
the
server
side
knows
what
they
do,
that
up
a
string
and
to
figure
out
what
the
next
chunk
is
gonna
be,
but
then
he
has
this
persistent
kind
of
State.
Anyway,
there
are
how
much
different
options
that
I
saw
out
there
and
I
just
wanted
to
get
people's
opinions
before
I,
try
to
attempt
to
write
up
PR
or
on
this.
So
let
me
pause
there
and
Ryan
I'll.
Let
you
speak.
J
So
I
definitely
have
some
opinions
here.
I
will
say
your
first
question
around
whether
e
the
URL
or
the
pointer
to
the
next
chunk
of
results
should
be
in
the
mid
data
versus
that
the
payload
I
am
definitely
in
favor
of
the
made
data
and
I'm
saying
that
is
a
truly
oh.
We
actually
put
it
in
a
payload,
and
that
has
caused
me
a
lot
of
personal
heartache
that
I
can
I
can
try
to
explain
a
a
synchronous
thing
when
I
have
some
time.
L
L
Even
so
so
also
keep
in
mind
this
isn't
for
Claire
events.
This
is
for
the
discovery.
Spec
yeah
I
mean
okay.
For
me,
the
disco
respect
is
about
knowing
what
close
events
are
on
the
service
side,
I
mean,
if
you
don't
have.
That
definition,
like
is
that
definition,
is
a
bit
wrong
at
the
moment
you
ask
there
was
a
deployment
in
the
mean
time,
I,
don't
think
so
you
do
see
what
case
you
just
we
worry
and
you
do
the
right
answer.
B
B
It
may
be
a
very
resource,
constrained,
client,
and
maybe
you
can
only
hand
or
handle
a
couple
of
services
coming
back
at
a
time,
because
the
size
of
the
service,
each
service
chunk
could
technically
be
rather
large,
but
does
it
make
sense
that
the
client
be
able
to
specify
the
number
of
items
on
every
single
step
as
through
everything
meaning?
Should
they
be
able
to
change
it
on
each
iteration
or
once
they
set
it
once
for
their
queries?
They're
stuck
with
that?
That's
sighs
all
the
way
through
anybody
have
an
opinion
on
that.
I.
B
Right
I
think
that's
I,
think
that's
closer
to
what
this
is
saying
right.
This
is
saying
this
references.
The
next
element
and
I
want
the
next
100
after
that
right,
and
that
makes
perfect
sense
to
me.
It's
when
you
have
situations
like
this,
that
it
gets
less
clear
to
me
right
is
this
saying:
I
want
the
next
100
or
each
page
size
is
100
and
I
want
the
next
one
nerd,
because
that
right,
because
if
it's
a
paid
size,
that's
going
to
influence
how
big
each
page
is
right.
B
N
So
consider
the
situation
where
you
have
a
schema
of,
let's
say
a
hundred
different
things
and
if
five
percent
of
them
are
giant
schemas
mm-hmm,
so
your
each
page,
even
though
I
have
the
same
amount
of
elements,
would
be
dramatically
different
sizes.
So
I
don't
know
if
you
want
to
talk
about
element,
counts
or
payload
size.
B
B
Okay,
in
that
case,
the
other
one
that
popped
up
as
I
was
implementing.
It
was
I
realized
that
as
a
client,
if
I'm
periodically
querying
a
discovery
service,
just
to
see
whether
the
list
of
services
have
changed,
I
need
to
be
able
to
have
a
unique
field.
I'm,
sorry,
eight,
an
immutable
field
in
each
service
to
know
that
that
field
will
never
change,
because
that
way,
if
it
does
change
or
advantages,
I
should
say
that
I
can
be
assured
that
that
service
is
gone
now.
B
Another
one
may
have
popped
up
with
the
exact
same
bit
of
metadata.
You
know
exact
same
name
everything
else,
but
because
of
this
unique
field,
as
it's
now
no
longer
appears
in
the
results
set.
I
need
to
think
of
it
as
a
completely
new
service,
whatever
that
means
from
a
client
perspective
right,
and
so
what
I
was
thinking
was
making
the
service
name
be
that
immutable
field.
B
If
we
don't
want
name
to
be
immutable
because
people
may
have
fat-fingered
it
and
they
want
to
change
it,
then
we
may
need
to
come
up
with
a
EE,
a
more
normal
immutable
field
like
an
ID
and
use
that
going
forward
and
say
look.
We
don't
actually
use
this
for
anything,
but
we
need
it
there
for
this
consistency,
check
kind
of
thing
or
you
know,
newness
check.
What
are
you
gonna
call
it
anyway,
I'd
like
to
I,
like
some
input
on
that?
K
If
the
service
name
is
information
or
is
no
I,
presumably
it's
not
it's
probably
more
product
related
yeah.
The
events
themselves,
presumably
are
going
to
be
pretty
durable.
You're
not
going
to
you,
know,
discard
an
event
type
and
then
suddenly
recreate
it
with
a
completely
different
schema
attached
to
it.
So
I
could
see
you
know,
as
we
always
do
our
product
teams
turning
around
and
you
know
rebranding
things
and
putting
yo
events
into
different
families,
but
I'm
not
quite
sure
what
the
intention
of
the
value
is.
It
does
raise
an
interesting
point
of.
K
K
It
is,
but
it
suddenly
struck
me
when
you're
talking
about
changing
things.
It
led
me
down
that
road
of
okay.
Well,
what
are
the
scenarios
where
you're
going
to
change
something?
What
would
cause
you
to
you
know:
remove
a
service,
for
instance,
and
I.
Don't
think
you
should
be
able
to
just
blindly
remove
one
without
you
know
having
at
least
the
capability
to
say.
Oh,
it's
changing
or
it
will
be
going
away.
Yeah.
B
I
think
that
may
be
worthy
of
a
separate
issue
to
bring
up
to
have
that.
Have
that
discussion
so
going
back
to
this
one
I
think
I'm
leaning,
if
I
read
you
correctly,
Gemma
I
think
I'm
leaning
more
towards
what
you
were
saying
as
being
accurate,
which
is
even
if
we
expected
the
name
to
be
kind
of
geeky
and
not
necessarily
human
readable,
because
that's
kind
of
what
description
is
for
I
just
can't
help
but
get
the
feeling
that
someone
may
change
that
name
from
time
to
time
right.
B
You
know
they
may
change
their
product
name
and
therefore
they
want
to
stop
calling
it
github.
They
want
to
start
calling
it
foo
hub
or
something
like
that
right,
but
everything
else
stays
the
same
and
they
want
everybody
to
think
of
it
as
the
same
service.
It's
just
they
have.
You
know
anybody
shows
this
name
in
there
to
their
clients,
so
they
want
to
stop
saying
github
right
or
something
like
that.
B
So
I'm
leaning
more
towards
saying
each
of
these
things
needs
to
have
a
unique
identifier,
that's
immutable,
and
that's
for
no
other
purpose
other
than
this.
This
check
that
we're
talking
about
here
that
way,
we
don't
have
to
worry
about
fat
fingers
or
anything
like
that.
Anyway,
where
are
your
hands
up
yeah.
L
Like
if
you
change
it's
like
a
new
service
anyway,
so
I
don't
understand.
Why,
like
what
is
interest
of
immutable,
because
if
you
rename
the
service,
it's
still
a
new
service
and
the
discovery
the
way
you
match
it,
it's
not
gonna
be
the
same
anyway.
So
because
we
formula
specification,
the
discovery
is
based
on
the
name
or
maybe
I
did
the
wrong
implementation
and
acted
based
on
the
type.
So
it's
already
kind
of
immutable
in
you
know
sense
me.
B
Tell
you
what
let's
take
this
offline,
because
I
don't
think
we
have
time
to
dive
into
the
deep,
but
I
do
think
it's
important
that
that
receivers
of
this
information
be
able
to
know
when
something
changes,
metadata
versus
advantaged,
because
I
think
as
a
consumer.
This
information
I
may
need
to
do
two
different
things
right,
because
I
may
have
my
own
customers
who
are
using
the
service
and
they
need
to
know
whether
their
service
just
vanished
and
then
down.
They
need
to
pick
a
new
one
to
use
or
stop
using
it
versus.
Oh,
it's.
B
L
L
B
The
problem,
though,
right
that's
the
problem,
because,
if
all
you
did
is
you
change
your
name,
but
you
don't
want
to
disrupt
any
of
your
people
who
are
subscribed
to
you.
You
definitely
don't
want
to
unsubscribe
them
right,
because
the
simple
name
change
should
not
screw
up
any
existing
subscriptions.
L
L
B
I
agree
that
it
may
be
someone
else's
decision
to
make.
We
may
we
don't.
We
could
choose
them
to
to
say
something
one
way
or
the
other
in
the
spec,
but
if
we
leave
it
up
to
the
implementation
decide
they
still
need
a
mechanism
to
be
able
to
make
that
choice
themselves,
and
if
we
don't
give
them
a
unique
field,
that's
immutable.
They
don't
have
a
choice
and
that's
that's
that's
where
I'm
worried
about,
but
anyway
we're
running
out
of
time.
We
could
talk
about
that
through
the
issue
itself.