►
From YouTube: Thinking Out Loud #2 — with Dale Lane
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
Hello,
everyone
welcome
to
another
episode
of
thinking
out
loud
today.
I
would
like
to
introduce
dale
lane,
but
before
I
jump
into
that,
I
would
love
to
explain
the
purpose
of
thinking
out
loud
itself
right.
A
This
is
the
second
episode
of
thinking
out
loud
and
I
started
it
with
the
purpose
of
getting
the
community
together
to
work
on
smtpi
challenges
so,
for
instance,
we're
now
discussing
the
publish
and
subscribe
meanings
on
this
api
which
are
causing
a
lot
of
confusion,
and
I
have
to
admit
myself
as
well
to
myself
so
I'm
inviting
members
of
our
community,
like
I
invited
lorna
and
today,
I'm
inviting
daily
to
speak
about
and
to
come
up
with
potential
creative
solutions,
or
at
least
to
leave
some
clues
to
the
community
and
to
the
audience
on
how
we
could
be
solving
that
right.
A
So,
as
I
was
saying,
I
don't
want
to
spend
more
time
explaining
this
today,
I'm
happy
to
introduce
and
to
and
to
have
dale
lane
developer
at
ibm.
C
Yeah
sure
machine
learning
for
kids
is
is
trying
to
raise
awareness
amongst
children
about
what
ai
and
machine
learning
is
all
about,
how
it
impacts
their
lives,
starting
to
open
their
eyes
up
to
how
ai
isn't
this
future
thing.
But
it's
actually
here
now
and
it's
already,
you
know
we
all
interact
with
these
systems
every
day
and
it
gets
them
to
learn
about
this
stuff
through
hands-on
projects.
C
So
they
train
their
own
machine
learning
models
and
they
build
things
with
them
and
it's
all
integrated
with
platforms
that
students
are
used
to
so
things
like
scratch.
So
they
get
this
of
visual,
drag
and
drop
way
of
building
machine
learning-powered
ai
projects,
and
by
doing
it
they
get
to
sort
of
understand,
get
a
bit
of
an
insight
into
what
this
technology
is
and
how
it
affects
us.
A
Awesome
that
sounds
exciting
before
we
joined
live.
I
was
telling
dale
that
I
might
be
interested
in
what
he's
doing
with
machine
learning
for
kids.
Now
that
I
have
a
baby
so
we'll
I'm
for
sure,
we'll
ping
you
in
the
future,
once
you
know
the
baby
can
actually
do
something
other
than
crying
and
eating
right.
But
yeah
sounds
like
I
mean
something
exciting
and,
as
I
agree
like
artificial
intelligence
is
not
something
of
it
of
the
future.
Is
it's
happening
right
now?
A
It
can
be
improved
by
a
lot
yet,
of
course,
but
you
know,
machine
learning
has
been
around
for
a
while
and
it's
getting
you
know
it's
getting
even
better
and
better,
and
I
think
this
is
gonna
make
a
difference
in
the
future
and
even
even
nowadays,
by
the
way
the
other
day.
A
Now
it
you
reminded
me,
with
this:
the
other
day
we
were
discussing
how
we
could
be
generating
different,
the
same
api,
parse
snk,
api
parser
in
different
programming
languages,
but
we
don't
want
to
create
an
intermediate
language
or
or
dsl,
or
something
like
that,
because
that
would
be
like
too
much
right
and
we
were
discussing,
like
maybe
a
machine
learning
approach
to
this,
like
we
train
the
machine
learning
model
on
how
to
translate
from
one
programming
language
to
another.
A
A
C
Yeah
that's
an
interesting
idea
because
in
some
ways
it's
sort
of
analogous
to
translating
from
natural
language
one
to
another.
I
mean
we're
able
to
do
that,
because
there
are
large
numbers
of
examples
of
a
document
written
in
one
language
and
another
so
yeah.
What
would
the
equivalent
be?
It
would
be
a
fun
project
to
try.
A
I
got
you
curious
with
them
great
I'll,
we'll
talk
about
it
later,
I'm
sure
so
dale
so
we're
here
today
to
discuss,
publish,
subscribe,
meaning
or
perspective
or
call
it
whatever
you
want.
A
A
I
would
prefer
this
subscribe
and
listen
capguy
to
have
a
different
meaning,
but
yeah,
I
don't
know
which
one
right
so
so
here
here
we
are
like
we're
discussing
this
on
a
github
issue
that
I'll
share
with
the
with
the
audience
later
and-
and
also
I
would
love
to
invite
the
audience
here
today
to
leave
some
questions
in
the
chat
or
leave
some
comments.
A
If
you
have
ideas
and
we're
happy
to
discuss
what
you
have
to
tell
us
on
the
on
the
chat
right,
so
my
question
for
you
is
what
has
been
your
feeling
with
regards
to
publish
subscribe
when
working
with
this
in
kpi.
C
So
I
definitely
misunderstood
the
way
the
spec
was
meant
to
work.
I
mean,
like
you
say
I
I've
since
realized
that
I'm
in
good
company,
so
that's,
okay.
I
I
think
partly
why
I
misunderstood
it
was.
C
I
think
the
main
bit
I
missed
was
the
at
the
goal
being
to
describe
an
application,
because
that
wasn't
what
I
was
setting
out
to
do
so
the
goal
I
had
was
essentially
being
more
channel
oriented
trying
to
describe
the
sources
of
data,
not
the
application,
and
it's
because
the
sorts
of
customers
I
was
working
with
and
the
kind
of
problems
we
were
looking
at
were,
if
you
think,
of
microservices
applications.
C
There's
a
lot
of
the
issue
has
been
looking
at.
If
you
take
that
whole
microservices
application,
how
could
you
describe
it
in
a
spec
and
describe
all
the
interactions
between
the
microservices
that
wasn't
what
I
was
trying
to
do?
I
was
looking
at
if
you
look
at
the
application
as
a
whole
as
that
sort
of
logical
application
boundary
and
what
are
the
apis
that
are
external
to
that.
C
You
know
what
are
the
event
sources
that
are
going
to
be
exposed
for
use
outside
of
the
microservices
application,
so
I
was
looking
at
it
as
an
outward
external
thing,
so
kind
of
the
details
of
the
application
weren't.
What
I
was
trying
to
capture
essentially,
if,
if
someone
has
got
something
producing
message,
so
I've
come
at
this
from
the
kafka
side
of
things.
C
I've
been
working
in
the
kafka
space
for
many
years
now,
so
I
tend
to
frame
a
lot
of
this
in
in
kafka
terms,
but
I
think
it
sort
of
applies
to
other
protocols
as
well.
If
a
team
has
got
something
producing
messages
to
a
kafka
topic,
they're
going
to
make
use
of
that
themselves,
they've
got
a
reason
why
they're
doing
that
and
they're
using
that?
That's
fine.
C
But
how
do
you
enable
reuse?
How
do
you
think
you
know?
Well,
I
actually
I've
got
this
stream
of
events
that
is
about.
I
don't
know
whatever
it
is
and
I'm
making
use
of
that,
but
I
think
that
I've
gone
to
the
trouble
of
setting
this
up.
There
might
be
other
developers
in
my
organization
that
could
you
make
other
uses
of
it.
So
I
want
them
to
know
that
this
topic
is
there
that
the
stream
of
events
is
there.
I
want
them
to
know
how
to
get
going
with
it.
C
What
data
looks
like,
but
I
wouldn't
consider
them
using
it
to
be
part
of
my
application
or
to
be
interacting
with
my
application.
It's
just
partly,
I
think,
as
I'm
coming
at
this
from
like
an
api
management
world,
I'm
used
to
the
idea
of
publishing
and
socializing
apis
to
enable
them
to
be
reused,
not
because
they're
part
of
my
microservices
application,
but
just
that
I
consider
that
an
external
interface
you
know
that's
on.
I
publish
that
externally,
that's
on
the
boundary,
so
that
so
that
other
teams
can
make
use
of
it.
C
C
Listening
to
the
when
you
were
talking
lana
last
time
around
around
things
like
looking
at
actors,
and
I
was
trying
to
work
out
like
how
does
that
map
to
the
problem,
I'm
trying
to
solve
of
my
external
interfaces
that
or
my
external
reuse,
because
I
yeah,
I
don't.
B
A
So
I
guess
so
I
guess
what
you
were
looking
for
in
first
place
was
like.
I
think
we
we
discussed
this
in
the
past,
like
like
a
menu
of
channels
where
you
can
just
publish
or
subscribe.
You
don't
care
if,
if
an
application
is
publishing
or
subscribing
you
just
want
to
have
like
a
list
of
here
are
my
list
of
topics
in
the
case
of
here
on
my
list
of
topics
and
of
course
you
can
pass
this
to
the
topic
and
subscribe
to
the
topic,
but
you
don't
want
that.
A
You
just
want
to
know
the
existence
of
these
topics,
how
to
and
how
to
send
messages
and
and
what
to
expect
when
sending
messages
and
receiving
messages,
and
things
like
that,
I
guess,
like
you-
were
not
looking
at
the
application
side
but
more
on
the
overall
system.
Description
right.
C
Yeah
cataloging
it
as
a
source
of
data,
so
you
know
here
is
the
stream
of
events
that
you
might
find
useful
in
your
application.
I
have
no
idea
how
you
might
use
it,
what
you
might
do
with
it.
It's
there
if
you
want
it,
but,
but
so
conceptually,
I
don't
think
of
like
if
you
write
an
application.
That
starts
doing
something
interesting
with
my
stream
of
events
from
my
topic.
I
don't
consider
your
application
to
be
interacting
with
mine.
I'm.
C
Not
it
doesn't
bother
me,
I
I'm
making
use
of
the
messages
on
the
topic
for
my
own
purposes,
but
I'm
documenting
it
with
async
api
to
enable
you
to
write
an
application
and
not
just
you
but
the
10
other
use.
They
might
write
10
other
applications.
Doing
you
know
wonderful
things,
I'd
never
even
considered
it's
that
that
was
the
kind
of
thing
I
was
trying
to
enable
that
sort
of
discovery,
innovation
that
sort
of
enable
wider
reuse
of
these
sources
of
events.
C
The
kind
of
things
we've
seen
enabled
in
by
api
management
over
the
last
few
years-
we're
not
a
few
years
many
years,
and
that
was
where
I
saw
async
api
as
being
a
nice
way
of
crisply,
describing
that
to
enable
reuse
and
stuff
like
the
cogen
accelerates
that
reuse,
so
it
all
sort
of
fit.
But
because
I
wasn't
trying
to
describe
my
application-
or
at
least
I
didn't
think
of
myself
as
describing
an
application.
C
So
so
I
can
sort
of
see
why
I
ended
up
there,
but
I
still
think
that's
a
use
case
that
we
can
address
as
we
take
the
spec
forward
and
even
with
things
like
the
you
know,
whether
we
call
it
actors
or
views
or
perspectives,
or
any
of
that
I
think
that's
fine.
I
think
we
can.
I
can
still
sort
of
describe
my
problem
in
my
use
case
in
that
way.
It's
just.
I
have
a
more
generic
actor
of
anonymous
consumer
that
that
I
don't
need
to
know
about.
A
Yeah,
like
a
default
actor-
maybe
something
like
that,
like
you,
have
like
a
default
actor,
you
don't
know
who
this
actor
is
it's
like
a
it's
something
that
you're
doing,
because
the
spec
requires
you
to
define
an
actor
or
something
like
that
in
case.
We
go
that
way,
of
course,
but
I
mean
that
that
problem
that
you're
describing
it's
not
the
first
time.
I
hear
it
like
you
mentioned
a
lot.
A
You
know
enabling
reuse
of
of
the
channels
of
the
definitions
right
and-
and
I
think
that
has
been
another
issue
so
together
coupled
to
the
public
subscribe
issue.
There
is
the
the
other
issue,
which
is
I'm
gonna,
I'm
gonna
show.
I
think
it's
better.
If
I
show
my
so
people
can
understand
better
what
I'm
talking
about,
because
in
my
mind,
it's
perfect,
but
but
I'm
I'm
working
all
day
with
with
using
kpis,
but
I
think
that's
the
case
for
everyone
right.
So
let
me
try
again
so
this
one.
A
A
This
is
a
list
of
channels,
let's
say
or
a
map
of
channels,
and
this
is
the
operation
problem
subscribe,
and
this
is
again
that's
a
part
of
the
channel
like
what
it's
going
to
be
inside
the
channel
or
flowing
through
the
channel.
If
you,
if
you
see
channels
as
pipes,
I
tend
to
imagine
them
as
as
pipes,
and
this
is
what
this
this
is-
the
water
flow
into
the
pipe
right.
So
this
is
the
the
messages
was
where
it's
going
to
be
inside
the
bike
inside
the
channel.
A
So
if
we
want
to
reuse
this
channel
definition
the
mind
channel
definition,
it
is
impossible
because
we
have
the
problems
here
right
and,
and
the
problem
is
that
this
is
not
part
of
the
channel.
This
is
what
the
application
is
doing
with
the
channel
right.
It
is
enabling,
in
this
case
it's
enabling
publishing,
so
others
can
problems
to
this
channel
to
communicate
with
myself.
It
is
highly
confusing
to
describe
that
people
is
always
expecting
that
publish
there
means
I
am
publishing
to
this
channel
this
message,
which
is
like.
A
If
you
look
at
this,
it's
like
what
it,
what
you
will
think
it
is
doing
right,
but
it's
not
it's
the
opposite.
Actually,
so.
C
Used
the
publish
very
much,
or
at
least
because
I'm
using
async
api
to
describe
external
interfaces,
I
haven't
yet
come
across
a
use
case
where
customers
create
a
topic
and
want
someone
outside
of
their
application,
someone
external
to
their
team,
to
start
putting
messages
on
their
topic,
so
we've
only
been
using
it
for
consuming,
like
essentially
using
async
api
to
describe
like
a
contract
saying
I
have
this
topic,
and
this
is
what
I'm
going
to
be
putting
on
it,
and
you
can
be
sure
that
this
is
what
the
data
on
this
topic
will
look
like.
C
So
if
you
decide
to
consume
it
and
make
use
of
it,
you
know
what
to
do
with
it,
but
like
for
what
we've
been
doing,
we
don't
allow
other
teams
who
discover
the
topic
exists
in
through
the
async
api
spec
and
use
that
to
work
out
how
to
start
consuming.
We
don't
allow
them
to
publish
to
it
because,
and
like
say,
I've
got
a
narrow
use
case
right.
C
So
although
I've
got
a
number
of
examples
of
where
that's
a
problem,
I
tell
you
I'm
not
saying
the
spec
shouldn't
have
a
publish
as
part
of
its
semantics,
but
just
that
for
the
for
the
problem
I'm
trying
to
solve.
I
don't
want
someone
to
interact
with
my
app.
I
don't
want
someone
to
affect
my
app
and
I
don't
want
someone
to
put
stuff
on
my
topic.
What
I'm
doing
is
describing
what
I'm
doing
with
my
topic,
and
you
can
use
those
messages.
A
So
yeah
it
makes
total
sense.
So
this
is
more
like
the
approach.
That's
why
you're
never
using
problems
here
like
here
which
isn't
subscribe?
I
mean
you
could
be
using
whatever
yeah,
because
you
don't
you're
not
really
concerned
about
what
others
can
do
with
the
channel.
You
know
that
anybody
can
can
be
publishing
or
subscribing
to
these
topics.
A
So
yeah
you
don't
you're,
not
worried
about
the
birth
here
so
and
and
you're,
not
the
only
one.
So
so
my
proposal
or
my
think
initial
thinking
about
that
was-
and
I
think
it
was
inspired
by
a
comment
from
james
higginbotham
like
we.
What
if
we
have
what
if
we
take
the
birth
out
from
the
channel
description,
I
think
that's
a
mask.
That's
why
I
was
saying
like
did
it?
A
This
problem
is
like
very
related
to
the
department
subscribe
problem
like
general
reusability
is
like
strictly
coupled
to
the
problem
at
hand
here
and-
and
I
was
thinking
like
what,
if
we
have
like
a
menu
of
channels
right
something
like
this
and
we
have
operations
separated
right.
A
Led
as
to
his
actor
description,
but
again
I
would
love
to
to
you
know
to
explore
it
again
a
little
bit
further
and
what?
If
we
have
something
like
operations-
and
we
have-
I
don't
know
paladins
to
my
channel
right-
something
like
this
and
the
operation
type
is
going
to
be
published
and
and
the
channel
is
going
to
be
my
channel,
which
is
defined.
B
A
Right
on
the
on
the
channels
list,
so
by
doing
this,
by
doing
this,
we'll
have
we'll
have
a
list
of
things
that
this
application
is
doing
right.
This
application
here
do
it,
but
then
I
thought
like
what,
if
none
of
this
is
actually
required,
like
you
can
have
all
of
them
are
optional
right.
So
what
if
I
don't
know
having
a
list
of
channels
is
optional?
Maybe
you
can
be
referencing
an
external
channel
here
or
or
you
can
have
your
channels
here,
but
what
if
this,
I'm
just
gonna
comment
the
gap?
A
So
then
it
will
sweep
your
use
case
perfectly
right,
like
you,
just
get
a
list
of
channels
of
topics
with
the
messages
described
inside
and
and
that
will
be
like
this
kind
of
menu
right
like
this
makes
sense
like.
Is
it
something
that
will
fit
your
use
case.
C
Yeah,
and
certainly
like
I
said
you
know
I've,
I
looked
at
this
as
describing
the
data
describing
I've
been
looking
at
this
from
a
channel
centric
point
of
view,
but
that
said,
you
know
I
do
see
on
on
the
get
fed,
there's
a
lot
of
people
who
really
see
a
lot
of
value
in
the
application-centric
approach
side.
So
I'm
wary
of
throwing
that
out,
but
I
think
the
problem
when
you
go
for
an
application-centric
approach
is
which
application
are
you
describing
like?
Are
you
describing?
C
A
C
C
A
Of
yeah
it's
not,
it
is
not.
I
mean
it
is
like
permissions.
Yes,
I
I
recall
friend
of
mine,
told
me
once
like
you
probably
can
explore
explore
this
a
little
bit
more,
like
a
permission
side
of
things,
let's
say
or
permission
approach,
but
it's
not
so
much
about
permission.
It's
more
about
like
if
you
publish
to
this
channel,
then
I'll
get
this
message
right
this
I
I
am
the
application.
A
A
That's
that's
the
sort
of
definition
that
we
have
right
now
then
on
ac
and
that
fits
well
when,
when
you
have
like
client
server
architectures
like
with
http
or
web
sockets,
where
you
have
a
client
and
you
have
a
server
and
you
can
tell
your
client
what
they
have
to
do
right,
but
I
mean
it
fits
let's
say:
maybe
not
well
but
better,
and
when
you
have
a
broker-based
architecture.
A
A
Who
is
you
and
and
why
should
I
be
talking
to
someone
who's
like?
No,
I
just
I
don't
care,
and
even
driven
architecture
is
usually
one
of
the
cool
things
is
loose.
Coupling
yes
loose
coupling
feature
right
so
that
you
can
create
new
publishers
and
subscribers
or
or
whole
applications
that
will
publish
and
subscribe
to
different
topics.
There
will
be
a
mix
and
you
don't
have
to
tell
anyone
right
you
just
plug
it
and
and
connect
it
to
the
broker
and
it
works.
C
Async
api
is
useful
for
that
because,
like
I
said
I,
I
see
it
as
a
contract
so
that
the
person
publishing
is
making
a
commitment
to
what
they're
going
to
publish
so
that
if
they,
because
if
they
just
make
arbitrary
changes,
they
break
all
those
other
applications
that
they
don't
talk
to
those
developers
they're
not
aware
of
them
sort
of
closely
and
if
they
start
changing
what
the
data
is,
though
all
those
loosely
coupled
apps
fall
over.
So
so
I
think,
async
api
serves
a
useful
role
in.
A
Even
though
this
is
one
of
the
you
know
like
one
of
the
biggest
advantages,
it's
also
one
of
the
biggest
problems
right
because
when
it
comes
to
management
to
managing
this
communication,
because
unless
you
have
that
feature
on
the
broker
itself,
how
do
you
manage
this
communication
right
like?
How
do
you
know?
A
A
Who's
gonna
get
affected
when
I
do
that,
like
who's
gonna
because
of
this
loose
coupling
precisely,
it
is
hard
to
say
right
so
who's
managing
that
who's.
My
where
who
has
this
this
solution
this
this
answer
for
this
question
and
I
think
smk
can
play
a
big
role
there
like.
If
the
whole
thing
is
described
with
this
in
api,
then
it
will
be
just
a
matter
of
getting
all
these
kpi
files
and
drawing
the
map
going
a
graph.
A
You
know
like
a
graph
of
connections
and
you
could
answer
these
questions,
but
if
we
go
for
the
channel
centric
approach-
and
I
think
this
is
cool-
because
that
will
enable
reusability
of
channels
if
we
only
go
for
channels-
and
we
forget
about
publish
and
subscribe
for
applications,
we
forget
about
the
role
of
the
application
here,
then
we
lose
that
we
don't
know
yeah
we
lose
that
that
capability.
So,
like
you
said,
it's
also
important
to
keep.
C
C
A
Exactly
so,
by
the
way
I
have,
we
have
guests
yes,
many
from
from
solas
and
thanks
for
the
for
saying
that
it's
an
awesome
discussion
and
I'm
sorry,
it's
6am
where
you
are,
we
have
to
do
it
at
some
point
and
and
yeah
and
also
here's
a
question
for
you.
A
C
C
Plug
it,
but
I
see
a
strong
analogy
between
api
management
and
events,
even
though
traditionally
events
haven't
really
been
managed
in
this,
with
the
same
discipline
that
the
apis
have
so
a
lot
of
what
we've
learned
over
the
last
decades
of
what
an
api
manager
means
we're
trying
to
bring
events
to
so
so,
although
I
know
you
can
just
have
a
folder
and
storage
and
kpis
loose
files,
we're
approaching
it
as
they
live
in
a
catalog,
they're
organized
it's
a
searchable
catalog.
C
You
know
that
it's
structured,
it's
published
in
a
browseable
catalogue,
so
so
yeah,
I'm
approaching
this
from
as
a
they
live
in
a
database
presented
as
a
catalog,
they're,
managed
and
and
also
we're
looking
at
other
things
like
you
know
how
we
enforce,
how
we
do
subscriptions
enable
people
to
sign
up
to
get
access
all
that
sort
of
stuff,
so
so
yeah.
I
I'm
looking
at
async
api
as
as
a
way
as
a
format
for
storing
things
in
a
formal
registry.
A
Hopefully,
it
makes
sense
yeah,
I
agree,
like
I
think,
storing
things
in
files
is
like
the
most
basic
way
of
doing
it
when
you're
getting
started.
It's
like
this
is
the
most
basic
way
of
doing
things,
but
as
these
things
get
more
mature,
more
and
more
mature.
A
We'll
start
seeing
we
already
started,
seeing,
especially
with
solas
and
now
ibm
as
well
that
and
I
think
wso2
as
well,
so
we're
seeing
more
and
more
people
approaching
this
as
a
kind
of
registry.
So
you
have
your
asynchronous
definitions
on
a
database
like
you
said
like
so
effectively.
This
is
stored
in
a
database
and
but
it's
a
searchable
registry.
It's
a
referenceable
registry,
so
you
can
reference
to
a
specific
sdk
file
on
the
registry,
but
yeah
like.
I
think
that
the
part
of
that
part
of
having
the
same
kpi
not
file.
A
I
was
going
to
say
it's
a
cpa
file.
This
isn't
a
paid
document
in
a
file.
You
know
it's
like
this
is
just
like.
I
will
say,
implementation
details
on
how
you
store
it
right,
but
but
yeah,
and
I
think
it
is
cool
to
store
it
in
files
and
put
it
on
on
github,
for
instance.
So
you
can
use
github
as
a
as
a
kind
of
registry
and
that
that
also
works
for
sure,
but
yeah
more
and
more
we'll
see
services
offering
these
catalogues
of
office
and
kpi
files.
C
But
I
think
it
also
depends
at
what
point
in
the
workflow
you
want
to
use
it
because
I
think,
if
you
see
it
as
a
design
time
resource
asset,
then
then
maybe
like
the
flat
file
approach
is
is
okay,
but
I
think,
partly
because
I've
come
from
the
kafka
world,
where
we've
had
schema
registries
for
quite
a
while
and
schema
registry
serve
not
only
a
design
time
role,
but
a
runtime
role,
something
that
applications
can
dynamically
get
the
the
description
of
the
schema
so
that
they
can
use
that
to
dynamically
deserialize
and
serialize
data,
and
I
know
that
it's
quite
nice,
the
way
async
api
isn't
trying
to
replace
that.
C
C
A
It
is
it
is,
I
mean
initially
that
the
purpose
of
facing
kpi
was
to
generate
code
and
documentation.
So
so
I
think
it's
you
know
it's.
So
it's
all
design
time.
You
know
it's,
it
all
happens
offline.
So
I
think
it's
all
that's
why
we're
seeing
this
use
cases
like
it's
four
years
now.
I
think
yeah
more
or
less
it's
four
years
after
I
created
this
in
kpi.
A
We're
now
see
in
runtime
use
cases,
but
because
we're
not
seeing
it
since
the
beginning,
because
yeah
the
very
beginning
it
was
for
design
time
right.
So
that's
your
thumbs
up
from
jesus
thanks,
yes
and
and
yeah,
so
so
coming
back
to
to
coming
back
to
the
public
subscribe
thing.
So
I
was.
B
Saying
that
let
let
me
just
to
get
used
to
this
saturday,
oh
nice,
I
love
it.
A
This
approach,
like
we
decouple
these
things
here
so,
for
instance,
a
document
can
be
just
this
and
this
will
serve
that
purpose
of
you
know,
acting
as
a
registry
of
channels
as
a
menu
of
channels.
Right
then,
at
some
point.
What
can
happen
is
that
I
don't
know
just
this
is
the
opposite,
so
I
want
to
document
my
application
right
and
then
I
could
be
doing
something
like
my
list
of
channels.
A
Is
my
registry
dot
com,
my
channels,
okay,
something
like
this,
and
that
would
be
more
amazing
or
whatever
right,
so
you
can
put
your
channels
somewhere,
which
could
be
effectively
could
be
a
single
file
or
a
single
file.
You
know,
a
single
document
can
be
in
a
database
can
be
a
on
a
file,
it
can
be
a
single
file
and
then
from
here
we
have
from
the
application
definition
we
can
have.
This
like
here
are
my
channels,
and
now
they
are
described
somewhere
else
and
here
are
my
operations.
A
So
this
is
what
I'm
gonna
be
doing
right,
so
I'm
gonna
be
publishing
to
my
channel,
which
is
not
visible
here,
but
it's
described
here
on
this
url
and
I'm
gonna
be
publishing.
This
is
my
channel.
Okay
still
so
for
for
kafka
for
brokers.
You
know
this
is
cool.
This
is
like
very,
I
will
say,
intuitive
of
what's
happening
and
I'm
just
gonna
do
this,
so
we
can
still
see.
A
But
what
happens
is
that
let's
say
that
we
have
a
client,
server,
client
server
api
like
websockets,
we
have
websockets,
you
have
your
websocket
server
and
you
have
websocket
clients
so
effectively.
This
is
like,
like
a
rest
api
like
an
http
api,
there's
no
broker
or
if
you
want
the
server
the
websocket
server
is
the
broker.
It's
the
application
and
the
broker
is
the
two
things
at
the
at
once
and
that's
in
a
single
piece.
So
if,
if
we
do
this
then
say
this
is
my.
A
This
is
my
website
api,
so
or
websocket
server?
Okay,
and
what
does
it
mean
like?
What
does
publish
to
my
channel
mean?
Does
it
mean
that
the
client
can
publish
to
my
channel
or
is
it
that
the
server
is
sending
messages
to
the
client
on
on
the
my
channel
topic
topic
coming,
you
know,
websockets
like
socket.
A
A
I
want
to
define
what
my
clients
can
do
with
with
me.
You
know
it's
like
how
they
can
communicate
with
me
like
you
can
publish-
or
you
can
subscribe
to
my
messages
here-
that
that's
exactly
what
is
making
these
things
highly
confused,
confusing
it's
like
if
we
change
the
meaning
of
publish
and
subscribe,
and
we
make
it
mean
what
my
application
is
doing
and
instead
of
what
my
application
is
expecting,
then
the
case
of
client
server
doesn't
work
anymore.
Like
it's
broken,
you
know,
but
then
these
other
cases
will
become
confusing
right
yeah.
A
It's
like
you,
have
this
situation
where
it's
like.
Damn
there's
no
way
here:
it's
like
whatever
we
do,
someone
is
gonna,
be
losing
you
know
it's
it's
always
it's
like.
We
have
like
two
house
we
can.
A
We
can
be
arguing
forever,
which
half
is
bigger
than
the
other,
like
no
brokers
are
bigger
than
than
the
client
server
websocket
use
cases
I
don't
mind,
but
even
if
websocket
use
cases
are
not
as
big
as
the
broker
use
cases,
they're
still
big.
So
there
are
many
people
doing
web
circuits.
A
Graphql
subscriptions
http
two
servers
sent
events
which
is
still
event-driven
architectures,
but
with
a
different
topology
right.
It's
not
there's
no
broken,
it's
client
server,
so
we
cannot
just
say
we
lead
them
out
and
we
don't
care
right,
and
it's
like
this.
This
is
for
for
only
for
broken.
So
so
that's
why
lorna
came
up
with
this
solution
of
the
of
the
actors
right
as
a
way
to
as
a
way
to
describe
things.
A
A
I
understand
I
partially
understand
her
point
of
view.
I
still
think
we
can.
A
It
will
be
great
to
explore
not
having
to
define
what
the
client
has
to
do,
because
my
feeling
here
is
that-
and
this
might
this
might
be
a
little
bit
purist
if
you
want,
from
the
point
of
view,
is
that
this
is
not
describing
the
api.
This
is
describing
behavior
right.
A
This
is
like
I'm,
I'm
coding,
I'm
effectively
coding
here.
I'm
like
I'm
saying
like
this
to
my
channel
right.
I
want
to
publish
I
I'm
telling
the
application
what
to
do,
and
instead
of
defining
the
interface,
I'm
not
defining
the
interface,
I'm
defining
I'm
defining
a
behavior
right,
so
we
will
not
be
talking
about
apis
anymore.
We
will
be
talking
about
behavior
definition
right.
It's
like
tablets
subscribe.
A
You
have
to
do
this
or
that
you
know
it's
not
as
supposed
to.
I
am
expecting
that
you
do
this
or
that,
if
you
want
to
communicate
with
me,
this
is
my
interface
right.
I
used
to
put
this
example
with
audio
jacks.
You
know
like
the
audio
jack
is
like
you,
you
always
have
the
in
and
out
on.
The
audio
jack
yeah.
C
A
You
don't
care,
what's
what
is
inside
the
box?
You
just
have
the
interface
right
and
no,
nobody
should
be
caring
of
what
is
inside
the
box
and
the
box
should
not
be
caring
of
which
electronic
device
are
you
plugging
in
right?
It's
like
no.
This
is
my
interface.
If
you
want
to
communicate
with
me,
here's
here's
how
you
should
do
it
right.
A
Here's,
the
interface
right
yeah,
but
again
this
example
is
one
one
right,
so
it
matters
well
with
client
server
when
it
comes
to,
then,
if
we
keep,
if
we
keep
doing
it
like
this,
then
the
broker
example
suffers,
which
is
where
we
are
right
now
right.
This
is
the
point
where
we
are
right
now
so
now,
I'm
gonna
ask
you
the
big
question
like
how
do
you
think
we
could
be
solving
this?
C
I
don't
know
because,
because
I
am
like
I
said,
I'm
biased
you
know-
I've
got
one
very
niche,
not
niche,
but
one
particular
subset
problem
that
I'm
looking
to
solve.
So
I'm
I'm
kind
of
biased
by
that.
But
if
I
was
to
ignore
everyone
else,
I
would
go
with
a
channel
centric
approach
describing
the
data
and
because
I
see
it
as
an
external
interface
similar
to
like
you
say
you
know
your
audio
device
idea.
You
know
I
don't
want
to
describe
my
application.
My
application
is
mine.
It's
nothing
to
do
with
you.
C
C
C
Yeah
I
do
like
the
idea
of
having,
I
think
you're
right,
that
reusing
the
message:
definitions,
reusing
the
channel
definitions-
does
allow
you
to
have
different
views,
so
you
could
have
a
document
that
describes
one
actor's
perspective
and
another.
So
you
could
have
your
one
document
that
describes
your
internal
view
that
you
might
use
to
code,
generate
your
application
and
then
the
a
different
document
that
you
give
to
third
parties
or
other
developers
or
people
outside
your
team
who
are
allowed
to
consume
the
data
that
and
their
document
describes
a
different
perspective.
C
The
you
know
the
external
interface
only
that
contract
for
loose
coupling-
I
mean
we
instinctively.
I
don't
want
to
maintain
two
documents
for
one
thing,.
C
But,
but
certainly
when
it
comes
to
because
it's
not
just
about
the
the
semantic
bits,
but
it's
all
about
the
because,
where
I
I
see
so
much
value
in
people's
use
of
async
api
is
in
that
free
text
stuff
the
description
and
the
summary
and
the
title,
because
it's
that
narrative
that
helps
the
developer
know
where
to
start
it's
that
kind
of
setting
the
scene
like
the
fact
that
it's
marked
down,
they
can
put
images
in
there.
They
can
put
rich
formatting
in
there.
C
B
A
A
There
tends
to
be
a
problem
when
so,
for
instance,
one
one
of
the
things
that
that
happens.
If
we
want
to
describe,
let's
say
this
is
websocket
server
and
we
are
describing
no
matter
what
let's
say
this
is.
A
A
Let's,
let's
not
mention
server
or
client,
but
let's
say
like
this
is
yeah.
Let's
say
that
this
is
messages
sent
to
my
channel
and
published
to
my
channel
actually
means
that
the
websocket
server
is
listening
to
my
channel.
So
if
we
do
it
like
this,
then
this
description
means
that,
but
if,
by
using
this
definition,
we
want
to
generate
a
client,
for
instance,
we
want
to
use
this
definition.
We
know
it's
a
one-on-one
relationship,
so
it's
like
cool.
So
by
reusing
this
definition
we
can.
A
C
A
It
will
be
or
say
like,
let's
say
that
messages
the
server
sends
my
channel
right.
So
if
we
generate
the
client,
then
it's
like,
why
is
it
on
my
channel
on
the
client
side?
Why
is
it
defining
what
the
mess
with
the
server
is
doing?
You
know
it
should
be
saying
something
like
messages
the
client
can
consume
from
my
channel
right
right.
A
So
you
know
what
I
mean.
C
A
A
It
becomes
effectively
impossible
right,
but
now
that
I'm
thinking
about
it
like
open
api,
has
the
same
problem
like
when
you're
describing
a
rest
api
and
you
have
get
put
pause
whatever
and
you
describing
these
operations,
and
you
have
a
description
there
right.
If
you
put
a
description
there
and
you're
describing
what
the
client
can
do,
you
can
send
a
get
request
to
to
the
server.
A
Then,
if
you
have
this
this
documentation,
this
description
on
the
on
the
server
side,
it
doesn't
make
sense,
you
know
it's
like
I'm,
I'm
defining
the
server
side.
Why
are
you
talking
to
me
about
what
the
client
can
do
right
so
another
another
thing
that,
and
I
don't
want
to
forget
about
it.
So
there
is
there's
something
that
that
cash
was
was
mentioning.
It's
like
something
like
operation
id.
This
is
meant
for
for
the
programming
languages
right.
A
So
if
I
have
something
here
like
say,
this
is
websocket
server
and
subscribe
to
my
channel
yeah
publish
to
my
channel.
Let's
leave
it
right
there
and
if
I
have,
I
don't
know,
let's
put
it
a
little
bit
easier
to
follow
this
user
signed
up
and,
let's
say
on
user,
signed
up.
A
If
we
put
it
that
way,
and
we
use
unsigned
app
for
code
generation
on
the
server
side,
this
might
make
sense,
but
if
we're
gonna
generate
client
side
of
things,
we
cannot
use
the
word
on
user
signed
up.
This
is
doing
the
opposite.
It's
not
an
event,
it's
actually
publicity
right,
so
you
know
what
I
mean.
A
A
You
cannot
generate
a
client
from
the
server
description,
not
even
an
open
api
people
are
doing
it,
but
you
cannot
accurate
accurately
generate
a
client
from
the
server
description
and
that's
why
it's
getting
confusing
right.
C
A
A
Let's
say
this
is
subscribe,
okay,
so
my
server
is
gonna
subscribe
and
whenever
it
receives
the
message,
it's
gonna
trigger
this
function
and
whenever
and
the
client
is
publishing
this
message
and
to
publish
this
message,
it's
gonna
call
this
function
to
send
it.
This
is
in
the
case
of
code
generation,
of
course,
that
could
work
right
and
then
you
have
to
put
something
like
roll
client,
and
here
you
roll
server
right
or
I
want
to
make
it
clear.
These
are
not
you
can
put
whatever
you
want
right.
A
My
client
might
record
it
so,
but
then,
if
you
do
that.
A
A
C
The
problem
is
it,
it
depends
what
it
is
you
want
to
document.
Are
you
documenting
your
own
application,
because
internal
documentation
is
useful
and
valuable,
or
are
you
documenting
what
other
applications
are
able
to
do
to
enable
them
to
create
their
applications,
and
the
problem
is
both
are
valuable
things
to
do
so.
C
We
kind
of
instinctively
want
the
spec
to
be
able
to
support
both,
but
they
are
two
different
jobs
and,
and
it's
trying
to
do
trying
to
satisfy
both
things
is
is
yeah
is
a
challenge
and
I
don't
think
we
should
just
pick
and
do
one,
but
I
think
we
do
need
to
acknowledge
that
they
are
different
objectives
and
if
we
try
and
do
both
at
the
same
time
we'll
end
up
doing
both
badly.
A
Yeah,
that's
that's
a
risk,
exactly
that's
a
risk
that
we,
if
we
focus
on
doing
everything,
maybe
we'll
never
do
anything
well,
so
I
had
this
other.
I
had
this.
This
other
idea,
which
is
like
operations,
are
what
the
application
is
doing,
and
then
you
have
another
section
here,
which
is
the
api
and
the
interface
right.
I
know
it
sounds
weird
because
it's
in
kpi
it's
supposed
to
be
about
apis
right,
it's
in
the
name
right.
So
so
why
are
you
needing
another
section
called
api
right?
A
But
let's,
let's
just
forget
about
that-
about
the
name
and
let's
just
put
a
section
here
and
and
let's
say
so
here
on
operations.
A
B
C
Yeah,
I
like
the
idea
of
that,
so
you
start
by
at
a
high
level
describing
this
is
my
application.
This
is
what
it's
doing,
but
then
separately
you
explicitly
call
out
and
here's
the
things
that
your
application
is
allowed
to
do
so
you're
allowed
to
I'm
coming
back
to
permissions
again,
which
is
probably
not
the
right
way
of
framing
it,
but
but
that
idea
of
explicitly
calling
out
your
interfaces
and
your
expectations
of.
C
C
A
A
So
when
you
have,
when
you
are
in
a
broker
architecture,
having
this
that
you
have
here
this
api
section,
it
is
like
mostly
none.
You
know
it
is
it's
not
something
that
you
will
probably
do.
You
know
it's
like
why
I
just
want
to
define
if
I'm
publishing
or
subscribing
right.
I
will
probably
use
this
section
here.
I
just
want
to
tell.
A
I
just
want
to
tell
here
that
I'm
I'm
sending
messages
to
the
broker
or
I'm
subscribing
to
the
topic
to
receive
messages
from
the
broker
right.
I
don't
care.
What
others
can
do
with
me
is
that
it
is
not
the
case,
but
so
so
people
so
broker
centric.
Let's
say
architectures
will
be
using
that
part
the
operations
and
yeah.
That's
just
so
we
do.
We
will
not
need
that
role
in
here,
so
it's
just
I'm
using
signed
up
and
yeah.
So
because
I'm
defining
this,
I
am
receiving
the
message.
A
I'm
subscribing
to
my
channel
to
receive
this
kind
of
message,
and
this
is
my
operation
id
in
the
code
that
you
want
to
generate.
You
can
use
this
work
and
there's
no
client
side,
because
because
I
am
a
client
myself
like
when
you
are
defining
this,
you
can
find
the
client,
because,
when
you're
connecting
to
a
broker,
you
are
a
client
you're,
not
server
right,
so
so
yeah.
A
So
there's
no
client
side,
but
here
when
you're
doing
something
like
exposing
this
something
to
the
public
or
not,
necessarily
it's
the
public,
but
when
you
want
to,
when
you
want
others
to
consume
your
api
right,
your
server,
then
you
will
probably
have
this,
which
is
similar
to
what
we
have
right
now,
and
that
will
mean
that
people
can
communicate
with
you
by
publishing
a
message
on
the
user
signed
up
channel
right
and
it
is
separated.
It
is
another
section
on
purpose
to
make
the
distinction
like
it's
like.
A
A
A
Right
so
I
will
be,
and
the
server
will
be
kafka
right,
so
so
this
this
is
effectively
like
composing
an
application.
So
imagine
that
you
have
an
application
that
is
listening
to
websocket.
Clients
would
be
a
ui,
for
instance,
your
browser,
your
browser
ui,
and
it
means
that
user
signed
up
means
that
the
the
user
actually
hits
the
you
can
sign
up.
Then
the
sign
up
button
right
and
fill
the
whole
form
and
everything
so
there's
a
new
message
that
goes
to
the
server.
A
I
will
do
this
with
http
but
yeah.
Let's
assume
that
this
is
one
second
and
and
then
you
send
this
message
to
the
to
the
to
the
server
and
as
a
result,
this
same
application.
The
website
server
will
send
a
message
to
kafka
right.
So
this
could
be
encoded
here
in
a
single
document
without
the
link
of
just
because
you
do
this
operation,
then
this
other
one
is
going
to
happen,
but
both
operations
can
can
be
defined
there
right
and
in
a
separate
way,
so
operations
in
api.
C
C
I
think
making
yeah,
making
it
clear
what
you're
describing
in
each
section
does
give
people
like
me
that
only
have
one
side
that
they're
particularly
interested
in
gives
a
clear
place
of
just
describing
that
and
for
scenarios
where
you
want
to
describe
both.
You
can
reuse
the
definition
so
you're
not
duplicating
the
spec
yeah.
That
seems
like
I,
like.
A
That
awesome,
so,
as
I
mean
I'm
enduring
a
lot,
but
we're
approaching,
I
mean
we
already
passed
one
hour
so
and
it's
lunch
time
for
both
of
us
right
so
and
but
before
we
we
finish,
I
would
love
to
ask
you
a
question
or
a
question.
I
would
like
to
ask
you
a
favor
and,
as
you
don't
know,
the
next
guest,
and
so
I
would
love
if
you
could
ask
a
question
to
the
next
guest.
Even
if
you
don't
know.
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
sort
of
way
and
if
so,
what.
C
A
Good
cool
perfect,
so
we
get.
We
get
that
thanks
a
lot
for
joining
me
today.
A
It's
been
a
pleasure
man,
so
I'm
happy
to
to
chat
again
I
mean
we
chat,
often
on
the
on
the
bi-weekly
meetings
facing
kpi,
which
I
encourage
the
the
audience
to
join
if
you're,
not
aware
of
them,
just
go
to
asmtk.com
and
or
dot
org
and
you'll
find
everything
everything
in
there
and
and
yeah
thanks
everyone
for
joining
as
well
on
the
chat
thanks.
Yes
for
the
questions,
thanks
to
earth,
for
your
great
words
and
yeah,
see
you
in
the
next
episode.