►
From YouTube: Thinking Out Loud #1 — With Lorna Mitchell
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
A
I
would
love
to
take
the
opportunity
now
to
actually
let
me
just
a
sec.
Okay,
I'm
just
receiving
messages
from
london,
so
I
will
have
to
to
take
the
opportunity
to
explain
what
thinking
out
loud
is
about
since
the
beginning
of
the
spec.
The
beginning
I
mean,
since
I
started
working
on
this
on
the
spec.
A
As
you
may
know,
I've
been
almost
working
on
this
myself
and
I
mean
with
some
with
some
help
with
some
help
from
time
to
time
and-
and
I
was
like-
we
need
to
make
it
more
community
driven
right,
so
tooling,
tooling
is
solved.
We
have
an
amazing
community
and-
and
you
can
see
it-
it's
a
vibrant
and
an
amazing
community,
but
with
the
spec
it's
a
little
bit
different,
it
seems
to
be
attracting
less
people.
A
So
what
we
did
instead
is
okay,
let's
just
make
this
more
collaboratively
right.
Let's
just
try
to
involve
more
the
community,
the
experts
from
the
community
and
and
so
we
can
fix
the
problems,
challenges,
not
problems
that
we
have
there.
One
of
these
pr
challenges
is
precisely
the
publish
and
subscribe
meanings
and,
as
you
may
imagine,
we
want
to
fix
this
right.
It's
it's
about
time
already
that
we
fix
it.
So
we
we
thought
like
who
can
who
can
invite?
A
B
A
A
Me
too,
so
I
would
love
if
you
could
probably
introduce
yourself.
Maybe
you
want
to
talk
about
what
you've
been
doing
lately
and
just
so
people
know
a
little
bit
more
about
you.
B
Of
course,
hello,
I'm
lorna,
I
run
developer
relations
for
ivan
we're
a
databases
as
a
service
company.
One
of
the
things
we
have
is
not
technically
a
database,
it's
kafka,
so
we
work
quite
a
lot
with
async
api.
It's
something
that
I
use
a
lot.
In
my
demos
we
see
customers
asking
for
before
I
came
to
ivan
my
background
was
very
much
in
apis
and
I'm
an
open
api
spec
contributor,
so
working
with
async
api
is
not
too
different.
A
So,
and
also
for
for
the
audience
to
know
on
the
latest
open
api
version,
I
think
you
made
a
great
contribution
there
that
people
may
or
may
not
know
about.
So
you
want
to
talk
about
it.
B
Sure
so,
open
api,
as
of
the
3.1
release
at
the
beginning
of
this
year,
has
support
for
web
hooks,
which
is,
I
think,
a
real
milestone,
and
it
reflects
how
the
way
that
we
use
apis
in
the
wild
has
changed.
Open
abi
always
had
support
for
like
an
asynchronous
callback,
but
you
had
to
register
with
a
previous
call
and
lots
of
apis.
Don't
work
that
way.
You
know
you
sort
of
sign
up
out
of
band,
and
then
you
receive
events,
so
it's
that
very
sort
of
event
driven
flavor.
B
A
So
I
mean
that's
that's
awesome,
and
and
and
partly
that's
why
I
wanted
to
invite
you
first
because
I
think
you've
been
working
on,
you've
been
doing
a
great
job
on
dating
and
the
open
api
community,
and
lately
you
were
very
engaged
with
async
api
community
as
well
and-
and
I
thought
like
we
can't
lose
this
opportunity
to
bring
lorna
in
right,
so
so
yeah
just
for
the
audience
to
know
a
little
bit
more
about
it.
Let
me
just
share
what
we
have
regarding
the
publish,
subscribe
challenge
and.
A
A
A
Okay,
yeah,
I
can
even
read
it
in
the
in
the
little
miniature
there,
so
I
guess
it's
readable
now,
yeah
so
just
to
just
to
summarize
what
happens
with
async
api,
publish
and
subscribe.
Is
that,
as
opposed
to
what
people
might
think,
publish
doesn't
mean
that
your
application
can
publish
messages
right
and
subscribe
doesn't
mean
that
your
application
is
subscribing
to
messages,
but
instead
what
it
means
is
that
other
other,
let's
say,
clients,
other
applications,
other
other
people,
other
other
software,
can
publish
or
subscribe
to
you
to
your
messages
right.
A
Broker-Based
architectures,
for
instance,
is
not
that
clear
right,
like
people
working
with
brokers,
which
is
the
majority
of
raising
kpi
users.
Usually
what
happens
is
that
they
seem
this.
They
find
this
confusion
and
I'm
always
saying
people,
but
I
am
one
of
these
people,
so
I
am
myself
like
getting
confused.
All
the
time
is
like
damn
it's
like
40
years
already,
almost
and
I'm
still
getting
confused
about.
A
I
mean
that's
something
that
I
did
because
that
was
inherited,
but
but
yeah,
something
that
I
did
in
the
end.
So
yeah.
B
A
And
it's
I
mean
it's,
it's
incredibly
confusing
and
people
was
suggesting.
I
recall,
for
instance,
before
we
launched
version
two.
I
think
it
was
a
first
release
candidate.
We
switched
the
minute
on
the
first
release
candidate
of
version
two.
It
was
the
opposite
like
we
tried
to
fix
it
at
that
time,
but
then
some
other
people
started
complaining
like
hey.
A
This
is
not
gonna
work
for
public
client
server,
apis
like
slack
api,
for
instance,
or,
like
many
other
apis
right,
and
it's
like
you
know
what
let's
leave
it
as
it
is
as
it
as
it
was
in
version
one
and
let's
not
touch
it,
and
then
we
dedicate
some
good
time
and
effort
to
solve
it,
so
so
yeah.
So
I
wanted
to
clarify
this
and
I
think
you
made
you
made
a
great
suggestion
here
so
for
for
the
users
reading
this.
Let
me
just
share
this
with
the
audience
so.
A
A
Yeah
exactly
I
didn't,
I
didn't
want
to
be
like
buyers
and
people
myself.
I
have
my
idea
like
how
can
it
be
done,
but
I
have
to
admit
that
it's
not
a
very
creative
idea.
I
am
not
like
100
sure
this
is
the
best
way
to
do
it,
and
then
you
came
in
and
suggested
something
completely
different
and
I
was
like
there
might
be
another
way
right
so
so
yeah
and
that's
why
that's
why
I
was
I
I
was
thinking
like
for
this
challenge.
A
B
You
a
really
long
message
in
a
slack
conversation
and
in
the
end,
you
just
moved
it
over
to
the
to
to
where
the
github.
C
B
B
A
It
depends
it.
It
depends
on
the
what
you're
generating
right,
because
that's
another,
that's
another
thing
like
when
you're
generating
documentation,
it's
clear
to
generate
documentation,
I
mean
most
of
the
time
you
generate
documentation
for
your
users,
your
consumers,
not
for
you.
You
already
know
how
it
works,
but
but
for
the
code
you
might
be
generating
the
server
or
you
might
be
generating
the
client,
which
is
funny
because
there
are
no
servers
or
clients
here
and
that's
and
that's
what
we
were
trying
to
say
all
the
time
like.
A
It's
all
clients
right,
it's
all
clients,
especially
when
talking
about
brokers,
it's
all
clients
in
the
server
it's
a
broker.
Actually
you
have
to
list
the
server
on
the
server
section.
So
it's
clear
like
everything
is
a
client.
So
then
it's
like
it.
It
means
like.
Are
you
generating
the
code
for
your
client
or
for
other
clients
to
consume
your
client
right.
B
A
Yeah,
but
that
that
doesn't
have
the
whole
thing
like
we
cannot
just
change
it,
because
if
we
change
it,
then
this
client
server
architectures
are
messed
up
like
suddenly
it
doesn't
make
sense
for
them
now.
So
it's
like,
you
probably
think
like.
Oh,
it's
easy,
just
change
the
minute
of
the
verbs
and
done
right,
that's
what
we
thought
and
then
it's
like
some
other
people,
like
my
websocket
api,
doesn't
make
sense
now
like
how
how
how
am
I
supposed
like
it's
like?
A
A
We
can
be
like
it's
a
little,
but
it's
tricky
we
can
be
very
like
can,
I
say,
like
we
can
be
very
strict
here
or
we
can
be
very
yeah
very
strict,
like
in
in
terms
of
we
stick
to
the
definition
of
api
and
therefore
it
still
remains,
as
it
is
right
now,
because
it's
defining
what
it's
going
to
expect,
but
that's
not
gonna
be
useful
for
the
majority
of
the
users
and
the
developers
using
this
in
kpi.
So
so
we
then
stick
to
the
strict
definition
of
api.
A
I
have
my
opinion,
obviously-
and
I
also
want
yours
here
so
like
what
do
you
think
like?
Do
you
think
we
should?
We
should
be
like
favoring
the
user
experience
here
in
this
case,
or
we
should
be
very
like
purists
here
in
terms
of
the
api
definition
like?
Is
it?
B
I
am
always
more
pragmatist
than
a
purist.
It's
the
way
that
I
think
about
things
and
honestly.
I
don't
really
think
it
matters
what
we
choose
here
as
long
as
it's
clear
and
well
documented,
because
currently,
like
I
say
you
end
up,
it
depends
super
quick
and
then
it's
it's
confusing
and
especially
for
people,
and
I
think
I
would
include
myself
in
this
group
who
you
know,
I
don't
work
with
async
api
every
day.
I'm
not
super
familiar
with.
You
know
new
tools
getting
released.
I
I've
seen
some
chatter
of
some
go
tools.
B
I'm
probably
not
testing
them
this
month.
You
know
so
it's
quite
hard
to
keep
up
with
the
detail
and,
to
my
mind-
and
I
felt
this
way
about
open
api
as
well.
It's
about
making
these
things
really
approachable
and
making
them
as
transparent
as
possible,
and
and
so
it
tends
to
be
more
about
more
about
the
user,
and
that's
why
I
asked
the
question
about
how
does
the
websockets
thing
work
now,
like
I've
done
a
little
bit
with
mqtt?
A
B
B
Yeah
so
then
I
guess
the
async
api
spec,
for
that
use
case
is
from
the
point
of
view
of
the
client
as
it
is
for
the
open
api
http
specs,
but
it
gets
confusing
with
the
brokers,
because
then
the
broker
is
the
server,
but
we
have
lots
of
clients.
So
I
really
strongly
remember
the
first
time
I
used
async
api
and
I
was
doing
two,
an
integration
of
some
smart
home
stuff,
the
leds
that
used
to
be
in
the
backdrop
when
I
was
streaming
a
lot
and
also
some
other.
B
I
think
it
was
the
video
lighting
was
on
like
a
smart
plug,
so
I
needed
to
send
two
types
of
message
onto
mqtt
and
then
different
things
were
going
to
react
to
them
and
I
couldn't
describe
both
things
in
one
spec,
because
they
were
for
two
different
clients.
One
was
the
smart
plugs
and
one
was
the
pie
that
controlled
my
leds,
but
it
for
me
to
me
as
a
software
developer.
It
was
kind
of
like
here
are
the
things
you
can
do
like
a
list
of
api
endpoints.
A
Yeah,
so
exactly
it
only
makes
sense
for
the
broker,
but
actually
so
what
you're,
suggesting
there
is
to
to
sit
in
or
to
sit
in
another
way,
is
like
a
menu
of
options
and
things
that
you
can
do
right,
which
kind
of
makes
sense
right
like,
and
you
were
expecting
a
single
snk
file
to
describe
your
whole
architecture,
not
just
a
single
application,
but
your
whole
architecture
right.
B
A
If
that's
the
case,
so
we
we've,
we
thought
about
it
in
the
past
and
the
reason
we
we
did.
This
idea
was
that
if
you're,
a
big
company
with
thousands
of
topics
and
microservices
publish
and
subscribe,
this
file
is
gonna,
be
huge
right.
This
is
gonna,
be
huge
to
process
right.
So
so
it's
like
and
a
manageable
most
of
the
times
right.
So
so
we
decided
to
follow
like
microservices.
A
That
is
common
for
both
for
two
or
three
or
four
or
thousands
of
applications.
They
have
a
common
channel,
a
topic
where
they
publish
or
subscribe
depending
on
the
role
they
have
right.
So
so,
then
you,
you
have
to
repeat
this
channel
description
everywhere
and
it's
like
that's,
not
very
convenient
like.
How
do
you
maintain
that
right
and
and
even
what
happens?
Is
that
all
the?
A
So
all
these
all?
Even
if,
if
you
will
be
able
to
extract
it
somehow,
then
what
happens
is
that
you
can
you
can't
completely
extract
it?
Let
me
just
show
an
example
for
for
people
watching
this.
It's
an
example
of
what
I'm
talking
about.
So
just
maybe
this.
I.
B
A
A
B
A
B
A
B
A
A
Just
invent
a
new
operation
which
could
be
like
on
user
signs,
app.
B
A
And
then
this
operation
is
going
to
be.
I
don't
know
it's
just
not
this
type.
There
are
many
types
in
here
kind
subscribe
and
the
channel
is.
A
A
So
we
can,
we
could
be
pointing
to
channels
which
this
is
going
to
be
fun,
because
now
you're
gonna
do
this
is
I
think
it's
something
like
this.
A
A
A
But
yeah
because
otherwise
it's
gonna
be
inspecting
channels
user
and
then
some
other
object
inside
and
it's
not
the
case.
It's
an
it's
this
key,
but
anyway,
let's
just
put
it
like
this
okay,
so
I
teach
you
to
grasp.
A
So
if
we
do
this,
we
will
have
operations
on
user
sign
that
subscribe
and
blah
blah
blah
whatever,
and
therefore
we
can
just
get
rid
of
this
right.
B
B
But
now,
for
me,
what
is
missing
from
async
api
is
one
of
two
things
it's
either
like
currently
async
api
is
every
specification
is
for
each
thing,
so
my
my
tool,
which
I
have
a
button
that
sends
what
color
the
light
should
be
and
the
thing
that
understands
the
message
that
was
sent.
B
Alternatively,
we
could
bring
that
into
async
api
and
I've
worked
extensively
with
open
api
and
that's
much
simpler,
because
there
are
only
two
people
at
the
party
and
it's
obvious
who
is
who
right
so
the
spec
is
from
the
api
description
for
open
api
is
always
from
the
point
of
view
of
one
client,
and
there
is
one
server
and
that's
basically
it.
There
are
some
finer
points,
but
that's
that's
the
fundamental
thing
with
async
api
right.
Your
architecture,
diagram,
isn't
request
response,
it's
potentially
spider
yeah,
and
so
we
need
to
name
these
individuals.
B
A
Can
you
can
you
just
maybe
open
playground
and
and
share
what
you're
thinking
about?
Maybe
I
think
it's
it's
going
to
be.
I
don't
know
if
you
can
share.
Oh.
B
B
B
A
A
B
Yeah
we
can,
let's,
I
just
how's
that.
A
A
little
bit
more
yeah,
I
think
that's
will
be
enough.
Maybe
okay,
let's.
B
B
C
A
A
B
Okay,
never
mind,
never
mind
yeah,
so
I
thoroughly
agree
that
and
I'm
a
little
bit
shaky
on
the
brokerless
solution.
So
I
I
am
for
me,
you
know
I
work
at
ivan.
We
do
kafka
and
that's
my
context,
so
I
yes,
this
verb
does
not
belong
here.
B
B
I
think
that
could
be
it's
not
quite
enough
by
itself,
but
it's
not
bad.
It's
and
it
wouldn't
be
confusing
right,
because
you
could
use
this
and
from
a
very
sort
of
two-dimensional
point
of
view.
You
can
generate
documentation
that
just
details
stuff
and
doesn't
have
publish
or
subscribe,
but
you
could
have
like
the
code
generation
for
generating
a
producer
or
code
generation
for
generating
a
consumer.
B
B
Imagine
some
some
different
component
messages.
They've
all
got
different,
payloads
yeah
right,
I'm
not
sure
I
named
it
really
well
the
first
time,
so
I'm
just
diverging.
Let's.
B
So
then,
what
we
actually
need
to
know
is:
who
is
here,
and
what
can
they
do?
I
propose
actors
because,
like
you
say,
we
have
too
many
types
and
groups
and
generic
terms,
so
I've
called
mine
actors
and
in
a
in
an
in
an
api
request
response
scenario,
then
you
would
have
something
like
you
know,
clients
and
just
sends
or
just
receives
or
does
whatever
so
but,
for
example,
we
could
have
the
I'm.
B
B
B
B
B
A
B
A
Just
just
think
about
something
for
a
moment
this
is
thinking
out
loud,
so
it
doesn't
need
to
be
perfect.
Let's
just
like,
as
if
you
were
in
your
desk
yourself
alone,
thinking
about
it,
it
doesn't
have
to
be
a
show.
I.
A
So
no
problem-
let's
just
we
this
this-
can
be
the
the
most
boring
show.
If,
if
you
want
that's
okay,
it's.
B
Right
so
this
is
my
example
that
the
payment
gateway
would
know
which
would
publish
that
the
user
had
paid,
and
maybe
the
website
needs
to
know
about
that
as
well.
So
you
can
add
it
here
right,
so
it'll
display
it
in
the
front
end.
So
then,
we've
got
all
these
topics
with
payloads
described
and
then
we
start
saying
who
can
do
what?
B
What
like
who's
here?
In
your
iot
example,
we
might
have
sensors
and
then
like
the
smart
home
hub
and
then
the
actual
iron
light
bulbs
then,
and
some
of
those
are
publishing
and
some
of
those
are
consuming
and
one
of
them's
doing
all
of
those
things
so
yeah
just
trying
to
think
about
that
separation,
because
for
me
not
knowing,
if
I'm
the
website
or
the
payment
gateway,
all
the
time
in
async
api
and
some
of
the
tooling
takes
the
opposite
view
to
the
other.
B
Tooling
has
been
really
confusing,
and
this
I'm
not
sure
if
it
belongs
here.
But
this
is.
A
B
A
What,
if
let
me
show
my
screen
again?
So
what?
If
I
do?
Oh,
then
this
is
really
small.
Now,
let
me
just
a
little
bit
bigger
here.
Okay,
that
would
be
enough,
so
you
have
this
identifiers
for
the
applications
right
like
the
website,
and
all
of
that
we
have
this
field
here,
which
is
already
it's
part
of
this
of
version.
Two
it's
called
id
and
this
id
is
usually
a
urn
or
a
unique
identifier
right,
but
we
can
call
it
something
I
don't
know
like
a
website.
It
shouldn't
be
called
website
either,
although
because.
A
Because
I
mean
that
would
be
ideally,
this
would
be
unique
like
globally
unique,
not
just
in
your
in
your
in
your
product,
let's
say
or
your
company
but
but
yeah-
that
that
will
work
as
well.
So
you
will
have
a
file
where
you
have
the
id
describing
who
the
hell
is
this
person?
How
the
hell
is.
Is
this
async
kpi
file
for
right?
So
it's
for
the
website
right
and
if
this
one
is
for
the
website,
then
you
will
have
another
file,
which
is
for
the
payment
gateway
that
you
were
describing.
A
So
you
will
have
another
file,
id
payment
gateway
right
and
then
you
can
have
the
the
rest
of
the
things
as
they
are
right
now,
maybe
just
moving
around
operations
and
other
stuff
for
reusability,
because
I
think
it's
kind
of
related
moving
operations
outside
and
and
then
you
might
not
need
actors
anymore
right.
The
only
thing
here,
the
only
thing
here
is
that.
A
Yeah,
it
can
be
less
convenient
to
have
multiple
files,
it
usually
is,
but
it
is
also
true
that
most
of
the
times
different
applications
are
in
different
repos,
and
you
can
have
this
gpa
file
along
with
your
application,
describing
only
this
application
right
and
then
it
might
be
the
responsibility
of
the
tooling
to
get
all
of
those
together
and
provide
the
hack,
like
you
were,
describing
before
right
and
show
you
how
they
relate
to
each
other
right.
B
B
A
Of
course
you
can
always
start
splitting
it
with
dollar
revs
pointing
to
other
files,
so
you
can
split
it
in
the
end
and
just
have
a
menu
and
all
the
other
files
are
in
different
repos,
but
you
still
have
some
like
a
kind
of
a
half
moving
the
half
concept
to
async
api,
like
you
described
before,
and
that
kind
of
I
kind
of
like
that
that
approach
right
but
yeah,
I
will
say
that
this
is
like
what
we're
discussing
here.
Now
then
is.
A
Is
it
a
like
centric
approach
like
every
everything
is
on?
Everything
is
on
the.
A
I
didn't
know
people
weren't,
seeing
you
so
is
it
like
a
centric
approach
where
everything
is
in
a
single
file
and
you
just
have
to
go
to
a
single
file,
and
this
file
will
tell
you
the
truth
versus
a
distributed
approach
right.
So
I
could
be
a
bad
person
here
and
be
saying
like
do
you
prefer
a
coupled
approach
or
a
decoupled
approach
right,
like
usually
people,
think
about
the
couple
being
better,
but
in
this
case
it
can
be
much
better,
a
single
source
of
truth
right
or
much
easier
to
handle.
A
At
least
then
there
will
be
processes
on
how
to
edit
this
file,
of
course,
because
then
well,
we
all
know
what
happens
when
you
have
this
centric,
let's
say
or
or
a
central
hack
or
piece
where
you
have
to
manage
everything
right
like
suddenly,
it's
like
the
master
branch
on
your
the
main
branch
on
your
git
repository
right.
It's
like
conflict
conflicts.
You
need
pull
requests
right.
B
A
B
C
B
Made
them
optional,
so
you
get
an
open
api
file
that
might
only
have
components
in
it.
So
you
and
I
think
that,
for
your
enormous
files,
you
can
have
paths,
you
can
have
components
you
can
have
web
hooks.
You
could
put
the
web
hooks
in
a
separate
file.
You
can
have
paths
multiple
times.
You
can
split
the
components
over
as
many
files
as
make
sense
for
you
and
then
refer
to
them
from
the
paths
or
web
hooks.
B
How
how
we,
if
we
take
the
verbs
out
and
think
that's
probably
likely
because
it
is,
it-
is
confusing
in
most
cases
to
be?
Is
it
coming
in
or
going
out
when?
Essentially
it
doesn't
matter,
you
just
need
to
know
what
it
is
and
it's
in
motion
and
then
separately,
which
thing
can
this
particular
player?
Do
then
you
can
choose
whether
the
actors
go
here,
but
I
could
well
imagine
having
you
know,
components
in
one
file
channels
in
another
or
maybe
multiple
files,
and
then
actors
saying
right
so
there's
for
this
application.
B
Here's
our
actors
file
and
it
calls
out
to
all
the
other.
It
uses
that
this
and
the
other
and
those
the
channels
block
is
published
somewhere,
because
I
think
each
actor
might
still
need
its
own
file,
because
the
way
that
the
server's
stuff
is
architected,
but
it
might
not.
A
I
think
it's
gonna
yeah,
I
I
get
what
you
say.
Would
you
say
I
think
it's
gonna
all
depend
on
on
how
you're
really
doing
software
in
your
company,
like
if
you're
doing
microservices,
you
probably
want
everything
on
a
single
file
distributed
and
but,
if
you're,
if
you
have
a
monolith,
you
have
a
single,
I
mean,
don't
want
to
call
it
a
monolith
but
yeah.
I
think
the
opposite
will
be
a
monolith.
So,
let's.
A
With
this,
so
if
you,
if
you're
working
on
the
monolith
or
in
a
single
reaper
right,
it
will
may
be
much
better
if,
if
we
have,
if
you
have
everything
in
a
single
file
right
or
at
least
a
single
source
of
truth
like
so
I
agree
with
you,
I
don't
think
we
should
be
dictating
if
this
will
be
a
single
file
or
multiple
files,
if
it
will
be
a
centric
approach
or
distributed
approach.
So
I
agree
with
this.
So
I
think
this
is
a
very
good
point
and
I
think
I'm
not
sure.
A
And
yeah
I
was
putting
my
ipad
here
in
case
we
had
to
take
notes
but
yeah.
A
A
B
And
also
allowing
components
by
itself
so
that
one
file
or
multiple
files
are
just
the
reusable
components
and
then
the
rest
is
composed
from
that,
because
I
mean,
as
you
say,
if
we've
got
different
sensors
doing
different
things,
but
they're
all
doing
it
on
in
the
same
payloads
on
some
of
the
same
channels,
then
that
reusable
set
for
multiple,
multiple
nodes
in
an
architecture
diagram
to
be
able
to
reuse
everything
except
the
verb,
I
think,
makes
a
lot
of
sense.
B
A
So
if
I'm
understanding
correctly-
let's
well-
let's
just
get
rid
of
this-
we
could
be
doing
something
like
this
from
a
from
an
18
kpi
file
specific
for
for
a
for
an
application,
and
we
could
be
pointing
to
not
not
this
something,
like
I
don't
know
my
components:
library.com
yeah
right
but
yeah.
A
And
well-
and
that's
just
like
include
all
of
them
here
and
this
will
be
on
each
on
each
async
kkk
file
and
then
you'll
have
all
your
components
in
a
single
place
and
and
same
for
channels,
maybe
like
maybe
channel
definitions
will
be
also
in
this
components
files.
So
maybe
we
have
to
add
channel
definitions
to
components,
so
they
can
be
reused
and
then
you
will
end
up
since
well.
Actually
that
would
be
like
sure:
well
yeah,
yeah
yeah
yeah,
so
that
would
be
something
like
so
channel.
A
Definitions
will
be
in
that
components,
library
and
then
operations
will
be
like
channels.
Channel
users
signed
up,
for
instance
like
here,
and
it's
gonna.
B
B
You
know,
we've
just
had
ivan
we've,
just
added
a
ui
feature
to
let
you
tag
your
kafka
topics,
because
once
you've
got
a
few
thousand,
it's
genuinely
hard
to
find
them
in
the
ui,
and
I
see
async
api
as
very
much
in
that
space
of
the
helper
tooling.
That
helps
you
to
know
what
you
have
in
terms
of
topics
and
understand
what
the
data
should
look
like
and
because
async
api
supports
things
like
cloud
defense
and
the
avro
schemas.
Then.
A
B
A
Yeah
for
the
code
generation
for
discovery,
I
would
say
you
you
get
everything
you
need
for
the
event
discovery
for
even
for
channel
discovery
and
for
even
for
applications.
Discovery
like
how
many
services
you
get
around
like
publishing
or
subscribing
yeah.
I
agree.
We
got
everything,
I
mean
you
get
everything
you
need.
A
If,
if
you
use
some
kpi
and
it's
already
possible
but
yeah,
it's
it's
still
a
pain,
so
we're
gonna,
we
gotta
solve
it,
and
I
I
was
thinking
about
something
else
like
because
this
exact
thing
happens
to
me
every
time,
I'm
working
on
trying
to
solve
this
unsubscribe
challenge,
and
is
that
I
end
up
thinking
how
to
reorganize
things
and
people
might
be
wondering
like
okay,
but
what
does
it
have
to
do
with
subscribing
publish
meaning
right?
B
I
think
when
you
see
website
and
subscribe,
the
website
has
to
be
doing
the
verb.
The
thing
in
whether
whether
it's
here
at
the
top
level,
one
file
per
item
on
the
architecture
diagram
or
whether
we
use
the
actors
approach
to
put
all
the
nodes
into
one
file,
the
where
the
name
of
the
node
is
and
there's
a
verb,
the
node
is
doing
the
verb
right.
It's
like
subject
objects,
yeah,.
A
A
So
we
don't
want
to
tell
the
user
that
you
are
publishing
and
therefore
they
can
subscribe,
because
that
might
not
be
true
just
because
you're
publishing
doesn't
mean
that
the
user
can
subscribe
to
your
messages,
because
you
might
be
publishing
to
a
private
thing
that
the
user
doesn't
have
access
to
or
you
might
be,
publishing
to
a
like
a
private
broker
that
only
you
can
publish,
but
the
user
can
subscribe,
but
it's
in
a
different
address
right
or
it's
a
different
broker
that
they
are
all
like.
A
Somehow
coordinated,
not
coordinated,
but
you
know
like
yeah:
let's
stick
with
coordinated
like
that's
fine,
so
the
thing
is
that
the
end
point
where
you're
publishing
doesn't
have
to
be
necessarily
the
end
point
where
the
user
can
subscribe.
A
That's
that's
what
stopped
us
to
to
change
the
meaning
of
publish
and
subscribe
on
version,
two
right
right,
because
your
your
application
might
be
published
into
an
internal
server,
an
internal
broker.
There
is
an
internal.
This
internal
broker
is
forwarding
the
message
to
another
broker.
That
is,
this
one
is
accessible
for
the
public
and
then
this
one
is
accessible
for
the
public
and
it
has
another.
A
It
has
a
different
address.
It
has
a
different.
It
may
be
a
different
topic
name,
so
you
can
just
tell
like,
because
I'm
publishing
here
you
can
just
subscribe
and
you'll
receive
it
right.
That's
that
was
a
problem.
So
so
I
was
thinking-
and
I
want
to
know
your
opinion
here,
like.
A
Might
be
a
little
bit
convoluted
or
or
ugly,
but
what
if
we
just
invent
two
new
verbs
like
so
publish
and
subscribe,
are
like
with
what
you
said
like
the
website
is
subscribing,
that's
it.
So
it's
the
opposite,
as
it
is
right
now.
Okay,
but
that's
fine,
so
website
is
subscribing
or
website
is
published.
It
is
paulism
yeah,
but
if
I
want
to
communicate
the
clients
that
they
can
subscribe
or
publish,
I
will
just
do
something
like
client,
publish
or
try
and
subscribe,
but.
B
A
B
I
think
it
would
be
better
to
consider
to
avoid
that
special
case
and
to
consider
everything
as
a
node
on
a
spider
diagram,
even
if
there's
only
one
edge
so
that
we
would
write
another
async
api
file
or
we
would
have
the
actors
edition.
C
B
Would
separately
say
if
you
are
a
client
here
is
what
you
can
do
you
can
subscribe
to
this
channel,
which
is
described
over
there
with
all
of
its
payloads
and
stuff.
So,
rather
than
being
like
I'm
a
server
I
subscribe
to
this
thing
you
can
publish
to
me,
be
like
I'm
a
server.
I
subscribe
to
this
thing
and
then
you're
a
client
here
is
your
here
is
what
you
can
do
and
keep
it
very,
and
I
think
that
makes
us
also.
It
feels
more
distributed.
A
Yeah,
so
this
is
the
current
approach,
actually
just
the
birth
of
pubs
and
subscriber
the
opposite
ex
expected
right,
so
that
will
that
will
make
it
easier
for
if
we
change
it,
that
will
make
it
easier
for
broker-based
architectures,
but
they
will
make
it
harder
to
understand
for
client
server
in
this
case.
A
But
we
have
that's
exactly
what
we
have
right
now,
but
the
thing
is:
let's:
let's
suppose
that
we
do
this
so,
for
instance,
we
want
to
communicate
the
the
clients.
This
is
a
server
and
we
have
clients.
This
is
an
http
server
or
websocket
server,
and
we
want
to
tell
our
clients
that
they
can
pause.
A
A
B
A
C
A
Which
is
like
highly
inconvenient
in
my
in
my
opinion
like
compared
to
open
api,
for
instance
in
open
api.
You
have
just
one
file
and
from
that
file
you
can
generate
the
server
and
the
client
right.
It's
clear.
The
direction
is
clear,
and
in
this
exact
case
the
direction
is
also
clear.
It's
the
same
example
as
an
open
api,
so.
B
B
The
api
description
file
describes
the
point
of
view
of
the
client.
It
says
you
can
get
this.
You
can
post
that
you
can
subscribe
to
this
web
hook,
whatever
you
might
receive
this
web
hook,
whatever
it's
very
much
from
the
client
side,
because
we
know
that
this
client
must
have
a
server.
We
can
make
assumptions
about
the
server
and
generate
code
for
the
server,
because
async
api
is
not
like
that
right.
We
cannot
make
assumptions
about
other
players
in
the
architecture
diagram.
B
In
a
sense,
we
don't
care
if
there's
one
server
or
a
hundred
a
broker
with
a
hundred
other
things
hanging
off
it.
Async
api
has
to,
and
currently
does
only
worry
about.
One
thing:
it
can
only
represent
one
node
and
it
describes
what
that
node
can
do,
whether
it's
I'm
a
sensor.
I
publish
data
to
here
and
the
data
just
all
it
does.
It
doesn't
care.
What's
consuming
it,
what
doesn't
tell
anyone
else?
How
to
subscribe
it
just
oh
hello!
I
am
a
sensor.
B
B
A
B
So
I
think,
we've
always
said
that
the
async
api
file
describes
the
from
the
point
of
view
of
one
thing:
one
node,
let's
say
one
publisher,
but
then
it
needs
to
just
do
that
the
weaknesses
or
the
confusion
for
me
in
async
api
is
when
we
try
to
say
oh,
but
in
this
case
we
can
also
assume
this
about
the
server.
B
No,
we
can't
and
that's
where
it
falls
down
a
little
bit,
because
we
there
are
other
actors
or
there
can
be
other
actors,
because
it's
a
very
scalable
and
distributed
kind
of
approach.
A
C
A
A
So
his
proposal
here
was
like
okay,
we
don't
know
what
this
website
is.
If
it's,
if
it's
defining,
this
publish
is
like
the
website
is
publishing
or
the
website
is
expecting
the
clients
to
publish.
So,
let's
define
it
here
like
provider
is
the
website
is
publishing
and
client
is
the
website.
It
is
expecting
the
clients
to
publish
to
the
provider
right.
B
A
B
That
this
whole,
are
you
the
consumer
or
are
you
the
producer
is
just
like
the
thing
that
open
api
just
had
to
fix.
Okay,
I
contributed
the
web,
their
web
hooks
functionality
right,
but
it
was
like.
Oh,
you
are
a
client,
you
make
requests,
and
so,
when
we
had
clients
that
in
fact
received
requests
and
responded,
the
spec
was
not
designed
for
that
at
all,
and
we
had
to
have
like
a
special
going
in
the
other
direction.
B
So
for
me,
if
I
was
rewriting
this-
and
I
think
the
actor's
proposal
is
actually
a
real
decoy,
because
it's
about,
should
you
be
able
to
describe
a
whole
system
or
a
single
node
in
one
file,
it
doesn't
matter,
but
this
file.
The
way
that
I
put
my
example
up.
I
had
one
node
my
website,
node,
which
both
published
and
consumed.
A
B
Things
so
some,
maybe
some
components
only
consume,
but
they
can
publish
an
alarm.
So
then,
if
you
do
at
the
file
level,
I
am
a
consumer
or
I
am
a
producer,
that's
not
how
our
event
driven
systems
work
most
nodes.
If
you
think
about
a
kafka
architecture,
most
nodes
mostly
do
one
or
the
other,
but
might
well
do
the
first
thing
or
might
receive
from
one
channel
and
redistribute
just
the
some
sort
of
information
right.
B
So
I
think
file
level.
I
am
a
consumer,
I
am
a
producer,
will
bite
us
later.
I
think
it
has
to
be
in
this
file.
You
may
do
this
for
this
and
that
for
that.
A
A
No,
no,
we
we
all
will
fix
it.
Don't
worry!
This
is
a
community
driven
works.
That's
what
we!
What
that's?
Why
we're
here?
By
the
way,
I
forget
to
tell
the
audience
that
they
can
just
jump
in
into
the
conversation
and
make
proposals
and
and
share
ideas,
we're
happy
to
take
them
and
but
before
I
so
yeah.
Let
me
just
come
back
to
what
I
was
saying.
A
The
thing
with
the
view
here,
thanks
lucas
for
reminding
me
the
name
of
the
property.
It's
not
perspective.
It's
view
right.
The
thing
with
this
is
that
we
have
things
not
here,
but
channels,
for
instance,
actually,
no,
no
on
operations.
A
A
So
let's
say
that
what
we're
saying
here
is
that,
when
you're
using
http
to
perform
this
operation,
it
must
be
a
request
right
and
by
the
way
you
here
mean
the
clients,
the
client.
A
When
the
client
tries
to
communicate
here
to
publish
it
must
do
a
request.
If
it
will
be
subscribe,
then
this
must
be
a
response
like
you
should
expect
this
message
as
the
response
of
some
other
request.
We
don't
know
which
one
right
so
if
we
define
this
from
the
provided
point
of
view,
which
is
what
I
did
here
right
and
we
switch
this
and
say
like
no.
This
is
now
client
and
this
will
also
be
changed
right.
A
What's
this
property
value
right,
that's!
Well,
let's
try
not
to
have
side
effects
right.
Let's
try
not
that's
why
the
the
the
the
spec
is
always
using
these
indented
right,
like
syntax,
like
everything,
is
inside
another
thing,
so
it's
clear
that
it's
there's
an
order
right
this
it
for
sure
there
is
another
way
to
do
this,
that
has
that
is
much
more
readable.
But
that
was
intentional
that
we.
A
Right,
yeah
and
nested-
that's
the
word.
I
was
trying
to
find
so
we
removed
this,
but.
B
This
is
amazing,
because
I've
totally
changed
my
mind
on
the
right
way
to
do
this.
In
the
course
of
this
conversation,
there
we
go
I'll
have
to
go
back.
A
But
no,
no,
we'll
continue
that
if
you
want,
of
course
but
subscribe
here,
so
imagine
that
we
still
because
I'm
still
like
is
there
a
way
that
we
can
just
have
one
file
in
the
case
of
one-to-one
relationship,
client
server
right
for
simple
client-side
relationship,
let's
say:
is
there
a
way
that
we
can
simply
just
have
one
file
and
we
could
generate
the
server
and
the
client?
A
Is
there
a
way
for
that,
and
I
want
to
explore
that
option
so
can
we
just
do
instead
of
instead
of
having
the
view
property
here?
Why
don't
we
just
have
it
on
each
operation
kind
of
like
the
view,
which
is
the
role
and
the
role
is
not
going
to
be
the
actor
role
right,
so
the
actor
is
not
going
to
be
either
provider
or
client,
because
that
means
nothing
to
someone
new
to
asking
kpi
is
that
I
don't
know
what
you're
talking
about.
A
B
But
for
me
I
would
rather,
if
I
have
to
have
a
separate
async
api
file
or
with
with
like
some
kind
of
extra
glue
outside
it
to
wire
them
together,
like
the
hub
that
I've
seen
like
the
actors,
change
that
I
recommended
here
right.
If
there's
some
way
of
explaining
the
relationship
between
all
these
individual
nodes,
that
each
have
their
own
async
api
file,
and
we
can
only
generate
for
this
node
right
if
there's
a
server
node,
the
server
node
has
an
async
api
file
and
it
generally
we
generate
from
that
file.
B
For
that
and
from
this
file
for
this,
I
think
if
we
could
get
down
that
route
and
agree
what
the
abstraction
looks
like,
bearing
in
mind
that
these
individual
nodes
might
publish
to
one
place
having
subscribed
to
another,
then
your
special
case
will
become
obvious
later,
but
because
we've
started
from
the
special
case.
I
think
it's
the
source
of
the
confusion
where
it's
for
the
client,
except
sometimes
it's
for
the
server.
B
So
if
you
generate
documentation,
it's
for
the
client,
but
if
you
generate
code,
it's
not
for
the
client
it's
for
the
server,
then
it
sort
of
doesn't
matter
which,
which
way
you
choose
it,
but
that
assumption
that
you
must
always
be
a
requesting
client
or
a
responding.
Server
is
what
we
stumbled
on
and
spent
a
long
time
trying
to
decide
how
to
fix
in
the
open
api,
which
is
which
is
already
the
special
case
right
with
two
players.
B
A
A
B
B
Actors
set
up,
and
I'm
not
like
I
say,
I'm
really
not
sure
if
this
belongs
inside
an
async
abi
file
or
if
it
is
somehow
outside
and
each
of
these
actors
is
instead
an
async
api
file
with
dollar
refs
in
it.
That's
not
clear
to
me-
and
I
also
don't
make
tools
for
this
sort
of
thing,
so
we
could
ask
the
tools
providers
what
hopefully
they're
watching
tell
us
what
to
do.
B
They
might
hate
us
for
this,
but
for
the
broker
channels,
knowing
what
the
topics
or
channels
or,
however,
we
call
them
are
and
what
the
payloads
look
like
is
really
important
and
then
it's
kind
of
like
a
separate
thing.
Oh
this,
this
component
sends
this
component
receives,
and
we
currently
got
this
like
yeah,
publisher,
subscriber
client
server
generator
when
in
fact,
every
node
is
going
to
be
a
mix
or
potentially
could
be
an
async
api
wants
to
support
that.
A
B
B
Some
operations
yeah
one
of
those
so
but
each
one
of
those.
I
think
the
bindings
also
go
with
the
channels
by
the
way,
not
higher
up.
A
A
B
Are
and
then
you
wonder
why
I'm
confused.
A
Now
because
they
find
different
things
like,
for
instance,
I
mean
in
this
case
I
think
it
makes
sense,
because
some
things
are
for
defining
the
channel
itself
topic
like,
for
instance,
you
want
to
find
if
a
kafka
topic
has
multiple
replicas
or
multiple,
not
replicas,
because
that
that
wouldn't
be
things
about
that
wouldn't
be
related
to
the
to
the
api.
A
But
let
me
just
be
more
specific,
so
well
in
the
case
of
kafka,
there's
nothing
on
the
channel
on
the
channel
binding,
but
other
other
other
protocols
have
things
for
the
channel
to
configure
the
channel
and
then
there's
also
specific
things
on
how
you
pablo
is
on
how
you
perform
operations
to
this
channel
so
to
define
this
like
in
the
case
of
kafka,
you
have
group
id
or
a
client
id
actually
no
look.
A
This
is
something
that
I
found
the
other
day
while
working
on
working
on
with
kafka
right,
so
we
mistakenly
placed
group
id
here
or
client
client
id.
I
think
it's
a
client
id
yeah,
so
client
ids
will
then
be
here
on
the
operation,
because.
A
Create
a
channel
and
you
create
a
new
topic
or
when
you
create
a
client,
let's
say
on
your
code
to
reference
yeah
when
you
create
a
client,
you
have
to
specify
the
client
id
for
for
your
client
independently.
How
many
topics
you
publish
or
subscribe
to
so
this
client
id
should
actually
be
on
the
server
on
the
server
binding
object
right.
A
It's
like
you,
I'm
gonna
be
creating
a
client
that
subscribes
to
this
server,
but
then
group
id
will
be
only
for
will
be
for
the
operation,
I'm
not
sure
if
it's,
if
it
will
be
for
publishing.
B
A
It's
a
consumer
group
yeah,
so
yeah
it's
only
for
subscribing
for
consuming
right,
and
then
you
have
things
like
the
message
like
to
define
the
key
of
the
message,
so
they
they
represent
different
levels
of
obstruction,
of
course,
so
I
think
it.
It
still
makes
sense
to
have
this,
but-
and
I
want
to-
I
want
to
read
something
that
lucas
was
saying
on
the
chat.
Let
me
just
show
you
here
so
so
yeah,
it's
like
on
operations.
The
confusing
part
there
is
that
the
file
is
written
for
the
client.
A
I
don't
know
if,
if
in
case
you're
not
aware
of
this
or
someone
watching.
This
is
not
aware
of
this
problem
of
this
challenge
as
well.
It's
also
documented
is
that
when
we
try
to
use
a
single
file
for
defining
the
server
and
the
client,
then
this
name
only
makes
sense
for
one
of
them
right.
It's
like
own
user
signs
up
yeah.
So
imagine
that
server
is
waiting
for
this
message
or
well.
The
client
is
waiting
for
this
message
on
user
signs
up.
A
Then,
if
we
look
at,
if,
if
we
generate
the
other
code,
it's
like
no,
it's
not
only
user
science
app
is
send
used
to
sign
up.
It's
like
sending,
send
it
right,
so
the
other
can
trigger
the
event
on
user
signs
up
right,
but.
A
This
is
this
is
for
for
machine
readable.
I
mean
kinda,
but
if
you
have
something
like
description,
which
is
purely
human,
readable
and
not
parsable,
unless
you
have
natural
language
processing
and
then
what
happens
is
that
you
have
something
like
when
the
server
or
when
we,
whatever
we
means
it
says,
receive
a
message,
a
message
that
user
signed
up
this
description
only
makes
sense
for
one
of
them
like
for
whoever
is
receiving
the
message,
but
whoever
is
sending
the
message
they
see
this.
This
description.
A
A
What
the
server
is
exactly
and
then
now:
okay,
let's
assume
this
and
then
because
I'm
thinking
on
the
on
the
user
experience
here
the
developer
experience
here,
maybe
there's
a
way
that
we
can
create
some
tool
that
will
generate
what
we
think
more
or
less
your
client
could
be
interested
like.
We
know
the
server.
A
I
can
backported
to
reverse
the
verbs
right.
I
can
reverse
the
verbs
and
change
the
reactor
name,
so
it's
website
website
client
whatever,
and
it's
like
this
is
kinda
what
you
need,
but
you
might
have
to
tweak
it
and
mix
it
with
other
stuff.
So
it's
just
for
you
not
to
start
from
scratch
and
then
using
kpa
file.
A
B
A
Me
too
now
I
understand
why
I've
been
confused
as
well
like
and
and
and
I'm
I
mean
I'm
amazed
by
this
kind
of
I'm
liking
this.
It's
episode,
one
of
thinking
out
loud
and
I'm
already
loving
it.
So
so
I
think
this
is
totally.
This
totally
deserves
the
the
effort
of
doing
more
of
them.
So.
A
Some
people
think
that
we,
the
people
that
are
working
on
the
spec
or
an
async
api
in
this
case,
or
an
open
api
or
refcul
or
whatever
they
think
we're
experts
and
that
we
know
everything
right
and
they
sometimes
they
come
to
us
and
it's
like
or
they
look
at
us
like
wow.
These
people
are
like
wow
rock
stars,
and
no
so
I
would
love
to
reinforce
this
like
no,
it's
just
we're
working
on
this
the
same
way.
They
are
working
on
something
else,
and
I
don't
know
everything
and
I
don't
pretend
to
know
everything.
A
B
But
I
also
want
to.
I
also
want
to
echo
your
message.
You
know
I'm
I'm
here.
I've
done
a
bit
with
a
sister
specification
with
open
api
and
I'm
I'm
a
user
of
kafka,
but
I'm
not
actively
working
on
async
api.
I'm
just
here
to
kind
of
tell
my
story
from
my
perspective,
and
I
hope
that
the
people
watching
whether
you're
watching
the
recording
or
you're
with
us
in
chat
with
the
little
bit
of
heckling
going
on.
I
hope
that
you'll
also
join
and
follow
the
conversations
that
we
have
in
the
later.
B
Episodes
of
this
twitch
stream
and
yeah
can't
wait
to
see
what
happens
next.
A
Yeah
I
mean
I'm,
I'm
super
happy
that
that
you
joined
us
today
before
before
I
I
wrap
up.
I
would
like
to
to
reply
to
some
comments.
So
rodrigo
is
a
friend
of
mine.
A
Yeah,
maybe
descriptions
as
well,
oh
well,
yeah,
it's
a
rev
under
kind,
which
is
funny
because
kind
can
be.
Some
can
mean
something
different
here,
so
it's
not
being
kind,
and
so,
if
we
do
something
like
here,
this
is
what
you
mean
like.
We
have
ref
under
the
kind,
not
sure
exactly
what
you
mean,
because
here
is
just
a
a
like
a
value.
It's
it's.
Just
probably
it's
just
published
or
subscribed.
So
I'm
not
sure
if
it's
worth
being
able
to
ref
here,
but
if
you're.
A
If
you
want
to
explain
as
a
little
bit
further,
I
will
be
happy
to
take
it
and
then
he
says
applying
in
alpine
comments
natural
languages,
language
processing.
So
yeah,
like
I
was
saying
like
description
here.
A
Comments
and
then
yeah
descriptions
right,
so
so
yeah,
I
think
that's
out
of
the
spec
scope
right,
so
so
yeah
and
then
sergio
was
pointing
out
that
consumer
group
should
also
go
to
server.
So
in
the
case
of
kafka,
I
think.
B
This
time
open,
there's
some
open
pull
requests,
I
think
for
the
kafka
binding.
So
there
are
a
few
things:
oh,
maybe
not
just
some
schema
stuff.
Okay,.
B
A
Actually,
I'm
I'm
gonna,
I'm
gonna
start
something.
I'm
gonna
start
something
new,
just
completely
improvised
and
I'm
going
to
reply
also
to
sir
here,
which
is
sergio.
Please
open
an
issue
because
I
don't
think
we
should
be
discussing
this
here
now,
but
but
yeah
I
don't
know
who
I'm
I'm
going
to
be
inviting
next.
I
want
to
share
this
with
the
audience,
so
I
didn't
think
about
it.
A
I
wanted
to
try
first
with
you
and-
and
I
think
it's
been
so
good
that
we
definitely
have
to
do
it
regularly
and
I
would
like
to
ask
you
like:
do
you
want
to
send
a
message
to
the
next
invitee.
B
Yeah
yeah-
and
I
I
think
my
message
is
that
at
this
stage
in
the
project
you
know
we
are
so
open
to
the
input
of
people
who
have
tried,
async
api
and
perhaps
more
the
people
who've
tried
it
and
disliked
it
or
found
it
tricky,
because
I
think
those
voices
are
so
important.
We
know
that
the
event-driven
systems
and
the
real-time
comms
are
such
a
growing
area
and
there
are
lots
and
lots
of
people
working
actively
with
async
api
or
looking
at
it
and
not
sure.
So
I
would
thoroughly
encourage
people
to
volunteer.
B
B
I
think
we've
had
some
I've
definitely
thrown
out
some
of
my
ideas
today,
but
yeah
we've
we've
talked
about
some
stuff
in
there,
but
there's
so
much
more
that
we
could
talk
about.
We've
already
ran
a
bit
longer
than
we've
intended
to.
So
that's
my
that's
my
call
to
action.
A
Cool
thanks
well
lorna.
As
you
said,
we've
been
it's
taken
longer
than
we
expected,
because
I
was
honestly
enjoying
the
conversations
and
the
process
the
thinking
process.
This
was
really
helpful
and
thanks
for
joining
me
today
into
thinking
out
loud,
so
so
yeah
thanks
a
lot
and
and
see
you
around
bye,
bye.