►
From YouTube: CNCF Serverless Working Group 2020-09-17
Description
CNCF Serverless Working Group 2020-09-17
B
I
I
just
looked
at.
I
just
looked
at
the
document
like:
oh
it's
everything
is
there
already
doug.
Is
I'm
thankful
that
doug
is
doing
this
because
this
group
would
not
be
what
it
is?
If
you
were
there.
A
A
This
is
over
because,
like
other
things
going
on
and
then
friday
is
either
you
know
you're
doing
your
normal
work
or
you're
kind
of
slowing
down
a
little,
because
it's
almost
the
weekend
kind
of
stuff,
and
I
keep
thinking
okay,
you
know
I
don't
necessarily
have
to
to
go
back
to
some
of
my
action
items
from
from
the
serverless
working
group.
I
could
save
it
either
for
the
weekend
or
early
next
week,
but
then
the
next
thing
I
know
the
weekend's
gone
and
then
I'm
I'm
looking
at
monday,
and
it's
like,
oh
my
gosh.
A
I
want
to
get
this
stuff
done.
I
only
have
until
tuesday
night
to
get
it
done
because
of
the
deadline
for
people
to
be
able
to
review
it
and
the
next
thing
I
know
it's
like
after
tuesday
and
it's
like,
oh
crap,
I
missed
the
deadline.
So
I'll
just
wait
till
later,
and
then
it's
like
this
perpetual
thing
of
never
having
the
time
to
actually
work
on
the
stuff.
I
wanted
to
work
on
yeah.
B
D
A
D
B
By
the
way
for
while
we're
waiting,
I
think
I
think
in
the
in
the
schema
registry
spec,
there
will
be
the
first
use
of
cloud
events
for
cloud
events
cool,
because
I've
been
thinking
about
how
to
do
replication
and
because
we'll
have
to
go
and
share
the
schemas.
Obviously,
and
I
think
the
way
the
best
way
to
do
this
is
to
raise
cloud
events.
E
B
Cool,
so
that's
kind
of
how
this
is
all
going
to
tie
together
is
by
by
raising
events
whenever
this
is
their
state
changes
and
then
whoever's
subscribed
can
go
in
and
pull
this
the
state
changes
or
the
the
schema.
That's
changed.
A
Makes
sense
I
mean
that's
what
we're
thinking
about
doing
with
the
discovery
endpoints
as
well
right,
because
I
know
people
want
to
subscribe
to
see
changes.
That's
right!
So
that's
that's!
How
we
generation
yep.
Should
we
go?
Get
your
own
dog
food,
hey
mark
and
ginger?
Are
you
there.
F
G
A
H
Outside
that
is
ugly
yeah,
there's
actually
a
good
island
view
out
there,
but
not
today
or
not
for
the
past
week,
interesting.
A
And
minister
scott
brian
either
hello,
doug,
hello
and
mr
baldwin,
hello,.
A
A
All
right
gem
welcome,
hey
all
right!
Why
don't
we
go
ahead
and
get
started?
It's
three
after
what
about
my
mind,
just
so,
you
stop
there
for
a
sec,
okay,
ai's,
okay,
community
time,
anything
from
the
community.
People
want
to
bring
up.
That's
not
on
the
agenda.
A
All
right,
we
do
have
an
sdk
call
right
after
this
one
this
week
I
don't
think
there's
anything
on
the
agenda
as
of
right
now.
So
if
you
have
anything,
please
go
ahead
and
add
it
before
the
end
of
the
call,
otherwise
it'll
be
a
very
short
call.
Interop
discovery,
I'm
not
sure,
there's
anything
worth
mentioning
from
last
week,
but
I
think
actually
a
lot
of
people
have
to
drop
off
for
the
phone
calls
scott
or
anybody
else
who's
on
that.
Can
you
guys
think
of
anything
worth
mentioning.
A
Okay,
not
hearing
anything
moving
forward.
I
don't
see
team
we're
on
the
call
to
give
an
update
on
workflow.
I
do
believe
they've,
so
they
voted
on
a
new
logo.
Unfortunately,
I
don't
have
it
handy
to
show
you
guys
but
their
their
work.
They
have
a
new
logo
now
and
I'll
try
to
find
that
and
place
it
into
the
web
into
the
slack
channel.
If
you
guys
are
interested
all
right
before
we
get
into
the
core
part
of
the
agenda.
Are
there
any
other
topics?
People
wanted
to
bring
up
that?
F
Let
me
let
me
see
here,
man.
F
Okay,
you
can
stare
at
my
sweet
sweet
prompts.
So
I
have
a
little
go
program.
That's
implementing
the
discovery
api
as
it
sits
in
the
repo
right
now.
I
didn't
have
a
chance
to
implement
epoc
yet,
but
I
kinda
wanna,
I
wanna
show
what
I
think.
Discovery
aggregation
and
propagation
looks
like,
so
I'm
going
to
set
up
a
scenario
here.
So
I'm
going
to
talk
about
this
as
this
is
the
left
box,
middle
box
and
right
box.
F
The
left
box
is
going
to
be
this,
so
this
is
all
local
host.
There's
no
kubernetes
or
anything
it's
just
running
locally.
F
This
thing
is
going
to
run
on
port
8080,
but
and
then
ignore
this
downstream
thing
I
have
well.
Maybe
I
can
show
you
the
kind
of
what
I'm
seeing
this
stuff
with.
I
have
some
config.
F
F
It's
not
really
that
interesting.
It's
just
the
discovery
server,
so
we
can
curl
localhost
at
8080
and
ask
for
its
services.
F
F
I
mean
I'm
using
jq
to
just
strip
out
everything
except
for
the
service
name,
so
we
can
see
what
services
this
particular
discovery.
Endpoint
is
aware
of
it's
getting
some
errors
because
of
a
future
demo.
Ignore
that
so
we'll
set
up
a
the
middle
box,
this
one's
going
to
run
on
81.81
and
it's
downstream,
is
going
to
be
82..
F
Right,
okay,
so
the
left
boxes
downstream
is
8181,
which
is
the
one
we
just
started
up.
It's
getting
can't
talk
because
the
the
next
server
hasn't
started
that,
but
here
you
can
see
service
c
outdated.
I'm
kind
of
I'm
trying
to
say
that
this
has
a
copy
of
service
c,
but
it's
out
of
date
in
terms
of
like
what
the
most
recent
c,
what
c
looks
like,
and
you
can
see
that
that
propagated
over
to
the
first
server.
F
F
So
we'll
run
that
we'll
watch
its
services
and
now
we
can
kind
of
see
the
the
a
b
and
c
propagates
down
the
chain
all
the
way
to
the
left
side,
which
that's
neat,
that's
neat
where
it
gets
fun
is
you
can
make
a
ring
if,
if
you
so
like,
you
can
imagine
like
in
a
very
complex
system,
you
might
accidentally
make
a
ring
unintentionally.
F
So
we'll
start
that
so
the
left
hands
downstream
service.
Oh
sorry,
the
right
hand's
downstream
service
is
the
left-hand
server.
So
now,
after
a
couple
seconds,
this
thing
is
going
to
pick
up
all
of
the
xyz.
It
also
picked
up
d.
So
so
now
everything
knows
about
everything
else,
which
is
neat
which
brings
me
to
why
we
need
epoch.
F
So
I'm
going
to
start
based
on
timing.
So
this,
the
middle
server
here
has
has
reintroduced
service
c
as
an
outdated
thing,
but
it's
going
to
continue
to
propagate
and
now
it
starts
walking
the
ring
which
is
kind
of
entertaining
to
watch
and
the
reason
they
can't
understand
how
to
reconcile
the
outdated
c
versus
the
this
updated
c
is
because
it
has
no
way
to
understand
which
one
is
the
most
relevant
one
in
this
ring.
So
it
like
it'll,
never
actually
fix
itself
it'll
just
cycle
forever,
but
that's
my
demo.
A
A
Oh
crap
hold
on
I'm
sharing
the
wrong
thing.
Let's
try
this
again.
A
Okay
again!
Thank
you,
scott.
I
liked
it
all
right,
so
tell
you
what,
since
he
just
talked
about
the
epoch
thing,
let's
talk
about
that
one
first,
so,
unfortunately,
both
of
my
prs
were
updated.
I
think
technically
too
late
to
do
any
kind
of
vote
today,
but
even
so,
I
still
think
people
need
time
to
review
it.
So
on
this
one,
this
is
the
epoch
one.
I
basically
took
what
we
talked
about
last
week
and
said:
okay,
we're
going
to
go
with
epoc,
which
is
just
a
number
it's
an
integer.
A
It
has
no
semantic
meaning.
People
can
technically
put
anything
they
want
in
there,
whether
it's
just
a
counter
or
it's
an
actual
unix
in
timestamp
kind
of
thing.
That's
up
to
the
implementation
choice.
The
only
requirement
is
that
it
must
always
increase,
as
it
goes
forward
as
the
service
entry
is
actually
updated,
and
that's
basically
it
in
terms
of
what
I
made
here
in
terms
of
changes.
A
Yep:
okay:
okay,
unless
there
are
other
comments
or
questions
I'll
leave
it
for
you
guys
to
review
it
for
wordsmithing
type
stuff,
but
if
you
guys
think
in
general,
it's
heading
in
the
right
direction,
just
need
to
worry
about
wordsmithing.
We
can
do
that
offline.
So
any
questions,
high
level
questions
comments.
A
All
right
cool,
thank
y'all
rest
apis
again
too
soon
to
vote
or
anything,
but
so
this
one,
let's
see
if
I
can
remember
all
the
changes
I
made
so
I
think
the
biggest
change
that
I
made
was
to
split
out
the
apis
into
two
sections.
Let's
ignore
that
for
a
minute
I
split
it
into
discover
apis,
which
has
basically
just
the
gets,
and
it's
a
get
of
services
with
a
get
of
services
with
a
name.
Okay,
I
think
that's
what
we
had
in
there
before
so
I
didn't.
A
I
didn't
really
change
a
whole
lot
in
there
other
than
I
added
a
little
more
clarity
around
what
the
response
codes
could
possibly
be
mentioned.
You
can
use
pagination
in
case
the
list
of
services
is
too
long
again,
just
return
code
type
stuff.
Hopefully
nothing
in
there
is
too
shocking,
but
then
the
big
change
is
the
management
api
section.
A
However,
on
the
post
side
of
things
make
it
so
that
you
can
obviously
add
a
new
service
entry
by
just
doing
a
post,
this
one
is
it's
expected
that
there
is
no
id
associated
with
it,
so
one
will
be
assigned
by
the
endpoint
by
discovery
endpoint.
However,
if
you're
doing
a
put
that
in
cases,
for
example,
you're
doing
an
import
or
you
just
want
to
update
an
existing
one,
obviously
the
id
is
already
in
there
and
therefore
it
must
be
inside
the
service
entry
as
well,
and
that
is
fairly
straightforward.
A
I
do
talk
about
how
the
id
needs
to
make
sure
it
gets
updated
during
the
up
during
the
put
because
it
is
an
update.
However,
there's
one
gotcha,
I
want
to
point
out
make
sure
you
guys
are
aware
of
this.
A
Okay,
so
down
in
here
when
you
do
an
import,
if
you,
if
you're,
trying
to
do
an
import,
but
that
id
is
already
being
used
by
the
discovery
service.
A
So
I
decided
to
add
logic
in
here
that
says:
well,
if,
as
a
client,
if
you're
doing
an
an
import
and
thing
where
it
exists,
you
have
to
first
delete
it
because
the
problem
is,
I
don't
know
whether
to
update
the
epoch
or
not
right,
because
on
an
update
I
should
it
should
get
updated
on
an
import.
It
should
not.
So
it
got
a
little
funky
there.
I'm
not
sure,
that's
actually
the
right
answer.
A
A
So
maybe
we
need
to
add
a
query
parameter
or
something
that
says
import
as
opposed
to
a
generic
update.
I
don't
know
I
thought.
Maybe
somebody
else
would
have
a
more
brilliant
idea
or
anything
idea
whatsoever,
because
I'm
not
happy
with
what
I
came
up
with,
but
it
was
late
last
night
anyway,
that's
about
it.
I
do
allow
for
deletes
to
be
asynchronous
as
well,
but
anyway,
let
me
go
ahead
and
pause
there.
You
guys
can
read
it
on
your
own.
Hopefully
it's
not
too
earth
shattering.
A
Oh,
I
should
say
for
the
asynchronous
stuff.
I
thank
you,
klaus,
for
the
link
to
how
odata
does
it.
I
didn't
exactly
take
what
they
did,
but
I
used
some
of
the
similar
thoughts
they
had
in
there
and
clemens.
You
had
a
comment
last
week
about
trying
to
do
301,
redirects
and
all
this
other
stuff
and
I'd
be
honest.
A
A
J
A
I
actually
did
not
talk
about
that,
yet
I
was
kind
of
assuming
it's
a
hard
delete,
but
if
someone
wants
to
offer
something
different
that
I
don't
know.
B
F
I
think
the
soft
versus
hard
delete
might
matter
for
the
downstream
consumers.
So,
if,
like
in
my
example,
if
the
middle
ring
deleted
the
d
service,
how
does
the
downstream?
How
does
the?
How
does
the
upstream
server
know
the
downstream
service
understand
that
d
no
longer
exists,
because
it
doesn't
exist
on
the
payload
anymore?
B
If
you,
if
you
make
soft,
delete
a
thing
in
the
protocol,
then
you
also
have
to
figure
out
how
to
go
and
resume
things
and-
and
you
really
have
to
then
include
collision
warnings,
because
you
can't
create
something
that
doesn't
list,
but
there's
some
there's
some
deleted
record
in
the
back.
That
might
cause
it
to
cause
a
conflict
anyways.
J
Slope
it
is,
I
mean,
I'm
just
and
again,
maybe
maybe
I'm
misinterpreting,
but
if
I'm
a
client
that's
using
one
of
these
services
and
suddenly
it
just
disappears
under
my
feet
I
mean
you
where's.
The
life
cycle.
Management
of
this
service
is
about
to
go
away
yeah,
so.
F
J
A
B
We
have
a
we
have
in
our
services,
we
have
a
status
field,
which
kind
of
says
you
know
creating
deleting
and
then
the
various
states
of
liveness,
and
that
might
make
sense
to
go
and
introduce
that
here
that
you
have
that
you
have
a
status,
which
is
the
thing
doesn't
really.
The
thing
is
not
deployed
right
now
or
it's
not
reachable,
but
it
nevertheless
exists.
J
B
J
I
guess
from
my
standpoint:
it's
the
other
angle,
where
you
know:
if
something
is
deprecated,
you
shouldn't
maybe
advertise
it,
but
that
doesn't
stop
me
from
continuing
to
use
it
yeah
until
you
know,
until
its
replacement
has
arrived,
yeah
yeah,
but
then
I
think
the
status
will
do
our
job
it.
It
would
if,
if
that's
the,
if
that's
the
proposed
mechanism,
I
I
wasn't
aware
that
that
data
went
down.
So
that's
all
level
you
have
to.
J
If
you
deprecate
something
I'd
also
expect
to
know
when
it's
going
to
be
retired
altogether,
you
know
so
otherwise
how
can
I?
How
can
I
plan
my
work?
Yeah,
it's
something
we
face
internally,
yeah
at
paypal
with
people
wanting
to
create
new
stuff,
all
the
time
and
change
versions,
and
having
an
understanding
of
something.
The
fact
that
something
is
deprecated.
Therefore,
I
shouldn't
use
it.
I
shouldn't
build
new
stuff
on
top
of
it,
but
it
will
continue
to
operate
for
a
certain
period
of
time.
J
A
Okay,
scott,
your
hands
up.
F
A
C
I
agree
with
jim
I
I
wrote
that
up
in
paypal,
api
guys-
and
I
was
just
going
to
post
a
link
for
that.
I
think
it's
on
the
public
guidelines,
I'll
write.
It
write
the
link
here
for
the
deprecation
okay,
cool
thanks,
jim
okay.
A
A
A
A
A
F
Oh
the
total
service
list.
I
see
I
yeah
okay,
I
I
think
we
need
to
figure
out
how
to
do
that
because,
like
in
the
aggregation
case
that
becomes
very
complicated,
because
if,
if
right,
if
d
disappears,
I
don't
know
to
delete
it
because
it
could
have
come
from
some
other
downstream
and
I'm
doing
a
merge
of
things.
I
know
not.
A
All
right
sorry
hold
on
my
my
screen.
Just
does
some
really
weird
stuff,
so
I'm
not
sure
what
you
guys
are
seeing
from
sharing
perspective
there
we
go
so
should
I
should
I
open
up
a
separate
issue,
because
it
sounds
like
this.
This
might
require
some
more
thought
process
beyond
just
trying
to
introduce
some
of
the
some
management
apis.
F
A
A
Oops
golly,
okay,
eric
your
hands
up.
G
Yeah
this
this
might
be
way
too
out
of
left
field,
but
I
thought
that
was
coming
up
for
me.
While
I
was
listening
to
all
this
good
discussion.
Is
that
there's
kind
of
this
discussion
of
this
materialization
as
a
the
source
of
truth
for
these
described
services,
and
it
seems
to
me
that
it's
maybe
a
little
ironic
that
we're
not
instead
offering
a
kind
of
stream
of
events
or
a
log
of
events
that
can
be
just
consumed.
G
That
says:
hey
the
the
last,
although
here's
the
entire
history
of
what
what
I
know
about
this
service
and
the
last
entry
on
that
service
is
it
it
was
requested
to
be
deleted.
I
don't
know
if
that's
terribly
helpful,
but
it
might
be
potentially
a
different
way.
We
could
approach
this
rather
than
worrying
a
lot
about
how
we
specifically
materialize
the
state
of
or
of
our
knowledge
of
the
service.
We
could
instead
just
keep
a
history
and
here's
our
latest.
You
go
for
that
latest.
There's
nothing
there!
G
B
I
I
think,
that's
a
very
reasonable,
reasonable
thought
and
actually
before
before
most
people
joined.
I
mentioned
that,
certainly
for
the
for
the
service
registry
spec.
B
I'm
planning
to
have
state
change
events
that
that
do
what
you
just
proposed
and
that
is
like
whenever
the
the
state
changes
that
you
can
then
learn
about
that
state
change
as
a
subscriber
and
then
basically
keep
track
of
it
and
then
for
attaching
as
a
fresh
subscriber,
it's
fathomable
that
you
know,
given
that
your
delivery
path
supports
it,
you
could
basically
subscribe
to
from
the
start,
and
if
you
subscribe
to
the
start,
then
the
existing
state
of
the
service
registry
is
basically
played
to
you
as
inserts
as
insert
statements.
B
B
If
you
will
so
so,
that's
something
that
I
certainly
have
thought
about
for
the
the
for
the
service
registry,
and
it
might
also
be
for
discovery
that
discovery
synchronization
on
in
the
on
on
in
flight
happens
through
raising
of
events.
B
But
there
will
always
be
the
case
that
delivery
is
difficult
and
that
you
have
to
go
and
effectively
do
this
from
a
client
that
sits
behind
a
firewall,
etc,
where
you
need
to
have
some
imperative
way
of
of
of
manipulating
the
store
kind
of
from
the
outside,
with
the
in
the
correct
way.
So
I
think
what
we're
doing
here
is
not
is
is
useful,
but
I
think,
having
an
event-driven
way
to
also
do
synchronization
will
also
be
great.
So
I
second.
C
That
so
is
it.
It
also
mean
that
we
are
adding
the
requirements
for
consistency
for
implementation,
because
the
events
have
to
be
presented
in
a
consistent
manner
right
from
any.
You
were
showing
the
demo
and
it
was
a
kind
of
eventual
consistent
kind
of
scenario.
C
So,
anytime
you
try
to
access
the
latest
event.
Maybe
you
know
you
know
whichever
server
you
are
hitting,
it
may
not
have
the
latest
event,
but
dns
is
like
that
right.
F
One
way
you
could
do
this,
is
you
keep
the
top
level
get
services
and
then
you
introduce
the
services,
slash
epoch
or
something?
And
you
ask:
what's
the
what's
the
changes?
What's
the
changelog
since
this
last
epoch
that
I
knew
yeah
and
you
could
get
that
sub
list,
which
is
really
interesting
idea,
yeah.
B
A
So
that's
actually
interesting
so
hold
on
a
minute
that
would
put
a
new
requirement
on
to
do
because
I
like
that
idea,
but
we
would
need
to
make
it
so
that
the
epoch
doesn't
just
go
up
for
that
one
service
entry.
It
goes
up
across
the
board,
so
between
two
service
entries
you
could
see
which
one
was
updated
latest
right,
because
otherwise,
scott
you
couldn't,
you
could
have
a
global
epoch
for
your
get.
F
A
A
G
Oh
goodness,
this
is
the
big
can
of
worms
that
I'm
opening.
I
guess
I
I
don't
think
that
there's
anything
inconsistent
about
using
a
log
of
events
to
create
the
materialization
that
we've
been
talking
about
interacting
with
via
this
rest
api.
I.
A
Yeah
this,
because
one
thing
that
wasn't
clear
to
me
when
you
described
it,
was
whether
you
were
suggesting
that
we
offer
up
a
log
or
a
stream
event
type
of
thing.
In
addition
to
what
we
see
here
or
not
or
whether
you're
suggesting
you
know
what
we
only
have
the
logs
and
and
and
then
there
really
wouldn't
be
a
way
to
say.
Just
give
me
the
latest
snapshot,
which
is
what
I
think,
the
the
rest
apis,
as
I
proposed
here,
offers
up.
G
The
way
that
feels
compact
to
say
that
is
fairly
indelicate,
a
lot
of
a
lot
of
the
engineers
that
I've
worked
with
would
struggle
to
really
work
with
a
a
log-driven
conception
of
the
history
of
a
service
that
sets
more
in
depth.
There's
more
to
know
to
do
that,
but
a
materialization
is
easy
for
them,
and-
and
it
comes
up
with
consistency,
problems
and
other
issues
like
that.
G
So
I
would
think
that
kind
of
the
law
would
form
the
core
of
it,
and
some
specialized
code
would
know
how
to
materialize
that
and
then
those
that
are
more
interested
in
just
the
latest
snapshot
or
don't
want
to
do
any
of
the
extra
work
which,
for
great
business
reasons
or
whatever
can
just
access
that
materialization.
A
B
And
I
agree
that,
because
we
need
to
have,
we
need
to
have
a
way
to
communicate
the
the
event
view
over
the
wire
as
cloud
events,
of
course,
and
so
that's
that
we
need
to
go
and
express
that,
of
course.
F
I
think
I
have
enough
time
for
next
week.
I
would
like
to
demo
exactly
what
clemens
just
asked
about
where
each
of
that
the
services
in
the
demo
produce
cloud
events
when
their
catalog
changes,
so
that
was
like
phase
four
of
my
prototyping
that
I've
been
doing.
I
just
didn't
have
time
to
get
to
it,
but
maybe
I
can
get
to
it
this
week
and
show
it
off
next
week.
A
Sounds
good
to
me,
okay,
so,
to
try
to
wrap
this
up.
I
think
jem
was
going
to
open
up
an
issue
around
deletes.
I
think
eric
you
were
going
to
open
up
an
issue
around
the
the
the
logging
interface
thingy,
sound
good,
so
far,
okay
and
so
back
to
the
pr
itself.
As
I
said,
I
don't
want
to
merge
it
today.
I
think
you'll
need
time
to
read
through
it,
but
from
a
high
level
conceptual
point
of
view:
does
the
direction
seem?
Okay,
so
far,.
A
Okay,
not
hearing
any
complaints,
so
please
just
review
review
review
it
then
for
wordsmithing
or
whatever
and
we'll
see
we
can
get
this
thing
in
next
week.
All
right!
Thank
you,
everybody!
Okay!
So
let
me
between
these
two
I
know
they're
both
really
new,
but
jim.
Do
you
have
an
update
on
the
protobuf
stuff
that
you
want
to
talk
about
today,
or
should
we
punt
until
next
week?
I
wasn't
sure
there's
a
status
of
that.
J
Actually,
I
I
think
we're
pretty
much
done
so
that
that's
a
late
breaking
update.
There
was
some
concern
from
one
of
the
reviewers
around
some
of
the
language
in
our
overall
spec
to
do
with
time
stamps
because
he
had
concerns
around
you
know
if,
if
a
publisher
sends
a
timestamp
him
in
one
yo
know
stringified
format,
for
instance,
and
it
and
it
arrives
at
the
other
end.
Maybe
without
you
know
it
gets
changed
from
an
offset
basis
to
a
utc
zulu
time
basis.
J
You
know,
was
there
an
expectation
that
local
offsets
had
been?
You
know,
retained
across
transports
or
formats
and
having
had
a
quick
chat
with
with
clemens
yesterday
that
that
doesn't
seem
to
be
the
that's,
not
the
expectation.
J
So
it's
really
a
question
of
whether
I
want
to
tweak
the
spec
a
little
bit
just
to
make
that
more
expensive
other
than
that.
I
think
we're
basically
done.
I
will
ask
for
one
more.
You
know
round
of
votes
from
from
all
the
different
people
that
have
chimed
in
on
that
pr,
but
one
of
the
longest
running
prs,
I
think,
did
I
know.
A
A
J
B
J
A
I
Yeah,
so
I
tried
to
to
draft
our
socket
protocol
binding
specification.
I
I
try
to
to
take
inspiration
from
the
existing
implementations.
We
have,
in
particular
the
sdk
javascript
as
a
very
well
made
sample
of
sending
javascript
outstanding
web
sockets
over
javascript,
and
what
I
did
is
that
I
just
put
these
in
the
words,
so
the
the
two
big
things
of
the
spec
is
that
you
send
events
just
inside
the
websocket
message.
I
So
one
websocket
message
is
one
cloud
event
which
is
serialized
with
an
event
format
and
in
order
to
agree
on
the
event
format,
we
use
the
sub
protocols
feature
of
websockets,
so
maybe
maybe
open
the
readme.
Where
I
have
an
example,
this
one,
no,
no,
no,
I
have
in
not
three
flights
changed.
I
Yeah
down
down,
where
is
the
example
below
below
okay,
this
one?
So
this
is
the
example
handshake.
This
is
a
normal
and
shake
of
websocket,
so
the
client
does
a
get
request
and
add
the
upgrade
the
websocket
and
the
server
applies
with
with
connection
upgrade.
So
the
only
thing
that
we
add
here
is
that
websocket
allows
you
to
say,
allows
the
client
to
specify
what
protocols
it
can
understand.
I
So
in
this
case,
I
coded
our
event
formats
to
to
somewhere
to
to
the
websockets
sub
protocols
and
the
server
when
it
replies,
says:
okay,
I've
chosen
this
sub
protocol,
which
in
this
case
is
json
cloud
events.
That
means
that,
during
all
the
stream,
the
events
will
be
sent
always
as
json,
so
using
the
json
even
format
and
that's
all
the
spec.
Basically,
then,
it's
just
words
and
formalities,
cool.
C
B
I
I
We
basically
encode
this
information
in
the
path
so,
like
you,
do
slash
events
plus
json
to
get
events
as
json
yeah
yeah.
But,
to
be
honest,
I
prefer
this
one
because
you
have
the
choice
so,
for
example,
in
this
case,
if
the
server
doesn't
support
json,
I'm
just
saying
it
could
reply
with
abram,
because
the
client
gave
the
choice,
use,
json
or
use
opera.
B
No
yeah
yeah,
I
mean
yeah
exactly
they're
grinding
something
something
something
rubs
me
the
wrong
way
about
this,
but
I
can't
articulate
what
rubs
the
wrong
way
about
this.
So
I
have
to
stare
at
this
at
this
that
I
might
also
be,
in
the
end,
be
okay
with
it.
So
I'm
not
sure
yet,
where
that,
but
it's
putting
putting
the
co
putting
what
effectively
is
the
content
type
of
the
the
the
cloud
event
kind
of
baking
that
into
the
protocol?
Identifier,
that's
kind
of
what
is
like
that
jumps
in
my
eye
and
says.
B
So
so
I'll
I'll
consider
it
and
then
I'll
I'll
give
comments
on
it.
I
don't
think
it's
necessarily
wrong.
It's
just.
I
That
I
think
I
think
you
should
look
at
it
from
from
another
point
of
view.
So
in
this
context
we
are
talking
about
a
full
duplex
stream
where,
but
in
in
both
ways
you
send
cloud
events
right,
yeah.
So
the
protocol
here
is:
how
do
you
send
the
calibrate
and
this,
how
it's
the,
how
you
serialize
the
cloud
event
to
send
it
to
me
so
and
if
you
think
about
that
that
that
then
this
is
kind
of
the
protocol,
the
the
sub
protocol,
which
is
the
name
that
gives.
B
I
think
what
what
is
what's
poking
me
is
that
if
we
introduce
message
pack
or
sibor,
if
when
then
we'll
have
to
go
and
update
that
spec.
I
Well,
well,
well,
wait
wait,
so
I
think
it's
fine
to
just
use
the
the
other
content
types.
So
we
could
you.
I
think
we
could
use
application,
slash
called
events
plus
json.
I
think
we
can
do
that.
The
reason
why
I
use
this
notation
store.
Json.Cloud
events
is
just
to
follow
the
guidelines
of
the
spec,
but
I
mean
we
can
bend
those
guidelines
and
use
our
content
types.
So
we
don't
have
to
update
this.
B
I
think
there
are
some
that
there
is
a
bit
more
to
negotiation
in
the
web
sockets
in
web
sockets.
So
so
I
think
we
understand
each
other,
so
my
I
think
my
concern
boils
down
to.
B
I
would
like
for
the
bindings
for
these
binding
specs
to
be
stable,
while
we
add
more
encodings,
if
possible,
right
with
json
being
the
weird
exception,
because
that's
the
universal
stuff
that
everybody's
is
doing,
but
otherwise
I
would
like
for
us
to
be
able
to
add
seabor
and
not
touch
any
of
the
any
of
the
the
specs
to
be.
You
know
for
special
immunes,
etc.
I
B
Okay,
I
mean
I
mean
your
choice,
that's
something
that
debatable
it's
in
the
end,
we're
all
gonna
agree
on
it,
but
I
just
that
was
my
reaction
to
it's
like.
This
is
a
little
I'm
always
thinking
about
the
the
extensibility
angle
and
stability
of
the
specs
angle
when
we
are
making
this
composable.
So
that's
the!
So
that's
my
I
think.
That's
ultimately
my
concern,
let's,
let's
think
about,
let's
think
about
how
we
can
go
and
make
this
a
little
bit
more
flexible.
A
Does
it
seem
like
the
right
general
direction
to
go
aside
from
this
question.
I
I
I
I
Think,
that's
that's,
that's
actually
defined
or
to
refuse
the
upgrade.
It's
not
defined.
What
happens
where
when
the
protocol
is
not,
when
you
don't
support
any
of
the
sub
protocols,
then
you
just
don't
you
just.
B
Don't
accept
the
socket,
which
means
which
means
you
can
it's
your
choice,
whether
that's
your
whether
you
choose
to
be
that
your
your
fault
or
the
client's
fault.
But
then
I
think
the
right
answer
is
to
to
give
back
at
400.
I
B
But
since
you're
in
http
closing
the
connection
is
not
your
visit
is
none
of
your
business
at
that
abstraction
level.
Layer
right,
you
simply
refuse
you
simply
refuse
to
to
honor
the
upgraded
request
and
that's
it.
But
the
client
is
then
completely
at
liberty
to
reuse
the
connection
for
to
do
something
else.
I
B
But
you're
doing
you're
you're
out
you're
you're
doing
a
polite
applied,
request
yeah
this
is
and
that
upgrade
gets
refused
by
the
server
giving
you
a
405
or
400
and
then
the
connection
just
sits.
There
waits
for
the
next
thing
that
you
want
to
go
and
try,
but
there's
no
need
or
there's
no
need
to
close
the
connection,
because
you,
you
might
then
go
back
to
go
and
and
and
try
something
else
and
and
that
will
reuse.
You
have
look
effectively
in
in
most
http
stacks.
B
A
A
A
A
Paris,
I'm
here
excellent,
welcome.
Okay,
did
I
miss
anybody
for
the
roll
call,
okay
and
actually
hold
on?
Do
we
have
anything
on
the
agenda
for
today
we
have
nothing
as
of
right
now.
Does
anybody
have
any
topic
that
they'd
like
to
talk
about?
Otherwise
we
could
just
end
both
calls
right
here
right
now,.