►
From YouTube: AsyncAPI SIG meeting 49 (May 25, 2021)
Description
This is the recording for the AsyncAPI Special Interest Group (SIG) meeting #49.
https://github.com/asyncapi/community/issues/27
Chat:
00:08:53 Fran Méndez: https://github.com/asyncapi/community/issues/27
00:09:01 Fran Méndez: Agenda ^
00:13:40 Lukasz Gornicki: https://summerofcode.withgoogle.com/organizations/5554758561038336/#!
00:15:10 Lukasz Gornicki: https://github.com/asyncapi/spec/issues/536
00:23:26 Jonas Lagoni: Intent API: https://github.com/asyncapi/parser-api/blob/master/docs/v1.md
Discussion: https://github.com/asyncapi/parser-api/discussions/4#discussioncomment-775939
00:41:23 Mike Ralphson: Because the intent-driven parser API will be around longer than any one version of the spec, the naming conversation becomes much more important with regard to the parser.
00:54:04 Jonas Lagoni: Framework issue: https://github.com/asyncapi/shape-up-process/issues/75
00:54:29 _acebuild: Really need to go now, guys. It's nice attending this meeting
00:54:38 Fran Méndez: Thanks, Ace!
00:58:08 Kin Lane (Postman): Lukasz is subscribed to Fran.
01:00:23 Colin Sullivan: I need to drop off for another meeting - take care all!
A
A
B
C
A
A
A
A
D
A
D
D
E
D
D
So
many
people
are
joining
come
on
so,
as
usual,
we
start
with
a
hello
and
reminder:
please
keep
in
mind,
this
call
is
being
recorded
and
monitored
and
it's
it's
gonna,
be
I'm
not
sure
why
I
always
think
about
recorded
and
monitored.
At
the
same
time
it's
not
monitored.
I
guess
it's
recorded.
It's
going
to
be
saved
to
youtube
for
the
future
generations
so
just
make
sure
and
to
leave.
If
you
don't
want
to
be
recorded
or
just
turn
off
the
camera
and
change
the
name.
D
D
E
I'll
go
I'm
colin
sullivan,
I'm
on
the
nats
team,
natsio
and
you
know
in
the
past,
we've
had
some
some
work
by
you
guys
for
nats
and
the
async
api.
We've
had
some
interest
in
in
some
of
our
shared
users
in
expanding
that.
So
I
just
wanted
to
listen
in
see
where
things
are
at
and
then
we
may
ask
them
to
work
on
some
contributions
or
we
will
directly
ourselves.
D
D
Open
source
organizations
can
apply
for,
for
like
propose
some
different
solutions
that
students
could
work
on
students
around
the
world
and
then
students
can
propose
solutions.
Then
google
accepts
or
not
with
the
organization
the
proposals
assign
slots
like
assign
not
sure.
What's
the
english
name
for
it,
like?
Let's
say
you
like:
an
employment
like
temporary
employment,
I
don't
think
you
can
say
it's
temporary
employment,
where
you
basically
get
a
spot
in
a
in
a
given
organization
to
work
on
something,
and
that's
then,
as
an
equivalent.
At
the
end.
D
We
were
not
accepted,
but
postman
applied
as
well
and
they
got
accepted
and
because
few
of
us
work
at
postman,
then
of
course
we
got
an
offer
from
postman
that
maybe
some
ideas
that
were
not
accepted
because
we
were
not
accepted
could
go
through
postman
and
that's
how
we
ended
up
with
ending
up
with
having
five
slots
assigned
to
us
in
the
api
organization
through
postman.
So
the
good
news
is
we're.
D
Gonna
have
five
amazing
folks
working
with
us
for
next
few
months
on
different
ideas,
and
there
is,
for
example,
aryun
that
is
on
the
call
that
will
work
on
the
and
on
the
proposal
for
asking
api
application
relation
finder.
So
a
a
library
that
can
pick
up
several
async
api
documents
and
find
relations
between
them
like
discover
channels,
relations,
publish,
subscribe,
stuff,
etc.
D
D
D
D
D
In
the
chat,
so
we,
the
cool
stuff,
is
that
we
have
like
part
of
the
automation
done.
So
we
are
ready
to
publish
the
release
artifacts
for
the
release.
Candidates
for
the
parser,
the
json
schema
and
the
spec
ayush
is,
is
pretty
advanced
with
setting
up
the
automation
of
like
let's
say
that
whenever
we
have
a
release
candidate,
we
also
get
updated
release
candidate
documentation
on
the
website,
and
we
already
have
at
least
two
candidates.
I
think
for
for
merger,
two
proposals
from
from
dale.
D
Then
please
that's
the
best
moment
to
work
on
it
to
get
it
into
two
one
release
and
if
you
don't,
if
you
think
that
some
idea
it's
already
accepted,
but
you
don't
have
time
to
add
something
in
the
parser
you're
like
super
busy,
feel
free
to
put
information
in
the
general
channel.
If
there
are
others
that
are
waiting
for
for
a
given
feature,
maybe
they
can
jump
in
and
help.
D
D
D
F
F
Like
the
main
discussion
that
me
and
lucas
have
had
so
far
and
try
and
get
your
thoughts
on
it,
actually
so
how
it
currently
is
with
our
parishes.
So
if
you
want
to
build
any
tooling
for
it
or
for
the
spec,
it
is
that
you
have.
Let's
just
say
you
have
application
a
and
you
want
to
produce
a
message
over
some
channel
to
some
external
either
broker
server,
whatever
protocol
you're
using
it
doesn't
matter
in
this
example.
B
F
F
F
D
F
It
doesn't
need
to
know
anything
about
the
the
problems
that
we
have
with
the
spec
or
how
you
actually
define
it
with
the
spec.
It
doesn't
really
matter
from
the
tooling
perspective
and
again,
if
you
want
the
external
point
of
view
and
develop
tooling,
for
that,
you
just
say:
client
subscribe
operations,
so
this
is
our
way
of
abstracting
from
the
problems
that
we
have
with
the
specification.
D
Yeah
yeah,
so
the
I
think
the
car
here
is
of
the
discussion
we
are
having
there
and
it
would
be
nice
if
more
than
two
people
involved
in
the
discussion,
because
I
think
the
parser
api
is
pretty
crucial.
But
the
main
like,
like
main
place
where
we
don't
or
we
don't
have
an
agreement,
is
that,
from
my
perspective,
the
ap,
the
parser
api
should
not
solve
the
challenges
we
have
with
this
pack.
D
So
if
there's
a
need
for
some
additional
vocabulary
or
or
something
it
should
be
in
the
spec,
not
in
the
in
the
parser,
because
the
parser,
we
might
have
some
nice
vocabulary
for
for
functions
in
the
parser
to
to
solve
the
issue
with
the
with
the
spec.
But
the
problem
is
that
not
everyone
have
to
use
our
parsers.
Not
everyone
has
to
use
our
official
parser
api
design.
D
So
I
would,
I
would
say,
like
to
summarize
all
the
comments
we
had
there.
That's
that's
the
core
here
like
where?
Should
these
confusions
challenges
be
introduced,
I'd
like
solutions
to
be
introduced?
Is
it
like
always
spec,
or
is
it
fine?
If
sometimes
it's
just
the
tool
that
is
trying
to
fix
the
spec.
D
A
There's
always
going
to
be
this
two-point
abuse
right
so,
for
instance,
even
if,
even
if
we
solve
it
somehow
on
a
spec,
there's
always
going
to
be
this
situation
where
there
is
a
something
like
I
don't
know,
say,
for
instance,
microservices
architecture
and
the
the
microservices
are
communicating
through
robin
q
or
kafka
or
whatever,
and
then
in
this
situation,
it's
like
an
application.
Talking
to
the
broke,
a
study
broker,
another
application
took
it
to
the
broker.
A
You
know
this
distributed
messaging
architecture,
but
in
this
case
it
will
be
like,
like
the
you
know,
like
the
application
point
of
view,
if
you
want
right,
it's
like
every
everyone
is
an
application,
and
this
is
publishing.
So
we
use
problems
in
the
future.
Imagine
we
change
it
because
I'm
publishing
I
use
problems
and
because
I'm
subscribing
to
the
broker
I
subscribe.
A
Imagine
we
change
it,
but
if
we
do
it
like
this,
then
when
we
have
a
case
like
a
public
websockets
api,
for
instance
like
it's
the
case
of
slack
and
we'll,
have
the
problem
that
you
want
to
communicate
people
what
they
can
do
with
your
api
know
what
your
api
is
doing
right.
So
in
this
case,
it's
like.
I
want
to
tell
people
that
they
can
publish
a
message
to
me
and
slack
and
you
go
and
you
can
publish
a
message
to
me
or
you
can
subscribe
from
my
messages.
A
So
there
is
a
it's.
Usually.
This
discussion
always
happen
around
websockets
and
public,
private
and
and
or
if
you
want
to
to
think
about
it,
as
well
as
a
broker-based,
client,
server
architecture
right,
so
there
can
be
messaging
through
client
server
as
well
like
websockets,
like
servers
and
events.
All
these
situations,
it's
weird
to
find
a
publish
and
in
spec
when
you
actually
want
to
subscribe
and
then,
if
you're
gonna.
A
Exactly
so,
that's
my
point
so
so
that
that's
where
I
I
want
to
to
go
right
now,
so
with
the
parser,
what
we're
doing
is
being
explicit.
The
problem
is
well.
One
of
the
problem
is
what
the
hell's
application,
what
the
hell
is
client.
What
does
it
mean
right?
We
need
to
come
up
with
better
names,
probably
so
far,
I
don't.
I
can't
think
of
any
different
names
that
have
that.
Don't
have
any
other
connotations,
existing
existing
names,
let's
say
but
anyway,
so
one
imagine
that
we
find
the
names.
A
C
I
ran
into
this
when
we
tried
to
build
our
husbands.
We
ended
up
with
you
know
some
of
our
products.
You
can
subscribe
to
something
we
can
publish
to
some.
You
can
only
subscribe
to
a
certain
language
in
sc,
because
we
have
the
classic
example
of
support
three
protocols
for
everything
right
and
one
of
them
is
ssc,
which
is
only
one
direction.
C
So
what
happens
then?
Is
we
end
up
with
this
document
which
is
about
you
know
a
kilometer
long
because
of
there's
so
many
pieces
of
spec
in
there
and
when
you
add
the
ability
for
a
wild
card
creation,
you
certainly
just
do
not
have
enough
either
your
machine
generating
these
specs,
at
which
point
you
need
to
have
things
which
are
incredibly
explicit,
because
I
want
to
machine,
generate
my
api
specs.
C
C
A
That's
that's
my
point,
so
we
need
to
fix
the
spec,
but
the
thing
is
even
if
we
fix
the
spec
and
we
come
up.
For
instance,
one
of
the
the
solutions
that
that
has
been
discussed
is
we
have
two
more
verbs.
We
are,
we
have
published
subscribe
and
then
we
have.
We
have
client,
publish
client
subscribe,
for
instance,
something
like
this.
Okay.
A
And
then
publish
and
subscribe
are
from
the
application
point
of
view
by
default,
and
this
is
like
publish
means.
I'm
publishing
to
the
broker,
for
instance,
and
subscribe
means
I'm
publishing,
I'm
subscribing
to
the
broker,
and
then
you
have
client
publishing
client
subscribe,
which
means
that
you
as
a
client
can
subscribe
to
my
messages
or
you
as
a
client
can
publish
to
to
me.
You
know
what
I
mean
for
this
specifically
for
these
public
apis,
which
in
this
case
it
will
become
useful
right.
If
that's
the.
E
A
We'll
do
that.
That's
that's
the
key
thing
here.
We
need
to
come
up
with
a
solution
together.
I
think,
and-
and
the
thing
is
that,
even
if
we
add
explicitly
to
the
spec,
it
needs
to
be
also
solved
in
the
in
the
in
the
in
the
parser.
It's
not
going
to
disappear
from
the
person,
and
what
we're
trying
to
do
here
is
that
we
put
it
on
the
parser
first
right.
So
whenever
we
migrate
the
spec,
you
don't
get
a
breaking
change
on
your
code.
A
A
So
that's
that's
the
point.
That's
the
point
of
starting
with
the
parser
instead
of
starting
with
spec,
because
if
you
write
your
code
using
our
parser
right
now
for
v2,
and
then
you
upgrade
to
b3,
where
we
introduce
breaking
changes
in
this
meaning
of
the
verbs,
then
you
have
to
go
to
all
your
all
over
your
code
and
change
your
code.
So
it's
adapted
to
the
new
minion.
A
E
A
A
A
That's
why
I'm
I'm
willing
to
take
this
task
first
on
the
parser
and
then
on
the
spec
independently
of
what
change
we
end
up
doing
on
the
spec,
and
that's
why
I
was
asking
jonas
and
and
sergio
and
magik,
I
think
yeah.
I
think
I
was.
I
was
asking
them
in
the
beginning,
like
don't
think
about
asian
kpi
think
about
even
driven
architectures.
A
So
we
don't.
We
should
not
be
thinking
about
this
integrated
document
and
and
a
specific
map
to
the
document,
but
instead
forget
about
this
api.
Imagine
it
doesn't
exist
and
we
want
to
talk
to
user
intent
right,
so
I'm
a
user.
I
want
to
get
all
the
messages
I
can
subscribe
to
in
this
broker,
or
I'm
I'm
building
a
client
for
my
web
socket
apis
public
websocket,
apis,
maybe
and
as
a
client.
A
C
A
There
is,
there
is
even
a
there's,
even
a
list
of
edge
cases
that
we
might
do
to
the
spec
in
the
future
and
see
how
the
and
see
how
the
new
api
will
behave
if
it
breaks
the
api
or
not
cool.
So
so
the
thing
it
is
more
to
so.
The
thing
here
is:
it's
not
related
to
the
ctpa
document.
It's
more
than
the
parser
should
be
capturing
user
intent.
It's
like.
I
don't
care
how
the
I
think
api
document
looks
like
I.
A
Instead
of
focusing
on
the
internet
document,
I
think
we
should
focus
on
the
user
what
the
user
wants
to
do
with
the
with
async
api
right
and
it's
like
I
as
a
user.
I
want
to
get
all
the
messages.
I
don't
care
where
the
messages
are
located
in
version
two
of
the
spec
in
version
three
it
might,
they
might
be
located
in
a
different
place,
but
I
don't
want
this
to
break
right.
A
H
The
the
thing
is
that
and
my
concern
here,
it's
on
how
much
is
really
this
problem
of
the
of
interaction
between
the
source
and
the
sync
and
and
applications
overall
being
polluting
the
the
spec
by
itself.
Right,
so
are
those
limitations
from
the
parser
that
really
need
to
be
addressed
at
just
the
partial
level
or
is
something
that
really
needs
to
be
reflected
on
the
sync
api,
because
sometimes
what
we
see
is
that,
just
twist
the
spec
just
to
you
know
fulfill
a
limitation
on
on
one
of
the
of
the
implementations.
A
To
me,
the
idea
is
that
we
fix
it
on
the
not
fix
it,
but
we
prepare
on
the
parser
at
parcel
level,
and
then
we
fix
it
on
the
spec,
but
like
immediately
after.
Actually
this
this
publish
subscribe
thing
is
something
that
we
want
to
address
next
so,
but
it
needs
to
be
addressed
on
both
sides,
not
just
in
the
spec
or
not
just
in
the
parser,
not
just
in
the
spec.
A
And
also
it's
important
that
we
address
it
on
the
on
the
parser
as
well,
not
just
on
the
spec,
because
they
the
way
it
is
the
spec
like
the
person
right
now
is
that
it's
a
map,
so
so
the
the
parser
behaves
like
a
map,
a
direct
map
of
the
spec.
So
if
we
move
things
around
on
the
spec
in
a
breaking
change
way,
then
we're
breaking
the
parser
api
and
that's
what
we
want
to
avoid
right.
So
what
we're
doing
here
is
not
so
much
about
publish
and
subscribe.
A
A
It's
it's
immutable
and,
and
it
needs
to
work
with
v2
as
well
right,
because
many
people
are
going
to
be
using
v2
for
many
years
and
they're
not
going
to
upgrade
to
b3
or
before
or
whatever
right,
because
v2
is
good
enough
for
them.
But
we
want
them
to
the
software.
They
write
with
our
parser
to
be
prepared
for
them
to
upgrade
to
v3
or
v4
of
the
spec
whenever
they
need
it.
C
A
Exactly
so,
the
thing
is
that
it's
defined
the
api
of
the
parser
in
a
way
that
captures
the
user
intentions
like,
and
then
we
translate
these
user
intentions
into
v2
of
the
spec
p3
of
the
spec
v4,
whatever
right.
So
it's
of
a
shot
right.
It's
a
true
fact.
So
then
you
can
evolve
this
back
as
you
wish.
A
You
can
make
as
many
breaking
changes
as
you
want
by
I
mean
unless
you're
removing
stuff,
of
course,
but
you
can
move
things
around
as
you
want
that
or
change
the
meaning
of
the
of
the
of
subscribe
and
publish
that
your
code
is
going
to
remain
the
same
right.
It's
going
to
remain
the
same.
You
just
have
to
upgrade
your
library,
your
parser
and
and
that's
it.
It
works,
and
you
start
using
the
new
version
of
the
spec
that
has
this
problem
fixed
of
the
pilots
and
subscribe
right
and
you
have
to
migrate.
D
Yeah,
but
I
don't
think
that
anybody
questions
the
intern
driven
api
idea,
it's
more
about
that.
We
should
like
take
two
two
things
into
consideration
like
the
world
will
not
be
perfect
like
it's,
it's
not
gonna
be
you're,
not
gonna
have
like
100
of
developers
using
just
the
parser
and
not
knowing
the
spec.
A
A
A
A
You
know,
maybe
we
should
be
introducing
multiple
methods
like
messages
that
I
can
publish
to
the
broker
messages.
Like
you
know,
I
don't
know.
Even
long
names
might
work,
I
don't
know.
The
thing
is
that
I
think
if
we
make
it
clear,
but
not
mapping
to
the
to
async
api
but
more
to
the
event
driven
architecture's
concept,
the
easier
it
will
be,
but
the
problem
is
that
eda
is
a
non-uniform
world
where
each
broker
and
each
protocol
is
doing
their
own
stuff
and
they
use
the
same
terms.
A
Interchangeably
between
them
and
the
same
term
might
mean
different
things
in
different
protocols
and
that's
a
mess
so
yeah.
I
think
this
step
here
is
just
a
an
initial
step
to
align
the
language
that
we
use
in
eda
and
then
it
will
it
will
have.
Of
course
it
will
have
an
impact
on
the
spec.
But
but
that's
my
point
so
it's
like
if
you,
if,
if
I
see
again,
if
I
see
application
or
client
publish
operations-
and
I
know
nothing-
I've
never
seen
async
api.
I
have
no
idea.
A
D
So
yeah
and
I
think
that's
how
the
this
discussion
between
me
and
andyanna
started
at
mainly.
My
first
question
was
like:
does
the
intend-driven
api
means
that
the
name
of
the
function
has
to
sound
like
an
intent?
Maybe
we
can
actually
turn
it
around
like
if
I'm
a
dev
and
like
even
driven
world
is
so
complex
like
then
I
care
about
messages.
First
then,
like
just
function
like
a
message
and
then.
D
A
D
D
D
Provided
the
the
name
of
the
options,
but
the
thing
is
that,
with
the
with
the
message,
you're
already
like
it's
more
intuitive
in
the
api,
if
you're
looking
for
like
messages,
yeah,
then
you're
gonna
type
message
and
then
on
the
basis
on
the
option.
Of
course
it's
it's
all
about,
then,
on
the
vocabulary
on
the
message,
but
then
it's
much
more
intuitive
to
browse
through
the
api,
then
trying
to
catch
this
complex
vocabulary.
In
the
name
of
the
function,
then.
A
D
H
A
It's
not
gonna
happen
yeah.
I
don't
think
it's
gonna
happen
when
it's
we're
human,
if,
if
it
was
all
about
an
application,
libraries
or
whatever
it's
easy,
we
automate
things
and
that's
fixed
it's
fixed
in
in
a
few
months,
but
we're
humans.
We
have
to
agree,
we
have
to
discuss
and
it's
not
never
gonna
happen.
D
D
D
F
Yeah,
so
it's
still
a
work
in
progress
right.
That's
also
just
released
a
new
library
instead
of
the
typescript
library.
That's
currently
used.
That
has
to
be
converted,
and
I
worked
on
some
dot
net
plan
drivers
for
for
naps
as
well,
but
that's
also
working
progress
and
one
of
the
more
major
issues
or
major.
F
H
E
Well,
we
can,
we
can
certainly
help
out
wherever
we
can.
I
know
our
node
actually
everything's
dino
and
type
strip,
script
and
node
now
our
maintainer's
on
vacation
this
week.
But
you
know
I
can
ask
him
to
take
another
look
and
and
see.
If
there's
any
direction
he
can,
he
can
provide
or
any
contributions
there.
We
have
a
a
shared
or
common
user
who,
I
believe,
is
going
to
want
dot
net
their
heavy
java
user
as
well,
and
then
also
typescript.
E
F
Yeah
I
mean
if
you
want
to
jump
in
and
even
take
over
the
the
wrapper
and
keep
developing
that
that's
also
perfectly
fine,
like
anything,
is
possible
where
it
matches
your
needs.
Basically,
one
of
the
core
issues
is
also
the
bindings
for
that,
where
I
kind
of
stitch
together
some
vocabularies
or
ways
to
define,
request
reply
pattern,
but
that's
just
my
workaround
on
a
bigger
issue
with
the
specification,
so
that
also
needs
to
be
addressed,
but
yeah
jump
in
anywhere.
A
You
wonder:
that's
actually
a
big
one
yeah.
So
having
request
reply,
support
on
the
spec,
it
is
something
that
I
I
never
touched
because
I
never
used
this
case
in
my
in
my
careers.
I
was
hoping
that
someone
will
jump
in
at
some
point
and
help
with
this,
because
yeah-
and
I
know
that
especially
nats-
has
different
operations
or
type
of
operations.
It's
not
just
public
subscribe.
E
C
Planning
to
be
doing
a
live
stream
most
of
next
week
using
kpi
and
kafka,
as
the
twitter
thing
was
talking
about,
so
it
should
be
online
most
of
next
week.
Streaming
about
that
feel.
Free
to
drop
in
the
details
will
be
on
on
the
slack
as
soon
as
we've
actually
put
together
the
cards
and
the
rest
of
it
for
it
and
lock
down
the
times.
The
other
classic
thing.
If
I
decided
to
do
something
in
the
marketing
department
said
that
sounded
too
interesting
and
it
then
became
official.
C
A
A
A
It's
just
pure
brainstorming,
we'll
we'll
note
down
all
the
ideas
we
had.
We
keep
discussing
some
github
issues
and
slack
or
whatever,
and
then
at
some
point
we
may
have
a
good
idea,
hopefully
on
how
to
solve
this,
and-
and
we
can-
and
someone
can
champion
this
and
and
make
it
a
reality
right.
So
so
yeah.
A
So
you're
all
invited
by
the
way,
just
I'll
I'll,
leave
some
messages
on
the
github
discussion
around
the
parser
intent
api
on
slack
and
everywhere.
So
you,
you
should
be
able
to
see
it
and
and
yeah
it's
a
long
term
thing.
I
don't
want
this
to
be
like
just
one
or
two
meetings
with
that
right
now.
I
think
it's
an
important
topic
and
we
need
to
be
sure
that
whatever
we
do
is
it's
the
right
thing
right.