►
From YouTube: AsyncAPI SIG meeting 46 (April 13, 2021)
Description
This is the recording for the AsyncAPI Special Interest Group (SIG) meeting #46.
Agenda & Notes: https://github.com/asyncapi/community/issues/20
Chat:
00:30:23 Ben Gamble: Hi all, have to jump… the day job is calling…. Bye!
A
Okay,
so
welcome
on
our
asking
api
public
meeting.
This
meeting,
like
every
other
meeting,
is
recorded,
so
just
please
be
advised
that
whatever
you
say
is
gonna
stay
there
forever
on
youtube.
A
So
we
have
several
topics
on
the
on
the
agenda,
but
I
also
think
I
saw
a
few
new
names
on
the
list
of
the
participants.
So
folks,
that's
a
moment
for
you.
If
you'd
like
to
introduce
yourself
to
the
group
you
don't
have
to,
but
you're
most
welcome
to
to
do
that.
I
mean
I'd
like
to
meet
you,
for
example.
A
A
Okay,
so
before
we
jump
into
the
items
that
I've
put
there
and
also
sergio
and
and
jonas
wanted
to
have,
do
you
anyone
from
the
from
the
people
that
joined
the
new
commerce
and
the
old
commerce?
I'm
not
sure
if
it's
even
correct
word,
anyone
has
a
question,
so
you
don't
want
to
wait
until
the
end
of
the
meeting,
because
the
meeting
is
for
the
community.
So
if
somebody
has
a
question
doesn't
want
to
wait
until
we
cover
the
other
topics.
A
You,
okay
cool,
so
let's
continue
so
I
have
two
topics:
quick
topics.
I
guess
just
a
highlight
for
you.
So
we
long
story
short.
Last
year
we
applied,
for
I
mean
we
did
not
apply,
you
don't
have
to
apply
for
for
oktoberfest,
but
we
were
pretty
active
in
the
oktoberfest.
We
got
feedback
from
oktoberfest
participants
that
we
should
it's.
A
A
Okay,
so
let's
go
back
so
we
got
a
tremendous
feedback
that
with
our
engagement,
we
should
also
go
with
the
google
summer
of
code
and
now
we're
in
google
summer
of
code
and
I'd
like
just
to
say
remind
whoever-
and
I
see
ace
joined,
hi
ace.
So
we
have
a
few
folks
already
joined
slack
discussed
with
us,
the
ideas
that
we
had
for
google
summer
of
code.
A
So
here
it's
just
a
reminder
that
today
is
a
deadline
for
why
it's
called
deadline
nobody's
dying.
So
it's
a
deadline
for
today
to
submit
your
proposals
and
then
we
have
a
month
to
accept
them.
So
only
a
few
hours
left
so
ace.
If
you
didn't,
do
it
yet
go
to
google.com
what.
A
D
A
Engages
open
source,
community
and
and
students
around
the
world
to
work
together
on
some
some
ideas.
So,
for
example,
we
had
a
list
of
ideas
that
offer
tools
for
asking
api
like
a
async
api,
diff
or
some
crazy
idea
about
having
a
chatbot
that
can
help
you
out
creating
your
own
asking
api
file
and
we
had
a
few
of
the
all
those
ideas.
And
then
we
go
to
google
saying
we
want
to
apply
for
google
summer
of
code.
We
have
a
number
of
ideas
and
then
students
around
the
world.
A
They
can
go
through
all
those
different
projects.
Their
ideas
speak
some
join.
The
the
given
initiative
propose
that
they
will
solve
it.
For
us
we
say
yeah,
we
accept
your
proposal.
Let's
go
forward,
then
we
mentor
such
a
student
like
explain
the
project,
explain
how
to
work
with
us
and
basically
on
board
on
open
source,
all
the
like
from
coding
to
communication,
etc
and
then,
at
the
end
we
give
feedback
and
once
work
is
done,
I
believe,
there's
a
kind
of
sponsorship
from
google.
Then,
like.
A
I
think
google
plays
1.5
k
bucks
for
the
student
for
the
work
that
he's
done,
but
I'm
not
100
sure.
It's
one
point:
nice.
D
So
effectively
it's
a
way
to
get
parts
of
the
open
source
project
in
the
hands
of
students
and
get
them
to
develop
it
with
some
enumeration
to
make
sure
it's.
You
know
at
least
reasonably
abovebought
yeah
cool.
That
sounds
great.
A
So
discussion
of
over
the
proposal,
so
it's
I
I
I
for
me-
it's
awesome
because
you
kind
of
show
students
like
the
whole
path
from
working
on
the
idea
discussing
ideas
in
open
source
in,
like
with
the
community,
then
going
to
an
implementation,
pull
request,
review
like
adjustments,
etc.
You
you
show
them
like
how
the
communication
works
in
open
source.
So
it's
I
I
wish
I
I
knew
about
it
when
I
was
studying.
So
me
too,
yeah
great
fun,
but
it's
our
first
time.
A
So,
let's
see
how
it's
gonna,
how
it's
gonna
work,
I
think
it's
and
it
ends
in
our
august.
So
we're
gonna
have
some
cool
tools
at
the
end
of
august
and
and
more
feedback
ace.
You
want
to
do
something
to
what
I
said
now
I
force
you
to
say
something:
no,
you
don't
want
to
okay,
no
worries,
and
now
we
jump
to
another
topic
that
actually
involves
ace.
A
So,
for
example,
ace
is
one
of
the
students
that
came
up
with
one
of
the
proposals,
but
also
jumped
into
other
issues
and
and
things
we
could
do
already
for
using
api,
and
we
now
for
information
on
our
website
and
thanks
to
ace
implementation,
we
have
a
easy
way
for
you
to
also
post
job
offers
for
asking
api
community
members.
A
So
when
you
go
to
asking
api.com
jobs,
there's
a
pretty
easy
instruction
and
that
you
can
follow
to
submit
your
job
proposals,
you
can
do
it
through
the
github
ui
or
just
as
usual
fork
request
flow.
A
F
F
So
jonathan
and
I
are
working
on
an
intent
driving
api
for
the
parser,
not
just
for
the
javascript
one
yet
for
for
a
global
api
for
any
any
parser,
even
though
we
are
starting
with
the
javascript
one,
because
we
don't
have
any
other
parser
with
a
feature
parity
linked
to
the
current
spec
person.
So
anyway,
what
does
intent
drive
an
api
means.
So
we
figured
out
that
the
current
password
had
some
issues.
The
api
on
the
parser.
F
Okay,
so
everything
started
here:
fran
suggested.
F
F
F
F
What
does
it
mean
intense?
So
here
we
already
started
working
on
it
and
we
defined
some
of
them.
So
just
for
a
quick
example,
we
have
intents
translated
into
functions,
which
means
like
if
I
want
to
have
all
the
channels
that
are
publishable
by
the
application
and
here
application
and
client.
F
I
don't
know
if
you
are
aware
that
we
had
some
discussions
around
the
point
of
view
of
the
spec,
so
there
are
some
open
open
issues
that
suggest
that
we
might
want
to
introduce
a
new
concept
of
the
role
or
point
of
view
or
x,
because
we
didn't
decide
what,
because
sometimes
you
want
to
use
the
spec
from
the
point
of
view
of
a
client,
but
also
from
the
application
where
application
could
be.
F
F
So
you
don't
have
to
know
what
kind
of
operation
it's
behind,
because
it's
going
to
be
explained
by
itself
in
the
function.
So
you
don't
have
to
access
the
whole
structure
until
you
find
all
the
operations
that
are
published,
but
instead
you
will
have
all
of
them
just
by
calling
this
method,
and
if
we
follow
all
the
all
the
functions,
declare
it's
going
to
be
a
similar
behavior.
F
So,
for
example,
we
have
the
same
the
same
intents
for
client
perspective.
So
let's
say
I'm
a
client
that
want
to
use
the
parser,
and
I
just
need
to
know
all
the
the
channels
I
can
publish
too
right.
F
I
don't
have
to
know
if
we
mean
publish
from
the
point
of
view
of
the
application
or
we
mean
subscribe,
because
this
is
an
issue
that
we,
whenever
you
start
on
a
sync
api.
The
first
thing
you
you
you
think
about
is
like
what
the
participants
described
right
from
which
point
of
view
we
are
talking
about.
So
this
is
already
resolved
as
well.
By
those
intents,
as
you
can
see
so
just
to
clarify
for
a
second,
this
is.
D
Effective
the
the
the
objective
here
is
to
abstract
away
from
all
implementation
details,
whether
it's
spec
or
otherwise,
and
basically
say
these-
are
the
operations
we're
trying
to
achieve
whether
it's
a
published.
So
a
message
is
going
from
a
to
b
or
from
b
to
a
and
have
it
in
terms
of
the
actual
message
operations
rather
than
in
terms
of
implementation,
detail
of
a
protocol
or
of
a
spec
or
of
a
language
would
that
be
correct.
Yeah.
F
That's
correct,
in
fact
talking
about
implementation,
so
you
can
imagine
this
as
a
just
a
simple
mapping
between
that
that
could
change
between
versions,
so
users
of
the
parser
won't
have
that
much
braking
change
because
we
will
handle
that
directly
inside
those
functions
so
meaning,
if
channels
become
let's
say
in
the
spec.
We
move
operations
to
live
in
the
root
object
or
in
the
root
document.
F
Users
of
the
parser
won't
have
to
change
anything
because
the
person
will
handle
those
changes
for
them
right.
So
it
doesn't.
It
doesn't
matter
where
the
operations
live
with
this
api
because
we
will
handle
that
inside
inside
each
each
of
the
functions
right.
It's
just
changing
the
mapping.
D
C
F
Yeah
you
can
have
here,
those
are
not
all
the
functions
that
we'll
have.
Okay,
those
are
just
the
most
important
related
to
intents
I
see,
but
you
have
you
have
an
example
here
for
channels,
so
you
can
get
the
operations
from
a
channel.
C
F
B
F
That's
the
point:
what
we
did
also
is
that
we
try
to
for
building
this.
This
is
just
a
draft
of
the
of
the
suggestion
we
wanted
to
do.
F
F
F
So
our
goal
was
to
not
break
the
api
with
any
of
those
braking
chains
and
there
are
some
breaking
changes
like
the
one
we
said
moving
operations
from
I
mean
I
think
it's
sorry
for
the
mess.
F
As
you
can
see
here,
operations
is
in
the
root
document
right,
so
operations
are
linked
to
channels
and
to
messages,
but
still
the
api
won't
break.
We
can
still
call
the
same
methods
and
the
users
of
the
parser
won't
have
to
change
anything.
F
So
yeah,
don't
don't
take
a
lot
of
like
this
is
just
fake,
fake,
possible
changes.
It
was
just
to
to
provide
some
scenarios
that
could
could
make
the
fbi
work
break.
Okay.
So,
having
said
that,
do
you
have
any
question
about
the
intent
driven.
F
F
F
Somehow
access
this
operation
and
then
get
the
summary,
but
just
following
the
same
structure
as
the
document
like
the
same
functions,
order,
mapping
to
the
document
will
be
like
async
api
dot
operations,
dot.
Let's
say
on
lightmesser.com.
F
A
C
F
In
fact,
there
is
another
another
project
that
I'm
working
on,
not
in
parallel,
but
is
the
evident
gateway
or
the
event
proxy,
which
will
need
to
use
the
parser
for
validating
messages.
So
that's
the
reason.
I
also
moved
my
effort
to
work
on
this.
C
Let
me
just
clarify
what
I'm
asking
so
essentially
in
the
in
the
community,
everyone
who's
potentially
interested
in
asig
api.
Do
they
typically
use
that
one
javascript
parser
or
is
it
likely
that
other
passes
have
been
developed
which
would
not
benefit
from
this
work?.
F
No,
there
is
only
this
javascript
one.
There
is
a
golden
one,
but
it's
under
development,
so
yeah
we
only
have
the
javascript
one.
A
F
Okay,
so
that
was
the
introduction
what
I
what
we
wanted
to
talk
about,
jonathan
it
was
about
those
two
issues
here
that
are
kind
of
related.
The
first
one
is
this:
one
that
match
I
created
magic
is
not
in
the
call,
so
I'm
not
gonna
be
focused
a
lot
of
this,
but
we
can.
We
can
just
do
a
brief
summary,
so
the
idea
is
to
support
json
schema
on
the
bindings,
meaning
we
could
validate
the
bindings.
F
We
could
use
the
bindings
models
in
templates
and
it
seems
I'm
not
aware
of
this.
I'm
still
learning,
but
it
simply
could
also
help
for
rendering
correctly
the
the
components
on
the
templates.
The
react
template.
F
The
point
here
is:
it
sounds
like
cool
and
good
to
go,
and
but
the
the
thing
is
that
we
have
to
consider
several
several
things
here
to
move.
We
have
to
store
somewhere
digestion,
schemas
right.
F
There
are
some
suggestions
I
did
here
like
putting
them
in
the
bindings
repository
and
probably
link
from
spec
to
those
files
directly
whenever
we
validate
the
document,
or
rather
I
think
machek
was
suggesting
to
use
another
approach
here,
which
I'm
not
very
aware,
but
anyway.
The
point
is
that
that's
the
concept
we
want
to
add
validations.
F
There
are
more
things
to
consider,
and
here
is
why
I
mentioned
this.
This
issue,
which
is
not
completely
related
but
kind
of,
and
it's
the
person
findings
have
their
own
person
right.
We
keep
personing
on
the
findings,
which
means
we
could
introduce
a
breaking
change
in
between
finding
versions
like
renaming
a
field
or
something
like
this,
and
that
means
that
the
document
will
change
as
well.
F
And
coming
back
to
the
intent
driving
api,
we
also
have
to
somehow
get
the
the
bindings
into
the
parser's
api,
the
intend
driven
api
and
we
still
have
the
same
issue.
So
how?
How
do
we
know
which
person
our
parser
is
going
to
be
compatible
with
person
talking
about
binding
person?
C
I
believe
there
is
no
standard
way
in
the
spec
to
specify
the
version
of
a
binding.
If
so,
you
can
only
the
binding
is
for
a
protocol.
No,
let's
say
channel
pi
channel
binding
for
amqp,
but
the
version
of
that
emqp
binding
that
is
being
used
has
no
standard
place
in
in
the
spec.
If
is
that
correct,.
A
So
there
is,
I
mean
every
binding
has
to
have
one,
so
you
can
specify
which
binding
version
you
you're
using
in
your
binding
object.
F
F
So
how
how
it
looks
now
from
the
parts
of
point
of
view
bindings
is
just
kind
of
a
key
value
structure.
They
are
a
schema,
but
they
are
treated
like
a
black
box.
It
doesn't,
it
doesn't
know
about
what
is
behind
so
it's
whatever
it
comes.
I
I
return
it
to
the
to
the
parser
function.
Call
right.
So
if
I
call
bindings
from
this
message,
it's
gonna
just
return.
Whatever
it
has,
it
doesn't
have
any
intent,
it
doesn't
have
extra
functions,
it's
just
getters
to
the
fields
under
the
the
binding.
F
Which
is
not
a
problem,
it's
just
a
possibility.
F
So
here
in
this
issue,
we
we
are
adding
some
example
of
how
the
parser
could
help
or
could
handle
breaking
changes
on
the
binding
versions.
But
first,
let's
start
with
an
example
of
what
we
are
talking
about
here.
So
let's
say:
mqp
binding
version.
F
1.00
introduces
a
breaking
change
where
the
field
method
returns
an
array
of
possible
methods
instead
of
oh
sorry,
I
think
wow.
This
is
wrong.
I
didn't
mean
that
it's
not
the
mqp
is
the
is
the
websocket
one
anyway,
so
the
websocket
binding,
instead
of
returning
a
method
which
is
boston,
get.
I
think,
let
me
open
just
in
case,
because
I
don't
remember.
F
Yes,
so
here
is
later
in
just
a
string,
so
let's
say
we
introduce
a
breaking
change
where,
instead
of
one
one
string,
we
return
several
or
an
array.
I
don't
mind:
why
reasons
behind
that,
but
just
try
to
to
believe
that,
and
so
this
meaning
that
the
current
use
of
the
parser
will
look
like
this.
The
binding
dot
method.
F
To
adapt
to
getting
instead
of
one
field
to
have
an
array
if
we
also
introduce
a
new
change
like
moving
the
method
to
to
live
under
another
like
a
subtype
or
child
called
request,
it
means
that
if
we
will
have
also
to
change
the
call
to
be
like
this
binding
the
tree
quest
of
method
whatever,
so
this
is
the
breaking
change.
This
is
quite
related
to
what
we
were
talking
about
previously.
What
the
intents
api
tried
to
solve
here,
nothing
new.
F
The
point
here
is
it's
not
just
about
writing
the
intents
or
not,
it's
just
how
the
password
api
can
support
those
persons
and,
at
the
same
time,
be
like
resilient
to
those
breaking
changes
introduced
by
the
new
versions.
So
you
cannot
only
point
to
one
person
right.
You
cannot
only
say
yeah.
F
The
parser
only
uses
websocket
binding
version
1.0,
because
the
spec
document
could
be
like
using
the
binding
0.2.0.
So
you
have
to
keep
support
for
several
versions,
and
this
is
like
a
problem.
How
do
we
do
that?
F
C
C
I
would
just
treat
them
literally
past
them,
literally
as
as
they
are
represented
in
in
the
spec
in
the
async
api
document,
and
so
I
think,
if,
if
we
can
accept
that,
then
the
problem
just
comes
down
to
being
able
to
look
up.
The
json
schema
for
a
given
protocol
for
a
given
version
of
the
binding
for
that
protocol.
F
C
F
F
C
If,
if
what
lucas
has
said
before
is
correct,
that
every
binding
should
have
a
version,
a
binding
version,
no
then,
when
you
come
to
the
node
in
your
async
api
document
that
says
channel
soon
so
binding,
emqb
amqp,
then
you
and
then
bindingversion100.
You
know
you
must
look
up.
This
json
schema
for
emqb
zero
bindingdefinition100.
A
H
So
yeah
this
is
great
when
we
want
to
validate
things
right,
and
this
is
exactly
what
we
should
be
using
it
for
the
problem
at
hand.
Here
is
about
making
sure
that
tooling
does
not
have
to
change
when
the
bindings
behind
the
scenes,
changes
and
all
the
structure
of
the
bindings
and-
and
this
is
kind
of
a
problem
with
how
should
when
a
binding
has
their
own
version,
that's
separated
from
the
spec
completely.
H
How
can
we
keep
a
compatibility
matrix
in
the
parsers
to
ensure
that
this
version
of
the
parser
works
with
these
bindings,
for
example,
there's
different
approaches,
as
outlined
here
as
well
as
at
the
moment
in
tooling?
If
you
want
to
access
a
binding,
you
need
to
know
exactly
the
structure
of
the
object.
That's
returned.
H
H
So
you
have
to
from
the
tooling
side
you
have
to
know
exactly
what's
in
bindings
and
if
binding
changes
and
you
are
yeah-
I
don't
want
to
say
obligated.
But
if
you
want
to
keep
compatibility
with
newer
versions,
you
have
to
change
your
code,
which
is
a
problem,
which
is
why
we
want
to
introduce
these
intents
basically
for
the
bindings.
C
I
see
two
example
of
tooling
being
an
a
code
generator
using
your
parser
correct.
If
that
code
generator
finds
an
emqp
version,
one
zero
zero
channel,
binding
object.
It
must
know
what
to
do
with
that,
but
there's
no
way
around
that.
No,
it
can't
not
everything
can
be
generic.
I
think
at
some
point
specific
code
has
has
to
be
written.
A
H
F
It's
not
all
converting
because
again,
so
the
users
here
are,
let's
say:
templates.
Okay,
so
templates
are
using
the
parser
and
template
will
have
to
handle
these
breaking
changes
and
it's
fine.
We
can.
We
can
move
with
that
and
it's
fine,
even
though
we
could
avoid
somehow.
But
let's
say
it's
fine.
F
F
The
point
is
that
you
can
have
like,
like
we
say
yeah,
you
ask
the
partner
to
return
whatever
they
have
and
you
manage
everything
you
on
your
own,
or
rather
you
tell
the
parser
how
the
parser
should
parse
it
or
which
version
of
the
bindings
to
use.
We
could
also
do
that
right
and
everything
that
returns.
F
The
parser
will
be
known
as
well
by
the
template,
and
we
could
also
introduce
intense
driving
api
there.
We
could
keep
it
even
though
that's
like
a
hard
move.
It's
not
that
easy,
and
this
is
like
we
have
to
find
a
balance
between
complexity
and,
I
would
say,
usability
here
so
anyway.
Everything
is
we
put
some
options
here
to
try
to
fix
that
issue.
F
The
second
option
was
to
just
tie
the
binding
versions
to
the
expect
version,
so
meaning
every
time
a
binding
decreases.
The
spec
does
as
well.
I
know
that's
like
a
lot
because
for
any
change,
let's
say
we
release
a
new
version
on
the
mqp
binding.
F
The
third
option
is
also
related
to
this,
but
it's
completely
moving
the
findings
to
be
part
of
the
spec
and
not
having
their
their
own,
really
cycled.
So
everything
in
the
same
village
cycle,
which
is
very
similar
to
the
option
two
with
those
options.
What
I
imagine
behind
that
as
a
technical
solution,
since
the
parser
only
supports
some
spec
versions,
will
mean
that
it
will
also
support
those
binding
persons
that
the
spec
supports
right.
F
The
big
cons
here
is
that
we
are
going
to
do
a
lot
of
releases
on
the
spec,
which
I
think
it's
not
very
good,
and
the
the
good
point
of
the
bindings
is
that
they
have
their
own
release
cycle
right.
F
So
they
can
add
changes
and
they
can
release
measure
or
miners
who,
without
even
affecting
the
spec.
C
F
F
No,
but
we
try
to
put
all
the
options
that
came
to
our
mind,
because
it's
good
to
have
all
of
them
here
option
four.
On
the
other
hand,
it
goes
goes
a
bit
further
and
adds
a
bit
of
complexity
technically
speaking,
but
the
idea
is
that
the
bindings
provide
their
own
partial
library.
Like
the
same
we
talked
at
the
beginning,
like
they
provide
their
own
json
schema
for
validating.
F
F
E
C
A
Which
is
not
that
bad
if
it's
such
an
important
parser
and
so
at
least,
and
it
kind
of
makes
sense,
because
we
also
do
a
kind
of
plugin
support
for
parsing
the
different
schema
formats
right.
So
we
have
a
parser,
but
we
have
a
plugin
for
avro
schema
parser,
so
you
can
plug
in
to
the
parser
and
then
the
parser
is
able
to
to
parse
your
asking
api
document
that
includes
a
avro
schemas
inside.
A
So
this
flexibility
is
in
the
parser,
so
long
term
having
it
for
the
binding.
Doesn't
sound
like
something
super
strange
I
would
say,
but
I'm
consuming.
To
be
honest,
like
my
my
view
is
like
option
one.
Definitely
because
because,
as
you
can
already
see,
the
the
bindings
add
a
complex
super,
huge
complexity
to
the
to
the
intent
api,
where
we
it's
our
first
approach
to
the
idea
of
intent
api.
So
my
question
my
challenge
question
would
be
like:
does
it
make
sense
to
really
try
to
solve
it?
A
Looking
at
the
bindings
and
their
current
version,
because
I
I
think
it's
okay
to
say
that
bindings
are
is
something
that
is
not
yet
stable.
I
don't
think
we
have
any
single
binding
that
reached
1.0,
many
of
them
missing
full-time
maintainers,
and
they
are
they
are
subject
for
for
change
like
they
can
change.
However,
they
want
until
they
reach
one
zero.
A
So
my
my
like
my
opinion
here,
I
I
think
it's
better
to
keep
it
as
it
is
with
the
parser,
so
you
just
get
the
whole
binding
and
that's
it
and
then
see
how
the
intent
api
evolves
and
then
try
to
like
push
those
best
practices
that
we
we
have
in
the
intended
npi
and
try
to
map
them
to
bindings.
When
we
are
once
we
are
like
ready
to
do
it
actually
with
the
bindings.
C
A
And
that's
what
we
can
currently
that's
the
only
thing
we
can
currently
do,
because
we
don't
have
schemas
for
bindings.
We
don't
have
a
solution
in
place
where
we
can
like.
We
don't
generate
models
for
for
those
bindings
that
we
can.
I
mean,
there's
no
way
we
can
guess.
What's
the
type
of
the
data
that
we
that
we
return,
so
we
return
objects.
H
It
does
not
it's
it's.
The
validation
should
still
be
in
place.
It's
only
on
the
tooling
side
that
you
should
have
a
direct
api
to
call.
E
F
We
we
already,
I
think,
matcha,
suggested
to
us
a
few
weeks
ago
to
use
like
json
mapping
between
versioning,
but
we
by
now
we
discard
it
and
by
now
we
are
gonna
just
hard
code.
The
mapping.
F
Yeah
I
mean
the
point:
is
that
let
me
explain
so
we
want
to
validate
the
api
as
soon
as
possible
and
for
validating.
We
need
the
api
to
be
like
available
like
in
a
alpha
or
whatever
person
as
soon
as
possible
out
right.
If
we
go
into
this
mapping
detail
like
internal
implementation
details,
which
is
good,
I
mean
it's
a
super
good
suggestion.
F
This
is
gonna,
be
lowering
us
and
we
prefer
to
invest
this
time
on
redefining
the
api
whenever,
rather
than
technical
details
right,
like
let's
say
all
those
sorry
I
don't
know
what
is
you
know
all
the
intents
that
I
showed
before
are
wrong.
Maybe
right
so
maybe
users
say
yeah.
This
is
not
useful
at
all
and
we
have
to
redefine
this
or
we
have
to
add
new
ones
whatever.
F
E
Yeah
definitely
get
the
surface
areas
the
intent-based
api
exactly
right,
first
and
then
think
about
how
we
implement
it.
But
if
I
can
just
put
out
the
idea
of
making
it
a
generic
process
or
maybe
using
code
gen
or
something
like
that,
because
I
would
love
to
be
able
to
do
this
for
open
api
and
open
rpc
as
well
and
json
schema
itself.
E
H
H
Exactly
so,
if,
if
that's
what
not
that
we
want,
but
if
that's,
what
is
the,
what
can
you
say
not
expected
but
wanted
yeah?
We
can
do
that.
A
But
yeah,
I
think
that
kind
of
just
to
summarize
the
the
goal
here
is
the
api
not
how
it's
implemented
and
then
once
we're
super
happy
with
the
api,
then
we
can
and
then
we
actually
will
jump
into
the
final
implementation
but
yeah.
We
need
to
remember
that.
F
F
E
F
Because
the
point
is
not
only
the
mapping,
so
there
are
more
more
things
behind
if
it
would
be
only
mapping
that
change
between
version.
It's
hard,
it's
like
easy
to
do,
but
it
would
be
like
not
only
mapping
like
there
are
several
changes
that
can
be
introduced
in
the
spec.
That
cannot
be
represented
by
changes
on
the
mapping
and
then
you
have
to
add
extra
support
for
that.
It's
like
that's
why
we
didn't
move
on
that
direction
in
the
first
iteration
yeah
totally
it's
worth.
E
C
Do
we
do
we
agree
that
your
intent
reason
api
will
still
need
to
change
with
future
versions
of
the
spec?
Now,
for
instance,
let's
say
a
new
field
is
introduced
on
a
channel
that
says.
Is
it?
Is
it
a
point
to
point
of
publish
subscribe
now
that
that
will
require
change
to
your
intense
dream,
api.
H
D
H
H
Exactly
and
from
the
fastest
point
of
view
right,
it's
just
a
feature
change.
Basically,
it's
just
a
minor
version
change
and
even
major
version
changes
in
the
spec
does
not
necessarily
result
in
a
major
version
change
of
the
parser,
meaning
that
if
you
create
tooling
using
this
parser,
you
don't
have
to
change
anything.
You
just
have
to
bump
the
passer
version,
and
then
you
support
the
newest
async
api
version,
for
example-
and
this
is
basically
the
entire
also
called
the
outcome
of
this
intent.
Api.
A
Okay-
and
this
way
we
came
to
the
end
of
the
meeting,
we
have
one
minute
left.
Anyone
has
a
question
if
somebody
was
waited
waiting
until
the
end
of
the
meeting,
it's
a
good
tip
for
the
future
to
ask
questions
before
we
start
talking
but
yeah.
If
anyone
has
some
questions,
you
know
our
slack
most
of
you,
I
think
are
already
in
our
slack.
Then
please
join
and
ask
us
in
a
synchronous
way
on
slack
we're
responsive
there.