►
From YouTube: AsyncAPI spec 3.0
Description
A
B
A
B
Yeah
out
of
that
or
not
I
think
what
happens
if
I
just
what
happens
if
I
just
change
it
just.
C
A
B
Welcome
to
another
respect,
3.0
meeting
this
time,
or
at
least
last
time
we
talked
about
it's
kind
of
giving
a
status
of
where
we
are
what's
happening.
What
is
is
anything
plugged
moving
forward
Etc,
but
before
doing
that
is
anyone
who
wants
to
bring
something
up
before
jumping
into
that,
because
it's,
it's
probably
gonna,
take
the
rest
of
the
meeting.
If
I'm
not
mistaken,.
C
B
A
B
But
with
that
there's
also
a
lot
of
questions
and
stuff,
we
need
to
kind
of
discuss
because
we
are
not
very
good
at
moving
things
to
rfcs
and
through
the
RFC
process,
because
sometimes
we
just
have
proposals
in
PRS
without
actually
having
the
specific
issue
outlined
as
well,
and
we
have
a
couple
of
instances
where
that's
the
case,
but
we
can
take
them
as
as
we
go.
B
Basically,
we
do
have
a
lot
of
the
issues
that
are
being
championed
by
Magic,
but
he's
not
on
the
call
so
I
guess
it's
I'm
not
sure
how
far
we
can
take
it.
But
let's
see
so,
for
this.
Introducing
info
item
objects,
I'm,
pretty
sure
it's
already
in
ifc1,
just
without
the
title,
or
at
least
that's
how
I
see
it
there
is
a.
B
There
is
somewhat
of
a
consensus
of
that.
This
is
needed
and
we
also
discussed
it
a
couple
of
times.
If
I'm
not
mistaken
on
these
meetings,
so
Fran
now
I'm,
basically
talking
to
you,
do
you
mind
updating
that
label
because
I
can't
do
it?
If
you
think
it's
ready,
which
one.
B
A
A
I'm
not
following
the
process
with
with
version
three,
because
it's
weird
it's
weird,
because
so
for
instance,
it
requires
that
you
have
implementations
in
the
parser
and
decent
schema
and
so
on.
So,
but
what
I'm
finding
right
now
is
that
some
of
this
some
of
these
are
not
yet
possible
because,
for
instance,
parser
is
being
migrated,
so
I'm
not
going
to
work
on
3.0
stuff
on
the
current
person
implementation,
because
it's
gonna
get
removed
in
a
few
I.
A
Don't
know
whatever
a
few
weeks
three
months
whatever
so
I'm,
not
gonna
lose
the
time
implementing
it
on
the
current
version,
but
I
cannot
well
it's
it's
difficult.
Let's
say
to
implement
it
right
now
on
the
on
the
current
API
on
the
on
the
future
parser,
because
it's
still
under
development,
so
so
yeah.
So
I
wasn't
following
this
this
process
of
RFC.
A
You
know
like
stroma
and
all
this
stuff,
just
because
of
that
I'm,
just
like
pushing
stuff
together
and
and
then
over
time,
we
will
be
evaluating
like
what
needs
to
be
implemented
in
each
place.
A
I'm
I'm,
of
course,
trying
to
implement
things
on
each
place,
but
but
yeah
so
I
can
I
can
update
the
the
one
from
the
info,
but
or-
and
if
you
want
me
to
follow
the
RFC
process
from
now
on,
I'm
happy
to
do
it,
but
I
don't
know,
I
have
the
feeling
that
it's
a
little
bit
of
a
yeah
I
mean
let's
say
weird
because
yeah,
for
instance,
I
was
moving
components
and
channels,
but
these
are
not
RCS
right.
These
are
just
parts
of
an
RFC.
B
A
So
these
are
just
pull
requests:
small
pull
requests
to
solve
just
a
part
of
the
RFC
so
and
I
don't
want
to
create
another
long
leaf
Branch
for
the
on
top
of
the
existing
long
leg
branch,
which
is
next
major
version
and
keep
them
in
sync
Just
for
the
a
specific
RFC
right.
So
yeah.
B
Have
we
have
I
mean
this
one
is
for
a
matrix
proposal
about
having
this
meta
update
and
we
talked
about
this
before
and
it's
more.
B
We
already
have
introduced
the
change
to
the
spec
through
the
pr
which
is
as
far
as
as
I,
remember,
that's
where
it
reaches
5c1
and
starts
to
needing
to
or
needing
to
move
towards,
ifc2
right
and
it's
I
think
it's
it's
completely
fine
that
we
don't
do
passer
at
the
moment,
especially
while
it's
migrating,
but
we
can
at
least
start
finishing
the
changes
to
this
spec
itself
and
start
finishing
the
changes
to
the
spec
document.
This
Json
schema
documents
because.
A
B
We
can
always
in
the
end,
take
it
and
start
yeah
yeah.
A
Well,
my
point
was
that
I
mean
this
one
about
the
info
object
check.
A
Yeah,
so
this
one
yeah
so
RFC
one
if
I'm
not
mistaken,
cannot
be
issues.
A
They
have
to
be
pull
requests
right,
so
you
can
put
together
an
RFC,
zero
and
a
strongman
proposal
as
an
issue,
but
I
think
the
proposal
has
to
be
a
already
a
pull
request,
or
the
draft
I
can't
remember,
but
it's
either
one
or
the
other
person
should
be
should
be
a
pull
request.
This
is,
we
cannot
I
mean
we
cannot.
Of
course
we
can
make
an
exception
here,
but
but
yeah
like
yeah.
Let's
take.
B
A
It's
basically
stated
this
will
be
actual
changes,
not
discussions
or
anything
like
that
right.
But
it's
true.
We
might
want
to
review
this
process
because
it's
true
that
one
single
issue
might
be
composed
by
many
pull
requests,
so
you
might
want
to
merge
multiple
pull
requests
and
once
once
all
of
them
are
are
merged,
then
you
can
move
it
to
the
next
stage
or
even
if
they're
not
merged,
but
they're
ready
to
be
accepted,
ready
to
emerge
that
we
can
move
this
to
the
next
stage,
but
yeah
something
to
yeah.
A
It
is
not
so
much
about
version
free,
it's
more
than
version.
3
is
a
huge
job.
It's
a
huge
change
and
usually
don't
you
don't
want
to
create
a
huge
pull
request
with
lots
of
changes.
You
want
to
do
multiple
small
pull,
requests
right.
Yes,
so
so
yeah
having
RFC
one
for
a
small
pull
request
and
then
NFC
one
again
for
another
pull
request
and
then
for
another
pull
request.
A
I
think
it
breaks
the
purpose
so
so
yeah.
So
probably
we
should
be
assigning
this
to
an
easy
route
step.
A
Yeah
just
saying
that
they're
saying
that
this
is
this.
B
A
I
think
that
that
is
how
graphql
does
it
as
well,
but
it
was
almost
it's
not
copy
paste.
It
was
almost
copy
paste
from
graphql.
A
B
A
A
A
So
so
at
least
this
two
or
three
pull
requests
right.
So
so
we
probably
have
to
change
that
anyway.
This
is
just
a
I
mean.
The
process
is
here
to
help
us
not
to
stop
us.
So
that's
why
I
was
like
forgetting
about
rfcs
and
so
on.
B
But
I
mean
this
also
means
that
this
is
basically
like.
We
can't
really
use
any
of
this,
because
it's
not
how
it
really
moves
or
reaches
the
different
stages.
A
Let's,
let's
make
sure
that
we
have
this
discussion
I'm
going
to
change
the
label
on
the
info
item.
Object!
Introducing
the
item
object
as.
B
A
So
what
I
mean
is
that
this
one
that
you
have
the
cursor
over
Fitness
changes
to
its
back?
This
item
will
have
to
be
moved
to
rfc3
right.
A
You
know
what
I
mean,
because
it's
like
we
can
consider
something
as
accepted
when
it's
already,
let's
say,
merge
or
ready
to
be
merged
right.
A
Not
just
the
spec,
but
all
of
them
respect
the
spectation
schema
and
the
parser
three
of
them
right.
They
should
be
finished.
It
doesn't
mean
that
they
have
to
be
merged
right,
but
they
should
be
finished
and
they
should
be
like
ready
to
merge.
Okay
yeah
anyway.
We
need
to
look
at
this
process
because
it's
a
I
think
it's
a
pain
going
through
all
the
the
pull
requests
and
assigning
the
label.
I
think
it's
it's
best,
if
well,
not
always
his
best,
but
it's
it's
better.
A
If
we,
if
we
can
use
issues
as
a
way
to
group
together,
multiple
pull
requests
right,
yeah,
I.
B
Also
wanted
to
oh
sorry,
go
ahead.
A
You
only
have
one
pull
request
for
this
back.
One
pull
request
for
the
decision
schema
and
one
pull
request
for
parser,
but
I
have
multiple
pull
requests
for
the
spec
yeah
just
for
respect
right
so,
and
none
of
them
is
closing
the
RFC.
It's
finished
in
the
IFC
right,
but
I
need
them
to
be
to
to
start
I
need
to
start
merging
them.
A
That's
the
thing
yeah,
so
I
am
unlocked,
so
I
unblock
other
people,
for
instance,
for
the
request
reply
features
they
needed
to
have
the
channels
the
new
channels
object
right
ready.
So
that's
why
I
focused
in
having
the
channels
object,
ready,
so
I,
so
I
unblock
them
to
have
request
reply,
but
it's
not
the
only
change.
A
It's
multiple
changes.
We
can
always,
of
course
say
that
we
have
multiple
rfcs,
but
in
the
end
it's
just
one
RFC,
which
is
like
it's
all.
Public
subscribe,
profusion.
B
Make
sense
since
Magic's,
not
here
I,
did
want
to
ask
him
of
the
status
of
this
change.
What
is
blocked
at
the
moment,
because
I
don't
have
any
idea,
but
I'm
gonna
get
back
to
him
in
the
issue
itself
then,
and
ask
there.
B
Just
quickly
we
talked
about
this.
This
problem
about
at
least
I,
think
or
think
friend
thinks,
as
well,
without
putting
words
in
your
mouth,
that
we
kind
of
need
a
new
referencing
standard
in
order
to
reference
portable
effects,
ML
and
X
like
a
non-json
standards.
Basically-
and
we
have
a
lot
of
discussion
going
on
in
the
pull
request
itself,
but
we
actually
don't
have
any
I
can't
remember
if
we
have
an
issue
for
it
specifically.
B
So
a
lot
of
the
discussion
is
happening
in
the
pull
request
itself,
so
yeah
I
think
I
still
either
need
to
find
an
issue
or
or
create
one
and
I'm
not
sure
where
to
take
the
the
discussion,
whether
to
pull
everything
into
the
issue
or
whether
to
keep
it
in
the
pull
request
and
just
keep
it
already.
A
That
that's
exactly
my
point
like
so,
for
instance,
to
allow
reference
in
non-json
structures.
You
don't
only
need
to
introduce
a
new
schema
reference
in
standard.
You
need
to
do
more
stuff
right
just
on
the
spec,
without
even
looking
at
other
stuff,
so
you
probably
will
have
multiple
pull
requests
on
the
spec.
Only
right
I
mean
strictly
speaking,
we
can.
You
can
create
another
branch
that
will
be
the
branch
of
this
specific
RFC
that
will
be
in
sync
with
next
major
spec.
A
That
will
be
in
sync
with
master,
but
long
I
mean
you
know,
you've
seen
what
happens
with
long-leaf
branches.
You
know,
there's
sync
issues
and
you
know
conflicts
and
so
on.
So
so
I
don't
really
recommend
having
long
leaf
branches
because
they're
paying
to
maintain.
We
need
it
for
the
next
major
version.
That's
okay,
but
I
I
will
not
continue
creating
deeper
a
lot
of
different
branches.
Okay,
so
that's
why
I
was
I
was
saying
that
we
probably
have
to
change
the
the
way
we
handle
this
yeah.
A
In
any
case,
the
the
the
branch
that
released
branches
is
unstable
by
definition
in
the
meantime
right
it's
so
we
can
merge.
I
can
complete
things.
It's
okay,
as
long
as
once
we
finish
the
RFC,
it's
complete.
It's
finished
it's
done
right,
but
in
the
meantime
it
can
contain
incomplete
changes
right.
So
though,
so
we
don't
keep
creating
more
stuff
or
we
don't
create
a
huge
pull
request
with
all
the
changes
right
so
yeah
so
yeah
up.
B
A
B
Then
we
have
some
stuff
from
metrics
as
well
about
improving
components
or
what
can
be
defined
within
them.
It's
also
missing
an
issue
I'm
pretty
sure
it's
from
another
issue
where
it
was
talked
about
and
then
kinda
agreed
upon,
and
then
the
pull
requests
were
created.
B
So
yeah
same
issue
here:
I
still
need
to
get
an
overview
from
Magic.
What
is
missing
from
from
here
whether
something
is
blocked.
We
have
the
same
issue
with
something
about
cleaning
up
the
root
object.
Where
he's
proposing
to
move
tags
and
external
talks
into
the
info,
please
still
missing
an
issue.
There
still
need
to
ask
the
status
of
this
and
what's
missing,.
A
There's
one
this
one
that
are
just
a
single
pool
request
per
Reaper
I
think
that
these
are
fine.
If
they
don't
have
a
an
issue.
I
think
that's!
Okay,
right!
You
can
use
the
one
on
the
spec
as
the
issue.
If
you
want
to
hold
the
discussion,
but
but
if
you
need
to
have
multiple
pull
requests
per
repo,
then
I
will
create
a
means:
okay,
right
right.
B
Proposals
to
allow
defining
schema
formats
other
than
the
default
one,
so
this
one
is
a
big
bit
tricky
and
it's
it's
a
shame.
Magic
system
here,
but
I
would
I
would
propose
that
we
scale
this
one
down
to
not
include
to
not
include
examples
such
as
how
you
can
Define,
protopoff
and
etc,
etc,
because
you're
you're
trying
to
grab
two
issues
one
you
want
to
move
schema
format
into
the
schema.
B
B
Basically,
supporting
non-json
structures,
which
I
think
is
too
much
for
this
specific
change,
which
is
why
I
basically
think
it's
what's
related
to
this
one
and
needs
to
be
moved
towards
that,
so
this
change
is
focusing
solely
on
moving
schema
format
from
message
to
schema.
That's
my
suggestion,
at
least
in
order
to
keep
it
as
simple
as
possible.
A
Yeah
it
can
be
referenced,
it
should
be
possible
to
inline
it
usually
yeah.
Of
course,
I
agree,
that's
a
big!
This
will
keep
it
simple
and
I
don't
recall.
Maybe
you
do
I
think
we
once
discussed
that
this
is
probably
a
very
complex
issue
for
version
three,
that
we
don't
want
to
solve
it
on
version
three
or
maybe
anyway.
We
need
to
discuss
this
somewhere,
probably
on
the
on
the
pull
requests
or
issues.
A
It
has
an
easy
perfect,
so
so
yeah
because
I'm
not
sure
yeah,
it
will
create
a
another
breaking
chain
if
we,
if
we
add
it
in
the
future,
so
yeah
actually
so.
B
If,
if
we
just
talk
about
whether
we
can
reference
an
inline,
non-json
structures,
for
example,
if
that's
the
change
to
talk
about,
then
it
doesn't
necessarily
have
to
be
a
breaking
change.
I'm,
pretty
sure
we
agree
that
it
would
just
be
a
future
change,
because
we
are
basically
just
allowing
extra
stuff
to
be
defined.
A
B
A
B
A
I
mean
that
the
other
one
I
mean
this
one
plus
schema
format,
move
schema
format
to
schema
object.
This
is
gonna,
be
a
breaking
change.
Yeah.
Yes,.
B
A
C
A
We
don't
want
to
create
yet
another
breaking
change
right
after
we
ship
version.
Three
I
mean
we
okay.
If
we
do
it,
but
but
we
do
it
because
we
didn't
expect
it,
but
if
we're
already
expecting
it
okay,
so
we
shouldn't
leave
it
out,
but
yeah
I
fear
that
this
is
gonna.
Take
long.
B
B
Yeah
I'll
contact
magic
to
see
what
what
exactly
we
are
going
to
do
there.
Okay,
publish
confusion
yay,
so
this
one
about
making
the
field
optional.
Let's
take
that
first,
because
I'm
pretty
sure
this
is
solved.
This.
B
A
This
one
is
about
optional,
okay,
okay,
adoption.
A
Why
you
can?
Because.
B
C
But
should
we
close
before
I
mean
I
am
a
bit
confused
so
should
we
close
it
before
implementing
it
or
not
implementing
it,
but
before
releasing.
A
Yes,
that's:
let's
follow
the
same
process
that
we
do
with
normal
releases
if
it's
implemented.
If
it's
done,
if
it's
merged
to
the
release
branch,
which
is
the
case,
then
we
close
it
in
this
case.
In
this
case,
it's
missing
the
Json
schema
implementation.
I
already
have
it.
I
already
have
the
pull
request,
but
but
it's
not
yet
merge.
A
C
And
this
is
something
this
is
something
we
have
been
discussing
some
time
and
it's
it's
confusing,
because
when
we
do
release,
we
don't
close
the
issues
until
we
merge
the
release
PR,
so
the
one
that
holds
my
thing
I
think
it's
the
one
that
holds
the
spec
changes
right.
No.
A
We
do
like
in
some
I
mean
some
of
the
changes,
for
instance
in
2.5
right
now.
Some
of
the
changes
don't
have
an
issue
they.
They
only
have
a
pull
request.
If
you
merge
the
pull
request,
it's
already
closed,
so
we
are
actually
closing
and
if
the
in
the
pull
request,
it
says,
resolves
or
closes
the
whatever
issue,
it's
going
to
close
it
before
we
release.
A
I
cannot
guarantee
that
this
is
happening
always
but
I'm,
pretty
sure
that
most
of
the
time
is
like
this
and
there
and
there
are
cases
where
there
are
no
uses
this.
Just
it's
just
a
pull
request
and
the
discussion
happened
over
happens
over
a
pull
request.
Once
you
merge.
It
is
closed.
B
Not
if
it's
merged
within
a
next
Branch,
damn
it
yeah.
B
A
A
B
French
there
it
does
it
automatically,
okay,
so
moving
on,
because
we
have
a
lot
of
other
things.
Yeah
the
channels
be
identifier,
sorry.
A
A
So
what
else
but
yeah
it's
not
closed.
Obviously,.
A
Yes,
what
else
so
RFC
2
it
means
finished
changes
to
the
spec
addresses
move
to
a
new
field.
That's
done
so.
It's
rfc2,
RFC
2
is
complete
as
well.
A
A
But
because
that
this
is
not
the
the
pull
request,
this
is
not
the
pull
request,
so
these
ones
will
be
closed
and
we
should
be
referencing
the
the
one
that
I
created.
C
C
A
Then
I
should
reopen
the
other
one
yeah,
the
Phantom
of
look
at
Lucas
you're
in
the
cold
start
talking
on
Slack.
C
A
A
It's
adding
this,
you
know
like
channel
that
channels
be
identified
by
an
ID
rather
than
the
address.
B
A
A
A
But
I
think
it's
just
a
missing
Champion:
that's
it
I
can
do
it,
but
can
promise
I'll
have
time
during
this
cycle
yeah
but
yeah.
If
not
I
can
take
it
for
the
next
cycle
and
that's
it.
A
A
B
I
tried
to
figure
out
what
exactly
is
blocking
any
progress,
but
the
only
thing
I
could
figure
out.
Was
this
channel
object
and,
yes
channels
be
identified
by
ID
rather
than
address
and
I'm,
not
sure
about
how
those
things
this.
B
Okay,
so
right
now
anything
else,
that's
blocking
it
or
should
she
be.
B
A
B
B
B
Then
we
have
this,
it's
kind
of
something
that
has
been
on
the
back
Banner
for
some
time
now,
where
it's
it's
kind
of
two
things
we
did
something
in
2.3,
which
deprecated
some
fields
and
now
in
3.0
we
have
to
remove
some
stuff.
As
I
understand,
we
already
have
the
changes
and
I'm
pretty
sure
they
already
have
been
merged
as
well.
B
A
Yes,
yes,
it's
an
implementation
change
as
well,
but
I
think
that
will
be
also
covered
by
my
chance,
because
I
removed
the
dollar
rep
on
purpose.
So,
okay
yeah
my
pull
request
with
the
new
channels
object:
it
doesn't
contain.
It
doesn't
give
you
the
possibility
to
and
you
can
use
dollar
ref,
but
dollar.
Ref
is
not
part
of
the
list
of
properties
that
you
can
use
yes,
okay,
perfect,
so
so
yeah,
okay,
so
this
is.
This
will
be
complete.
A
B
B
Okay,
so
yep,
so
this
one
is
ready
whenever
that
PR
is
done.
I'm
gonna
change
these
as
well
so
I
added
this
back
for
another
stuff,
which
is
basically
all
the
issues
that
well
there
isn't
any
specific
progress,
but
we
need
to
keep
in
track
in
terms
of.
Is
there
anything
we
need
to
to
bring
forward
again.
B
But
yeah
it's
basically
just
all
all
the
issues
that
has
no
progress,
then
I
started
adding
this
completed,
basically
moving
all
the
things
that
we
have
up
in
progress
whenever
things
are
completely
done
in
order
to
to
basically
show
what
we
are
working
on
and
have
that
concise
into
just
one
specific
section.
A
C
C
It's
about
schema
servers,
operations
and
messages
Collections,
and
it's
about
what
what
is
used
for
you
by
your
application.
What
is
not
any
use
by
your
application?
So
we
want
to
let
users
to
filter
those
collections
by
whatever
is
being
used
in
your
application
or
not
right.
So
this
has
a
strong
use
cases
behind.
C
So
that's
almost
kind
of
I
I,
don't
want
to
say
decided
because
it
never
is
decided,
but
we
are
trying
to
figure
out
what
is
the
best
implementation
for
the
Quran
for
the
current
spec
for
v2
of
those
of
those
sorry,
the
implementation
in
Departures.
Yes,
I
mean
of
those
methods.
C
Besides
that
this
is
what
I
said.
It's
blocking
another
pull
request
that
it's
one
one
program
with
a
couple
of
fixes
on
on
some
methods
and
that's
all
the
only
missing
would
be
visiting
the
readme
a
bit
and
the
migration
guide.
So
it's
all
about
documentation
or-
and
that's
all.
Theoretically,
everything
should
be
with
that,
of
course,
after
that,
so
we
will.
We
will
release
this
and
we
will
start
working
on
the
generator.
C
The
templates,
blah
blah
blah
blah,
but
in
terms
of
password
I
will
I
would
say
that
it's
going
to
be
like
I
expect
for
the
next
meeting.
We
could
do
some
kind
of
like
an
announcement
and
the
speech
will
be
something
like
hey.
We
release.
Please
try
out
yeah,
that's
it
nice.
A
That's
really
cool
yeah,
we're
very
close,
it
seems
so
one
thing
that
I
will
suggest
is
once
you
think
it's
stable.
It's
only
lacking
with
me.
For
instance,
I
will
suggest
that
you
tell
us
like
hey
this.
It's
only
missing
some
readme
changes
and
so
on.
So
you
can
already
work
on
top
of
this.
A
And
also
I
guess
this
is
only
working
with
version
two,
as
you
said,
right
three
or
a
potential
version
three
right
so.
A
Yeah,
so
there
is
another
branch
which
is
next
major
spec
right,
which
is
so
if
I
want
to
introduce
something
as
part
of
my
rfcs
on
the
on
version
three,
what
do
you
think
should
I
do?
Should
I
merge?
That's
a
good
question:
it's
like
emerging
next
major
Insight.
Next
major
spec
branch,
yeah.
C
In
that
case,
yes
and
and
I
think
it's
easy
to
understand.
No,
we
are
doing
two
versions
right
of
the
parser.
One
is
a
major
version
and
another
related
to
a
major
spec
person.
C
A
Right,
so
that's
that's
why
so?
Yeah,
okay,
okay,
so
yeah
I
need
to
have
a
look
at
that,
because
that's
part
of
the
the
rfcs
that
I'm
working
on
the
channels
and
the
operations
and
moving
operations
to
the
roots.
A
C
Easy
than
what
what
do
you
think?
Because
there
is
already
a
directory
where
you
will
have
to
implement
the
the
an
interface
that
in
the
interface
is
already
created.
So
you
will
just
have
to
implement
these
interfaces
and-
and
that's
all
perfect.
A
So
then,
then
it's
just
that,
like,
if
I,
have
to
add
new
interfaces,
I
will
I
will
have
to
do
it
on
the
parser
API
repo
as
well
right
and
on
the
parser
J.
Yes
right.
C
A
A
But
the.
C
Good
point:
I'm.
Sorry!
Oh
sorry,
what
I
was
about
to
say
the
good
point
of
you
working
on
this
is
that
you're
gonna
be
our
early
adopter.
You
know
it's
like
you're
gonna
put
this
like
under
under
stress
in
validate.
If
the
API
worked
in.
A
A
I,
don't
think
so,
I
think
it's
I
mean
it's
gonna
I
mean
we're.
Gonna
put
it
under
stress
to
some
degree
because
we're
gonna
test
how
well
it
will
map
to
another
version
of
the
spec,
but
a
completely
different
version
of
the
spec,
but
well
I
think
it
should
be
stressed
with,
is
with
pulling
like
the
templates
or
or
with
I,
don't
know
with
Glee
or
templates
or
whatever
some
or
studio
right,
so
regenerator
templates.
So
there
is
where
we
will
see
if
it
really
has
all
the
things
that
we
need.
C
The
point
on
that
is
that
the
good
point
is
that
we
did.
We
tried
Jonas
and
I
when,
when
we
started
designing
this
new
API
that
it
was
based
on
those
templates
yeah.
So
hopefully
we
want.
We
won't
have
that
that,
but
yeah
I
agree
that
the
templates
are
the
real
use
users,
let's
say
yes,.
A
B
B
There
is
some,
but
it
hasn't
been
released
yet
has
it
on
the
next
branch?
No.
C
Let
me
see,
but
it's
fully
functional,
so
you
could
start
working
right
now.
There
is
only
one
missing
thing
that
you
can
reach
it's
about:
how
to
get
all
the
schemas.
C
B
C
B
B
C
I
mean
there
is
one
bug
that
we
know
as
says,
and
there
is
one
missing
feature
so
at
the
end
we
could
release
it,
but
I
would
I
would
say
I
I
would
at
least
wait
for
that
to
be
merged.
Maybe
why?
Because
I
want
so
when
to
start
like
reporting
this
back,
when
we
already
discover
that
I
don't
know,
I
I
know
I'm
open
to
suggest
it.
A
A
It
is
at
least
it
contains
at
least
the
same
amount
of
features
as
as
previous
version
and
from
now
and
from
there
we
can
keep
adding
whatever
features
we
want
on
2.1,
2.3,
2.6,
right,
whatever
and
also
fixing
bugs,
but
if
yeah,
if
the
feature
wasn't
present
on
the
on
the
previous
version,
we
don't
have
to
wait.
C
Don't
it
is
missing,
it's
missing:
I
I
I
put
the
pull
requests
in
and
so
I'm
gonna
paste
it
in
YouTube
as
well
the
schemas
method.
It
was
missing
because
we
let
it
for
almost
the
end
because
we
needed
to
solve
other
things
previously
and.
C
But
this
one
is
blocked
by
the
other
one
kind
of
like
blocked,
not
100,
but
kind
of,
because
we
want
to
review
the
job
twice
and
because
it
was
a
discussion
and
I'm
going
discussion
how
to
solve
it.
We
put
on
all
these
ones.
A
Well,
in
any
way,
it's
I
don't
think
we're
far
from
releasing
already.
So
let's
fast
track
this,
if
you
need
approvals
on
on
these
pull
request
and
and
you're
waiting
just
for
for
approvals
or
something
that's
just
let
us
know-
and
let's
fast
track
this,
because
in
the
end
it's
just
like
Jenna
said:
if
we
make
a
mistake
or
introduce
a
bag
or
something
like
that,
we
fix
it
later
and
that's
okay.
We
will
anyway,
introduce
backs
so
so
yeah.
So
who
cares
if
it's
known
or
unknown
yeah.
A
A
A
Like
I,
don't
know
how
to
define
this
because
yeah,
it's
a
it's
going
to
be
a
pain
like
how
to
like
how
to
fly,
not
black,
but
how
to
direct
like
it
should
be.
It
will
use
this
implementation
or
this
other
implementation
right
so
yeah
anyway,.
B
C
C
This
should
be
reviewed
and
merged,
and
theoretically
this
would
be
reviewed
emerged
before
parser
GS
implementation
happens.
Right,
I
agree
that
we
are
mixing
here
because
an
exception.
This
is
the
first
time
we
do
this.
This
is
the
first
time
we
are
implementers
of
of
parser
API
yeah.
A
B
A
B
A
I'm
excited:
that's
the
only
thing
that
I
want
to
share.
I'm
freaking
excited
excited
that
I
see
this
moving
forward
and
it's
I'm
already
able
to
play
a
little
bit
with
version.
Three.
That's
gonna
be
cool.
A
Definitely,
definitely
at
some
point:
I'm
gonna
start
integrating
a
future
version
or
release
candidate.
If
you
want
of
Studio
with
the
new
parser,
the
new,
with
support
with
the
news
for
the
new
spec
and
so
I
can
start
playing
on
Studio
right
and
also
some
other
some
other
tools
like
the
the
documentation
generation
or
the
react
component,
so
so
that
I
can
play
with
it
there
and
see
how
it
goes
so.
Yeah,
let's
be
excited.