►
From YouTube: Thinking Out Loud #4 — with Jesse Menning
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
all
right,
all
right,
so
one
more
time
on
thinking
out
loud
this
time,
as
some
of
you
know,
we'll
have
jesse
menin
as
our
next
guest
and
jesse
used
to
work,
for
I
mean
used
to
nassari
and
jesse
works
for
solas
in
the
office
of
the
cto,
and
I
think
that
why
am
I
introducing
him
myself
when
he
can
introduce
himself
himself
better
than
I
right
so
welcome.
Jesse
thanks
fran
glad
to
be
here.
B
Sure
sure
so
I
work
for
the
office
of
the
cto
here
at
solace,
and
my
job
encompasses
a
lot
of
things,
but
also
it
encompasses
interacting
with
the
open
source,
community
and
certainly
async.
Api
is
a
huge
part
of
that
and
we
also
have
contacts
with
cloud
events
and
with
open
telemetry.
B
A
Yeah,
so
well,
thanks
for
that
this
works.
It
actually
is
important
for
a
broker
company.
I
couldn't
think
of
a
of
a
like
better
company
or
a
better
product
that
I
think
api
will
can
be
like
more
perfectly
right,
like
brokers,
actually
were
the
reason
why
async
api
was
created,
so
you
should
totally
write
so
yeah
so
before
this.
So
you
know
before
the
before
jumping
live.
A
Jesse
was
just
challenging
me
with
the
game.
You
want
your
mind
explaining,
or
what
do
you
want
to?
How
do
you
want
to
prick
me.
B
Sure
I
I
will
say
that
I
am
an
american
in
case
you
couldn't
tell,
but
I
work
for
solace
as
a
canadian
company
and
I
love
canada.
I
grew
up
just
across
the
border
from
canada
in
michigan,
which
is
a
state
in
the
us,
so
I've
always
had
a
fascination
with
with
canada,
and
I
feel,
like
canada
has
a
greater
cultural
influence
than
people
give
a
credit
for.
B
So
what
we
have
here
and
I'll
share
my
screen
now
is
just
a
brief
quiz
for
for
fran,
that
is
there
we
go
sharing
my
screen
called
name
that
canadian.
I
think
people
can
see
the
screen
yeah,
it's
the
musical
edition.
You
know
we'll
leave
the
the
movie
stars
for
for
a
future
date,
and
so
we
have
five
photos
of
of
of
canadian
musical
acts.
B
A
I
I
I'm
mentally
not
prepared
for
anything
well
we're
gonna.
B
A
B
A
A
No
really
so
yeah
what
what
was
the
name
of
this
group.
B
A
A
I
think
I
know
I
mean
I'm
not
into
the
latest
rap
music
trace,
rapper
yeah.
I
can
you
know
you
could
guess
it
by
looking
at
him
only
but
yeah.
A
I
I'm
I
am
I
I
love.
You
know
rap
music.
As
I
told
you
before,
jumping
life,
I
used
to
break
dance
professionally
for
10
years,
so
I
listened
to
a
lot
of
rap
even
while
coding,
but
that's
why
that's
why
you
can
guess.
I
mean
this
way.
You
can
guess
that
when
I
was
rapping
when
I
was
hearing
rap
while
coding
and
not
because
you
can
see
that
my
code
completely
like
smails.
B
By
the
way
we
won't
touch
on
it
here,
but
you
should
ask
fran
about
the
callous
on
his
head
from
break
dancing.
I
mean
that
shows
real
dedication
to
the
to
the
craft
of
dancing.
I
was
saying
that
I
am
bald
as
well,
but
not
for
cool
reasons.
Just
because,
like
that's
how
I
am
fran
actually
earned
his
baldness.
So
congratulations
on
that.
B
B
A
I
know
I
know
his
face
from
somewhere.
I
don't
know,
I
think.
A
So
I
actually
love
it.
I
I
loved
it
that
you
in
this
quiz
to
introduce
you
know
to
introduce
yourself
and
to
introduce
canada.
I
freaking
love
canada,
but
I
don't
know
canada
so
much.
I
know
just
I
only
visited
once
and
now,
you're
gonna
kill
me
because
I
don't
remember
the
name
of
the
city,
because
I'm
super
bad
with
names.
A
I
have
this
problem
and
it's
a
famous
one,
so
it's
not
a
small
one.
I
it
happens
to
me
the
other,
the
other
time.
The
other
day
it
happened
to
me
that
I
had
to
google.
I
had
to
search
for
the
name
of
australia
because
I
couldn't
remember
australia.
So
imagine
that
to
that
point,
so
yeah
vancouver.
Of
course.
Thank
you
very
much.
A
Knows
vancouver
we've
been
there?
Actually,
I
think
I
still
have
his
his
his
laptop
connector
at
home,
maybe
somewhere.
A
A
So
yeah
so
jonathan
now
that
you're
watching
ass,
it
would
be
better
if
you
buy
multiple,
you
know
plaques
and
you
and
you
spread
them
all
around
the
world.
So
it's
kind
of
for
sure.
D
A
So
so
yeah
cool.
So
thanks
thanks
a
lot
for
for
this
game.
I
actually
appreciate
it
so
now
back
to
the
or
not
back,
but
let's
go
to
into
the
topic
of
the
of
the
episode
which
is
about
publish
and
subscribe.
So
some
of
you
already
know
that
we
started
this.
I
started
this
show.
A
If
you
want,
is
I
call
it
the
most
boring
show,
because
it's
not
about
show
it's
about
thinking,
right
and
and
seeing
other
people
thinking
on
the
screen
is
not
funny
at
all
or
my
might
not
be
right.
It
doesn't
have
the
television
rhythm
so
so
we
started.
I
started
this
as
a
way
to
to
ask
the
community
to
come
up
with
creative
solutions
for
the
publish
and
subscribe
challenge
that
we're
having
on
async
api.
A
Just
to
summarize
for
those
who
are
not
familiar
so
when
you
see
publish
on
an
sync
api
document,
it
doesn't
mean
that
your
application
is
publishing
a
message.
It
means
that
a
potential
client
can
publish
messages
to
you.
So
that's
highly
confusing
same
for
subscribe.
If
it
say
subscribe,
it
means
that
a
potential
client
can
subscribe
to
your
to
your
application,
but
given
that
your
application
might
be
another
client,
another
client
of
the
broker,
then
it's
where
you
know
it
becomes
chaotic.
This
definition
becomes
chaotic
and
difficult
to
understand.
A
It
all
comes
inherited
from
open
api
because
open
api.
That
relationship
is
clear,
so
we
have
a
server.
We
have
a
client,
we
are
defining
the
server
we're
not
defining
the
client
with
open
api
and
therefore
it's
easy
to
understand.
If
you
see
get
post
put
whatever
it
doesn't
mean
that
your
code,
your
server
code,
is
doing
a
get
request
somewhere.
It
means
that
you
accept
that
request
and
that's
where
the
simulation
comes
from
right,
so
so
yeah.
So
it
works.
Well,
if
you
have
a
client
server
architecture
in
async
api
as
well.
A
So
if
you
have
a
websocket
server,
it
makes
total
sense,
because
it
means
that
you
can
you're
defining
a
server
and
therefore
you
can
publish
message
to
the
server
or
you
can
subscribe
to
messages
coming
from
the
server.
So
it
still
makes
sense
in
these
cases,
but
in
the
cases
of
clients
broker
client,
it
totally
doesn't
make
sense,
so
it
is
highly
it
can
make
sense
somehow,
but
but
yeah,
it's
like
highly.
It's
highly
confusing.
B
Yeah
I
mean,
let
me
say
that
I
have
we
have
a
new
developer
relations
person,
geary
who's
fantastic
at
solas,
and
I
was
sort
of
like
walking
him
through
async
api
yesterday.
Actually
we
were
doing.
C
B
B
So
yes-
and
I
think
you
and
I
have
both-
you
know
you
at
least
you're
a
smart
guy,
I'm
kind
of
a
smart
guy
like
we've.
I
even
today
like
I
sometimes
I
like
you
know,
encounter
things
where
like
oh
no,
no,
I
got
that
wrong
like
when
I'm
trying
to
like
you
know,
write
up
an
async
api
document
or
explain
it
to
someone
like.
I
will
forget
the
publish
and
subscribe
meanings
in
sort
of
in
everyday.
A
And
and-
and
it's
highly
confusing,
it's
not
just
a
problem
because
it's
highly
confusing,
but
it's
also
limiting
the
spec
in
some
in
some
cases,
let's
say
right,
so
it
is
also
like
inconsistent
in
many
cases
like
sometimes
some
tooling
are
detecting
that
the
protocol
is
websocket
and
they're
instantly.
A
Assuming
that
what
you
want
to
create,
the
code
that
you
want
to
generate
is
a
server,
but
if
you,
if
you
have
other
protocol
like
I
don't
know
like
kafka
or
mkb
or
mqtt
or
whatever
they
instantly
assume
that
what
you're
going
to
create
is
a
client
and
obviously
because
you
don't
want
to
create
a
broker,
you
don't
want
to
generate
the
code
for
a
broker.
Usually
that's
that's
not
useful.
It
will
be
cool
for
you.
If
you
have
a
code.
A
A
A
Requests
so
so
yeah
I
mean
it's
not
usually
the
case
websockets
with
brokers,
because
you
know
websockets
are
meant
for
web
right
for
for
web
sites,
for
websites
for
web
pages
and
brokers
are
more
meant
to
be
internal
and
not
accessible
from
the
public,
so
yeah.
I
can
see
why
they're
not
playing
well
together.
B
But
I
mean
I
think
that
that
is
really
sort
of
the
sorry.
I
don't
mean
to
cut
you
off
fine,
but
I
I
think
that
is
actually
really.
B
The
the
diversity
of
you
know
the
ways
that
you
can
implement.
Async
communication
is
really
like
the
awesome
thing
about
asynchronous
communication
and
really
the
challenge
like
you
are
obviously
the
founder
and
you
so
you
bit
off
this
huge
task
to
like
try
to
encompass
all
these
different
ways
of
asynchronous
communicating
asynchronously.
B
So
in
ways
you
know
it's
a
cool
task,
but
it's
a
very
a
challenge
and
I
think,
as
a
community,
you
know
that's
sort
of
our
our
challenge
as
well.
Now
that
like
how
can
we
encompass,
like
so
many
different
ways
of
of
of
capturing
that
that
type
of
communication,
whereas
rest,
you
know
the
open
api
guys
actually
have
it
kind
of
easy,
because
that's
always
going
to
be
http,
it's
always
going
to
be
sort
of
the
same
url.
You
know.
I
know
that
lauren.
Forgive
me.
B
I
know
that
there's
web
hooks
now,
but
you
know
that
complicates
things.
I
know
it's
gonna
come
back
at
me,
but,
like
you
know,
in
a
way,
because
they're
have
a
more
constrained.
It's
always
server.
Client
like
that.
Actually
is
a
a
simpler
use
case
and
that's
still
a
pretty
complicated
spec.
But
now
we
as
async
api,
have
to
encounter
all
this
additional
complexity
which
what
you're
hinting
at
right
now.
A
Yeah,
so
exactly
so,
that's
the
the
whole
thing
right
like
so
when
I
started
this
in
kpi.
I
started
this
for
random
queue.
My
use
case
was
to
make
it
work
with
rapid
q.
Actually
in
version
one,
the
channels
were
called
topics
and,
and
the
syntax
was
using
dots
as
as
interrupting
as
in
amqp.
A
A
So
I
didn't
think
about
the
perspective
or
anything
because
yeah,
it's
not
something
that
you
see
at
first
glance,
right,
yeah,
but
and
then
I
was
using
them
the
other
way
around.
But
then,
like
soon
after
when
the
project
started,
gaining
some
more
traction,
slack
announced
that
they
were
using
async
api
for
their
web
public
websocket
api.
So
and
therefore
it
was
like
oh
so.
This
is
another
use
case.
So
this
is
not
a
broker
right.
So
it
is
point
to
point.
A
This
is
client
server
communication,
it's
just
happening
through
websocket,
not
through
http,
but
it's
client
server
anyway,
and
and
that's
completely
different.
So
if
I
was
changing-
and
I
re-
and
I
recall
that-
and
my
discussions
with
jonathan
as
well
so
jonathan
was
telling
me
like
hey,
we
should
change
this
meaning
and-
and
I
was
like
yeah:
let's
do
it
because
I'm
working
mostly
with
brokers
myself
as
well.
B
I
can't
see
the
chat.
He
can't
see
the
chat,
so
I'm
sure
he's
making
fun
of
me.
No,
I
can't
actually
I'm
not
I'm
not
logged
into
like
the
back
end.
A
A
So
I
just
was
tracked
so
what
I
was
saying
is
that
what
was
I
saying,
you're.
A
So
so
yeah
and
I
was
like
yeah:
let's
do
it,
let's,
let's
just
change
the
the
meaning
of
the
birth
to
like
pablo's,
actually
means
that
you're
publishing
to
the
broker
and
subscribe
that
you're
subscribing
to
the
broker,
and
that
will
solve
the
problem
cool
done
right,
but
no
because
then
you
have
a
websocket.
They
probably
goes
up
again
websocket
api,
like
slack,
and
it
doesn't
make
sense
anymore.
It's
like
you're.
What
are
you
defining?
You
know
it's
like.
Are
you
defining?
What
slack
is
doing?
A
Is
it's
like
it's
sending
you
a
message
as
a
client?
It
is
weird
it
is.
You
know
it's
not
defining
the
api,
it's
defining
the
behavior
of
your
application
right.
We
are
we're
creating
a
new
programming
language
based
on
yaml
here,
right
sure
I
mean
it.
It
can
be
seen
like
this,
but
it
also
somehow
makes
sense
right
so
and
also
it
has
its
other.
This
other
problem,
which
is
especially
for
public
apis.
A
That
is,
you
have
servers
right,
so
servers
are
they
have
a
url
on
where
you
can
reach
the
server
right,
the
address
to
reach
the
server?
A
So
if
you
have
any
a
public
api-
and
you
say
the
clients
should
reach
me
on
port
80,
that
doesn't
mean
that
my
application
should
be
listening
on
port
80
because
I
might
be
listening
on
5000
or
3000
or
whatever,
because
I
have
a
proxy
in
the
middle
right
and
and
and
that's
very
common
right
that
you
don't
make
your
applications
listed
on
port
80,
because
that
will
require
root
permissions,
usually
or
extra
permissions
for
the
software
to
run,
and
that's
not
that's
not
secure
right.
A
So
so
that's
pretty
common
use
case
for
servers
not
for
clients,
obviously
for
clients,
clients,
don't
have
this
problem
and-
and
I
was
trying
to
come
up
with
a
way
of
you
know-
I'm
we're
still
trying
to
come
up
with
a
way
of
how
we
can
we
make
this
work
for
both
cases
right
if
at
some
point
it
happens
that
we
realize
it's
not
possible.
Look
it's
it's
impossible
to
to
have
18kpi
to
work
for
both
cases.
A
B
B
B
So
I
think
both
on
the
same
thing
where,
where
we
have
to
explicitly
define
both
the
server
and
the
client
and
and
sort
of
use,
the
verbs
from
the
perspective
of
the
of
whatever
we're
particularly
interested
in
interested
in.
A
And-
and
if
you
I
don't
know,
if
you
recall
from
lorna's
episode
for
the
from
the
first
episode,
she
was
actually
telling
us
that
at
open
api
they're
facing
the
same
problem
is
that
they're
defining
the
server
you
can't
infer
the
client
from
the
definition
of
the
server,
for
the
very
same
reason
right
so
like
with
what
I
just
said
about
the
port.
The
port
is
an
example.
A
Like
you
don't
know,
what's
in
between
the
server
and
the
client
like
there
might
be
different
proxies,
or
you
know
other
other
kind
of
stuff
in
the
middle
that
you
basically
don't
know.
So,
if
you,
if
you
define
the
server
from
the
perspective
of
the
client
cool,
the
client
will
be
fine.
But
if
then,
you
want
to
use
the
open
api
file
to
generate
the
server
itself,
the
code
for
the
server
you
have
a
problem.
It's
not
going
to
be
listening.
A
Where
you
think
it's
listening,
it's
not
going
to
be
doing
what
you
think
it's
doing
right
and
then
you
will
have
to
understand
that
the
meaning
of
the
birth,
the
other
way
around.
It's
not
that
the
get
means
that
I'm
gonna
accept
gets
so
that
I'm
doing
a
get
right
as
opposed
to
the
to
the
client.
The
client
is
going
to
do
it
yet
not
accepting
gets
because
yeah
client
cannot
accept,
get
or
calls
because
there
are
clients,
not
servers
right.
B
Beyond
even
sort
of
the
the
port
stuff
into
even
the
functionality
of
things-
and
I
think
lauren
touched
on
this-
and
I'm
going
to
say
the
name
lorna
like
15
more
times,
because
I
I
think
that
was
a
fantastic,
fantastic
episode.
That's
like
seinfeld
for
me
that
first
episode
with
lorna,
because
it's
like
you,
know
the
classic
thinking
out
loud.
So
I
think
lauren
makes
a
great
point
that-
and
you
have
stated
this
before
too,
that
you
know
it's
not
an
either
or
situation
like
these.
B
These
applications
are
both
publishing
and
subscribing,
and
so
you
know
to
in
there.
Maybe
you
know.
There's
no
particular
you
know
application,
that's
going
to
be
the
mirror
image,
either
in
terms
of
the
ports
or
the
the
functionality,
and
so
we
need
to
really
lay
out
sort
of
explicitly
what
each
of
these
things
can
do,
particularly
when
it's
you
know
not
just
a
one-on-one
scenario,
but
a
sort
of
you.
C
B
End-To-End
communication,
where,
like
you
know,
you're
publishing
from
some
people
and
subscribing
from
other
people
and
there's
a
mediation
layer,
perhaps
there
so
you
know
that
all
that
you
know
the
ports,
the
functionality
all
feeds
into
sort
of
the
same.
We
need
to
make
things
more
explicit
rather
than
having
implicits
sort
of
reversal.
A
And
there's
also
this
thing
about
the
operation
id
and
the
description
fields,
the
the
summary
description
fields
that
cash
konichke
my
friend
raise
this
issue
about,
which
is
so,
if
you
define
an
operation
id
the
operation
id
is
for
you.
Usually
it's
it's
used
for
priming
my
programming
languages,
to
name
the
function
that
is
gonna
or
the
class
or
the
function.
A
Whatever
that's
gonna
handle
the
the
message:
that's
it
or
the
operation,
the
publish
or
subscribe
operation,
and
but
if
you,
if
you're,
if
you're,
generating
a
websocket
server,
for
instance-
and
you
have
the
operation
id,
the
operation
id
might
be
called
on
user
signup,
for
instance,
and
then
you
spec
on
the
server
that
the
server
is
going
to
subscribe
to
client
messages
and
the
client
telling
the
server
that
a
user
has
signed
up.
A
A
And
you
know,
and
and
the
same
happens
with
description
and
summary,
if
you
have
a
description
saying
this
listens
for
messages
on
the
user's
channel
whatever
for
the
server
might
be
good
for
the
client
might
not
be
good
if
we
define
it
for
the
client,
it
might
not
be
good
for
the
server
the
other
way
around
right.
So
so
it
is
sorry.
The
way
I
see
it
today
is
that
it
is
all
mixed
right
now
amazing
kpi,
and
we
just
have
to
clear
this
mess.
A
Basically
it
is,
it
is
there's
a
there
is
a
it's
been
great.
So
far
like
it's,
it's
been
good.
It's
it's
usable!
You
can
do
a
lot
of
things
with
async
api
still,
even
though
it's
not
the
greatest
thing
ever,
but
you
still
can
do
some
stuff,
but
it's
time
for
us
to
to
clear
to
clear
this
mess
right
and
to
separate
concerns.
So
you
know
like
make
it
clear
making
it
formal
right.
A
B
Exactly
exactly
one
is
the
canadian,
so
I
will
I'll
share
my
screen
here,
yep
and
I'll
I'll
say
that
yeah
calling
it
my
proposal.
I
I
think
this
is
first.
You
know
I've
been
so
impressed
by
the
community
here
yeah.
I
think
clearly,
the
the
the
person
who
created
this
or
the
initial
idea
was
lorna,
and
so
I
think
she
gets
a
ton
of
credit
for
it.
B
But
along
the
way
like
talking
with
with
you
know,
so,
many
people
within
the
community,
ian
and
gerald
from
from
mulesoft
and
from
james,
had
great
great
feedback
as
well
and
and
sort
of
talking
with
people
from
ebay,
shakar
and
from
lawrence
and
people
from
from
axeway
as
well.
B
Everybody
here
had
their
own
little
little
contribution,
to
which
I
think
is
fantastic
and
it's
a
much
better
proposal
for
it.
I
mean
it's
sort
of
like
the
true
open
source
collaboration
and
that
you,
you
would
always
hope
for
which
is
fantastic.
B
So
clearly,
this
is
deriving
a
lot
from
lorna's
proposal
and
essentially
it
creates
an
entity
called
endpoints
and
sort
of
in
the
desire
to
have
a
a
more
explicit
definition
like
we
were
talking
about
at
the
beginning,
and
then
those
endpoints
interact
with
channels
through
references
and
one
thing
that
we
didn't
mention
is
there's
also
beyond
the
perspective.
B
There's
a
sort
of
channel,
reuse
problem
where,
because,
because
channels
are
sort
of
housed
within
applications,
it's
really
hard
to
reuse
them,
so
sort
of
moving
channels
from
being
very
tightly
intertwined,
with
applications
to
sort
of
logical
means
of
exchange
between
different
endpoints
and
credit
to
ian.
For
initially,
this
was
called
actor.
B
It
was
switched
over
to
the
endpoint
at
at
ian's
suggestion,
and
do
you
think
it
sort
of
aligns
with
enterprise
application
integration
patterns
sort
of
are,
if
there's
a
bible
of
async
api?
I
feel
like
that.
B
That
is
probably
the
bible
of
async
api,
so
that
sort
of
channel
reuse-
and
I
think,
touching
on
sort
of
what
we
talked
about
at
the
beginning,
making
channels
as
logical
as
humanly
possible,
I
think,
is
really
the
key
to
driving
this
forward
and,
I
think
again,
like
we
talked
about,
we
have
to
encompass
so
many
different
technologies
at
async
api
that
you
know.
B
We
really
need
to
sort
of
force
the
implementation
specific
stuff
into
bindings
attached
to
either
the
channel
or
the
operation
level
for
an
endpoint,
because
otherwise
we're
never
going
to
encompass
all
all
the
particular
use
cases
that
will
that
touch
on
a
particular
implementation
technology,
like
you
know,
websocket
and
brokers,
are
so
different,
but
the
only
thing
that
we
can
say
that
sort
of
unites
them
together,
I
would
say,
is
there's
one
thing
on
one
end
of
the
channel.
There's
another
thing
at
the
other
end
of
the
channel.
B
Somehow
the
information
goes
into
the
channel,
it's
of
a
particular
format
and
some
somehow
then
goes
out
out
the
other
side
and
that's
all
a
channel
can
be
because
that's
the
only
thing
I
think
that's
going
to
be
common
across,
like
I
said
the
spectrum
from
websockets
all
the
way
over
to
over
to
brokers.
Everything
else
I
feel
like
has
to
be
a
binding.
B
So
at
the
heart
of
it
it
is
make
channels
logical,
explicitly,
define
the
the
endpoints
no
more
sort
of
like
inferring
endpoints
from
like
a
reverse
and
trying
to
do
that
mental
gymnastics
and
shoving
literally
everything
that
we
can
into
a
binding,
because
otherwise
we're
never
going
to
cover
the
spectrum
of
technologies
that
we
that
we
encounter
so
that
you
know
and
there's
a
lot
more
in
the
in
the
in
the
in
the
proposal.
But
I
think
if
those
are
sort
of
that's
the
heart
of
it,
the
beating
heart
of
it.
A
So,
there's
still
something
that
it's
not
clear
to
me.
Is
it
and
it's
the
end
point
so
with
an
endpoint
represents
like
can
you?
Can
you
probably
put
an
example
of
a
real,
really
real
world
example
like
what
would
be
an
end
point
like.
B
Java
spring
web
service,
you
know
an
ipass
listener
on
on
boomi
a
mule
soft
exposed
api
endpoint
on
their
on
their
on
their
their
their
api
management
tool,
ibm
mq,
something
that's
picking
up
messages
from
ibm,
mq
broker.
You
know
all
those
sorts
of
things,
essentially
a
program
application
that
type
of
thing.
A
B
A
B
B
B
C
B
A
A
So
this
is
yeah
clarifying.
No,
don't
worry!
You
can't
see
the
chat,
but
he's
he's
taking
care
of
this.
That's.
B
We
were
talking
about
means
of
of
of
of
distribution,
so
you
know
that's
the
broker
case
in
the
the
case
of
a
websocket.
Clearly,
that's
less
of
there's
less
of
a
middleman
there.
The
channel
is
this:
essentially
a
point-to-point
connection,
websocket
connection
between
the
the
endpoints,
you
know
requesting
information
and
the
endpoint.
B
Because
I
think
there
is,
you
know
you
can
ponder
I'll
extemporate
a
little
bit
more,
so
the
the
power
of
of
a
keeping
the
channel
logical
is
that
let's
say
that
you
know
you
start
off
with
a
websocket
implementation,
that's
sort
of
point
to
point.
You
know
you're
spawning
a
whole
bunch
of
servers
and
along
the
way
you
think
you
know
this
isn't
scaling
the
way
that
I
want
to
scale.
B
If
we
have
everything
logical
at
the
channel
level,
then
switching
out
your
implementation
is
just
a
matter
of
switching
out
the
binding
it
creates.
This
sort
of
you
know,
separation
of
concerns
between
you
know.
There's
you
know
that
there's
logical
interaction
between
these
endpoints,
how
that
happens,
is
at
the
binding
level.
So
your
sort
of
system,
topology
stays
the
same.
How
you're
interchanging
exchanging
the
information
changes.
A
Yeah
another
thing
the
thing
is
here
is
that
it's
not
so
much
about
how
that
happens,
but
more
about
the
role
that
the
application
plays
in
the
whole
ecosystem
of
applications,
let's
say
or
in
the
whole
architecture
of
your
event,
driven
architecture
right.
You
have
an
event-driven
architecture,
you
have
different,
microservices
or
whatever
you
can
call
it
wherever,
and
one
of
them
can
be
a
websocket
server
and
another
one
can
be
a
websocket
client
or
can
be
a
negativity,
client
and-
and
so
it's
not
so
much
about
an
implementation
details.
A
But
more
about
like
being
clear
that
this
specific
item
here
you
know
this
websocket
server,
it's
actually
a
server
right,
and
we
want
to
make
it
clear
that
this
is
a
server
and
it's
expecting
things
to
be
sent
to
to
him
or.
A
Or
or
sending
stuff
to
the
client
right,
so
it's
more
about
because
there,
I
think,
there's
there's
still
value
in
having
this
information
like
what's
the
role
this
application
is
playing,
or
is
it
playing
a
double
role
that
can
also
be
like?
A
For
instance,
we
have
a
public
websocket
application,
sorry,
a
public
websocket
server
for
our
website
and
and
say,
for
instance,
we
have
I'm
sure
you
heard
about
this
example,
but
say
we
have
a
very
simple
social
network
and-
and
we
click
like
the
like
button-
and
we
want
to
send
this
as
a
websocket
message
to
the
server
like
new
like
has
been
clicked.
Okay,
then
the
server
might
want
to
just
forward
this
to
a
broker
right.
A
It
doesn't
do
anything
just
forward
this
to
a
broker
or
might
want
to
store
it
somewhere
and
and
then
forward
or
create
a
message
to,
I
don't
know,
send
a
message
to
a
solos
broker
or
to
a
kafka
broker
or
an
entity
broker
or
whatever
right.
So
so
this
server
is
effectively
behaving
as
a
server
and
as
a
client
of
the
broker.
So
is
two
things:
it's
behaving
as
two
things
right
and-
and
I
think
that's
and
I'm
not
saying
that
we
should
be
documenting
the
whole
the
whole
flow
like
we
should.
A
I'm
not
saying
we
should
be
documenting
the
whole
workflow
from
someone
clicking
on
the
like
button
to
the
message
sent
to
the
to
the
broker,
and
we
I
mean
we
should
be
defining
all
these
steps,
but
not
saying
that
we
should
be
linking
these
steps
like
this.
One
is
the
result
of
another
right,
we're
not
creating
workflows
here,
but
but
but
yeah
like
this.
I
think
this
still
has
value,
because
then,
if
we
define
a
websocket
server
and
for
a
websocket
application,
that
is
a
server
and
a
client.
A
At
the
same
time,
then
we
will
have
bindings
for
the
server
and
bindings
for
the
client
and
then
what
the
hell
is,
this
application
right
is
it
the
server?
Is
it
the
client.
A
But
who,
who
is
like
like
it
is
the
server
for
who,
like
it,
is
a
server
for
other
people
for
this
part
of
the
of
the
api
layer,
or
is
it
for
the
other
part
of
the
api
layer?
So,
for
instance,
if
we
accept
the
message
from
the
like
button
and
forward
them
to
a
broker,
so
imagine
that
we
forward
this
to
a
broker,
also
using
websocket
protocol
right.
A
What
will
happen
is
that
we
have
some
messages
that
are
sent
to
broker
and
some
messages
that
are
sent
to
the
client
and
we
don't
know
which
one
is
it
right,
which
one
is
is
which
right
we
just
know
that
this
particular
entity
is
has
two
has
to
two
bindings,
one
for
the
server
and
one
for
the
client.
But
now
I'm
I.
What
I'm
concerned
about
this
approach
is
that.
A
B
B
B
Then
you
would
push
messages
out
as
a
websocket
client
to
a
broker,
so
the
binding
would
contain
that
information
which
we
don't
have,
and
I
think
that's
a
question
for
discussion.
Is
we
don't
have
the
causality
defined
there
that,
as
a
result
of
these
messages
coming
in
then
we
push
these
messages
out
to
the
broker?
Like
that's
fine
yeah?
Is
it
fine?
I
don't
know
some
people
would
say
that
that
is
like
clemens
makes
comments
that
that
says
you
know
like.
B
We
should
define
that
that
that
causality-
and
I
mean
maybe
that's
a
valid
point-
that's
something
we
talk
about
a
lot.
A
It
is
I
mean
it
is
for
sure
valuable
and
I'm
sure
that
at
some
point
we'll
address
this,
this
kind
of
workloads
and
reactions-
and
things
like
this
but
yeah
like
for
the
time
being
for,
for
you
know,
for
fixing
the
publishing
subscribers.
A
So
then,
so,
then,
so
then
tell
me
something
like,
for
instance,
in
a
single
async
kpi
file.
We
could
be
defining
multiple
clients
as
as
I'm
seeing
there.
So
it's
a
single
async
api
file
meant
to
have,
for
instance,
your
whole
architecture
defined
in
a
single
file.
B
I
think
the
question
is,
I
think,
the
the
right
response.
Is
it?
What
what
does
your
organization
want
to
do?
You
know,
I
think
that
if
we
have
the
ability
to
list
multiple
endpoints
in
the
same
file
and
that's
what
you
want
to
do
great,
if
you
want
to
keep
it
as
a
like,
you
know
one
endpoint
per
file
great.
If
you
don't
want
to
use
files
at
all,
you
want
to
use
a
registry
great,
I
think
in
you
know
even
moving
beyond
that.
B
B
Like
let's
say,
we
have
like
a
vendor
role,
endpoint,
and
you
want
to
extend
that
into
you-
know:
shipping
vendor
endpoint,
I
think,
having
the
ability
to
have
multiple
endpoints
and
have
endpoints
extend
each
other
gives
you
the
the
flexibility
to
do
a
lot
of
sort
of
for
lack
of
a
midterm
enterprise
level
functionality
in
in
terms
of
being
able
to
to
reuse
things
that
are
common
across
different
endpoints,
and
then
you
know,
but
at
the
same
time,
have
very
specific
endpoint
definitions.
At
the
same
time,.
B
Yes,
yes,
well,
I
think
this
dives
into
like
a
whole
other
whole
other
topic
of
discussion,
and
I'm
really
interested
to
get
your
perspective
on
this
as
well.
It
is
sort
of
endpoints
are
optional,
because
they're
optional,
currently
within
the
async
api
spec,
and
so
that
would
provide
for
a
level
of
backwards
compatibility,
and
I
think
I
know
you've
hinted
that
your
opinion
on
that.
I
think
we
have
a
different
opinion
opinion.
A
Didn't
I
didn't
mean
to
to
confuse
you
with
that
so
yeah
the
reason,
the
reason
I
was
asking,
if
it's,
if
it's
optional
or
not
it's
not
about
the
backward
compatibility.
B
A
B
A
But
my
concern
here
is
that
if
you
want
to
let
organizations
decide
if
they
want
to
have
some
everything
in
a
single
file
or
everything
split
in
different
files,
then
I
guess
that
there
will
be
files
with
with
no
end
points
or
with
just
one
endpoint
or
how
does
it
work
like
I'm
trying
to
to
you
know
to
to
wrap
my
head
around
this
new
concept
of
having
the
ability
to
define
all
the
applications
in
a
single
file
or
all
the
endpoints?
A
Sorry,
I'm
calling
application,
because
I
see
that
it's
mapping
to
the
current
application
definition
of
application
of
facing
kpi
right,
sir,
so
it's
like
you
can
have
different
applications,
design
defined
in
the
in
the
same
file.
That's
cool
for
many
use
cases.
This
is
really
useful
and
for
some
other
people
might
argue
that
this
is
not
cool,
so
they
want
to
split
in
multiple
files.
So
so
now
my
question
here
is
that
if
you
have
multiple
files,
then
I
guess
you
should
make
sure
that
each
file
is
representing
just
one
application:
slash
endpoint!
B
I
mean
the
beauty
of
it,
or
at
least
I
think
the
beauty
of
it
is
that
it
depends
thanks
to
me,
so
the
mobility
of
it
is
it
depends
like.
Does
your
organization
want
to
group
all
the
applications
for
a
particular
domain
into
an
async
api
file
done?
Do
you
want
to
have
your
server
and
your
client
defined
in
the
same
async
api
file?
B
You
know,
for
whatever
purpose
done,
do
you
want
to
only
you
want
to
have
your
internal
sort
of
event,
api
products
in
one
async
api
file,
but
then
the
stuff
you
expose
to
the
outside
world
in
a
separate
async
api
file
done.
Do
you
want
to
have
things
not
in
the
file
at
all?
Do
you
want
to
have
a
registry
that
has
all
of
your
channels
in
it?
That's
not
a
physical
file,
but
it's
a
database
done.
Do
you
want
to
use
a
schema
registry
for
your
for
your
messages
done?
B
I
think,
really
because,
like
we
talked
about
earlier
the
number
of
different
topologies
that
we
have
to
support,
I
think
the
more
flexibility
as
long
as
yeah,
I
think,
the
more
flexibility,
the
better.
A
A
Well,
I
I
have
to
disagree
with
something
you
said
now.
Is
that
the
more
flexibility
the
better
yes?
And
no?
So
it's
like?
Yes,
I
I
understand
why
you're
saying
this,
and
no
because
the
more
flexibility,
the
more
complexity
we
add
to
the
spec
and
the
more
difficult
it
will
become
to
understand
and
to
reason
about
for
people
right
so
right
now
it
is.
It
is
already.
A
I
would
say
for
most
people
like
it
is
already
defining
too
many
things
like
things
with
how
bindings
work
with
servers-
and
you
know
like
some-
I
think
it
was
general
gerald-
was
trying
to
put
some
information
and
restrictions
on
what
you
can
put
on
the
server
inside
and
it's
a
binding
definition
so
when,
where
bindings
are
not
supposed
to
to
define
these
constraints,
these
restrictions,
but
I
understand
why
he
he
tried
to
do
it,
and
so
the
already
bindings
themselves
alone
are
introducing
a
lot
of
complexity.
A
So,
if
we
add
more
complexity,
more
flexibility,
I
think
it
will
add
more
complexities.
There
yeah
not
sure,
not
sure
if
we
maybe
maybe
said
to
to
to
give
people
to
give
users
this
ability
to
group
files
or
the
or
application
definitions
together.
A
That
is
just
actually
the
name
of
the
group
and
the
list
of
files
or
the
list,
maybe
not
files
but
embedded
async
api
documents
inside
so
just
for
the
purpose
of
keeping
async,
apk
simple,
you
know
and
and
application
oriented,
let's
say
or
single
application
oriented,
and
then
this
whole
thing
about
people
wanting
to
group
them
somehow
single
group
for
the
whole
organization
or
different
event,
products
together,
don't
mind,
then
you
should
you
could
be
doing
this
with
a
new
spec,
a
simple
spec,
like
just
name
of
the
group
and
the
list
of
I
think
api
definitions.
A
You
know
that
that
you
want
to
group
together
right.
B
My
my
bias
is,
you
know,
there's
different
ways
to
introduce
complexity.
Introducing
a
whole
other
spec
level
to
me
seems
you
know
like
it's
introducing
complexity
as
well
yeah,
I
think
the
the
key
here
and
I
think
that
this
sort
of
leads
back
to
the
backwards
compatibility
is
like
how
you
use
these
pieces
together,
like
you,
can
have
exactly
the
the
the
the
the
scenario
describe
where
you
have
an
endpoint
one
endpoint
in
per
file
like
perfectly
allowed
go
for
it
and
I
think
that
would
actually
align
with
a
lot
of
different
topologies.
B
But
there
are
some
topologies
where
that
is
absolutely
absolutely
horrible,
where
you
have
4
000
different
microservices
and
you
don't
want
to
have
4
000
different
async
api
files
floating
around
and
plus
the
you
know.
We
have
by
introducing
the
sort
of
channel
concept
and
allowing
the
channels
to
be
in
their
own
in
their
own
files,
potentially
because
I
do
think
that
the
reuse
points
to
that
sort
of
model,
you're
already
sort
of
allowing
things
to
be
to
be
grouped
and
complicated
about.
B
A
A
So
I
I
I
find
it
funny
with
something
you
said
like
you
have
4
000
microservices
and
you
don't
want
to
have
four
thousand
hdk
files
floating
around,
but
you
want
to
have
four
thousand
repos
or
four
thousand
applications,
because
because
they're
organized
pro
they're
managed,
probably
different
by
different
teams-
and
you
know,
like
you-
usually
have
each
a
republic
microservice
or
at
least
a
folder
per
mic
for
microservice,
so
it
I
think
it
makes
sense
the
same
way.
A
You
have
the
code
separated
in
each
microservice
to
have
basically
this
giveaway
definition
together
with
the
code
like
closer
to
the
code
right.
That's
why
we
keep
asking
kpi
single
application
focus,
because
we
think
it's
a
it's
a
it's
a
unit.
A
You
know
like,
like
the
the
service
in
this
case,
is
a
unit
and
it's
like,
I
think
it
makes
sense
to
have
these
four
thousand
basic
kpi
files,
because
the
same
way
you
have-
I
don't
know
if
your
four
thousand
microservices
are
greeting
in
java,
then
you
probably
have
four
thousand
palm
dot
xml
files
right
so
the
same
way,
and
you
don't
want
to
have
all
the
font
files
in
a
single
file
right.
A
Yeah,
because
if
you,
if
you
merge
them
together,
then
aren't
you
introducing
coupling
like
if
you
have
everything
between
the
services
like,
if
you
want
to
independently
deploy
a
new
service
that
changed
the
the
api
you're
introducing
coupling,
because
imagine
in
in
the
case
of
ci,
where
you
know
deployment
is
done
automatically
and
in
the
case
of
cd,
actually
ci
cd,
you
might
change
the
async
ebay
file
and
then
it
regenerates
code
or
whatever
and
it
auto
deploys
yeah.
It's
gonna
change,
a
file
that
is
going
to
affect
the
4000
microservices.
A
A
Yeah,
well,
I
think
we
need
to.
Of
course
we
need
to
think
about
it
like
we
all
need
to
it's,
just
not
just
for
you
but
like
for
the
for
the
audience
as
well
for
the
community
to
think
about
it.
Like
that's,
why
I
raised
this
point
of
saying,
like
maybe
we
can
create
another
top
layer,
simple
spec,
that
will
give
you
the
ability
to
group
them
together
and
then
for
those
who
don't
want
to
group
things
together,
because
they're
doing
micro
services
or
they
just
bring
one
or
two
or
whatever.
A
Then
they
don't
have
to
think
about
endpoints
or
groups
or
anything
right.
They
just
go
and
define
whatever
they're
doing
and
that's
it.
But
for
those
who
really
want
to
have
this
this
ability
they
can
have
this
separate
file
that
will
be
linking
to
this
in
each
individual
file
or
you
can
be
embedding
these
files
inside
the
single
file
and
then
it's
up
to
you.
You
know
it's
like
there's
pros
and
cons
for
each
use
case.
A
Of
course
the
thing
is
that,
for
instance,
in
the
case
of
tooling,
it
will
be
much
simpler
to
create
tooling.
If
we
don't
merge
everything
in
a
single
in
a
single
place,
because
you
don't
have
to
consider
this
case
from
total
perspective,
you
only
consider
one
application
at
a
time.
You
don't
consider
the
option
that
there
might
be
multiple
endpoints
applications
right.
Then
there
will
be
some
other
tooling
for
helping
you
group
them
right.
B
A
A
I'm
not
I'm
not
saying
that
I'm
right
and
you're
grown
or
you're
right
and
I'm
wrong.
This
is
for
people
watching
ads.
This
is
thinking
out
loud,
so
this
is
really
thinking
out
loud,
I'm
just
I
I
have
the.
I
have
a
problem
that
some
people
already
raised
on
my
face,
sometimes
that
I
sometimes
sound
like
I
am
you
know
like
like
saying
this
is
like
this,
and
it
should
be
like
this
and
it's
like
I'm
just
thinking
out
loud
and
I'm
sorry
if
it
sounds
like
like
I'm,
I'm
saying
that
no!
A
No!
No!
No!
Your
point
is
not
valid.
Mine
is
no
I'm
just
trying
to
raise
another
another
point.
Another.
B
B
A
A
So
I
mean
this:
this
is
something
that
you
could
be
providing
and
you
already
provide,
but
but,
like
you
know,
other
other
companies
could
be
providing
other
products
can
be
providing,
and
but
yeah
I
mean
that's
a
really.
I
mean
forget
about
that.
What
I
just
said
like
this
is
a
really
bad
reason
to
or
or
argument
against
that
this
is
yeah
if
something
can
be
defined
in
a
standardized
way
between
solas
and
other
any
other
product
vendors.
That
would
be
even
better
right.
A
A
And
I
was
reading
it
and
I
was
like
what
I
was
confused
now.
It
is
much
clearer
to
me
so
thanks
for,
for
this
whole
explanation
of
your
proposal.
I
think
it
raises
a
a
few
interesting
points.
That's
now
I
that
I'm
seeing
you
that's
a
good
thing.
I'm
gonna
share
your
proposal
with.
B
I
know
we're
out
of
time,
but
I
do
think
we
should
talk
about.
I
think
this
is
more
of
a
philosophical
thing
is
sort
of
the
the
backwards
compatibility
and
I
I
I
totally
agree
with
you
that
it
would
be
nice
to
sweep
everything
away
and
start
fresh,
but
that's
just
not
realistic
of
where
and
I'll
use
a
kinder
term
than
you
did.
A
I
I
know,
but
this
is
a
spec
right,
so
we're
trying
to
and
and
even
though
it's
version,
two
version,
three
version.
Four.
A
We
sold
them
in
my
opinion
and
and
and
also
lucas
opinion
and
other
people
from
the
community
opinion
that
we
already.
We
already
raised
this
topic
before,
like
I
think
we
should
be
like
the
the
specs
will
be
constantly
changing.
You
know
like
being
developed
and
it
will
be
the
tooling
providing
a
facade
so
for
these
changes.
So
so
the
tool
in
the
parsers
you
know
should
be
able
to
give
you
the
abstract
entities
of
the
specs.
A
Then,
if
it's
version
two
of
the
spec,
it
will
go
and
look
on
the
subscribe
method,
and
if
it's
version
three,
it
probably
have
to
go
to
and
look
in
another
place,
but
your
codes
will
remain
the
same
right.
Your
code,
your
your
the
call
that
you're
doing
should
be
abstracting
away.
You
obstructing
you
away
from
the
from
the
spec
from
the
from
the
spec
definition,
which
is
not
the
the
the
current
case
right.
A
B
C
B
A
So
yeah,
so
I
I
I
see
what
you
say
what
you
say
like.
A
I
understand
and
that's
why
that's
one
of
the
reasons
I've
been
like
pushing
this
aside,
like
don't
release
this
yet
because
I
really
want
to
publish
a
new
version
of
facing
api,
a
new
major
version,
that
is,
that
has
a
breaking
change
right,
not
just
with
the
public
subscribe
changes,
so
it
actually
offers
you
something
more
right.
Some
some
some
further
improve
improvements
right.
A
So
that's
so
that's
why
we're
like
I'm
always
saying
like
hey
whistle,
because
we
I
mean
we
don't
want
to
be
breaking
the
spec
all
the
time
we
don't
want
to
either
be
holding
the
spec
just
because
we're
afraid
that
it's
going
to
break
other
people's
businesses
or
anything.
A
So
we
need
to
find
like
a
like
a
fine
balance
right
and
then,
in
my
opinion,
this
is
like
if
we
introduce
changes
to
publish
and
subscribe
right
now,
if
we
fix
this
whole
thing
about,
publish
and
subscribe,
this
gives
nothing
to
the
end
user.
There's
no
benefit
for
the
end
user.
For
the
I
mean
for
the
for
the
end
user
right
in
the
spec,
yes
for
the
business
behind
the
spec,
there's
no
there's
no
benefit
right.
B
Its
own,
like,
if
you,
if
you
have
to
train
your
developers
for
a
half
hour
and
explain,
explain
to
them
the
spec
and
I
feel
like
the
tooling
support,
is
also
lagging
because
it's
really
hard
to
pick
it
up
and
understand
it.
You
know,
and
one
of
your
goals
for
the
vision
is,
you
know,
for
people
to
start
making
contributions
in
a
faster,
faster
way,
yeah.
I
think
that
you
know,
and
that
in
turn
leads
to
better
tooling
and
more
business
value.
B
I
think
creating
clarity
around
these
sort
of
terms,
actually
in
a
very
in
not
very
but
indirect
way
creates,
creates
business
value.
A
So
I
think
the
way
it
is
right
now
the
the
way,
the
spec
it
is
right
now
it
will
be
super
hard
for
us
to
introduce
this
request
reply
functionality.
It
will,
it
will
just
add
more
complexity
to
the
existing
spec
like
it
like.
So
imagine
that
you
have
to
you
want
to
have
request
reply,
but
you
actually,
what
you
add
is
a
reply
option
to
the
subscribe,
verb,
yeah,
yeah,
yeah.
A
It's
like
yeah,
so
it's
like
yeah.
I
understand
that
we
that
there
are
some
people
that
devoted
a
lot
of
time
to
create
their
own
tools
and
to
parse
async
api
as
well,
but
yeah
this.
I
don't
think
we
should
be
carrying
this
forward.
You
know
it's
like
this
is
too
much
because
then
then
it's
going
to
be
painful
for
people
always
you
know
it's
always
going
to
be
the
same.
It's
going
to
continue
being
painful.
You
know
I.
B
A
A
If
you're
not
using
our
tools
in
this
sense,
you
don't
get
any
benefit,
but
another
thing
that
we
can
do
in
the
meantime
is
we
keep
maintaining
version
two.
So
we
keep
adding
features
to
version
two
for
some
time
and
then-
and
we
start
telling
you
that
you
should
start
migrating
because
next
year,
for
instance,
will
stop
supporting
version
2
or
in
two
years
or
you
know,
and
then
you
have
some
time
now
to
react.
It's
not
that
it's
not
that
from
one
day
to
another,
you
you
are
like.
A
Oh
fact,
I'm
I'm,
I'm
less.
I'm
left
alone
here
with
my
old
async
api
stuff
that
doesn't
work
anymore
right.
So
so
we
we
thought
about
it
as
well,
like
we're,
not
gonna,
stop
maintaining
version
two,
so
version
two
will
continue
to
evolve
like
2.3
2.4,
whatever
right
or
the
tooling,
supporting
version
2
will
continue
to
evolve
as
well,
but
new
features.
You
know
new
key
features,
I
will
say,
like
request
reply
shouldn't
be
added
to
version
two.
A
I
think
this
will
be
added
to
version
three
where
the
breaking
change
is
so
there's
a
there's,
a
motivation
for
people
for
businesses
to
start
migrating
with
time
right.
So
that's
yeah,.
B
There's
no
real
great
way
around
it.
I
would
say
that
yeah,
some
people,
like
the
way
that
things
are
defined
right
now.
They,
you
know
they've
built
the
business
around
providing
async
api
capabilities,
and
I
I
think-
and
they
like
the
way
that
async
api
is
structured
right
now
and
so
to
force
them
off
even
eventually
may
be
hard.
B
I
would
say
harder
that
harder
than
perhaps
anticipate,
and
I
think
by
allowing-
and
I
I
clear
I
do
think
that
there
is
hopefully
would
be
a
nat,
more
natural
trying
not
to
make
mistakes.
I
agree
yeah
yeah,
that
that's
that's
always
the
business
benefit.
I
would
assume
that
the
the
time
saved,
not
trying
not
to
make
mistakes,
would
be
because
you
yeah
you're,
not
you're,
not
forgetting
what
publish
and
subscribe
means.
That's
a
good
one.
I
assume
so
yeah,
if
maybe
they
could
follow
up
with
another
comment.
B
A
Yeah,
this
is
something
that
we
definitely
have
to
think
about
even
more.
We
don't
want
to
screw
anyone.
That's
take
it
for
granted.
B
A
B
Segway
like
what
what
how
do
you
envision
this
process
moving
forward,
because
I
think,
there's
a
sort
of
a
general
agreement
that,
like
something's
going
to
happen.
So
how
would
you
that
thing
happening?
Because
it
feels
like
you
know,
there's
a
github
and
that's
great
for
discussion,
but
then
like
it
feels
like.
There's
got
to
be
some
sort
of
like
push
to
get
this
done,
because
this
is
like
a
big
deal.
A
I
think,
as
you
know,
I'm
gonna
make
my
my
own
proposal,
so
I'm
gonna
publish
my
own
proposal,
but
I
already
started
I'm
gonna
put
mine,
which
is
like.
A
A
I
don't
want
to
bias
anyone
towards
my
spec
or
my
proposal,
sorry
or
towards
or
the
contrary
right
like
so
I
I
wanted
to
keep
it
like
yeah,
so
I
I
so
clarify
like
you
are
the
last
one
doing
this
series
of
public
subscribe
thinking
out
loud
episodes,
so
we're
not
going
to
talk
about
probably
subscribe
in
thinking
out
loud
anymore
right,
at
least
that's
the
hope
right.
A
My
hope
is
like
yeah:
it
dies
with
you
here,
so
you
have
a
proposal.
There's
some
other
people
doing
proposals.
I
I
recall
michael
davis,
made
another
proposal
but
yeah.
He
admittedly
said
that
that
it's
not
really
the
best
way
to
to
tackle
this
problem.
It
has
issues
right,
so
I'm
gonna
make
another
proposal.
A
I'm
gonna,
I'm
just
gonna,
try
to
mix
in
my
proposal
what
I,
what
I've
learned
of
course
myself
all
these
years,
but
also
what
I've
learned
from
you
during
these
episodes
and
during
this
you
know
this
github
discussion
and
thinking
about
and
talking
to
many
of
you
offline
as
well,
giving
you
my
feedback,
giving
me
my
your
feedback,
sorry
and
and
and
yeah.
So
I'm
just
trying
to
come,
I'm
just
going
to
try
to
compile
everything
there,
but
that's
a
proposal.
A
That's
what
I
was
saying
like
it
doesn't
mean
it's
going
to
happen
like
this.
You
can
all
vote
like
saying.
No,
we
don't
like
your
proposal
right
right.
So
so
it's
like
I
mean
you
all
you
all.
I
mean
you
know
the
maintainers
of
the
spec
right,
which
I
think
they
are
still.
I
don't
know
if
they're
defined,
yet
I
think
they're
defined.
A
Yeah
yeah,
you
know
that
we
moved
to
linux
foundation
recently,
and
this
is
the
the
new
the
new
governance
model
is.
It
is
just
getting
started
right,
but
in
any
case,
if
I
even
I
think
the
defined
maintainers
is
lucas-
and
I
right
now,
if
I'm
not
mistaken
but
of
the
spec,
we
want
to
invite
more
people
to
become
maintainers
so
to
have
a
vote
right.
But
even
though
it's
lucas
tonight,
right
now,
I'm
not
gonna.
A
A
So,
but
if
you
give
me
reasons,
you
know
reasonably
reasons
of
why
it
shouldn't
be
done
and
we
have
discussion
there,
then
I
think
we
can
all
come
up
with
a
solution
that
it's
good
enough
for
everyone
right.
So
if
we
we
may
have
to
do
some,
you
know
like
to
allow
some
some
trade-offs
ourselves
like
what
I
would
love
to
see
myself
as
a
perfect
solution
is
it
is
not
what
I'm
gonna
propose.
A
So
my
perfect
solution
is
that
my
proposal,
my
proposal
is,
as
I
said,
like
a
combination
of
all
your
ideas
and
thoughts
and
feedback,
but
but
it's
also
not
going
to
be
your
perfect
solution.
It's
not
going
to
be
lorna's,
perfect
solution,
and
you
know
and
everyone's
perfect
solution,
because
everyone
has
opinions
so
so
yeah,
it's
not
gonna,
be
perfect
for
anyone,
but
I
think-
and
I
hope
that
we
can
get
a
good
enough
proposal
to
move
forward
and
to
leave
the
spec
in
a
health
and
healthy
status.
A
B
A
No,
I
don't,
I
don't
think
we
should
be
creating
working
groups,
because
that
implicitly
leaves
some
people
out
either.
We
don't
want
to
leave
anyone
out
right,
so
I
think
we
should
be
as
open
as
as
possible.
We
follow
the
open
governance
approach.
A
Node.Js
has
been
following
this
approach
for
years
and
it's
working
well,
even
though,
if
you
don't
like
javascript
but
node.js
is
working
well,
but
the
you
know
the
the
organization-
and
I
think
we
should
follow
this
model
as
well
like
which
will
keep
allowing
anyone
to
jump
in
and
give
me
thoughts.
Of
course,
at
some
point,
we'll
have
to
stop
listening,
let's
say
and
and
taking
a
decision.
Of
course.
This
decision
is
what
what
I
was
talking
about.
The
proposals
we
can
be.
A
We
can
be
working
on
on
a
specific
proposal.
You
know
like
we
just
work
on
a
proposal.
Everyone
can
work
on
a
proposal.
If
that's
not
that's
not
going
to
be
perfect
either.
So
there
will
be
people
pissed
off
by
our
decisions.
I'm
gonna,
I'm
I'm
sure,
but
I'm
sorry
like.
I
cannot
please
er
everyone
right.
I'm
not
a
canadian.
A
Sorry
for
canadians,
but
but
but
yeah,
you
know
what
I
mean:
it's
like
it's
not
going
to
be
perfect,
but
it's
transparent.
Actually,
so
chris
was
just
raising
this
topic
so
the
process,
let
me
just
share
with
people
wondering
what
the
process
looks
like.
A
Yes,
so
so
I'm
sharing
the
chapter
there
in
the
chat
and.
A
A
A
So
the
thing
is
that
we're
gonna
we're
gonna,
keep
inviting
people
to
leave
opinions
after
this
proposal
is
merged,
and
maybe
after
I
mean
I'm
saying
after,
but
there
may
be
other
proposals
in
the
middle
being
merged
right
on
version
two,
so
most
probably
in
the
next
months,
we'll
be
inviting
new
people
to
become
maintainers
and
therefore
voters,
people
with
the
right
to
vote
to
the
spec
right
to
the
to
the
specification,
because,
let's
clarify
that
this
whole
thing
goes
by
reaper
right.
A
So
each
reaper
has
a
set
of
owners
code
owners
right,
which
are
the
maintainers
or
the
people
with
voting
rights,
and
who
are
these
people
that
we're
gonna
invite
to
to
join
as
maintainers
the
people
who
have
who
has
been
working
on
the
spec?
A
B
A
Become
a
maintainer
eventually,
you
know
it's
just
if
you
keep
pushing
you'll
become
a
maintainer
as
well
of
course,
so
you
know
what
I
mean
it's
like.
We
we're
trying
to
we're
trying
to
to
be
as
transparent
as
possible
here,
and
I
want
to
remove
as
much
responsibility
for
myself
as
possible
as
well
like
because
otherwise
yeah
we're
linux
foundation
project.
We
have
a
charter
blah
blah
blah,
but
in
the
end
friend
decides
no.
A
I
want
to
remove
this
and
that's
why
I'm
also
not
allowing
strictly
not
allowing
offline
conversations
trying
to
convince
me
to
go
one
way
or
the
other
I
I've
had
I've.
Had
this
people
politicking
with
me.
You
know
offline
trying
to
convince
me
to
go
one
way
or
the
other
no
way.
I'm
not
gonna
allow
this,
and
if,
if
someone
is
thinking
about
doing
this
and
is
watching
this,
no
don't
do
it.
B
So
I
mean
there's
public
discussion
right,
but
there's
also
different
formats
of
public
discussion.
Right,
like
I,
I
totally
agree
like
I
said
I
use
a
working
group.
I
would
say
a
working
group
is
whoever
you
know
is
interest
interest
enough
to
devote
the
time
to
it,
but
I
do
feel
like
having
a
real-time
interactive
discussion
with
whoever
is
interested
in
having
that
real-time
interactive
discussion
is
really
valuable.
I
think
this
is
proof
positive
of
that
right
now.
B
So
I
think
that
I
would
advocate
for
anyone,
who's
interested
show
up
I'll
show
up
in
the
middle
of
the
night
and
talk
about
it,
because
I
do
feel
like
sort
of
doing
it
in
real
time
and
not
and
being
able
to
respond
in
real
time
and
sort
of
ask
probing
questions
like
you
did
today.
I
think,
has
a
has
real
value
to
it.
A
As
a
manager
is
that
what
I've
been
feeling
is
and
noticing
is
that
there
are
many
people
who
don't
open
their
mouth
in
public,
not
in
public.
A
You
know
in
in
group
when
they
are
in
group
in
conversation
in
a
group
conversation,
they
don't
open
their
mouth,
they
have
thoughts,
they
have
really
good
thoughts
and
they
don't
and
they're
afraid
to
open
their
mouth
because
it's
like
you
know
this
is
not
I'm
not
smart
enough
like
them
or
something
while
if
it's
offline,
a
synchronous
like
this
living
a
common
disease
differently-
and
this
is
the
number
one
reason
I'm
doing
this
episodes
one
by
one
and
that's
why
I'm
not
inviting?
A
A
So
I
I
want
to.
I
want
to
avoid
that
as
well,
like
people
dominating
conversations
and
there's
egos,
there's
a
lot
of
things,
there's
lack
of
ego
as
well
sometimes,
and
I'm
trying
to
be
a
you
know
like
as
flexible
as
possible
there,
and
I
think
this
asynchronous
discussion
it
is.
It
is
good
and
also
it's
impossible
for
all
of
us
to
be
in
a
single
call
at
the
same
time,
because
we
have
people
in
australia,
america
and
europe,
so
someone
is
going
to
be
at
11
or
2
a.m.
A
You
know
11
p.m
or
2
a.m.
You
know
having
a
call
which
is
not
cool
and,
and
you
will
not
have
the
best
version
of
this
person
in
life
gold
and
also,
and
also
I
hate,
taking
decisions
in
meetings,
and
it
is
good
to
have
these
conversations
just
thinking
out
loud
process,
thinking
about
right
and
that's
cool,
but
then
decisions
will
be
taken
offline
and
with
time.
So
people
can,
you
know,
think
about
it
well
and
and
also
for
the
sake
of
transparency
as
well.
So
yeah.
B
I
will
I
will
volunteer
for
2am
duty
I've.
I
found
an
infant,
so
I'm
I'm
more
than
more
than
capable
of
operating
at
2am
in
the
morning.
A
A
You're
going
to
be
part
of
the
working
group
because
you
already
made
the
proposal
so
you're
working
on
that
right,
but
yeah
so
so
yeah
before
we
finish
because
we're
wait,
we're.
A
A
That's
right,
that's
fine!
When
it's
when
it's
a
funny
conversation,
it's
a
interesting
conversation.
I
I
always
like
to
to
keep
it.
So
you
know
it's
at
the
end
of
the
episode
and
as
we
are
approaching
the
end
of
the
episode,
I
always
ask
people
to
leave
a
question
for
the
next
guest,
but
before
that
I'm
gonna
remind
you.
A
What
was
the
question
that
the
michael
lefty?
Okay,
so
so
yeah?
So
that's
that's
a
thought,
and
so
now
it's
your
time.
I
would
love
to
ask
you
to
ask
a
question
for
the
next
guest.
C
C
To
be
talking
about
too
so
yeah,
that's
a
tough
one.
That's
the
one
thing
I
forgot
to
do
to
prepare
is
think
of
the
question
for
the
next
guest.
I
love
it,
but
but
I'll
I'll
I'll
just
say
the
first
thing
that
comes
to
mind.
I
know
that
jesse's
gonna
present
his
proposal
that
introduces
the
concept
of
endpoints.
C
So
I
would
like
to
ask
him
if,
if
there
is
a
way
we
can
kind
of
merge
in
what
I
presented
earlier
about
the
idea
of
roles
in
with
that
that
you
know,
can
I
can
I
somehow
come
up
with
a
definition
of
an
application
that
says
rather
than
me
saying?
Yes,
I
am
an
endpoint,
and
this
is
what
I
do
sort
of
say.
Well,
I
have
these
roles
that
might
involve
multiple
endpoints
and
how
can
I
pull
those
in
without
you
know
being
redundant?
C
I
guess
so
that'll
probably
be
a
challenge
for
jesse,
because
he
probably
doesn't
really
know
what
I'm
talking
about,
because
the
idea
is
very
fuzzy
in
my
mind
too,
but
hey,
let's
have
fun.
Let's
yeah.
B
C
B
You
want
to
again
have
endpoints
that
are
not
true
endpoints,
but
rather
define
a
role.
You
could
then
through
through
a
reference
inherit
or
reference
those
roles
and
then
potentially
extend
them
as
a
as
an
end
point.
So
you
know
the
certain
roles
have
capabilities.
Your
implementation
of
an
endpoint
uses
those
roles
through
reference
to
to
gain
those
capabilities,
and
then
you
extend
them.
So
I
do
think
that
there
is
a
a
good
use
case
for
what
michael's
talking
about.
I
understood
immediately,
even
though
it
was
wasn't
a
serious
one.
B
I
think
it
was
actually
a
great
one.
I
do
think
that
it's
it's
an
important
thing
for
us
to
to
think
about
seriously,
because
I
think
it
touches
upon,
particularly
when
we're
exposing
our
our
you
know
sort
of
our
api
to
external
entities.
What
we're
really
doing
that
doing
is
giving
them
a
particular
role
and
then
their
implementation
follows
on
from
that.
From
that
particular
role.
B
B
What
that
or
external
organization
chooses
to
do
is
sort
of
a
separate,
async
api
that
is
dependent
upon
that
endpoint
definition
and
I'm
being
fuzzy.
Now
too,
this
is
sort
of
laid
out
more
in
the
proposal.
I've
been
talking
for
like
an
hour
and
a
half
an
hour
and
a
half.
So
I
totally
understand
mike's
question.
B
I
do
think
there's
a
role
for
roles
and
I
would
encourage
you
to
check
out
the
the
proposal
where,
hopefully
I'm
a
little
bit
more
coherent,
but
I
I
feel
like
I
don't
want
to
be
dipped
out
of
my
my
chance
to
ask
a
question
and
I
feel
like
it's
natural,
that
you
would
be
the
next
person
in
line
since
you
are.
B
I
can't
believe
it
for
putting
forward
your
own
proposal,
which
is
a
total
surprise
to
me.
So,
do
I
get
to
ask
you
a
question.
A
D
B
If
we
put
forward
and
pass
async
api
3.0
proposal,
will
you
breakdance
live.
A
A
Love
it
yeah,
that's
a
good
one,
that's
a
good
one
and
related
to
that.
So
chris
was
just
asking
like
how
can
people
be
invited
to
vote,
and
I
don't
want
to
skip
this
question
so
just
to
make
it
clear
for
those
who
are
watching.
A
You
are
not
invited
to
vote
so
only
only
the
maintainers,
the
people
nominated
as
main
as
maintainers
on
each
reaper
can
vote.
A
So
for
that
you
have
to
become
a
maintainer
to
have
the
right
to
vote
and
to
become
a
maintainer
you
have
to
like,
not
continuously,
but
you
often
have
to
be.
You
know
contributing
to
the
to
the
to
acing
kpi.
You
know
to
this
specific
reaper
right.
So
if
you
want
to
be
a
maintainer
of
the
spec,
you
have
to
be
contributing
to
the
spec,
often
and
contributing
can
be
making
proposals
reviewing
other
purposes
of
giving
feedback.
A
A
So
that's.
We
hope
that
this
never
happens.
We
hope
that
we
can
friendly
reach
consensus
on
a
full
request,
level
or
israel
level
if
you
want
so,
for
instance,
this
probably
subscribe.
We
hope
to
reach
consensus.
A
Consensus
doesn't
mean
that
we
have
to
be
all
of
us,
so
be
happy
with
the
solution,
but
at
least
the
majority
of
us
would
be
happy
with
the
solution
right.
So
yeah.
B
A
Circumstances
is
usually
that
I
will
say
that
it's
not
50,
plus
one,
I
would
say
it's
it's
usually
everyone
right,
like
everyone
agrees
consensus
is
that
we
all
agree
on
something,
but
when
consensus
is
not
reached,
then
we
have
to.
We
have
to
go
through
other.
You
know
systems
which
is
voting
basically
and
there
it's
by
majority,
which
is
50
plus
one.
I
think
it's
on
the
chart
there.
I
don't
even
recall
anymore
what
we
did
there
because
we
changed
it.
Then
we
changed
back
that
which
is
it
again.
A
A
So
with
all
of
that
jesse
thanks
for
joining
me
today,
I
really
appreciate
this
conversation.
It's
been
a
long
conversation
because
it's
been
an
interesting
conversation.
It
has
so
it's
great,
so
yeah
and
and
yeah.
So
thanks
thanks
a
lot,
and
I
really
appreciate
that
you,
you
join
me
and
yeah.
I
hope
that
we
can
see
your
proposal
moving
forward
and,
and
we
can
at
some
point,
merge
all
the
proposals
into
single
one
and
then
come
to
our
consensus.