►
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
Hello
folks
welcome
once
again
to
thinking
out
loud
in
today's
episode,
you're
gonna.
Let
me
just
do
something
I
forgot
to
close
my
youtube
window
and
I
would
hear
my
top
level
so
welcome
again
in
this
episode
today
we
have
we'll
be
speaking
about,
I
think
kpi
3.0
and
the
work
that
we're
doing
to
get
there
to
get
into
the
next
major
version
which
is
or
it
looks
like
it's
going
to
be
a
huge
release
and
it's
going
to
take
a
a
bunch
of
time.
A
For
that
matter
we
have
sergio
moya
and
jonas
laguni.
Both
are
you
know
like
tse,
member
and,
and
you
know,
async
maintainers
of
different
repos,
so
so
yeah
I'll
introduce
them
in
in
a
second
before
I
forget,
I
want
to
do
this
collaboratively,
so
if
you
want
to
join
the
conversation,
use
the
chat,
don't
be
shy
like
if
you
want
to
join,
join
us
like
you,
want
to
give
your
perspective
on
something
or
ask
a
question
about
something
to
any
of
us.
A
Just
do
it:
let's,
let's
make
it
interactive
and
and
community
driven
like
everything
we
do
here
on
it's
in
kpa
right
also
before
I
forget,
we
have
enabled
closed
captions
on
our
youtube
channel.
So
if
you
need
or
prefer
to
have
closed
captions
head
over
to
youtube-
and
you
will
see
them
there,
if
you
can't-
please
let
me
know,
and
and
we
can,
we
can
tell
you
ways
to
to
add
them,
let's
say
to
to
enable
them
in
a
different
way
and
also
yeah.
A
Just
a
little
bit
of
brief
explanation
of
what
thinking
out
loud
is
so
the
purpose
of
thinking
out
loud
is
it's.
I
I
used
to
call
it
like
the
the
most
boring
show
ever
and
and
it
doesn't
have
to
be
boring,
but
because
it
doesn't
have
to
be
a
show
right.
So
so
the
thing
is
it's
not
a
show.
A
I
hope
it's
not
boring,
and
I
hope
it's
you
know
it's
entertaining,
but
it's
more
like
a
chat
like
a
castle
chat,
there's
no
script.
The
only
thing
the
only
prepared
thing
that
we
know
is
that
we're
gonna
talk
about
async,
pi,
3.0
and,
and
you
know,
and
the
work
that
is
happening
around
it
and
that's
pretty
much
it.
I
actually
have
sergio
and
janet's
talking
to
me
privately
saying
yeah.
What
can
go
wrong
right
like?
A
Let's
just
do
it
exactly.
Let's
just
do
it.
What
can
go
wrong?
Let's
let
things
go
wrong.
That's
that's!
Fine!
Let's
embrace
chaos,
as
I
was
telling
them
before,
so
so,
yeah
speaking
about
chaos,
I
can't
see
jonas
and
sergio's
on
camera,
so
we're
gonna
do
a
live
test
and
let's
see
what
can
go
wrong.
A
So
let
me
just
add:
jonas
you're,
there
perfect,
you
see
you
gotta,
embrace
chaos
and,
let
me
just
add,
sergio
whoa
nice.
Let
me
change
the
layout
a
little
bit.
No,
that's
too
much
it's
too
much
for
me.
I
don't
like
this
one
either.
Okay,.
A
Welcome
folks
welcome
to
thinking
out
loud,
I
mean
I'm
not
welcome
to
ask
api
you're
long,
long-term
contributors
already
so
but
yeah
for
those
who
are
watching
the
the
the
live
stream
right
now
or
the
them
remember,
there's
a
recording,
so
thank
you.
You.
B
A
Want
to
introduce
yourself
to
those
who
don't
know
you
who
goes
first,
I'm
gonna
play
stable.
C
D
D
C
D
E
Okay,
so
well
in
my
case,
it's
not
that,
like
so
much
time
it's
like
a
year,
I
started
working
with
async
api.
Before
of
this,
I
knew
a
few
folks
who
were
working
and
using
async
api,
but
nothing
nothing
else
regarding
the
spec
I'm
working
closely
to
with
the
spec.
In
fact,
I'm
the
release
coordinator
of
the
2.4
release
and
I'm
trying
or
I'm
trying
to
help
jonas
with
the
release
of
3.0.
E
A
Must
be
relieved
that
for
once
he
doesn't
have
to
be
doing
the
a
live
stream
or
a
meeting
yeah,
hey
lucas,
we
actually
miss
you.
We
should
be
inviting
you
on
each
thinking
out
loud,
even
if
it's
just
a
small
video
somewhere
in
a
corner
or
something
just
just
watching
him,
so
cool.
So
for
today's
episode,
I
I
my
my
vision
of
this
or
yeah.
A
My
vision
of
this
episode
is
that
we
get
to
tell
people
where
we
are
right
like
where
we
are
with
in
regards
to
to
the
I
think,
ebay,
3.0,
right
and
all
the
work
that
is
happening
around.
That's
just
a
spec
right.
So
so
this
question
is
for
for
jonas.
Let
me
just
start
directly
asking
you
directly:
where
do
you
think
we
are
right
now.
D
I
mean
we
are
in
the
very
very
early
stages,
because
nothing
is
concrete.
Yet
the
plan
is
that
as
soon
as
we
start
moving
things
into
like
getting
merged
into
the
spec,
we
can
start
using
it
in
the
tooling
like
immediately
more
or
less
so
we
can
kind
of
verify
as
we
go
as
well,
that
this
is
the
right
change
that
we're
doing,
but
we
are
in
the
in
the
very
early
stages.
The
the
branches
have
just
been
set
up.
There's
still
a
few
things
that
I'm
missing,
which
branches
you
mean.
D
That's
fair
so
for
the
for
the
3.0
we
have
or
everything
lives
in
a
separate
branch
from
the
main
branch
in
spec,
json
schema,
spec
repository
and
the
password
repository,
and
that
is
where
all
of
the
changes
are
happening
continuously
as
we
go
and
as
things
are
forming
to
be
like
complete-
and
this
goes
back
to
how
like
how
changes
are
made
in
the
specification
back
to
our
request
for
common
setup,
where
we
move
from
ifc
0,
which
is
just
an
idea,
then
it
gets
more
concrete
and
we
start
working
on
actual
changes
for
the
specification
and
then
in
the
tooling
right
and
once
it
reaches
ifc3
right
or
is
it
two?
D
A
So
I
may,
I
should
probably
mention
that
all
this
work
is
happening
on
a
on
a
separate
branch,
because
you
know.
A
There
we
still
continue
the
development
of
like
secchia
said
like
2.4
2.5,
I
will
I
was
going
to
say:
maybe,
but
not
maybe
2.5
will
be
released.
2.6
must
probably
before
3.0
will
be
released
as
well,
so
probably
so
so
yeah.
So
there
is
a
long
leaf
branch
that
represents
the
version
three
of
the
spec
and,
and
that
is
where
people
should
be
looking
at
right
now
right,
which
is
you
know
this
next
spec
yeah
next
space,
next
spec
branches?
A
That's
you
made
it
hard
on
purpose,
that's
so
good,
so
sergio
so
when
jonas
was
was
talking.
He
was
mentioning
this
this
thing
about
the
spec
that
we're
releasing
on
the
next
back
branch
and
also
expect
jason
schema
and
the
parser,
and
when
he
mentioned
the
parser,
I
was
like
think
so
here.
E
What's
going
on
what's
going
on
yeah,
so
3.0.
E
So
this
is
something
that
we
we
are
facing
every
time
we
release
a
a
major
version
of
of
the
parser
sorry
of
the
spec
that
breaking
changes
are
also
propagated
into
the
parser.
Why?
Because
the
current
parser
is
mainly
tied
to
exactly
the
same
structure
that
I
think
api
documents
have
meaning
the
api
of
this
parser.
E
It
looks
exactly
so.
You
have
to
navigate
exactly
as
if
you
would
be
navigating
the
the
async
api
document,
like
channels
are
under
document
channels.
Operations
are
inside
channels,
so
you
have
to
know
completely
the
spec
in
order
to
use
the
parser.
Any
breaking
change
in
the
spec
means
a
breaking
change
in
the
password.
E
So
since
we
knew
about
that
about
that,
we
wanted
to
develop
something
that
avoids
propagating
breaking
changes
into
the
parser
or
at
least
trying
to
avoid
all
of
them
right.
E
Like
a
common
interface,
where
no
matters
which
version
of
the
spec
you
use,
you
still
can
use
the
same
interface,
the
same
api
on
the
parser
meaning
in
this
case,
since
this
is
not
released.
Yet
breaking
chains
will
will
appear
in
the
new
in
the
new
parcel
version
right,
but
for
the
future,
if
we
release
a
spec
4
0.
A
Saying
it,
that's
that's.
No,
that's
fine!
I
mean
that
that
was
cool,
but-
and
actually
I
was-
I
was
thinking
right
now
that
this
is
actually
super
cool,
because
what
you,
what
you're
saying
here,
is
that
future
major
versions
of
the
spec
like
four
zero,
five
zero,
six,
zero,
whatever?
A
A
A
We
love
to
clarify
here
that
that
means
that
whoever
is
using
the
parser
or
any
other
tool
that
is
leveraging
the
parts
are
behind
the
scenes,
which
is
most
probably
every
asynchpa
tool
right,
not
only
the
official
tools,
but
also
external
community
contributed
tools
or
or
even
even
proprietary
tools
that
people
keep
in
their
companies
and
they
don't
share,
they
might
be
leveraging
the
the
parts
are
behind
the
scenes.
So
that
means
that
if
they
want
to
go
for
from
3.0
to
4.0
to
5.0.
A
They
can
immediately
upgrade
the
departure
dependency
and
it's
supported
it.
It
starts
being
supported
by
this
tool
right
off.
Obviously,
it
only
supports
whatever
was
in
the
spec
at
the
time.
Not
the
new
features
right,
so
we
cannot.
If
we
tomorrow,
we
add,
I
don't
know,
support
for
aliens
right
say,
for
instance,
we
cannot
provide
a
an
api
for
the
aliens
because
we
don't
know
we're
gonna
provide
support
for
aliens
in
the
future
right.
A
So
so
that's,
I
think,
that's
understandable
right,
but
that
it's
actually
pretty
cool.
So
that
means
less
headaches
on
on
the
on
the
user
side
because
they
will
not
have
to
update
their
code.
So
often
they
might
have
to
just
upgrade
the
dependency
on
the
parser
or
or
the
tool
they're
using,
and
that's
it
immediately.
They
can
start
using
async
api.
A
Four
five:
six
zero
right
like
in
me
completely
like
immediately
right-
and
that
is
that
is
to
me-
is
that
it's
it's
super
cool
which
reminds
me,
and
that's
usually
one
of
the
fears
why
people
don't
want
to
release
spec
versions
very
often
because
people
think
like
if
we
release
versions
very
often
we're
gonna
break
people's
code
and
tools,
and
so
on
and
yeah
people
will
get
tired
of
us
and
they
will
stick
to
whatever
is
good
for
them
or
good
enough
for
them
like
say
2.3,
and
they
will
not
update
their
versions
in
years.
A
Because
what
for
right,
like
they're,
getting
it's
a
it's
they're,
getting
a
lot
of
troubles
and
and
a
lot
of
difficulties
for
almost
no
value,
or
at
least
the
value
is
not
it's
not
worth
for
them
right,
so
so
yeah.
So
what
we're
trying
to
avoid
here
is
precisely
that
that
people
can
upgrade
without
fear,
and
we
can
continue
developing
spec
without
the
fear
that
we
cause
breaking
changes
and
obviously
we
will
try
to
avoid
breaking
changes
at
all
costs,
or
at
least
group
them
as
we're
doing
now
with
with
version
three.
A
But
at
least
I
promise
I
promise
I
will
try,
but
but
yeah
that's
the
that's
the
whole
idea,
right
and
and
and
for
those
who
are
curious
about
like
how
are
we
going
to
do
that
right.
A
How
are
we
going
to
avoid
breaking
changes
on
the
parser
api,
like
the
the
term
that
comes
to
my
mind,
always
is
the
facade
right?
It's
a
fashad.
That
is
an
often
a
term
using
software
engineering.
How
do
you,
how
do
you
think
we
or
or
can
you
explain
a
little
bit
more
like?
What's
going
to
be,
why
why
is
it
different
that,
where
it
will
not
propagate
breaking
changes.
E
The
point
is
that
we
created
a
an
interface
of
the
models
that
are
common
in
every
async
api,
spec
version,
no
matter
what,
as
I
say,
channels
operations
servers
unless
those
changes
which
is
not
so
I
don't
know,
I
don't
expect
to
change
those
in
the
next
two
or
three
major
versions,
please,
but
so
it
means
at
the
end.
You
are
hitting
an
api
that
it's
well
known,
that
it's
implemented
by
any
parser.
It
doesn't
mean
it's
only
the
parser
written
in
in
gs
or
typescript.
E
I
would
tell
more
later,
but
also
the
one
written
go
java.
Whatever
all
of
them
will
implement,
eventually,
this
new
api,
how
that
work
internally,
yeah,
for
example,
in
go
or
in
typescript
whatever
you.
You
have
your
own
interfaces
that
are
a
match
between
between
what
we
define
it
in
the
parser
api
parser
api
is
just
a
document,
a
markdown
of
all
the
models
or
the
functions
that
your
models
have
to
implement
in
some
kind
of
zelda
code.
E
Get
there
so
so
yeah
I
just
wanted
to
add
to.
If
there
is
a
breaking
change,
it's
just
a
matter
of
changing
the
implementation.
E
If,
instead
of
getting
operations
from
channels,
you
have
to
get
it
from
the
root
of
the
document,
it's
just
changing
the
implementation
of
that
function.
Exactly
that's
all,
for
example,
deprecations
also
work.
In
that
way,
you
can
deprecate
from
one
version
to
other
and
just
add
a
notice
whenever
you
use
a
method
exactly
or
provide.
A
Some
guideline
or
some
defaults
as
well
like
if
something
is
deprecated
like
something
gets
removed
from
version
three.
Let's
say
something
that
returns
an
array
gets
removed
from
version
three
to
version
four,
then
it's
as
easy
as
easy,
as
returning
an
empty
ray
right
like
or
whatever
is
the
equivalent
right
of
course.
A
So
it's
like
you
can,
of
course,
print
an
artist
or
something
like
that
deprecation
notice,
but
but
from
the
working
code
point
of
view,
it's
just
yeah,
we
can
make
decisions
like
okay,
it
used
to
return
a
an
array
of
some
things,
some
other
you
can.
A
There
is
a
default
that,
from
here
on,
you
can
still
use
it,
it's
deprecated,
and
but
it's
going
to
return
an
empty
array
with
that
specific
version
of
the
spec.
If
you
use
a
previous
version
of
the
spec,
it
will
return
something
right
so
so
yeah.
A
I
actually
I
actually
like
this
this
approach
and
then
and
something
that
that
comes
to
my
mind
as
well
is
so
the
the
I
think
the
real
deal
here
is
instead
of
accessing,
like
you
were
saying,
the
structure
of
the
document
like
info
title,
something
like
that
and
then,
if
something
moves
around
or
change
names
or
something
like
that,
it
gets
broken.
A
Instead
of
this,
what
we
offer
instead
is
like
a
set
of
root
methods
that
are
not
trying
to
map
the
spec
structure,
but
instead
they
try
to
map
user
intentions
right.
So
so,
usually
when
you,
when
you
want
to
query
an
snk
api
document,
you
have
a
purpose.
You
have
an
intention
you
want
to.
I
want
to
get
all
the
messages
that
this
application
is
publishing.
For
instance
right,
that's
all!
That's
what
you
want
to
get
you
don't
want
to
navigate
the
whole
structure
and
and
find
them
right.
A
That's
like
that's
something
that
you
have
to
do
to
get
them,
but
but
instead
what
we
offer
here
is
like
no,
you
don't
have
to
do
it.
We
get.
We
give
you
a
method
that
is
give
me
all
the
published
message,
messages
right
and
like
this,
we
should
be
offering
a
bunch
of
things
like
it
will
be.
It
will
be
evolving
over
the
years
like
you
need
something
like
you
need
a
net
case,
maybe
like.
A
I
want
to
get
all
the
messages
that
are
being
published,
but
only
those
who
are
being
published
to
this
broker,
not
all
of
them
right
so
same
thing
will
be.
There
will
be
maybe
not
initially,
but
in
the
future
there
will
be
a
way
to
filter
them,
so
so
the
function
itself
in
your
code
when
you're
calling
the
parser
remains
the
same
and
there's
no
breaking
changes
as
we
just
discussed,
but
yeah
cool
thing
is
that
so
I
think
the
real
deal
here.
A
A
And
yeah
so
yeah
before
we
jump
into
the
next
thing.
I
want
to
thank
alejandra.
F
A
Thank
you.
I
love
it
as
well.
I
was
I
was
questioning
if
I
should
be
wearing
it
or
not,
but
thanks
anyway-
and
you
see
we
interact
with
each
comment,
which
is
with
each
person
that
lives
a
a
comment
on
the
on
the
chat.
So
so
that's
what
I
want
to
that's
the
message
that
I
want
to
send
like
get
engaged
with
with
ass.
Don't
just
listen
to
us
and
sergio
was
just
sharing
something
with
me
in
the
private
chat
and
I'm
gonna
share
it
here.
A
Okay,
so
this
is
where
all
the
fun
is
happening
for
the
new
parser
api.
This
intent
driven
api
right
so
yeah
it
is
not
for
javascript.
It
is
not
for
java,
it's
not
for
go
it's
language
agnostic
as
much
as
much
as
possible,
of
course,
and
and
yeah.
That's
that's
the
whole
thing.
A
Changing
a
little
bit
subject,
I
was,
I
was
thinking
now
that
jonas.
A
D
The
problem
is
that
those
problems
that
are
raised
as
issues
in
the
spec
are
things
that
makes
it
hard
to
use
like
it
makes
the
specification
hard
to
implement
and
use
in
a
real
world
like
scenario
right
and
as
soon
as
one
of
those
issues
should
be
addressed.
For
example,
let's
take
the
pub
sub
confusion
as
soon
as
you
say
that
this
is
a
problem
that
we
should
fix,
because
it
creates
more
confusing
confusion.
D
D
A
Agree,
no,
no,
I
agree
and
and
that
actually
maps
well
to
what
I
was
mentioning
before
that
we
always
try
to
group
all
the
breaking
changes.
Of
course
like
we
don't
want
to
be
constantly
breaking
the
the
spec.
I
mean
we
cooled
with
the
new
parser.
We
cooled
right,
but
we
don't
have
the
parser
yet
so,
but
with
the
new
parser
we
could
just
easily
be
launching
yes.
A
Without
going
even
into
3.1
or
4.1
like
we
can.
We
can
go
like
major
to
major
and
that
will
be
fine
because
from
the
user
point
of
view
is
like.
Who
cares?
I
mean
if
it's
obstructed?
What's
there
here.
E
E
You
know
you
can
understand
that
releasing
a
new
major
version
of
the
spec,
it's
a
pain
because
you
don't
control
your
tooling
community
or
not
community,
but
you
don't
provide
the
support
from
the
from
the
initiative
to
the
community
to
to
build
or
to
to
manage
the
breaking
changes
right.
So
this
is.
A
You
open
a
big
box
here,
a
controversial
box
that
I
and
that's
fine.
I
love
it.
I
love
a
controversial
topic,
so
no
worries.
So
I
was,
I
was
thinking
as
you
were
saying
like
we
own
the
tooling,
but
we
don't
own
all
the
tooling,
of
course
like
there
might
be.
I
mean
there
are
tools
that
are
not
under
the
same
kpa
umbrella.
That's
fine
and
there
might
be
there
are.
Actually
I
have.
I
have
information
that
there
is
tools.
There
are
tools
in
companies.
A
You
know
in
closed
source,
proprietary
tools
that
are
parsing
using
kpi
documents,
so
these
tools
will
be
affected
will
get
affected
right.
So
now,
just
thinking
out
loud
thinking,
out
of
my
on
the
top
from
the
top
of
my
head
now
like
I
was
when,
when
I,
when
I
was
proposing
that
we
go
for
3-0
and
we
and
we
make
a
breaking
change,
I
was
scared
a
little
bit
afraid
that
these
people
will
simply
be
left
out.
A
If
you
don't,
if
you're
not
using
our
tools,
your
tools
are
going
to
break,
so
you
will
have
to
make
some
effort
to
adapt
to
the
new
version
or
what's
what's
wrong.
What's
worse,
is
that
they
will
not
and
they
will
stick,
they
will
stay
in
two
point,
something
right,
because
that's
what
their
parser
supports.
A
Now
I
was
thinking
like.
Should
we
care
about
these
people.
A
And
let
me
let
me
explain
a
little
bit
further
like
so
we
care
about
people
who
are
not
sharing
contributing
back
to
the
project
sharing
what
they
have
internally,
but
they
benefit
from
what
we
do
in
the
open
as
open
source
and
and
we're
and
we're
happy
to
accept
any
projects.
Usually
I
mean
that
all
projects
that
have
been
proposed
to
be
accepted
under
the
snkp
umbrella
has
been
have
been
accepted,
so
we
always
so
far.
We
have
we've
been
always
accepting
each
contribution.
A
So
is
it
morally
or
ethically
like
correct
that
we
care
about
them
because
we're
caring
about
someone
who
don't
care
about
us
not
as
we're
caring
about
someone
who
don't
care
about
the
rest
of
the
community
say,
for
instance
an
example.
A
We
don't
have
a
java
parser
right.
We
want
to
have
at
least
myself.
I
want
to
have
a
java
parser,
because
I,
the
more
I
talk
to
customers,
not
users.
Sorry,
not
customers,
yeah
too
much
old-school
stuff.
The
more
I
talk
to
to
users
is
the
more
I
find
that
they're
using
java,
and
they
want
to
use
the
spec
in
the
java
ecosystem.
A
They
want
to
build
tools
for
a
java
ecosystem,
so
they
need
a
java
parser,
and
I
know
because
I
have
I
have
more
information
as
well-
that
there
are
at
least
at
least
three
java
parsers
out
there
and
they
have
not
been
contributed
to
async
api.
A
So
now
they're
going
to
be
broken
with
the
new
version,
I
mean
broken
in
the
sense
of
they're
not
going
to
be
supporting
3.0
if
they
don't
update
it,
of
course,
but
that's
my
question
like
it:
should
we
be
caring
about
people
who
are
not
caring
for
the
community
but
they're
getting
the
work
from
the
community
spec
and
other
tools?
D
It's
a
it's
a
rough
question
right
because
there's
some
there's,
there's
many
perspectives
as
to
why
that's
happening
as
well
like,
if
you
think
about
like.
Why
do
they
keep
the
tools
for
themselves
or,
let's
say
in
their
own
repository
and
their
own
organization
on
github?
It's
because
it
creates
value
for
their
company
right
in
a
sense
it
creates
like
bigger
evaluations,
they
can
say.
Oh,
we
have
this
and
this
and
this,
but
in
the
open
sense
it's
like.
D
It's
everyone,
that's
benefiting
from
having
this
one
parser
in
one
language
that
everyone
can
use
and
everyone
is
helping
update
whenever
a
new
version
of
the
spec
comes
out
where,
if
it's
solely
on
your
side,
like
your
organization
on
github,
for
example,
it's
your
responsibility
most
of
the
time,
if
you
don't
have
a
community
around
it,
that's
helping
you
like
stay
up
to
date,
so
it's
kind
of
two
opposite
forces
like
business
side
and
developer,
not
satisfaction
but
like,
like
I'm,
not
sure
which,
like
with
experience,
yeah
experience,
developer
experience.
A
A
I
agree
like
if
it
wouldn't
provide
value
for
their
company.
They
will
then
invest
engineering
time
on
something.
That's
I
mean,
or
they
shouldn't
at
least,
but
most
probably
they
wouldn't
so
but
like.
There
are
two
things
here
that
that
come
to
my
mind
like.
Should
they
be
sorry?
So
should
we
be
or
is
it
our
problem
that
it's
a
like
it's
a
it's
providing
value
for
them
and
because
of
that
reason
they
don't
want
to
share
and
and
another
thing,
because
it
provides
values
for
them.
A
That
means
that
it
needs
to
be
kept
private.
It
can
provide
value
for
you
and
still
be
open
right.
I'm
not
saying
I'm
not
saying
donate
into
async
api
initiative.
You
can
still
keep
it
under
your
company's
github
organization,
or
something
like
that
and
may
and
make
it
open
right
and
accept
contributions
and
and
and
manage
it
yourself,
but
at
least
it's
it's
open
right.
At
least
it's
it's
available
for
others
to
use
right.
You
still
control
the
roadmap,
but
but
at
least.
E
I
think
I
want
to
say
something,
and
maybe
I'm
killing
myself,
but
I
think
that
the
real
difference
here,
it's
nothing
else.
I
mean.
I
don't
think
that
is
like.
I
don't
know
the
evil
behind
that
you
know
like
we
don't
want
to
contribute
to
open
source
because
open
source,
whatever.
No,
I
think
just
the
difference
that
companies
build
software
for
like
for
getting
revenue
pretty
fast,
so
they
build
software
thinking
on
the
short
meter.
E
E
In
many
companies
is
that
they
build
prototypes
pretty
quickly,
so
they
don't
be.
They
don't
want
to
be
involved
with
anyone
out
of
their
company,
because
some
reasons
I
I
could
name
some
of
them
and
then
they
think.
Okay,
once
this
is
going
cool,
we
can
move
to
open
sources,
but
that
never
happened
because
resources
move
into
other
area
like
they
don't
care
right.
Yeah.
E
Also,
I
think
the
process
on
the
companies
regarding
security
code
reviews
of
possible
secrets
being
leaked
into
the
soft,
the
software
they
create.
All
of
this
is
pretty
hard
to
maintain
in
companies,
and
I
think
they
they
could
be
scared
of
providing
this
to
to
make
it
public
right,
just
public
and
entering
on
the.
A
No,
I
agree.
I
agree.
I
agree
that
and
actually
I
think,
that's
the
main
reason
why
people
like
these
companies
don't
make
this
projects
open
source.
I
don't
think
it's
evil.
It's
an
evil
decision
like
we're,
gonna,
just
them
like
we're,
not
gonna
open
source.
This,
let's
just
use
it
for
ourselves.
A
I
don't
think
there's
there's
evil
behind
it,
but
yeah.
My
concern
was
more
or
my
thought
was
more
from
the
other
side
like.
A
Should
we
care
like
even
if
even
either
it's
evil
or
not,
we
should
make
a
decision
right
like
we
move
into
a
breaking
change
or
a
major
version,
or
we
don't
and
there's,
there's
always
fear
like
they're
they're,
not
gonna,
be
rewarded
right
because
they're
not
using
our
parser,
but
they
have
the
choice
to
use
our
parser
and
they
they
even
have
the
choice
to
configure
the
parser
and
then
we
and
from
there
on
we
maintain
it,
but
but
yeah,
no
just
thinking
out
loud
I
mean,
I
don't
think.
A
So
folks,
who
are
watching
as
we
are
really
into
agile
at
18kpi
and
specifically
at
the
postman
and
the
postman
team,
you
know
like
we
love
agile,
we
do
everything
on
agile,
yeah,
whatever
that
means
so
yeah
and
that's
and
that's
why
lucas
is
always
mentioning
a
child
because
he
loves
it.
If
you
have
any
giant
questions,
just
ask
him
so
yeah
yeah,
he
will
be
happy
to
answer.
A
So
yeah,
and
so
all
this
conversation
came
because
you
know
like
I
was
asking
jonas
like
why
why
a
major
version
like
why
version
three
right?
A
Why
do
we
need
it
and
because
all
this
conversation
happened
when
we
were
discussing,
I
think
under
the
proposal
that
I
made
on
the
public
subscribe,
I
think,
all
or
maybe
not
there.
I
think
it
was
in
another.
So
I
can't
remember,
but
all
this
discussion
happened
on
github
as
well
like
should
we
try
not
to
make
a
breaking
change
at
all
costs
and
and
yeah
and
we
are,
and
we
have
this
publish
and
subscribe
confusion.
A
So
for
those
who
don't
know
what
is
it?
What
is
it
about
head
over
to
the
sinkipi
website
and
try
to
learn
async
api
and
now,
once
you
do
it?
Try
to
tell
me
if
publishing
subscribe
makes
sense
for
you.
Maybe
it
does
depends
on
what
you,
what
you
try
to
do,
but
don't
try
to
do
a
web
socket
api
or
something
like
that.
A
Try
something
involving
a
broker
like
kafka
or
mqtt
mosquito,
or
something
like
that
or
whatever
something
a
broker
and
then
tell
me
if
it
makes
sense
to
you
so
so
the
thing
is
that
well
summaries,
it
doesn't
make
sense,
it
does
make
sense,
but
it's
highly
confusing,
like
you,
I
it
is
for
me
as
well,
like
I
define
this
behavior
as
a
mistake.
To
be
honest,
so
I
defined
it
this
way
as
a
mistake,
because
it
was
coming
from
open
api
and
in
open
api.
A
It
made
sense
because
it's
a
client
server
architecture
all
the
time.
So
that's
that's
fine.
But
in
this
case
it's
it's
a
problem.
It's
it's
confusing!
It's
not
that
it's
a
problem,
but
it's
confusing
right,
but
so
then
yeah
like.
If
you
want
to
change
this,
we
could
be
changing.
A
We
could
be
adding
something
I
don't
know,
maybe
making
the
spec
a
little
bit
more
nasty
nasty
is
a
word
I
don't
know.
I
don't
think
it's
still
well
yeah,
maybe
yeah
it's!
I
don't
know
if
a
spec
can
be
nasty,
but
if
it's
cool
it
will
be
nasty
so
and
making
and
having
more
staff.
You
know
like
adding
more
stuff
to
the
spec
just
to
try
to
cover
this
piece
of
that
that
we
did
and
then
it's
like
just
so
it
doesn't
smell
right.
A
Basically,
we
could
do
it,
but
then
it
will
make
the
the
spec
even
more
complicated
and
and
even
more
you
see
nasty.
So
it
it
made
sense.
A
spec
can
be
nasty
so
so
yeah
so
yeah.
It
was
always
in
the
air
like.
Should
we
go
for
a
major
version
or
not
right,
but
at
least
in
the
beginning
now
it
seems
to
be
clear.
A
Like
okay,
we
want
a
major
version,
and
now
it's
the
conversation
was
moved
to
tooling
right
like
then,
we
should
avoid
at
all
costs
breaking
changes
on
user
code
basis
because
yeah,
it's
it's
a
pain
right,
so
so
yeah.
So
it's
almost.
A
A
Who
should
be
answering
this?
Let
me
just
play
devil
here.
A
A
Even
more
I'll
I'll
go
even
beyond
that,
like
soul,
async,
kpi
3,
put
the
focus
in
the
application
like
sully
to
represent
an
application
and
other
other
options
are
can
be
representing.
The
broker
can
be
represented
in.
I
don't
know
no
behavior
at
all,
like
no
publishing
or
subscribing
just
a
list
of
topics
and
messages.
E
To
be
honest,
I
got
very
excited
at
the
beginning
with
this
just
got
raised,
because
I
saw
the
use
case
pretty
clear
by
then,
and
we
got
some
attraction
by
some
frequent
contributors.
Active
contributors.
E
But
then,
when
we
started
elaborating
correct
me,
if
I'm
wrong
jonas
right,
we
saw
that
maybe
we
were
like
trying
to
add
so
much
thing
or
that's.
What
was
my
my
impression
like
so
much
thinking
to
what
the
spec
is
right,
like
you
said
a
few
minutes
ago
like
we're
trying
to
patch
or
trying
to
trick
the
thing
to
done
to
remove
the
smell
or
something
like
this.
I
don't
know
yeah
something
like
this,
so
that
was
my
impression
at
the
end
as
well.
E
We
wanted
we
were
so
much
ambitious
on
what
the
spec
should
be.
In
my
opinion,
I'm
not
saying
is
a
bad
idea
not
at
all,
but
maybe
we
should
think
on.
E
A
D
I
think,
because,
while
we
do
have
this
problem
of
okay,
so
if
you
use
async
api
to
define
the
application,
what
if
you
wanted
to
define
an
entire
cluster
or
a
system
of
like
multiple
applications
together,
which
forms
the
system
in
itself
and
what
the
system
is
that's
up
to
discussion
as
well,
because,
like
this
is
around
the
is
it
around
the
broker?
Is
it
around
the
domain?
Is
it
around
like
yeah?
D
A
A
Yeah,
so
that's
that's
true,
like
we
don't
have
enough
context.
I
agree
with
this.
Some
people
may
may
do
may
have
enough
context
context
and
that's
why
they
were
proposing.
This
thing
is
that
we
are
as
in
as
an
open
source
initiative
as
an
open
governance
initiative
right,
because
it
can
be
open
source,
but
not
open
governance.
A
A
That
doesn't
mean
that
this
would
be
the
best
for
for
everyone
in
this
situation
right
so
so
yeah.
I
agree
that
we
lack
a
little
bit
of
visibility
on
what
are
the
the
needs.
The
user
needs
here
right,
and
that
leads
me
to
another
and
last
topic,
which
is,
I
think,
it's
in
it's
an
interesting,
interesting
one,
which
is.
A
How
do
we
solve
that
like?
Like?
We
lack
visibility?
We
we
have
many
people
contributing
to
the
spec
and
and
the
tooling,
mostly
to
this,
to
the
tooling,
not
the
spec.
Actually,
it's
it's
not
like
lots
of
people
contributing
to
the
spec.
We
don't
have
a
lot.
A
So
this
is
a
call
for
you
to
contribute
to
the
spec
to
you
who
are
watching,
but
the
thing
is
that
sometimes
it's
not
just
about
contributing
the
text
that
you
have
to
write
or
yaml
or
the
json
schema
files
or
whatever
it's
just
it's
precisely
this.
It's
like
we
don't
have
a
visibility.
We
don't
have
context,
we
don't
know
what
will
be
the
use
cases
out
there.
So.
A
F
D
Big
question:
that's
yeah
and
we
have
four
minutes.
A
Yeah,
I
may
sound
smart,
but
I'm
just
translating
all
my
problems
to
you
now
just
waiting
for
you
to
give
me
a
solution.
So
that's
that's
all
what
I'm
doing
here.
E
I
mean
from
the
technical
point
of
view,
it's
obvious
right.
We
can
build,
we
are
releasing
everything
we
do.
E
What
I
think
it's
important
is
that
every
especially
every
major
release,
we
should
include
changes
that
are
improving
the
user,
experience,
the
developer
experience
and
then
whatever
features
right
so
features
that
are
kind
of
like
accepted
for
several,
not
only
for
the
for
the
from
the
tse
or
or
from
the
common
contributor,
but
somehow
validate
that
with
real
use
cases,
companies
or
whoever
use
that.
F
D
How
do
you
define
an
api
for
an
application
in
a
non-specific
protocol
and
binding
and
what's
called
like
a
scenario,
so
it
doesn't
matter
whether
it's
rest,
whether
it's
cafca
or
nets,
or
whatever
way
you
define
anymore
in
which,
in
which
context
you
want
to
define
an
api,
you
can
do
it
with
async
api
like
that
is
more
or
less.
The
main
focus
is
that
there's
no
pain
points
in
in
defining
that
that
is
more
or
less
what
3.0
is
aiming
to
solve,
based
on
whatever
issues
we
have
gathered
right,
that's
more!
D
A
So
how
do
you
make
sure
that
we're
not
introducing
even
more
worst
problems
after
this
release
right
now?
It's
I'm
creating
a
sense
of
fear
in
you.
D
Want
to
release
version
3.,
no,
not
at
all
like,
because
whenever
I
use
async
api
to
define
whatever
project,
I'm
working
on
like
these
issues
that
are
defined
at
the
moment
in
the
spec
ripper
is
whatever.
Like
those
issue.
I
face
every
single
time
so
to
me
that
it's
it's
clear
that
those
issues
are
there
and
needs
to
be
solved.
D
A
I
was
looking
at
sergio
like
maybe
you
want
to
get
something
that
you
already
did?
Okay,
so
I
got
a
last
question.
It
shouldn't
take
long,
but
it
can
take
all
the
time
you
want.
A
It
was
your
first
time
in
a
live
stream,
I
think
other
than
the
other
than
the
you
know,
the
meetings
that
we
do,
which
don't
look
like
last
stream,
but
even
though
they
are
did
you
enjoy
it.
D
No,
it's
a
cool
concept
right
because,
like
it
doesn't
get
any
more
true
than
this,
because
we
have
no
idea
what
we
are
going
to
discuss
rather
than
an
overall
subject,
but
still
there's
kind
of
a
fear.
In
the
background
like,
even
though
that
we
work
with
this
every
single
day,
it's
still
like
what,
if
I
don't
know
something
like
we're
being
asked
or
don't
have
a
view
on
a
specific
topic,
then
it's
always
like
I
don't.
A
A
A
Saying
I
don't
know,
that's
fine,
that's
completely
fine
and
that's
why
I
wanted
to
invite
you
to
to
thinking
out
loud
and
it's
like.
Let's
just
have
a
honest
and
transparent
conversation
chat
like
we
will
have
privately,
but
in
public
right,
so
yeah
cool
folks.
So
I'm
glad
that
you
enjoyed
it.
I'm
gonna
leave
some
a
few
seconds
in
case
someone
wants
to
ask
something,
but
it's
usually
not
the
case
but
yeah.
A
A
By
the
way,
I
always
liked
this,
I
went
when
they
were
approaching
to
me
like
a
rock
star,
were
you
hiring
a
rock
star
developer
or
something
like
that?
Are
you
offered
cocaine
in
the
office
or
something
like
that?