►
From YouTube: Thinking Out Loud #3 — with Michael Davis
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
So
welcome
everybody.
Welcome
to
one
more
episode
of
thinking
out
loud
today.
I
I
would
love
to
to
invite
michael
davis
to
talk
about
me
so
michael
has
been
has
has
been
the
one
that
made
the
first
proposal
to
talk
about,
publish
and
subscribe
and,
and
he
told
he
he
works
personally
and
but
before
before,
I
invite
him
to
join
the
the
stream.
A
I
would
love
to
to
share
some
small
chunk
of
information
with
all
of
you,
so
so
for
all
of
you
who
don't
know
what
thinking
out
loud
is,
this
is
probably
the
most
boring
show
if
you
want,
so
I
don't
I'm,
not
pretending
or
I'm
not
trying,
so
that
this
becomes
a
a
super
funny
show
and
but
instead
it's
a
place
where
we
can
all
think
out
loud
and
think
together
and
discuss
proposals
about
async
api
specification
and
also
in
the
future
about
smgpa
tools
as
well.
So
don't
want
to
talk
more.
A
B
Sure
I'm
a
software
developer.
I've
been
working
at
solace
for
almost
five
years
now,
mainly
working
on
a
product
called
the
event
designer
and
that's
a
place
where
you
can
describe
schemas
and
events
and
applications
and
what
applications
can
subscribe
or
publish
to
to
events,
and
so
on
and
yeah.
Before
that,
I
spent
about
10
years
doing
contracting
work
for
the
canadian
government
and
various
departments,
and
before
that
I
spent
a
few
years
working
in
as
a
developer
in
the
financial
services
area
in
toronto.
B
So
yeah
I'm
based
in
ottawa
in
canada
and
yeah.
That's
that's
about
it.
A
A
Got
me
like,
like
you
know,
it
was
insane
for
me.
It
was
ottawa
right,
so
ottawa.
C
A
So
so
people
usually
so
for
me
as
a
spanish
person
right,
the
spanish-speaking
native,
when
I
see
we
pronounce
every
letter
the
way
they
see
them
in
a
word.
C
A
B
A
A
B
A
Yeah,
that's
true,
it's
true,
so
so
yeah
I
mean
that
just
wanted
to
share
this
this
funny
piece
of
my
past
with
the
english
right
so
with
the
english
language
cool
michael.
So
let's
just
move
forward
a
little
bit
with
with
this.
So
just
to
put
people
in
context.
We're
gonna
discuss
a
little
bit
about
publish
and
subscribe
confusion
on
async
api,
so
many
people
are
including
myself
are
getting
confused
with
the
meaning
of
publishing
subscribe
and
I'm,
I
have
to
admit
it
like.
A
B
A
And
so
yeah
we're
aware
that
this
is
this
is
customer
problem.
Maybe
you
want
to
tell
me
a
little
bit
more
about
your
first
experience
with
this
kpi
and
the
confuses
that
it
introduced
to
you.
B
Sure,
well,
the
first
thing
I
did
with
async
api
was,
you
know,
go
through
the
tutorials
and
and
the
street
light
tutorial
and
run
it
with
the
mqtt
server,
and
that's
where
I
immediately
got
confused
like
it
says
we're
publishing,
but
we're
really
subscribing,
and
I
I
think
I
had
to
kind
of
figure
it
out.
I
assumed
that
you
were
coming
from
the
point
of
view
of
open
api
where
you've
got
a
document
that
says,
for
example,
there's
a
get
verb,
and
that
doesn't
mean
the
server
is
doing
it
again.
B
It
means
the
client
is
expected
to
do
a
get
right
and
you
can
generate
code
for
the
client
where
the
client
does
the
get
and
you
can
generate
code
for
the
server
where
the
server
responds
to
a
get
request.
Right,
so
am
I
right
and
and
thinking
that
that's
kind
of
the
original
idea
behind
the
way
you
define.
A
C
A
It
was
convenient,
but
yeah
it
caused
this
problem
that
I
couldn't
detect
up
front
that
we're
seeing
that
we're
discussing
today
right
so
yes,.
B
Right
and
so
when
we
started
working
with
it
in
solace,
where
we,
you
know,
have
an
application
that
subscribes
to
something
we
generate
the
code
and
the
async
or
we
generate
the
async
api
file.
From
that
definition
and
to
be
correct,
we
say:
publish
almost
everybody
that
looks
at
it
says:
you're
doing
it
backwards.
You've
got
it
wrong.
We
have
to
explain
to
everybody
why
that
is
right,
so
so
that's
it's
kind
of
a
a
sore
spot
all
around.
So
that's
that's
why
we
came
up
with
the
idea
to
add
this.
B
This
view
parameter
where
we
can
say
well.
Why
don't?
We
have
a
way
to
put
something
in
the
file
to
say
that
we're
looking
at
it
from
the
opposite
point
of
view
right
so
that
when
we
say
an
application
is
subscribing,
then
the
application
really
is
subscribing,
and
I
don't
think
that
helped
very
much.
I
mean
that
was.
That
was
the
original
proposal
we
set
forth.
But
then
we
have
this
thing
where
the
view
can
be
either
provider
or
client,
and
I
can
never
remember
which
one
is
which
you
know.
B
That's
the
other
thing
now.
We've
got
sort
of
two
sources
of
confusion
right,
so
I
I
don't
think
my
proposal
really
helped
solve
the
problem.
Much
I
mean
it
gave
me
kind
of
an
easy
band-aid
solution
for
the
code
generator
I've
been
working
on.
I've
been
working
on
two,
but
the
main
one
is
for
spring
cloud
streams
and
java,
and
so
that
gave
me
a
way
to
have
a
little
switch
so
that
I
could
say
well,
you
know
if
we
want
the
document
to
look
the
way.
B
We
want
it
to
look
where
the
application
is
subscribing
when
it's
subscribing,
and
I
want
the
generated
code
to
to
sort
of
show
that
then
then
I
can
have
a
little
switch
that'll
do
it.
On
the
other
hand,
if
I'm
getting
a
document
that
you
know
where
I'm
supposed
to
follow
what
the
spec
says,
I
should
do
then
I'll
do
it
properly
for
that
where
publish
means
subscribe.
So
so
it
gave
me
a
workaround,
but
still
obviously
it's
not
satisfy
the
community.
It's
not
even
satisfied
us
at
solids.
B
We
still
get
confused
and
you
know
we
think
we'd
like
to
we'd
like
kind
of
something
something
different.
So
I
don't
know,
can
I
share
my
screen,
there's
a
kind
of
a
scenario
that
I'd
like
to
show,
because
that
I
mean
we
can.
We
can
talk
about
that.
But
there's
there's
also
another
thing
that
we
can
talk
about
kind
of
at
the
same
time,
which
is
the
idea
of
do.
B
We
want
an
async
api
document
to
describe
like
this
entire
system,
with
all
the
events
flowing
through
it
and
all
the
channels,
or
do
we
want
to
make
it
specific
to
one
application,
or
you
know,
as
lorna
called
it
one
node
or
one
actor
even
or
whatever,
and
I
think
I'd
like
to
kind
of
talk
about
that
at
the
same
time
and
sort
of
explain
why?
Okay,
so
I'm
going
to
share
my
screen.
A
Yes,
in
the
meantime,
while
you
share
your
screen,
I
would
like
to
disagree
with
you
on
something
that
you
said.
You
said
that
it
didn't
your
proposal.
C
A
Really
went
farther
and
they
didn't
contribute
so
much
I
I
don't
know
if
that
were
these
were
the
words
you
use,
but
more
or
less
like
this.
I
have
to
disagree
with
that.
I
think
your
proposal,
just
by
starting
the
conversation,
is
actually
doing
a
lot.
So
no
everybody
was
complaining
at
at
that
point,
but
nobody
was
taking
the
lead
here
and
saying:
hey
here's
a
proposal.
A
Maybe
it
doesn't
work
like
what
you
said
like
I
made
a
proposal,
but
it's
really
not
good
or
not
enough
for
us
and
not
even
not
for
the
community
as
well.
But
you
start
right,
you
start
to
do
the
sketching
and.
B
Okay
thanks:
I
have
to
try
and
figure
out
how
to
do
this,
I'm
having
trouble
getting
the.
B
We
should
have
set
that
up
before
right.
Let
me
try
one
more
time.
It's
telling
me
I
have
to
go
into
my
preferences
and
mac
and
and
change
permissions.
B
B
B
Okay,
well,
maybe
if
I
sort
of
scrunch
things
down
a
little
bit,
so
I
can
sort
of.
A
B
Okay,
so
the
idea
here
is
like
an
iot
application
where
you've
got
this
temperature
sensor,
that's
sending
temperature
readings,
and
then
this
data
collector
that's
collecting
that
data
and
if
the
temperature
somewhere
is
like
way
too
big,
then
it
can
send
this
alarm
to
this
emergency
responder
and
the
emergency
responder,
you
know,
might
send
an
sms
message
to
a
person
who
will
go
and
you
know,
fix
the
problem
right
so
good
so
far,
yep
so
I
mean
the
way
that
we
design
things,
for
example,
is
that
we
have
an
event
that
describes
the
temperature
reading
and
it's
got
a
topic.
B
Yeah,
so
an
event
in
our
world
has
a
topic,
and
this
this
topic
has
this
variable
for
the
sensor
id
and
it
describes
the
the
content
to
like
the
payload.
In
this
case,
it's
just
simply
a
number,
whereas
if
we
go
back
to.
B
B
B
But
the
we
don't
want
this
to
need
to
know
about
that.
We
don't
want
the
sensor
to
know
about
the
emergency
responder.
The
emergency
responder
doesn't
need
to
know
anything
about
temperature
readings.
All
it
cares
about,
are
alarms,
and
so,
in
my
mind,
it's
ideal.
If
this
guy
has
its
own
file
right,
just
describing
what
it
does,
the
emergency
responder
has
its
own
file
and
all
the
only
event
it
cares
about
is
the
alarm
event,
and
the
data
collector
knows
both
and
the
reason
why
they
should
be
separate.
B
B
If
we
have
one
file
that
describes
all
the
events
and
all
the
channels
whenever
there's
a
change,
that
means
that
everything
needs
to
be
looked
at
and
re-examined
it's
like
do.
We
need
to
rebuild
this
application
or
not,
and
because
of
the
dependencies,
it's
very
expensive
to
make
any
change
anywhere.
That's
where
I
think
it's
ideal.
B
If
if
things
are
sort
of
kept
small
and
we
have
a
different
file
for
each
different
application-
okay-
so
that's
that's
kind
of
one
thing
I
wanted
to
to
discuss
and
if
that's
the
case
that,
if
the
temperature
sensor
doesn't
need
to
know,
it
doesn't
even
need
to
know
about
the
data
collector.
All
it
needs
to
know
is
that
it's
emitting
these
temperature
readings
right
so
yeah,
so
that's
kind
of
where
we're
at
with
that.
So
I
just
wanted
to
raise
that
issue
too.
That
not
only
is
it
better.
B
I
think
if
the
temperature
sensor
is
explicit
about
publishing
this,
where
you
know
we
don't
really
care
what
the
other
apps
are
doing
or
looking
at
it's
also
ideal.
If,
if
we
try
to
compartmentalize
things
so
much
that
that
the
change
in
one
area
is
not
going
to
affect
the
change
in
another
area,.
A
Yeah
and
I
think
as
well
I
mean
this.
This
is
a
good
point.
Actually
I
think
it
was
lorna
who
mentioned
once
that,
maybe
what
we
should
be
doing
is
like,
like.
Actually,
I
think
she
said
like.
A
A
To
to
make
you
know
to
make
it
possible
right,
so
we
shouldn't,
I
think
in
my
opinion,
I
think
we
should
be
preventing
that
option
as
well,
because
I
think
also
they'll
reinforce
that
part
as
well
like
so
dale's
use
case
was
precisely
like
having
a
like
a
list
of
of
topics
available
and
he
was
actually
saying
like
I
don't
care
if,
if
I
can
publish
or
subscribe
it's
like
or
who
can
publish
or
who
can
subscribe,
I
just
want
a
list
of
channels
right.
A
list
of
topics
in
this
game.
C
A
So
I
think
it's
still
valuable,
but
yeah
like
like
what
you
said
like.
If
we
go
and
create
like
a
single
file
for
the
whole
thing,
then
we'll
have
to
figure
out
ourselves
the
dependency
management
here
like
what
how
to
how
to
figure
out
which
service
should
be
changing
like
redeploying
or
rebuilding.
B
Yeah,
we
actually
have
another
thing
that
we're
working
on.
We
just
released
a
beta
version
of
it
called
api
products
where
you
can
just
sort
of
list
a
bunch
of
events
and
make
them
available
and
we
have
an
export.
We
export
that
to
async
api
too,
and
that's
kind
of
more
along
the
lines
of
what
dale
was
proposing
in
terms
of
having
a
catalog
right.
So
we've
got
that
as
well.
B
So
we've
got
you
know
the
event
designer
that
I
showed,
which
is
which
is
really
focused
on
applications
and
then
this
api
products,
which
which
is
kind
of
like
provide
a
catalog
so
like
one
of
the
examples,
could
be,
and
the
example
I
showed
there
was
the
emergency
responder
right.
So
we
could
sort
of
publish
that
as
an
api
product.
That
says
anybody
who
wants
to
use
the
emergency
responder,
here's
the
events
that
you
can
publish
to
or
subscribe
from
or
subscribe
to,
and
we
generate
async
api
for
that
as
well.
B
So
that
gives
a
whole
other
perspective
and
that
that
sort
of
I
mean
it's
nice
that
the
specification
is
flexible
enough
to
support
these
different
use
cases
right
either.
I
want
to
generate
code
for
an
application
where
I
want
to
provide
a
catalog
of
all
the
events
and
all
the
topics
in
our
system.
B
Represent
this
particular
scenario,
so
what
I
did
was
I
exported
the
asic
kpi.
You
have
to
make
the.
B
Okay,
so
like,
for
example,
the
temperature
sensor
itself,
the
async
api
looks
like
this,
so
it
says
subscribe,
even
though
it's
publishing
this
is
going
along
with
the
with
the
official
spec
right.
So
this
is
the
way
that
we're
exporting
that
application
now,
but
in
our
api
products
thing
we
can
say
well.
A
B
Okay,
so
okay,
the
data
collector
when
I
exported
that
application.
I
get
this.
It
says
okay,
this
is
for
the
alarm
and
this
is
how
I
send
alarms,
and
this
is
how
I
receive
the
temperatures
sensors,
but
what
I
really
want
to
do
in
terms
of
roles
like
if
we
have
this
idea:
okay,
so
the
temperature
as
an
api.
B
I
just
sort
of
made
this
up
yesterday
just
to
play
with
like
that.
We
could
add
this
thing
that
says:
here's
a
role
of
whoever's
using
it
will
have
the
role
of
temperature
reader
that
if
you're
using
my
api,
you're
interested
in
reading
temperature,
sensing
things
right
and
then
the
emergency
responder
api,
that's
saying:
well,
let's,
let's
give
it
a
roll
called
emergency
reporter
and
your
job
if
you're
using
my
api,
is
to
report
emergencies,
report
alarms
and
because
we've
got
these
things
defined
as
roles.
B
B
You
know
the
schema
and
the
topic
or
channel
name
or
whatever,
and
so
that
allows
me
to
kind
of
combine
various
things
from
various
like
features
of
other
files
into
one.
So
that's
kind
of
one
idea
I
had
about
how
to
do
this,
and
I
know
jessie
manning
had
a
kind
of
a
proposal
that
I
think
is
is
even
better
well
much
better
than
this
that
you
know
he
talks
about
endpoints,
but
but
that
that's
another
solution
to
this.
B
A
B
My
one
application
wants
to
do
two
things:
it
wants
to
receive
temperature
sensor
events
and
it
wants
to
send
alarms,
and
so
because
we
have
an
api
that
describes
the
temperature
sensor
and
what
it
does,
and
we
have
another
api
that
describes
the
emergency
responder
and
what
it
does
I
can
say.
Well,
I
want
to
use
those
things
in
my
application.
B
A
B
Yeah
now
you
have
to
sort
of
look
into
the
other
files
to
see
that
actually,
this
this
doesn't
really
solve
that
problem.
So
much
as
try
to
solve
the
problem
of
of
or
try
to
represent
a
different
idea
of
having
you
know
what
lorna
called
actors.
B
C
A
A
Not
I
mean,
I
think
it's
a,
I
think
it's
a
it's
a
good
idea
like
because
you're
exploring
roles
instead
of
actors,
like
you
said
like
so
actor,
is
like
more
like,
I
think,
in
real
life.
So
an
actor
is
just
one
single
person
and
roles.
You
know
the
same
role
can
be
represented
by
different
actors
right,
so
so
yeah.
B
So
it's
kind
of,
but
I
thought
like
this-
would
be
implicit
in
the
role
we
shouldn't
have
to
explicitly
say
that
here,
because
the
role
of
a
reader
is
to
read,
you
know
and
that
kind
of
implies
subscribe
yeah.
So
I.
A
Know
I
know
but
yeah
the
the
thing
with
this
is
that
it
is
implicit
for
us
for
humans,
but
not
for
machines
right,
because
this
temperature
reader
can
actually
have
any
any
name
right.
It's
not
just
you
know
what
I
mean.
So
it's
not.
B
That's
why
I
wasn't
trying
to
say
that
the
name
implied
it,
but
just
that
it
would
be
specified
in
the
document
itself
and
we
give
it
a
role
name
that
would
be
a
hint
to
a
human.
You
know
that
this
is
what
it
does,
but,
of
course,
whether
it
publishes
or
subscribes
would
be
in
in
the
document
explicitly.
You
know,
machine
readable
for
sure.
A
So
now
I
I
get
I've
been.
I've
been
also
thinking
about
this
problem,
myself
like
I
before
we
jump
into
the
call
into
the
live
stream.
Today,
I
was
actually
sharing
with
you
that
I
that
I
have
also
my
own
proposal,
but
it's
not
something
I've
been
sharing
yet
because
you
know
I
don't
want
to
be
like
looking
like.
Look
at
this
guy
is
is
like
hearing
opinions
from
these
other
people,
but
he
already
has
his
own
opinion
and
he
doesn't
care
right.
A
This
series
of
episodes
about
publish
and
subscribe
on
nasa
kpi
and
which,
by
the
way,
is
next.
The
next
episode
will
be
the
last
one
in
in
in
theory
and
let's
see
if
we,
if
no
more
proposals
appear
in
the
in
the
in
the
next
two
weeks
and
and
so
and
so
yeah,
so
something
that
I've
been
thinking
about
as
well
is
when
you
have
an
async
api
file.
A
You
have
a
section.
We
we're
focusing
a
lot
in
public
and
subscribe,
because
that's
the
problem
right
problem
at
hand
here
right
now,
but
I
see
another
problem
implicit
with
this,
which
is-
and
I
want
to
know
your
opinion,
which
is
we
have
a
problem
with
channel
reuse
virtualization,
which
is
we
have
published
and
subscribe
inside
the
channel
definition.
A
So
if
we
want
to
extract
this
to
another
file
and
reference
it
from
publisher
and
from
the
subscriber,
then
we
got
a
problem
because
channel
definition
says
publish
or
subscribe
one
of
them
right,
but
depending
on
who
is
referencing,
the
channel
might
want
to
publish
or
might
want
to
subscribe.
So
it
makes
the
channel
not
really
reusable
at
all
right.
So
that's
that's
a
problem
right
and-
and
I
think
this
is
something
that
we
we
need
to
to
solve.
A
A
I
don't
think
it
is,
and-
and
I'm
gonna
explain
myself
so,
when
you're
working
with
brokers,
your
application-
is
a
client
right.
It's
a
client,
it's
a
kafka.
Client,
it's
a
mqtt
client
is
it's
a
client.
It's
not
server.
The
server
is
the
broker
right,
so
your
application
is
a
client,
but
when
you're
working
with,
let's
say
a
websocket
api-
and
you
are
the
developer
of
the
api
like
say,
for
instance,
we
have
slack
like
the
same
example.
So
you
are
a
slack
then
your
application
is
not
a
client.
A
Your
application
is
a
server
and
you
have
clients
right
and
everything
is
defined
in
this
in
the
same
place
in
the
servers
section
right.
So
there's
no
way
to
differentiate,
which
one
is
the
server
that
I'm
exposing
myself.
My
application
is
exposing.
My
is
exposing
itself
or
which
server
is
actually
a
remote
server,
a
broker
or
something
right.
A
I
would
like,
I
would
love
to
know
your
opinion
about
that,
like
what
do
you
think
is,
could
be
a
I
don't
know
potential
solution,
or
what
do
you
think
about
that
in
general?
If
you
have
no
thoughts
about
it,
that's
also
fine.
No.
B
First
of
all,
I
totally
agree
that
the
channels
should
not
have
the
operations
inside
them.
You
know
it'd
be
nice
if
channels
just
simply
had
messages
describing
the
payloads
and
the
channel
names.
You
know
they
kind
of
map
to
topics
in
some
in
some
systems
yeah.
I
agree
with
that.
B
I
think
there
should
be
another
place
where
we
say
that
an
application
subscribes
to
a
channel
or
publishes
to
a
channel
or
like,
in
the
case,
there's
the
other
case
of
response
request
response
too,
which
also
has
to
be
dealt
with
where
we
even
need
something
else
to
somehow
say
you
send
requests
on
this
channel
and
receive
the
response
on
that
channel.
You
know
that
that's
still
a
gap
that
we
need
to
think
about
in
terms
of
servers
this.
B
This
is
probably
a
bit
controversial
and
you
may
hate
me
for
saying
this,
but
I
I
don't
think
there
should
be
details
about
servers
in
these
documents
because
to
me
it's
kind
of
a
security
risk.
For
one
thing,
like
you,
don't
want
to
expose
connection
information,
also
like
as
you're
working
with
one
of
these
applications
or
or
you
know,
a
document,
and
it's
going
through
various
periods
of
being
developed
and
then
tested
and
then
put
in
staging
put
in
production
that
the
server
address
is
probably
going
to
change.
B
You
know
every
time
right,
and
so
I
think
that
server
connection
information
should
be
external
to
the
document.
There
may
be
other
things
related
to
bindings
that
might
be
useful
to
keep
in.
You
know
that
describe
certain,
I
don't
know
quality
of
service
things
or
something
like
that.
I'm
not
sure
about
that.
There
could
be.
There
could
be
certain
server-specific
things
that
are
useful
for
the
application
to
know
that
that
may
be
consistent
through
all
the
different
environments
that
an
application
is
running
in.
B
You
know
that
that
are
the
same,
no
matter
which
broker
which
server
it
connects
to.
I
guess
the
other
thing
that
kind
of
makes
it
interesting
if
you're
looking
at
something
like
kafka
or
solace
or
mqtt.
B
So
how
valuable
is
that
information
like
like
we've
so
far,
not
really
used
the
server
section?
Hardly
at
all,
like
we
don't
touch
it
when
we're
exporting
events
for
our
new
api
products
thing
we
do,
allow
you
to
put
in
a
server
name
and
a
port,
and
there
you
know
again.
I
I
believe
that
has
limited
value,
because
the
server
name
and
the
port
are
going
to
change
depending
on
where
you're
running
it
anyway.
So
you're
going
to
discard
that
information
anyway,
so
yeah.
Those
are
my
thoughts.
A
A
So
you
you
get
me
curious
with
this
part
of
of
like
it
can
be
a
security
problem.
First
of
all,
and
and
I
I
should
be
mentioning
that
you're
yeah,
you
probably
will
be
biased
by
your
use
case-
you're
working
with
brokers
all
the
time
so
but
that's
not
the
the
only
use
case
on
the
amazing
kpis.
So
there's
also
this,
like,
I
said,
like
websocket
server,
for
instance.
A
So
in
the
case
of
a
websocket
server
that
is
going
to
be
public,
like
slack
api,
for
instance,
I
think
it's
important
to
know
where
you
have
to
connect
to
right.
Otherwise,
otherwise
you
don't
know
how
to
start
consuming
events
right
or
publishing
events
so
and
and
the
url
is
fixed
right,
because
it's
a
it's
a
public
url
or
might
be
fixed.
You
know
it
might
be
templated
right.
So,
for
instance,
what
you
were
saying
like
the
the
url
might
change,
because
the
port
might
change.
A
That's
fine!
That's
why
we're
using
template
we're
losing
the
uri
templates.
A
So
so
you
can
define
those
those
chunks
right
like
this
is
important,
can
change
at
any
time.
This
is
your
user
id,
which
is
auto
generated
or
whatever
right,
or
this
is
a
random
id
that
we
generate
every
time
whatever
right.
I
do
think
that
in
in
the
case
of
solas
from
the
event
designer
perspective,
it
doesn't
have
much
value.
I
agree
with
that.
I
mean
how
can
I
disagree
right
like
if
you
didn't
find
value
it's
because
it
doesn't
have
value.
A
B
Yeah,
like
I
accept
that
that
that's
that's
a
good
good
use
case,
I
guess
yeah
when
they're
public
and
you
know
well-known,
then
why
not
sure.
A
Yes
and
and
for
instance,
another
another
use
case
of
using
brokers,
for
instance,
is
it's
not
very,
very
common
yet,
but
we've
seen
something
in
in
in
these
lines
and
it's
companies
exposing
their
brokers
to
the
public.
You
know
so
their
broker
url
to
the
public,
so
you
can
connect
user
using
a
username
and
password.
A
A
If
you
are
who
you're
saying
you
are,
or
you
know
like,
that's
how
you
authenticate
right
and
and
then
you
start
consuming
events
like
in
mqtt
or
like
especially
for
for
iot,
I've
seen
a
bunch
of
them
and
for
receiving,
for
instance,
updates
of
you
know
like
what
was
the
name
of
this
like
the
value
of
the
currencies,
you
know
like
ticks,
I
think
yeah.
A
Yes,
exchange
rates,
yes,
so
so
receiving
this
in
real
time
as
well.
This
this
is
you
connecting
directly
to
the
broker
and
receiving
information,
and
the
url
of
them,
therefore,
is
it's
table
it's
public
and
it's
it's
always
the
same
right.
You
may.
C
A
Have
things
in
the
url
that
might
change
like
you
probably
have
to
connect
to
a
url?
That
is
your
username.theproduct.com
right,
so
so
yeah
things
like
this,
but
yeah?
A
No,
I
think
I
think
it's
I
I
never
thought
about
it,
but
I
never
thought
that,
from
the
perspective
of
the
event,
designer
you'll
never
find
value
of
the
server
section.
That's
that's
actually
interesting.
B
Yeah,
well,
you
know
we
are
starting
to
see.
Just
like
you
say
there
are
organizations
that
are
starting
to
expose
their
data
publicly.
You
know
through
various
kinds
of
event,
brokers
and
sure
that
that's
a
great
example
of
where
you
would
want
to
use
the
servers
section
so.
A
So
I
have
another
question
that
is
like
it's:
it's
bugging
me
all
the
time
and
it's
it's
actually
kind
of
related
to
request
response
as
well,
but
so
do
you
think
that
a
message
belongs
to
a
channel
to
it
or
or
let's
say
another
way
like?
Do
you
think
that
a
channel
should
have
a
fixed
set
of
messages
that
can
eventually
flow
there?
A
A
Like
should
it
be
more
strictly
related
to
the
channel
or
the
operation
like?
Is
it
something?
Because
I'm
now
that
I'm
considering
like
getting
rid
of
publish
and
subscribe
from
the
definition
of
the
channel?
Now
I
think
myself
as
well
like
so
the
message
be
theirs
as
well
like
so
the
message
be
linked
somehow
to
the
channel,
or
maybe
it
will
go
with
the
operation
somewhere.
B
It
becomes
more
difficult
to
develop
the
applications,
because
then,
when
you
receive
messages,
you
have
to
make
sure
it's
really
the
message
that
the
kind
of
you
know
you
have
to
figure
out
what
the
message
format
is
somehow
right.
That's
why
it's
always
easier
to
have
different
different
schemas
on
different
channels.
Just
so
when
you're,
you
know
receiving
something
on
a
particular
channel.
You
know
what
to
expect.
B
That
being
said,
of
course,
there's
things
like
avro
that
handle
different
schema
versions
automatically
for
you,
so
there
could
be
different
different.
You
know,
payloads
could
look
differently,
but
I
think
you're
you're
sort
of
raising
an
example
where
you
publish
you
know
with
one
kind
of
payload
and
receive
on
another
payload.
B
But
if
it's
going
through
the
same
channel,
who's
ever
subscribing
to
that
channel
will
receive
all
those
messages
anyway,
so
they're
gonna
have
to
figure
out,
which
is
which
and
so
it's
possible.
If
people
really
want
to
do
that,
I
I
don't
think
we
should
prevent
it,
but
I
think
you
know
the
consequence
is
that
the
application
will
have
to
have
that
extra
complexity
of
having
to
look
at
the
message,
content
and
figure
out.
You
know
what
it
is.
Maybe
it
could
be
easily
done
in
message
headers.
B
You
know
where
the
header
could
have
the
name
of
the
schema
or
something
so
that
you
don't
even
have
to
deserialize
it.
Unless
you
know
you
want
it,
you
can
just
discard
it.
If
it's
not
the
kind
of
message
you
want,
but
to
me
it
just
it
has
that
level
of
complexity
and
and
brittleness,
and
I
think
you
know,
from
the
point
of
view
of
developing
applications,
it'd
be
harder
to
get
it
right.
B
But
but
in
terms
of
the
specification,
I
think
we
should
be
flexible
enough
to
allow
that,
but
in
terms
of
like
who's,
the
owner
too,
like
who
really
owns
what
the
message
should
be,
what
it
looks
like
that
kind
of
raises
another
issue
about
governance
right,
like
who's
allowed
to
change
the
schema
on
a
message
on
a
channel
or
whatever,
and
you
have
like
two
applications
that
are
communicating
across
a
channel
and
who
who's
got
the
authority
to
change
it
right.
B
A
So
some
people
tell
me
like
it's.
It's
a
responsibility
of
the
producer
right
of
the
publisher,
but
we
tend
to
forget
that
there
may
be
more
than
one
publisher
well.
B
B
A
And
what,
if
you
have
like?
Likewise,
you
have
different
subscribers
like
in
this
case.
It's
clear
right,
like
you,
have
just
one
subscriber
that
is
going
to
receive
the
alarms,
but.
C
A
It
triggers
an
event
and
notifies
various
services
on
microservices,
etc.
So
you
have
one
that
sends
email
to
the
to
the
user.
You
have
another
one
that
I
don't
know,
updates
some
crm
or
something
you
know,
and
you
have
others
like
doing
other
stuff
right.
So.
A
B
I
don't
think
either
is
you
know
like
like
if
thinking
about
the
way
that
we've
done
it
in
in
seoul
lists,
like
you
know,
there's
you've
got
like
an
application
and
you
got
an
event
and
then
you
got
another
application,
and
you
know
if
you
have
permission
to
change
the
design
at
all,
then
you
can
go
in
and
change
you
could.
You
know,
change
the
schema
associated
with
that
event
and
now
you've
you've
just
kind
of
broken
these
two
applications.
They
would
need
to
be
rebuilt.
B
But
it's
kind
of
your
responsibility
to
understand
that
right,
like
I
don't
think
or
or
the
designer
could
say,
yeah
like
it's,
this
application
is
the
one
that
really
should
kind
of
own
this
event,
because
it's
the
one
that
has
to
sort
of
deal
with
it
and
it
kind
of
is
up
to
the
people
designing
the
whole
system
to
sort
of
decide.
I
guess
you
know.
A
A
C
A
These
these
two
are
using
different
servers
you're
using
this
backing
for
front-end
approach,
for
instance,
and
and
each
of
them
are
sending
messages
that
I
usually
just
signed
up,
one
from
the
mobile
application
and
one
from
the
browser
sending
a
message
to
the
broker.
So
you
have
two
producers
of
the
same
event
and
then
you
might
have
these
all
these
micro
services
receiving
it.
So
you
might
have
two
three
one
thousand.
I
don't
care
so
so
you
have
many
to
manage
there
effectively
right.
A
So
when
people
tell
me
like
it
should
be
the
producer
it's
like
which
producer
yeah
and-
and
why
like
or
in
your
case
like
if
you're
receiving,
alarms
and
you
are
the
owner
of
this-
I
mean
it-
will
make
more
sense
that
the
subscriber,
in
this
case
is
the
owner
right
of
the
of
the
event,
but
so
yeah.
A
So
I
think
it's
actually
it
will
be
people
yeah
and-
and-
and
this
is
that's-
my
question
related
to
to
the
you
know-
to
the
the
message
being
tied
to
the
channel
or
to
the
operation
was
also
coming,
because
there
are
certain
protocols.
If
I'm
not
mistaken,
I
think
nats
allow
you
to
do.
A
A
So
if
you
send
a
request,
you're
going
to
receive
a
response
on
the
same
topic
and
but
when
you
send
a
response,
sorry,
when
you
send
the
request
you're
not
going
to
receive
your
own
request,
you
know
the
protocol
is
smart
enough
to
know
that
you
are
the
publisher,
I'm
not
going
to
send
you
the
your
own
event
right.
I'm.
A
Going
to
admit
it
right
so,
even
even
though
you're
subscribed
to
the
topic,
but
I'm
not
going
to
send
this
event
to
you,
because
you
are
the
one
publishing
it
so
so
that's
an
example.
Actually
I
think
amqp1
also
has
this
capability
that
you
can.
I
think
it's
with
a
header.
You
can
say
that,
don't
please
don't
tell
me,
don't
don't
send
me
my
own
message
right.
A
It's
there
because
I
published
it
so
so
then
it
effectively.
A
Bi-Directional
right
like
for
for
now
it
there,
they
have
been
like
still
bi-directional,
you
can
power,
listen
subscribe,
but
if
you,
if
you
do
both,
if
you
publish
and
subscribe
into
into
the
same
channel
when
you
publish
you're,
going
to
receive
your
own
message
right
and
that's
a
concern
from
for
some
protocols
right
and
for
some
type
of
architectures
and
but
but
some
are,
some
protocols
are
avoiding
you
to
to
have
this
problem.
A
A
A
B
A
Yes,
exactly
so
that's
that's
that's
why
I
was
saying,
like
it's
actually
related
to
to
request
and
response,
because
then,
if
that's
the
case,
we
with
the
current
setup
or
let's
say
we-
move
the
publish
and
subscribe
out
from
the
channel
definition
and
we
leave
it
as
it
is.
Without
the
with
the
without
the
operation
definition,
then
you
will
have
to
list
two
possible
messages
for
the
channel
request
and
the
response
right.
So
you
you
will
have
two
right
and.
A
A
C
A
Multiple
definitions,
then
it's
incorrect
right,
but
if
you're
doing,
if
you're
doing
requests
and
response,
how
can
you
guarantee
that,
like,
for
instance,
if
my
request
is
just
a
simple
plain
string
saying
or
no
turn
on
right
and-
and
my
response
is
okay,
like
I
don't
know
like
okay
turn
turn
on
then
strings,
and
both
of
them
are
gonna,
be
matching
the
the
message
definition.
So
one
off
cannot
be
used
there
right.
A
A
B
Yeah,
that's
a
real
edge
case
right
because
that
only
really
applies
to
the
kind
of
I
think
so
I
think
so
because,
because
what
we're
saying
is
that
when
we
send
a
message
on
this
channel,
we
want
this
message
format
when
we
receive
it.
We
expect
only
this
other
thing,
but
both
are
on
the
channel
like
if
you're,
just
looking
from
the
outside,
seeing
the
messages
flowing
through
you
see
both
of
them.
B
I
mean,
I
think
that
that
that
particular
scenario
could
easily
be
worked
around.
If
you.
B
B
C
B
B
I
mean
and
you're
yeah
fair
enough,
but
in
your
example,
they're
following
the
same
format
anyway,
they're
just
a
string
right,
so
it's
just
kind
of
what's
the
difference,
there's
really
no
difference.
So
why
don't?
They
just
share
the
same
schema
that
just
says
it's
just
a
string
like.
Why
do
you
need
two
different
messages?
Yeah.
A
As
well
yeah,
exactly
no!
No!
That's
that's
a
good
point.
You
don't
need
two
messages,
that's
right
because
it's
it's
actually
the
same
definition
so
yeah
so
probably
yeah.
I
was.
I
was
thinking
that
maybe
no
you're
right
completely
right.
Yeah
in
this
case
doesn't
make
sense.
It
was
a
bad
example
from
website.
B
Well,
I
mean
we
could
change
the
example
and
say
yeah.
You
send
a
string
and
then
receive
just
a
number
where
the
number
is
just
a
status
quo
like
zero
means.
Okay
and
it's
any
other
number.
If
something
went
wrong
right
now,
you've
got
two
different
messages
that
have
two
different
payloads.
So
how
does
that
change
things?
B
A
A
It
is
like
this
will
be
strings,
but
there
may
be
inherent
definitions,
like
you
said
like
if
it
starts
with
a
zero
it,
it's
a
code
right
if
it
starts
with
a
zero,
it
means
something
one
another
thing
two
another
thing,
and
maybe
you
can
only
publish
messages
starting
with
zero
or
one
and
but
but
you
will
only
receive
messages
with
two
and
three,
for
instance
right
or
with
two
or
with
one
two
and
three
for
instance.
Then,
let's
make
an
overlap
between
requests
and
response
there.
A
In
this
case
it
is
like
how
do
you?
How
do
you
actually
explain
this
to
the
user?
Without
I
mean
we,
of
course
we
have
these
description
fields
right,
that
people
can
feeling
for
humans
and
they
should,
but
but
yeah
like
how
can
we
make
it
like
more
explicit
from
a
machine,
readable
perspective
right
now?
That's
that's.
Why
I
was
thinking
that
maybe
it
will
be,
it
will
be
interesting
to
explore,
but
yeah
never
never
mind.
I
mean
this.
A
I
think
this
is
a
you
know
something
to
think
about
we're
approaching
actually
we're
the
past
time,
but
that's
okay.
A
Before
we
finish,
I'm
doing
something
with
every
guest,
I'm
sure
you
have
seen
the
previous
episode
with
with
dale.
So
I
asked
dale
to
ask
a
question
to
the
next
guest,
but
he
didn't
know
you
were
the
next
guest.
So
let
me
just
put
it
so
people
can,
let's
just
remind
you
what
which
was
the
question
it
was
about
to
ask
you
a
favor.
As
you
don't
know,
the
next
guest,
and
so
I
would
love
if
you
could
ask
a
question
to
the
next
guest.
C
Well,
I
I
touched
really
briefly
earlier
on
the
distinction
between
design
time
versus
run
time
and
how
and
I'd
love
to
hear
what
more
people
think
about
that
like
are.
Do
they
see
use
cases
for
async
api
in
a
runtime
way,
we're
not
really
doing
much
with
the
more
dynamic
runtime
elements
of
it
and
I'm
interested
to
know
what?
What
is
anyone
else
interested
in
taking
async
api
more
into
that
space?.
C
B
Well,
I
haven't
really
thought
much
about
run
twine
use
of
async
api.
B
I
you
know
my
first
thoughts
about
that
were
like
there
could
be
a
use
case,
that's
similar
to
what
avro
and
schema
registries
do
where
you
might
sort
of
dynamically
discover
like
what
schema
you're
going
to
expect
just
by
you
know,
fetching
an
async
api
file
and
looking
at
the
schema
and
saying
okay,
that's
it.
I
I
mean
avro
already,
does
that
I
don't
know
if
there's
much
point
in
duplicating
that
kind
of
functionality.
B
B
What's
the
advantage
of
doing
this
in
run
time
where
you
fetch
or
generate
a
file
on
the
fly,
and
it
could
be
something
new,
something
different?
What
are
you
going
to
do
with
that?
Does
that
mean
there's
new
new
channels
that
you
haven't
seen
before
that
you
know?
Are
you
going
to
subscribe?
What
are
you
going
to
do
with
them?
B
Have
the
schemas
changed?
Well,
if
you're
running,
like
a
java
application,
it's
kind
of
too
late
to
generate
a
new
model
file
that
represents
that
schema,
so
you
could
have
something
dynamic.
That's
just
a
bunch
of
you
know,
hash
tables
and
arrays
of
primitives
or
whatever
that
represent
the
data,
but
that's
kind
of
inconvenient.
So
I
guess
you
know
the
short
answer
is
no.
B
I
haven't
really
thought
of
a
really
good
use
case
for
for
runtime
use,
but
I
would
love
to
hear
of
one
just
because
I
can't
think
of
one
doesn't
mean
they
don't
exist
right.
So
yeah
I'd
like
I'd
love
to
to
hear
more
about
that
I
mean.
The
other
thing
I
should
mention
is
that
you
know
in
solids.
B
We
we
generate
these
documents
on
the
fly
right
so
that
when
you
change
an
event,
change
a
scheme
or
whatever
we
don't
store
the
files
we
generate
them
on
demand,
so
in
a
sense
they're,
almost
a
bit
like
runtime
and
that
they
they
get
generated
on
the
fly
on
demand.
But
that's
a
bit
different
anyway.
A
Yeah,
it's
probably
that
yeah,
so
the
generation
of
the
kpi
file
is
isn't
runtime
yeah,
that's
you're,
actually
designing
it
through
it.
So.
B
A
So
I
think
I
think
that
maybe.
A
So
maybe
related
to
to
scheme
and
race
trees.
There
could
be
something
there
for
sure.
I'm
sure
that
there
could
be
some
use
cases
there.
I
haven't
thought
about
it
yet
as
well
like
when,
when
people
compare
this
to
avro
and
it's
pretty
common,
I
wouldn't
comparison
kpi
to
avro.
A
I
will
compare
json
schema
to
avro
because
they're,
it's
kind
of
like
more
related
right,
so
it's
average
just
for
defining
the
message
right
and
not
the
whole
application
or
what
channels
are
or
anything
just
how
the
message
looks
like
and
json
schema
could
be.
The
use
for
the
same
purpose
right
so
json
schema
is
not
for
defining
data.
It's
for
defining
validations,
let's
say
or
yeah
like
I
don't
recall
the
name
they
use.
So
it's
like
for
defining
constraints
on
data
right.
So
it's
like
this.
A
A
But
it
also
has
these
if
dang
else
constructs
that
are
not
possible
to
map
into
a
into
a
typing
system
like
with
avro,
so
avro
maps
perfectly
to
typing
system
so
and
because
the
purpose
is
is
completely
different
right.
So
I
guess
that's
why
it
is.
It
was
super
easy
for
the
kafka
people
to
to
implement
average
support
because
yeah
you
can,
you
can
generate
an
avro
binary
definition
and
embed
it
into
the
you
know
into
the
message
itself.
A
So
you
have
the
definition
along
with
the
message,
and
you
always
have
an
up-to-date
definition
of
your
message,
because
it's
coming
along
with
the
message.
So
that's
cool
right
but
yeah,
but
something
that
to
think
about
maybe
is
about
runtime.
Now
that
I'm
thinking
about
is
maybe
brokers
could
be
providing
more
value
in
runtime
right,
so
brokers
loading.
A
I
think
that
that
could
be
a
a
good.
I
mean
we're
developing.
You
know
the
event
gateway
ourselves
that
it's
meant
to
sit
between
clients
and
brokers,
so
that
you
can
validate
and
do
stuff
with
the
message
and
mainly
validate
it
because
yeah
it
is
not
easy
or
let's
say
it's
not
viable
to
think
that
every
broker
in
the
planet
is
going
to
implement.
It
isn't
gps
important.
A
We
call
it
gateway,
but
it's
actually
more
like
proxy,
and
it
just
leaves
the
message,
content
and
validated
against
the
synthetic
definition
so
effectively
for
the
client
for
the
user.
It's
like
the
broker
is
validating
the
message,
but
it's
not
right.
It's
it's
this
piece
in
the
middle
right
that
that
is
completely
transparent.
B
That's
a
great
idea,
because
you
know
if
you
have
some
rogue
application,
that
starts
sending
bad
messages.
It
breaks
a
bunch
of
applications
that
are
listening
right,
so
yeah
yeah.
We
should
do
something.
A
Like
that,
especially
with
public,
you
know,
with
public
phased
apis.
C
A
If
you
spoke
like
nothing,
prevents
people
from
starting
sending
wrong
messages,
maybe
not
on
purpose
doesn't
have
to
be
on
purpose.
You
know
like
badly
formatted
or
I
don't
know
whatever
so
yeah.
So
that's
that's
a
thought,
and
so
now
it's
your
time
would
love
to
ask
you
to
ask
a
question
for
the
next
guest.
B
Know
who
he
is-
and
I
know
what
you're
going
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
just
say
the
first
thing
that
comes
to
mind.
I
know
that
jesse's
going
to
prevent
present
his
proposal
that
introduces
a
concept
of
endpoints.
B
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?
B
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
that's,
let's
have
fun.
Let's
yeah.
A
Exactly
that's
what
I
like
about
this
part
of
the
of
the
you
know
of
the
show,
which
is
ask
a
question
to
the
next
guest.
Even
though
you
don't
know
who
the
person
is,
and
in
this
case
you
know
who
he
is
and
and
he's
actually
working
with
you
so
but
that's
fun
because
you,
you
didn't
dedicate
time
to
think
about
it
and
now
you're
putting
him
in
troubles,
and
I
love
it.
A
A
B
A
So
dave
same
thing,
so
thanks
dave
for
watching,
and
one
thing
that
I
want
to
remind
to
people
is
this
is
not
a
two
guys
show.
A
It
is
called
thinking
out
loud
for
a
reason,
and
we
we
like
to
think
about
things.
Nothing
of
this
is
prepared,
like
we
just
jumped
into
the
conversation
and
and
decided
to
to
just
fluently
talk
about
it
and
and
also
would
love
to
remind
you
that
you
can
participate
via
chat
and
during
the
whole
episode
right
like
you
can
we're
live.
This
is
not
recorded
so
happy
to
happy
to
respond
to
your
questions
or
take
your
thoughts
as
well
from
the
from
the
chat.
C
B
A
Have
troubles
anyway,
so
so
yeah
anything
to
reply
to
jesse.
B
A
Yeah,
so
I
I
yeah,
let's
make
it
clear
for
for
the
audience
as
well
like
before,
jumping
live
so
so
michael
wanted
to
also
talk
about
the
proposal
from
jesse,
but
since
jesse
is
the
next
guest
right.
I
was
like
no,
let's
not
talk
about
jesus
proposal,
because
next
episode
we
will
talk
about
it
right.
So
let's
just
talk
about
your
thoughts
and
let's
jesse
talk
about
his
thoughts
and
at
some
point,
we'll
collect
all
thoughts
together
and
come
up
with
a
super
cool
proposal.
I'm
sure
so.