►
From YouTube: AsyncAPI spec 3.0 meeting
Description
A
And
we're
live
nice
welcome
everyone.
So
I'm
meeting
in
the
hot
summerslam
we
have
a
few
things
on
the
agenda
today,
but
since
fran
is
not
here
to
update
us,
we're
gonna
do
something
else
to
begin
with.
Does
any
of
you
folks
have
anything
you
want
to
add
to
the
agenda
or
ask
or
something
to
discuss,
not.
A
A
Because
it's
directly
directly
related
to
some
of
the
prs
that
are
currently
in
the
process.
Correct
me
if
I'm
wrong
so
go.
A
C
Yeah
there
is
some
work
that
frank
is
doing.
Let
me
try
to
find
him.
C
C
As
always
trade-offs,
you
know
in
the
previous,
I
think
it
was
in
the
previous
version
on
two
three
zero.
I
don't
remember.
We
decided
to
go
with
this,
adding
channels
to
sorry
servers
to
channels
the
servers
fields.
The
servers
feel
to
channels
where
you
can
specify
that
the
channel
it's
only
at
least
tied
to
a
to
a
server
right.
C
C
C
I
think
it
was
simplicity
and
to
kind
of
set
a
global
concept
of
ids
right,
like
each
object,
has
an
id
something
like
this,
which
at
the
same
time,
because
for
example,
we
say
that
whenever
you
use
a
reference
that
this
is
just
a
json
pointer.
So
if
you
change
for
some
reason,
the
place
where
you
are
defining
that
this
pointer
changes.
C
A
C
C
C
A
Since
magic
is
not
here
there,
I
guess
there's
no
updates
for
one
of
the
made
up
major
points
that
we
discussed
last
time
regarding
defining
this
custom
format
for
schemas.
A
Still
magics
don't
think,
there's
any
updates
there
for
now
right.
One
of
the
changes
that
are
being
that
I
have
suggested
for
our
json
schema
files.
That's
validating
the
the
spec
documents
is
to
include
bindings
and
I
proposed
a
setup
where
so
at
the
moment,
bindings
only
have
one
version.
Basically
like
we
only
save
one
version
in
the
bindings
repository
that
doesn't
exist.
A
A
And
that's
kind
of
the
reason
why
we
want
to
keep
all
of
the
versions
there,
so
the
spec
documents
can
can
reference
whatever
binding
versions
make
sense
for
that
version
of
the
spec.
A
So,
yes,
I
made
the
suggestion
for
or
made
an
example,
basically
for
the
mqp
bindings
and
then
integrate
them
into
the
spec.
3.0
json
schema
documents,
so,
for
example,
here
it
then
validates
against
0.2
of
mqb
channel
bindings,
and
this
is
done
without
parsers
having
to
change
anything
regarding
their
implementation.
C
A
C
A
C
Just
to
just
one
file
for
the
major
spec
person
you
know
like
for
3.0,
you
will
have
like
an
nqp
json
where
you
have
the
one
off
there.
You
know,
because
it's
gonna
be
the
same.
Always
should
be
right.
I
guess
it
should
be
compatible
with
any
three
dot.
Whatever
version.
A
A
A
Where
you
can
reference
one
file
for
all
of
the
versions
within
that
major
version
right,
but
like
yeah,
I
think
we
can
do
it
regardless
and
then
create
an
like.
You
can
still
create
a
file.
That's
for
3.1,
then
right
whenever
that
happens,
that
they
are
not
compatible
with
each
other,
because
it
does
make
sense
that
for
each
spec
version
that
you
don't
have
to
change
that
much
regarding
bindings,
they
are
just
there,
for
example,
for
two
and
three.
C
C
A
A
B
A
And
this
means
that
we
can
still
add
bindings
for
each
one.
So,
each
time
this
happens,
we
can
still
do
this
and
we
don't
have
to
change
anything
regarding
the
spec
documents
whenever
it
happens,
because
these
are
specifically
for
version
three
of
the
spec.
That
might
might
be
a
good
idea.
C
C
C
Yeah,
the
point
is
that,
in
order
to
to
make
a
document
valid,
you
would
need
not
to
make
a
document
valid.
It's
just
to
link
your
document
with
the
right
binding.
You
will
need
a
match
of
a
person
if
you
go
up
in
the
example.
I
think
I
brought
it.
I'm
not
certified,
maybe
not.
A
C
So
if
you
have
a
document
that
is
using,
I
don't
know
the
binding
a
amqp
or
something
with
version
1,
0
0,
and
we
don't
have
the
binding
version
documents
and,
for
example,
we
release
the
next
version
of
the
binding,
which
is
2.0,
makes
a
breaking
change
of
the
binding.
A
It's
also
a
problem
about
knowing
which
versions
like,
for
example,
let's
say
that
you
have
for
let's
say
you're
using
spec
2.0,
and
you
have
two
major
versions
that
you
can
choose
between
like
the
latest
assumes
the
newest.
A
C
C
B
What
can
I
say
like
the
binding
will
start
with
the
version
and
then
inside
the
version
object.
You
will
have
the
rest
of
the
fields,
so
the
version
is
still
there
right
thing
is
that
you
might
be
wondering
then
oh
cool.
So
then,
when
we
get
the
version,
sorry
the
binding
itself,
without
the
version,
when
we
get
the
inner
fields,
then
the
version
is
not
there
anymore.
A
B
B
Yeah
I
mean,
if
I
see,
can
you
show
me
an
example,
jonas
of
what
you
were
proposing?
Yes,.
A
A
A
B
C
But
jonas
anyway,
that
it
that
comes
to
to
my
previous,
the
previous
talk.
If
we
were
with
a
topic
we
was
we're
discussing
come
on,
I
cannot
speak
today.
I
don't
know
what
happened
to
my
tongue.
C
C
A
Micro
versions,
not
on
minor
versions,
but
when
you
assume
latest,
let's
say
that
you
have
aspect
3.0
document
and
you
have
this
list
of
bindings
for
amqp,
then
all
of
the
sudden
for
spec
3.0
braking
change
is
introduced
for
the
amqp
bindings,
because
people
want
to
move
things
around
because
it
makes
whatever
reasons
there
might
be.
Then,
all
of
a
sudden,
you
have
two
major
versions
within
3.0
and
if
you
assume
latest
you
do
not
know
what
latest
do
you
mean
the
latest
of
version?
A
B
C
C
A
A
We
have
to
look
at
that,
but
it's
going
to
be
beyond
the
scope
of
this
specific
pr,
so
might
be,
let's
see
if
it's
get
accepted
as
soon
as
dale's
comment
for
for
whether
we
want
this,
and
if
we
want
this,
then
we
need
to
create
the
follow-up
issues
regarding
the
binding
versions
and
the
latest
keyword
all
right
anything
else
for
this.
Before
moving
on
to
friends,
issues.
C
C
C
C
C
A
C
A
You
I
know,
you're
gonna
have
some
problems
with
this,
because
the
underlying
issue
is
that
there
are
no
reports
or
there
is
no
library
that
can
help
you
with
this
there's.
Currently,
no
library
that
can
dereference
correctly
json
schema
files
when
they
are
within
async
api
or
open
api
documents.
C
A
C
B
I
will
even
say
that
the
only
thing
that's
really
needed
is
the
new
api
right
is
this
that
I
mean
like
really
really
needed,
because
then
yeah
there
might
be
some
breaking
changes
here
and
there,
but
that
they
shouldn't
be
hard
to
to
change
in
the
user
base
code
right
and
they
use
code
base.
Sorry
so
so
yeah
like,
I
think
the
major
change
here
is
the
api.
B
So
as
long
as
the
api
is
like
stable
the
rest
of
the
things
like,
how
do
we
resolve
the
ref
links
and-
and
how
do
we
do
this
and
that,
like
side
effects
of
things
that
if
it
keeps
being
like
it,
is
right
now?
It's
it's
not
perfect,
but
it's.
I
would
say
it's
less
important
right.
Four,
four
versus
three,
because
what
we
want
to
avoid
with
this
new
parser
version
is
that
when
people
migrate
to
this
parser
and
then
we
release
version
3,
they
will
have
almost
no
change
to
doing
their
code
base.
B
C
I
agree
in
fact
I
I
told
magic
to
meet
again
virtually
like
we
can
do
it
like
on
a
string.
In
fact,
it
would
be
nice
to
do
a
streaming
on
it
to
again
review
this
list
and
try
to
remove
more
things,
but
not
sure
when
it
will
happen.
Probably
next
week
or
the
other.
B
A
B
No,
I
just
want,
I
mean,
I
know
that
some
people
see
this
issue
as
an
as
a
new
thing.
Like
frank,
keeps
inventing
things
for
3-0
right,
I'm
looking
at
you,
jonas.
B
B
We
didn't
come
up
with
any
conclusion
in
the
end
like
something
that
I
think
the
conclusion
was
like.
We
don't
want
to
fix
it
now,
but
because
we
didn't
have
a
good
idea,
I
would
say
like
something
that
we
wanted
to
aim
for
so
so
yeah
like
I
was.
I
was
hoping
that
we
can
still
give
it
a
chance,
and
this
is
precisely
this
so
and
the
another
thing
is
like
we.
I
think
what
happened
with
the
many
meanings
of
this
kpi
documentary
file
is
that
we
were.
B
So
it
defines
an
application
and
the
other
meaning
is
is
a
like
a
list
of
things
like
a
menu
like
a
like
a
library
of
objects
that
you
can
reuse
from
other
smgb
files
right-
and
this
is
the
one
that
I
want
to
target
here.
So
I
called
it
domain
specificate
domain
specification,
but
it
is
nothing
else
than
formalizing
what
people
are
already
doing,
which
is
extracting
stuff
into
json
files
or
demo
files,
and
they
put
it
there.
This
yaml
file
contains
all
the
common
objects.
B
Let's
give
it
a
structure,
let's
give
it
a
formal
definition
right,
so
so
yeah,
so
so
with
this
change.
What
I
wanted
to
do
basically
is
in
in
general.
Let's
say
I
don't
want
to
get
too
much
into
the
into
the
details
is
moving
things
like
if
the
server
is
a
broker,
we
want
to
put
it
on
the
brokers
here
right.
I'm
gonna
skip
this
because
that's
another
discussion
like
if
it's
to
be
it's
an
api
domain
or
what
I
don't
care.
B
Can
just
call
it
something
else
or
just
async
api,
we'll
see
in
the
end.
I
didn't
change
it,
but
I'm
I
thought
it
better
and
I
think
the
info
object
can
be
the
same
as
the
application,
the
current
one
that
we
have,
so
it
doesn't
have
to
be
any
different
and
actually
yeah.
I
say
it
here
like
or
maybe
we
can
just
use
the
same
one
right.
B
I
made
a
differentiation
which
is
part
of
the
another
thought
that
I
had
at
the
same
time,
which
is
separating
brokers
and
servers.
So
http
and
websocket
servers
on
one
side
and
brokers
on
another
side.
B
Might
be
the
case
or
might
not,
so
it
means
that
this
may
be
combined
under
servers
or
we
can
split
it
on
brokers
and
servers.
That's
I
just
wanted
to
leave
it
there
as
a
proposal.
That's
a
another
proposal.
That's
a
way
to
think
about,
so
people
will
want
to
have
channels
defined,
so
they
can
point
to
channel
definitions
from
multiple
asynchrony
files
in
their
company.
B
So
that
way
they
can
reuse
the
channels.
That
seems
to
make
sense.
That's
what
actually
that's
what
people
are
doing
right
now,
but
they
put
subscribe
or
publish
and
they
ignore,
publish
and
subscribe,
and
that's
it
so,
but
that's
that's
pretty
much
broken
and
then
messages
and
other
stuff
right
so
and
components
might
have
schemas
and
not
many
other
things,
probably
just
security
stuff.
B
No,
there
are
no
traits
here
at
all.
I
don't
know
yeah.
There
will
be
trades
here,
yeah,
I'm
not
I'm
wrong
yeah.
So
there
will
be
trades
here.
So
everything
can
be.
It
is
pretty
much
anything
gpa
document
it
just
doesn't.
Have
it
just
doesn't
have
operations,
it
cannot
have
operations
right
because
yeah,
it's
a
list
of
things.
It's
a
library,
it's
not
an
application,
so
it
does
nothing.
It's
not
an
entity
per
se
right.
B
So
it's
like
a
collection
of
entities
so
so
for
those
who
want
to
define
the
broker,
for
instance,
all
the
channels,
all
the
messages
flowing
around
in
their
company
and
so
on
and
they're
not
interested
in
one
in
what
which
and
what
a
specific
application
does.
Then
they
can
be
just
using
this
right.
B
So
so
yeah
from
an
async
api,
let's
say
the
current
assumptive
point
of
view.
It
will
be
something
like
this
like
we
can
specify
that
there
is
a
domain
that
we
will
be
using
and
and
then
we
can
be
referencing
stuff,
like
this
like
pointing
to
specific
domain
right
like
domains,
global
servers,
blah
blah
blah.
This
is
defined
on
the
other
file
right.
All
this
stuff
is
defined
on
the
other
file
we
can,
or
we
can
be
depending
on
in
line
here
and
so
on
thing.
B
Is
that
not
many
things
change
here?
The
only
thing
that
changed
is
that
all
stuff
that
it's
common,
that
is
common
to
a
specific
application
right
like,
for
instance,
if
I
have
a
websocket
api,
I
am
the
websockets
api,
I'm
the
websocket
server.
So
I
am
I'm
defining
my
my
websocket
server.
B
B
Then
it
will
go
here
right.
It
will
go
in
the
domain
specification
because
it's
not
part
of
a
specific
application.
It
is
a
shared
resource
across
applications
right.
So
that
is
the
main
distinction
here,
like
whatever
is
part
of
my
something
that
I'm
serving
myself,
I
create
a
channel.
I
I
am
the
server.
I
am
the
broker,
if
you
want,
if
I
am
my
application,
is
not
just
an
application
but
also
the
broker
like
in
the
case
of
web
sockets
or
http,
then
I
mean
http
servers
and
events
as
well.
B
Then
it's
like
it
belongs
to
the
application
right.
It's
a
channel
that
the
application
is
exposed
right.
B
I
hope
that
you
can
hear
me
and
it
is
not
a
problem.
Coffee.
A
B
So
so
yeah
lucas
was
suggesting
that
we
don't
create
another
another
spec.
Instead,
what
we
do
is
it
is
something
that
I
that
made
me
actually
implement
this.
This
new
proposal,
which
is.
B
We
leave
it
as
a
as
an
sync
api
document,
say,
for
instance,
here
right,
so
it's
the
same
right,
but
the
meaning
of
the
document
changes
based
on
the
existence
of
the
operations.
Keyword
like
it
exists
or
not
right.
If
it
exists,
it's
defining
an
application.
If
it
doesn't
exist,
it's
defining
a
domain
or
a
library
of
objects.
B
I
mean
we
can
go
this
way
of
course,
but
it's
implicit,
it's
not
explicit
right,
so
it
is
something
it
will
be
weird
that
just
because
I
remove
this,
then
I'm
not
defining
an
application
anymore,
I'm
defining
a
domain
right.
That
would
be
super
weird.
So
at
least
to
me
like,
like
it
is
an
implicit
change
that
I'll,
I
don't
think
anybody
will
be
expecting
just
because
I'm
removing
this.
It
changes
the
meaning
of
the
whole
document
right.
So
another
solution
that
I
came
up
with
today.
B
Actually
thinking
about
it
is
that
we
don't
create
a
new
spec.
We
just
add
a
new
field
here
right,
which
is
something
like
kind,
something
like
that,
and
then
we
make
it
one
kind
of
the
other
right.
If
we
made
a
default
like
if
there's
no
kind,
it's
an
application,
if
kind
is
is
domain,
then
the
whole
document
is
a
domain
defines
a
domain.
B
No,
not
an
application,
not
ideal
to
me,
but
at
least
it's
explicit
right,
it's
a
if
it's
a
domain,
it's
being
defined
there
explicitly,
but
this
is
a
domain
document
right
and
for
the
majority
of
cases
we
just,
which
is
the
application,
the
majority
of
cases
would
be
people
defining
applications
right
because
it's
obvious,
like
multiple
applications
using
a
single
common
file
right
in
single
domain,
so
the
majority
of
cases
it
will
be
an
application,
so
we
can
default
to
application
right.
B
B
It
was
included
it's
there
in
the
proposal
like
if
it's
it's
it's
it's
within
there
like
there.
It
means
if
it's
not
there,
it
means
something
else.
So
so
it
was
there
probably
a
notice,
because
it's
not
something
you
would
expect
so,
but
it
was
there.
It
was
different
there,
so
so
yeah.
I
would
love
to
have
this
song
for
3.0,
because
that
is
for
me.
A
B
B
Yes,
like
you
know
it's
it's
already
appearing
too
many
times
like
hey.
I
don't
want
to
define
an
application.
I
want
to
define
a
library
of
things.
Yes,
what
people
are
doing
currently
is.
They
are
misusing
async
api
to
to
make
it
to
make
it
work.
B
Luca's
suggestion
is
that
we
we
kinda
let
them
misuse
it
like.
Okay,
let
people
misuse
stuff
and
and
see
where
it
goes.
If
I
understood
correctly,
I
cannot
speak
by
by
lucas,
but
that's
what
I
understood.
B
I
say
that
between
going
for
a
new
spec
and
making
it
implicit
with
with
operations
keyword,
we
can
have
like
a
whole
like
a
middle
solution
right
like
which
is
like
not
ideal,
but
at
least
we
make
it
explicit
so
so
yeah.
So
we
just
by
inspecting
the
kind
keyword
we
can
say.
This
is
an
application
or
this
is
a
or
this
is
a
library
of
things
we
can
call
it
domain.
We
can
call
it
library,
we
can
call
it
grammar,
callset
and
and
ramen
follows
this
approach
of
the
kind.
B
I
think
it's
kind
attribute
or
something
like
that,
so
so
yeah
so
yeah
I
don't
know.
I
think
this
is
something
that
it's
a
breaking
change.
So
if
we
don't
include
some
3.0,
it's
gonna
be
it's
gonna
be
introduced
for
four
point:
zero,
because
it's
the
breaking
change.
A
B
B
If
it's
an
application,
I
mean
by
default,
because
we're
generating
code
for
your
application,
that's
what
generator
does
right
so
by
default.
If
it's
an
application,
it
works.
If
it's
not
an
application,
it
will
not
work.
It's
a
library
of
things.
What
do
you
want
me
to
do?
You
might
want
to
generate
the
types
and
classes
you
know
models
and
so
on
then
modeling
might
work
with
this
kind
of
file,
like
not
application,
library
domain
called
whatever,
but
most
of
the
tools
that
we
have.
B
C
B
There
is
an
implicit
change
in
the
meaning
of
the
file
like
what
the
file
is
representing
right.
Now,
it's
representing
an
application,
and
if
you
put
kind
domain
or
kind
library,
it
will
be
representing
a
collection
of
objects,
not
an
application
or
a
domain
in
domain,
or
you
know
like.
B
The
change
is
not
really
expensive.
The
the
change
in
tooling,
I
don't,
I
cannot
think
about
like,
for
instance,
glee
generators
will
not
work
if
it's
a
if
it's
a
if
it's
not
an
application,
documentation
can
work
with
both
we'll
have
to
work
with
both
so
documentation
we'll
have
to
we'll
have
to
render.
If
it's
an,
if
it's
an
application,
it
will
make
it
explicit
like
this.
Is
the
application
blah
blah
blah
here's
what
it
does
if
it's
a
domain?
This
is
the
main
blah
blah
here.
Are
the
resources
of
this
domain.
B
Document
and
then
the
actions
sending
or
receiving
will
be
defined
on
the
on
the
applications
so
yeah,
I
don't
know
there,
there's
some
impact,
of
course
on
pulling,
but
I
don't
think
it's
a
lot
to
be
honest.
I
don't,
I
think
it
sounds
if
we
create
a
new
spec,
there's,
definitely
a
more
impact.
That's
definitely.
B
B
What
the
problem
here
is
that,
where
I
think
where
the
complexity
will
lie,
is
in
mapping
versioning
like
domain
domain,
spec
versioning
related
to
async
api
version
that.
B
You
can
split
it
in
two
specs
yeah,
then
you
will
have
to
like
so
this
async
api
domain
spec
works
with
this
async
api.
For
that's
a
that's
the
help
yeah.
B
Will
lie
in
my
opinion.
You
don't
want
that.
So
that's
why
I
was
suggesting
they're
like
let's.
I
was
saying
before,
like
let's
forget
about
this,
because
I'm
not
opinionated
on
that.
But
another
thing
that
we
could
do
is
that
this
async
api
domain
field.
If
it's
an
if
it's
a
new
spec,
it
will
be
just
the
same
number
as
the
async
api
spec
and
it
will
be
a
one-on-one
relationship.
B
B
B
C
B
Yeah
but
but
it's
a
it's
a
nif
and
and
then
it's
like,
if,
if
kind
is
application,
then
you
can
have
this
object.
If
kind
is
domain,
then
you
can
have
these
other
objects,
that's
it.
In
the
end,
it's
like
you
can
have
everything
always
except
domain.
It's
a
operations.
That's
the
only
thing
that
you
cannot
have
for
now,
right,
so
so
yeah,
and
so
the
reason
I
wanted
to
introduce.
This
change
is
precisely
to
make
this
differentiation
right
like
to
make
this
differentiation
from.
B
B
B
An
application
and
a
broker,
but
if
the
channels
leave
on
a
broker,
then
no
application
is
the
owner
right
because
there
can
be.
Someone
could
argue
that
the
publisher
is
the
owner
of
the
of
the
chat
yeah,
that's
true,
but
you
can
have
multiple,
multiple
publishers.
B
B
B
This
way
we
can
tell
people
to
yeah
like
it's
a
good
practice
that
if
you
have
certain
resources
shared
in
your
company,
move
them
to
the
main
type
of
files
right
and
if
you
have
something
specific
of
your
application,
because
you
are
the
you
are
the
the
server
and
the
broker
right
then
define
it
on
the
application
file.
That's
because
this
is
the
owner
right.
B
This
is
the
owner
of
the
of
the
channel,
so
I
don't
know
we
can
we
probably
can
think
about
not
enforcing
it
and
creating
some
kind
of
best
practice
or
good
practice,
not
best
practice.
I
had
to
say
best
practice
just
best
practice,
depending
for
what
right
so
and
so,
better
practice
or
good
practice
is
to
separate
it
and
we
can
create
a
spectral
rule
rule
set
or
something
like
that
to
to,
if
possible.
B
A
B
I
don't
know,
leave
your
thoughts
on
the
issue.
I
think
like
give
it
a
give
it
a
thought.
I
just
wanted
to
explain
it
here
live,
so
people
can
understand
a
little
bit
better,
what
I
meant,
but
but
yeah,
probably
you're
more
confused.
Now.
Sorry
for
that.