►
From YouTube: AsyncAPI SIG meeting 3 (Mar 5, 2019)
Description
This is the recording for the AsyncAPI Special Interest Group (SIG) meeting #3.
Attendees:
- Fran Méndez
- Jonathan Schabowsky
- Mike Ralphson
- Raisel Melian
- Scott Nichols
- And a troll
Moderation:
- Fran Méndez
Agenda:
* Tooling plan discussion (20 minutes)
* Questions and feedback? (15 minutes)
B
A
C
A
B
A
It's
not
a
Sun,
a
simple
problem:
your
partner
would
have
to
understand
how
to
assemble
the
final
result.
Understanding
what
what's
expected
for
this
instance
of
that
object,
so
it
would
produce
a
boolean
shove
it
into
that
field.
It
would
still
serialize
fine,
but
it's
gonna
be
a
lot
of
work
to
assemble
that
object
and
not
very
easy
to
consume
it
either.
B
D
B
The
reason
was
that
go
compiles
really
well
to
see
libraries
right
and
we
can
then
reuse
these
see
libraries
in
other
languages.
So
if
we,
if
we
want
to
have
tooling
for
multiple
languages,
it's
easier
to
export
it
to
to
see
library
and
then
create
grabbers
on
those
languages
right
wrappers
of
the
C
library,
because
all
the
languages
support
to
say,
C
libraries
or
wrapping
C
libraries,
so
Mike
suggested
having
do
anything
dressed
because
it
creates
much
better.
B
D
B
B
It
might
change
in
the
future,
I
mean
if
we
keep
growing
and
then
we
get
more
resources,
more
people
working
on
async
API.
Obviously
that
would
be
happy
to
to
say:
hey,
let's
get
rid
of
this
C
libraries,
intermediate
intermediaries
and
and
that's
it
and
let's,
let's
do
it
natively
in
each
language.
That
would
be
awesome,
but
you
know
for
four
or
five
people
working
on
the
project
from
time
to
time
this
is,
it
will
be
impossible
to
manage.
B
Basically,
that
was
the
reason
so
yeah
and
regarding
plans
so
regarding
plans
for,
but
for
the
tooling,
not
just
for
the
parser
tomorrow,
I'm
gonna
have
a
meeting
about
I'm
gonna
have
a
meeting
with
with
Lucas
from
from
kima,
because
the
day
they
are
the
ones
who
created
a
syncope,
a
react
component
so
to
discuss
how
how
they're
gonna
implement
the
next
react
component
or
the
the
person
to
parser
for
the
for
the
browser.
If
at
all,
because
maybe
we
don't
implement
the
browser
version.
C
E
C
B
Mean
the
other
option
is
not
having
a
browser
version
parcel
at
all
like
if
you
want
to
parse
the
document
you
parse
it
in
the
server
and
return
a
JSON
schema
document,
the
result
of
the
the
parsing.
Let's
say
right:
that's
the
other
option
and
I
think
from
from
the
last
comments
with
with
Lucas
from
Isaac
Eid
right.
B
B
It's
it's
fine,
it
will
be
fine
for
them,
but
obviously,
if
we
can
have
something
that
can
parse
in
the
browser,
that
will
be
amazing,
but
with
restriction
with
restrictive
features
like
you
cannot
access
that
the
file
system,
obviously,
but
you
just
enter
URLs
or
strings
and
it
will
resolve
right
but
I'm,
not
sure,
for
instance,
the
support
for,
for
instance,
translating
yeah
that
completed
things
like
translating
protobuf
to
json
schema.
That
should
be
that
we
should
have
this
working
on
the
browser
as
well
right.
B
B
B
C
B
B
They
are
really
parsing
async
API
documents
on
the
back
end,
but
for
different
purpose,
not
not
for
the
documentation,
but
they
already
have
the
code
sets.
It
would
not
be
a
problem
for
them.
I
guess
I'll
check
tomorrow
within
hours
so
and
regarding
plans.
So
what
do
you
think
next
steps
for
this
will
be
for
data
I?
B
Think
I've
been
working
on
breaking
down
the
the
parser
work
into
some
chunks,
smallest
chance,
so
we
can
work
on
them
right,
but
since
we're
new
to
go,
you
know,
we've
been
experimenting
a
lot
and
not
working
on
this
test.
Yet,
but
the
and
and
and
I
want
to
put
an
emphasis
that
this
is
just
for
the
parser
because
correct
me,
if
I'm
wrong,
but
I,
think
we.
B
It's
a
correct
me
if
I'm
wrong,
but
if
I
know
that
you
might
feel
right
now
that
things
are
a
little
bit
starter
or
stack,
because
we
are
working
at
the
same
time
in
the
person
to
spec
and
on
the
on
the
tooling,
but
we're
experimenting
at
the
same
time
both
right
and
it's
like.
How
do
we
move
forward
right?
B
So
how
do
we
move
forward?
My
answer
here
will
be
less.
Let's
keep
working
like
that
like
we're
doing
right
now.
We
are
in
a
very
strange
area
right
now,
where
we
don't
have
the
the
person
to
expect
yet
finish
Oh,
although
it's
almost
there,
but
it's
not
yet
finished
and
we
experimenting
with
the
new
language
so
for
something
crucial
as
a
parcel
like
a
parcel
right
and
we
experimenting
on
the
new
language.
B
So
I
will
keep
going
like
that
for
at
least
two
more
weeks
or
three
more
weeks
and
then
I'll,
just
or
even
during
this
week's.
What
I
can
do
it?
If
you
think
it's
it's
okay,
we
can
I,
can
I,
can
split
the
working
in
in
tasks
and
and
and
and
have
a
vision
of
what
we
have
to
do
in
order
to
have
a
full
parser
working
right
or
or
a
parser
fully
working,
not
a
full
person,
a
person
fully
working.
B
It
might
be
not
not
necessarily
with
all
the
features
with
all
the
the
things
that
we
would
like
to
have
like.
We
will
have
the
sched
instead
of
a
car
right,
but
you
can
do
something
a
place
with
it.
So
what
do
you
think
about
it
like
I'll,
create
this
task
or,
if
you
want
to,
if
you
want
to
sit
down
and
and
and
and
work
on
that,
breaking
that
the
whole
the
whole
planning
in
small
chance
that
if
anybody
can
compete
in
working
this
I'm
happy
to
let
you
do
it.
C
B
Will
no
no
no
I
mean,
and
what
we
have
is
a
plan
yeah.
It
might
be
confusing,
but
we
have
a
plan
on
the
on
the
vision,
but
I
want
to
have
actionable
right
like
tasks,
something
that
you
big
and
you
complete,
and
it's
damn
right.
Something
small,
but
we
have
is
a
very
broad
vision
right.
It's
a
very
broad
vision
right
now.
What
it
should
be
I
want
smaller
things
like
things
that
you
can
solve
in
a
in
a
in
a
nasty
room,
maybe
write
smaller
chunks.
B
C
B
B
B
If
we
split
the
work,
we
cannot
have
I
know
that
what
we
have
right
now
is
sister
in
the
in
the
github
pieces
on
the
parcel
repo.
We
have
a
few
tasks
there
that
they
are
interdependent
but
would
like
to
see
something
really.
That's
not
that
we
don't
have.
So
we
don't
have
dependencies
basically
between
the
tasks,
because
that
that
prevents
people
blocking
other
people
right
so
so
that
that's
what
I
was
saying
is
I
can
work
on
that.
If
you
want
I
can
do
it.
I
I
already
have
experience
doing
it.
B
B
E
I
think
it
would
probably
be
beneficial
if
it
is
your
breakdown
of
the
high-level
concepts
and
the
high
levels
areas
that
you
outlined
before,
because
there's
probably
already
things
that
you've
thought
through
at
that
lower
level,
but
that
we
could
we
could
do
with
having
in
a
formal
document
with
all
those
tasks
working
down.
I.
Think
so,
if
you
don't
mind
doing
the
work,
then
no.
B
B
A
point
there
I
mean
I,
don't
mind,
I'm,
just
saying
that,
because
I'm
working
on
other
things
at
the
same
time,
you
know
sometimes
these
things
might
take
time
to
be
completed.
On
my
side,
you
know
because,
as
you
I'm
also
looking
for
for
sponsors
and
and
and
and
writing
articles,
you
know
doing
the
social
media
staff
like
publishing,
like
he'll,
always
scanning
tweets,
all
these
things
and
sometimes
encoding
them
and
then
async
API
to
the
spec
right.
B
E
E
You
could
represent
that
as
both
the
boolean
and
the
object
and
a
kind
of
artificial
field
which
would
which
Bank
like
a
discriminator
to
say,
which,
which
one
is
active,
yeah
it'll,
be
ugly,
but
it
would
allow
you
to
represent-
and
you
just
have
to
if
then
based
on
the
value
of
that
discriminative
property
and
I,
think
we
can
eliminate
the
case
of
where
it's
a
reference
or
a
real
object.
If
we,
if
we
move
the
dereferencing
sort
of
earlier
in
the
parser
stage,
so
we
eliminate
all
the
refs
first.
E
B
B
B
Yeah,
most
probably
yeah,
now
to
be
honest,
I
I
have
never
I
never
had
this
problem
with
circular
references
outside
schema,
I
I've,
never
seen
it
like
inside
schema,
makes
sense,
because
you
know,
like
the
typical
use
case
of
you,
have
a
person
with
friends
right
and
then
each
friend
is
a
person.
So
with
friends
with
no
so
yeah,
okay,.
B
That's
that's
a
good
idea.
We
can
have
this
kind
of
this.
This
idea
of
having
a
disk,
emulator
I
think
it's
a
good
idea,
maybe
I
happy
I
can
explore
it
or
a
thief.
If
you
want
explore
it,
I
mean
just.
Let
me,
let's
do
something:
I'm
gonna
create
all
these
things,
a
list
of
tasks,
let's
say
or
issues
or
whatever
we
want
to
call
it,
and
then
we
would
just
each
a
fascist,
Pig
one
and
then
working
it
like.
We
were
just
saying:
okay,
yeah.
E
B
A
So
the
the
particular
problem
I
have
right
now
is
I
need
a
way
for
a
venting
producers
to
describe
the
schema
that
they
will
produce
and
they
happen
to
be
producing
cloud
events
they're
not
targeted
toward
a
particular
cue.
It's
not
like
I
can
describe
what
a
cue
will
output
it's
it's
an
entity
which
could
be
a
cue
or
it
could
be
just
an
object.
E
A
So
at
the
end
of
the
day,
if
you
collect
all
the
schemas
from
all
the
producers
on
a
particular
cluster,
you
might
get
something
that
looks
like
a
registry.
And
then
you
could
take
a
look
at
that
registry
and
create
a
function
that
consumes
a
particular
output
of
a
particular
source
or
maybe
a
set
of
sources.
A
That's
the
same
type
and
the
ultimate
dream
would
be
to
ask
that
registry
for
the
shell
of
what
that
function
is,
and
then
you
fill
out
what
what
the
work
actually
is
doing,
and
then
you
upload
that
backup
to
the
cloud,
and
now
you
have
a
service
function,
that's
operating
just
on
the
chunk
of
code
that
you
had
to
write,
but
you've
gathered
all
the
metadata
from
the
registry
and
I'm
looking
at
ways
to
power.
This
idea
and
I,
a
sync
API
seems
to
be
fairly
close
with.
B
Yeah
I
think
what
you're
interested
in
it's
it's,
it's
something
that
we're
gonna
work
on
the
next
milestone
for
version
2
and
it's
called
protocol
mappers.
So
so
the
idea
behind
protocol
map
is
to
have
information
about
the
protocol.
Like
would
you
say
like
use
or
exchanges
or
like
a
QP,
for
instance,
they
have
exchanges
or
partitions
for
Kafka
or
whatever
this
kind
of
information
that
you
need
for
specific
protocol
and
that's
not
use
across
all
the
protocols
in
messaging
protocols
right
so
yeah.
B
This
information
will
be
possible
possible
to
be
described
on
the
next
version
and
just
to
close
the
loop.
The
new
parser
will
also
implement
a
way
to
validate
all
these.
All
these
little
things
on
the
on
the
on
the
on
the
protocol
mappers
right
and
this
information,
so
people
will
be
able
to
create
just
a
small
parser
if
you
want,
or
a
station
schema
document
specifying
how
the
information
should
look
there,
we
will
take
this
JSON
schema
this
little
distance
command.
We
will
validate
against
it.
B
So
that's
that's
extensible
right,
like
anybody
can
create
any
protocol
mapper
or
any
map
for
a
specific
protocol.
If
you
want
like,
if
you
were,
if
you
have,
for
instance,
your
custom
protocol
in
at
Google-
and
you
want
to
use
it,
you
should
be
able
to
do
it
as
well.
You
just
provide
the
definition
to
the
async
API
parser
and
it
will
just
parse
it
so
close,
it's
just
too
close.
It'll
drive
like
so
it's
gonna
be
supported.
You,
you
will
have
this
kind
of
information
in
the
document.
B
You
will
have
not
only
the
ID
of
the
producer,
which,
if
I
don't
mind
as
if
I,
don't
remember,
if
I
remember
correctly,
I
think
it
was
a
conversation
with
you
or
something.
You
said
on
the
on
the
train,
a
live
channel
which
brought
me
to
the
idea
of
putting
an
ID
to
the
whole
document
right,
because
the
whole
document
represents
an
application
as
a
specific
application.
B
Think
I'm,
sorry,
it's
just
I
thought
it
was
you
sorry
I'm,
saying
I
thought
I
saw
it
on
a
native
or
probably
on
the
cloud.
Even
sighs,
I,
don't
remember
yeah.
So
the
idea
the
idea
was
to
have
an
ID
to
represent
the
implications,
so
producers
now
have
an
ID
right
and
consumers
as
well.
So
so
eventually
you
can
create
this.
This
registry,
like
you,
think
you
can
from
these
all
these
async
API
documents.
B
A
D
B
Cool
so
yeah,
it's
summarizing
a
little
bit.
The
last
two
weeks.
I
would
like
to
tell
you
that
so
funding
like
having
sponsors,
basically
it's
moving
forward
and
it's
looking
really
good,
so
I
will
update,
probably
on
the
next
meeting.
I
will
update
to
build
more
information
as
soon
as
I
have
permission.