►
From YouTube: Spec 3.0 meeting 1 (February 2, 2022)
Description
Notes: https://github.com/asyncapi/community/issues/250
Chat:
17:06:49 From Abir | @imabptweets : sorry cannot turn on the camera... I am actually out of station for this week..in a hotel..
17:10:00 From Abir | @imabptweets : yeah the second picture of versioning is not so maintainable. I feel
17:15:23 From Fran Méndez : Noted on the issue already.
17:16:06 From Abir | @imabptweets : having bit connection issues... I wanted to say... the schema should be more integrable and maintainable... probably need to think from that perspective..
17:16:19 From Lukasz Gornicki To Jonas Lagoni(privately) : I know how to do live stream next time! Yay!
17:17:50 From Jonas Lagoni To Lukasz Gornicki(privately) : Cool! xD
17:18:34 From Jonas Lagoni : Abir, do you mind adding your thoughts about the schema reusability between versions in the issue?
17:18:52 From Abir | @imabptweets : Sure I will add it.
17:23:42 From Fran Méndez : I’m writing down my thoughts in the issue
17:24:22 From Jonas Lagoni : asyncapi/spec#691
17:26:11 From Jonas Lagoni : asyncapi/spec#694
17:29:04 From Michael Davis : I’ve got to leave now, bye!
17:45:10 From Jesse Menning : Anand, where did you get the photo of GoT?
17:45:38 From Anand Sunderraman : I used to work for HBO, so they had a throne in the office !!
17:48:15 From Jonas Lagoni : https://github.com/asyncapi/spec/blob/master/CONTRIBUTING.md
A
B
Yeah,
I
don't
know
if
I
distracted
you
guys
with
my
display
picture,
but
I
I
didn't
follow
the
first
3.0
meeting,
but
I've
been
following
the
proposal
spec
that
fran
put
out,
so
I'm
just
curious
to
find
out
where
we
are
at
and
how
we
are
going
on,
because
if
that
proposal
goes
through,
then
I'll
be
very
confident
of
introducing
it
to
my
team,
because
otherwise
the
confusion
between
publish
and
subscribe
wouldn't
sit.
Well
with
my
team.
A
C
D
Sure
I
put
a
link
to
the
issue
in
the
screen.
I
don't
know
if
you
want
to
bring
it
up
or
do
you
want
me
to
share
mine,
okay
yeah?
We
could
read
it
there.
So
basically,
the
idea
here
is
that
you
know
schemas
can
have
different
versions
and
right
now
there
isn't
a
very
clear
way
to
have
different
versions
of
the
same
schema
in
an
async
api
file.
So
I
mean
we
could
like
the
example
I
gave
encoding.
The
version
number
in
the
name
is
not
ideal
at
all.
D
You
know
because,
well
I
think
it's
obvious.
Why
it'll
be
much
better
like
from
the
point
of
view
of
like
the
parser
and
stuff.
It
would
be
nice.
If
we
could.
You
know
the
parser
could
prevent
present
a
list
of
versions
of
a
particular
schema
by
name
and
then
you
know
the
whatever
template
is
consuming,
what
the
parser
gives
it
can.
D
Then
you
know
do
whatever
it
wants,
with
the
different
versions
of
a
schema,
so
yeah
right
now,
there's
no
easy
way
to
do
versioning
of
schemas,
and
so
you
know
I'm
sort
of
throwing
out
a
proposal
and
I
know
there's
different
ways
to
do
it.
I
don't
really
have
a
strong
feeling
of
how
we
should
do
this
as
long
as
we
can
at
some
point
have
persian
schemas.
So
that's
that's
about
all
people
are
welcome
to
make
you
know,
proposals
of
other
alternative
ways
to
do
it.
So
that's
that's
about
it.
C
Yeah
we'll
like
to
add
something
to
what
michael
is
proposing
there.
There
I'll
add
it
to
the
issue
later
and
it's
like
we
need
whatever
we
decide
whatever.
We
do
like
how
we
solve
this
issue,
which
I
think
we
should
solve
and
it's
to
be
compatible
with
existing
schema
registries.
Right,
like
you
know
like
solas
or
confluent,
or
you
know
like
whatever
or
epicure
or
whatever.
C
E
D
Well,
I
mean
it
would
require
a
change
to
the
parser
to
make
it
work
properly,
because
right
now
I
mean
the
parser
would
accept
that.
But
if
you
try
to
render
something
like
that
in
the
studio
you
just
sort
of
get
this
like
it
doesn't
render
the
schema
properly,
even
though
it's
technically
allowed.
So
we
would
need
to
put
in
support
in
the
parser
which
of
course
in
turn
means
that
we'd
have
to
have
an
official
way
to
do
it
in
the
spec.
D
E
E
D
E
E
A
D
B
Yeah,
so
actually,
I
saw
the
two
versions
and
one
thing
that
I
am
getting
confused.
They
are
like
what,
if,
if
you
are
having
same
properties,
some
properties
will
be
similar
or
the
same
ones
in
version
1,
0,
0
and
version
1
0..
So
are
we
going
to
repeat
all
of
all
of
those?
It
will
be
something
like
code,
duplication
or
something
which
we
can
do
like
add
on
to
the
versions
so
that
we
don't
duplicate
the
things
out.
B
B
D
A
Yeah
yeah,
that's
definitely
an
excellent
question.
I
would
remind
adding
that
to
the
discussion
of
the
issue,
because
it's
a
really
important
point
to
have
thought
of,
because
if
you
split
it
up
like
this,
it's
gonna
maybe
be
a
bit
tricky
to
do
exactly
what
you
do.
What
you
talked
about
with
reusing
like
a
core
schema.
E
Well,
I
think
I
agree
with
fran.
I
do
think
in
the
sort
of
emerging
topology
into
relationships
with
the
schema
registry
is
going
to
be
increasingly
important,
so
thinking
about
ways
that
that
we
can
more
efficiently
interact
with
scheme
registries,
I
think
is
really
is
important.
I
think
it's
great
and
should
be
should
be
noted
on
the
proposal
too.
D
Yeah
I
mean,
if
we're
considering
having
a
mechanism
to
point
to
external
files
or
external
resources
like
web
resources
or
whatever.
Then
that
could
be
a
way
you
know
because,
like
with
confluent
or
whatever,
I
guess
you
can
refer
to
schemas
by
some
sort
of
uri
right
where
the
version
would
be
part
of
the
uri.
So
referencing
external
things
and
schema
registries
and
versions
could
all
sort
of
be
solved
that
way,
at
least
by
you
know,
if
we
have
a
way
to
reference
external
things,.
E
D
Don't
think
it's
so
much
about
managing
schema
versions,
but
just
about
like
if
you've
got
you're
representing
an
event
and
or
a
message,
and
that
message
uses
a
particular
version
of
a
particular
schema
and
it
can,
you
know,
like
some
sort
of
tooling,
can
extract
that
from
a
schema
registry.
So
you
just
need
a
reference
in
in
the
async
api
file.
You
don't
it's
not!
You
know,
I
don't
really
consider
it
managing
schemas
as
much
as
saying
that
this
message
refers
to
a
schema.
That's
in
a
registry
somewhere.
E
D
No,
I
I
would
consider
it
like
an
option
like
either
you
can
refer
to
some
schemas
somewhere
else,
whether
it's
in
a
local
file
or
a
schema
registry,
or
you
could
contain
the
schema
within
the
file.
If
that's
more
convenient,
you
know
if
it's
something
that
you
want
to
share
with
more
people,
I
guess
not
all
schema
registries
are
publicly
accessible.
Probably
most
aren't
right.
In
fact,
almost
certainly
most
aren't
so
there's
that.
B
Another
school
of
thought,
at
least
in
my
previous
organization.
They
did
considered
versioning
messages,
but
then,
if
you
had
to
version
the
schema
messages,
then
you
would
also
sort
of
attach
a
version
number
to
your
channel
or
your
topic
saying
you
know
this
topic
is
associated
with
so
and
so
version.
Maybe
that
is
another
thing
to
consider.
Why
do
you
want
to
version
it?
And
if
you
need
to
do
that,
then
maybe
associate
the
version
with
your
channel
or
topic.
E
Yeah,
I
think
that
there's
a
challenge.
Sorry
michael,
I
think,
there's
a
challenge
there
with
kafka
in
particular,
where
you
know
the
messages
from
the
beginning
of
time
are
there,
and
so
you
have
naturally
an
evolution
of
messages
on
the
channel
that
you
wouldn't
want
to
necessarily
you
know
for
every
version
you
know
create
another
channel
because
you
want
to
have
that
continuous
from
the
beginning
of
time
sort
of
thing,
so
you
want
to
have
a
full
listing
of
all
the
potential
schemas
that
you
could
have
on
that
kafka
topic
available.
D
Yeah,
that's
true,
and
I
think
you
know
that
I
like
the
idea
of
having
it
in
topics
if
you're
not
using
kafka,
if
you're
using
you
know
some
other
broker,
that's
more
flexible
with
topics.
I
guess
we
could
consider
it
a
best
practice
to
have
the
version
as
part
of
the
topic,
but
I
you
know,
I
don't
think,
there's
a
way
to
really
enforce
it.
E
It
yeah
in
the
same
way
like
your
first
example
like.
Is
it
possible
to
you
know,
create
sort
of
a
quasi-naming
standard
to
introduce
versions
like
you
did
person
underscore
one
underscore
two
under
underscore
zero:
zero
like
that,
will
do
the
job,
but
it's
not
particularly
efficient
or
cr.
You
know
standardized
right.
D
Anyway,
I
don't
think
we're
going
to
solve
this
problem
today.
I
just
wanted
it
to
be
known
that
that's
an
issue
that
I'm
concerned
with
and
people
can.
You
know,
read
the
issue
and
comment
and
hopefully
we'll
make
some
progress.
That
way.
I
know
it's.
I've
only
got
10
minutes
before
I
have
to
leave.
So
we
could
move
off
this
unless
anybody
has
something
to
add.
C
C
Instead
of
doing
this,
we
can
come
up
with
annotation,
which
is
saying
something
like
person
at
and
then
and
then
the
version
right,
and
it
will
be
like
officially
like
this
right.
If
you
put
the
version
there,
if
you
don't
put
any
version,
we
assume
that
this
is
there's
no
version.
This
is
like
it's
not
version.
This
is
or.
F
F
D
I
don't
know
just
yeah.
No,
I
like
that.
That
way,
you
could
have
the
real
version
number
instead
of
like
something
that's
kind
of
hacked
with
these
underscores
you
know,
yeah,
like
would
be
nice
if
the
version
was
real
version
like
1.0.0,
instead
of
using
underscores
so
yeah.
If
something
that
could
be,
you
know
reliably
parsed,
I
guess
would
be
helpful.
C
E
E
C
We
already
do
it,
I
mean
like,
if
you
think
about
it,
we
already
have
description
and
summary
in
multiple
places,
so
we
somehow
we're
somehow
doing
this
info
thing
on
many
places.
That's
why
I
was
thinking
like,
maybe
if,
in
the
future,
we
want
to
expand
to
have
more
version
more
info
about
the
version,
then
this
add
trick
will
not
work
right
right,
right
and
that
will
be
will
be
up.
E
A
E
E
E
Essentially,
the
concept
would
be
similar
to
how
we're
using
protocols
right
now
and
we
have
bindings
for
that.
It
seems
like
just
as
protocol
space
is
relatively
infinite.
The
the
format
space
is
relatively
infinite
as
well,
and
each
of
them
have
their
own
little
individual
quirks
and
so
trying
to
accommodate
them
all
within
the
base.
Spec
seems
like
rather
fool's
errand,
so
I'm
interested
in
introducing
that.
I
think
I
need
to
flush
it
out
more.
E
E
F
F
E
Think
that
we
are
largely
trying
the
same
ground-
and
I
you
know
in
the
previous
previously
we've
talked
about
that-
I
think
I'm
largely
aligned
with
you.
I
I,
I
think,
there's
a
lot
of
common
ground
there
and
I
think
I
just
need
to
devote
some
more
time
to
thinking
about
how
those
two
things
intersect
and
if
they
don't,
I,
I
I
think
that
your
proposal
is
pretty
a
pretty
good
one
too.
E
E
Yeah,
690
and
692
don't
seem
to
have
any
popular
support
or
not
particularly
widespread
popular
support,
so
I'll
withdraw
those
and
we'll
move
forward
with
some
other
some
other
plans.
I'm
looking
forward
to
the
more
deep
technical
discussions,
both
with
you,
jonas
and
fran,
and
I
have
been
talking
about
maybe
doing
the
comparing
to
contrast
between
the
different
ways
to
solve
the
the
publish
and
subscribe
problem
so
yeah.
I
think
that's
that's
the
direction.
I'd
rather
have
at
this
point,
so
I'll
close
I'll
close
the
issue.
G
F
Yeah,
I
will
be
click
quickly.
I
added
suggestion
to
create
the
the
branch
in
the
spec
repository
for
the
next
major
version,
as
we
do
for
the
minor
version
and
start
creating
the
peers,
because
I
see
that
if
people
see
the
the
pull
request,
they
are
more
active
than
in
the
discussion
in
the
issues
so
yeah.
F
F
G
G
G
A
G
Actually,
we
have
we're
gonna,
have
it
in
tooling,
so
parser.js
the
works
on
intent,
driven
api
started,
and
there
also
will
have
to
be
a
major
next
major
branch
created
and
therefore
there
will
also
have
to
be
the
same
branch
in
generator.
So
we're
gonna
have
already
few
few
rebels
that
approach
big
time.
A
A
A
A
G
Like
the
most
important
is
to
make
it
loud
about
it,
so
we're
not.
Since
it
was
created,
we
did
not
really
publish
it
anywhere
and-
and
I
recall
that
there
were
a
few
folks
in
the
community
that
already
suggested
that
wish
like
that,
the
spec
should
do
it
at
least
lorna,
for
example.
I
remember
not
sure
others.
So
first,
I
would
suggest.
G
Oh
nick,
as
well,
okay,
so
yeah!
Well,
what
I've
learned
last
year?
It's
not
enough
to
have
issue
and
expect
people
will
come
and
comment.
You
just
have
to
ping
them
directly,
so
definitely
ping
people
that
we
already
know
that
were
interested
with
this
feature
and
try
to
search
through
slack
with
some
keywords.
If
somebody
already
mentioned
it,
we
have
the
whole
history
of
slack.
Luckily,
so
maybe
you'll
find
some
names
and
then
yeah.
Let
me
know
I
can
push
it
through
our
social
media
as
well.
B
C
So
if
I
have,
I
have
myself
have
the
the
the
feeling
and
my
opinion
is
that
not
hundred
percent
sure,
but
my
gut
feeling
says
that
we
should
go
for
defining
a
collection
of
applications,
so
we
will
allow
it
right,
I'm
still
a
little
bit
like
scared,
maybe
because
there's
a
huge
change
right
for
all
the
tools
and
for
the
spec
as
well.
So
so
maybe
that's
what
it's
holding
me
off,
I
would
say
so
so
yeah
other
than
that.
C
I
don't
think
another.
Another
approach
that
I've
taken
in
the
past
is
is
saying
or
you
can
you
can
do
a
poll
like
people
are
suggesting
or
you
can
communicate
it
and
then
at
some
point.
If
nobody
replies
or
little
people
reply,
then
you
can
just
say
like
hey,
so
we
decided
that
we
go
with
this
and
then
people
get
scared
like
suddenly
like.
Oh
so
then
you
start
getting
feedback
quickly
because
you
scare
people
so
and
it's
not
decided
it's
just
you.
You
know
you're
just
playing
that
game.
C
C
If
still
you
don't
get
anyone
complaining,
then
it
means
either
people
don't
care
or
they're
fine
with
it.
So
or
they
just
don't
use
it
or
they
just
don't
eat
they.
Don't
care
or
they're,
not
they're,
not
reading,
that's
also
a
possibility,
but
we
can't.
We
can't
force
people
to
check
slacking
day
or
issues
or
twitter,
or
you
know.
G
A
A
C
I'm
actually
preparing
the
new
season,
and
it's
going
to
be.
This
is
going
to
be
a
mix
of
discussing
these
things,
like
you
know,
challenges
that
we're
facing
on
amazing,
kpi
and
also
some
interviews
to
some
people
in
the
in
the
space.
So
it's
going
to
be
like
a
mix
between
the
two
and
the
way
I'm
I'm
structuring.
The
in
this
case
is
is
for
interviews.
Of
course
you
have
to
prepare
up
front.
C
Maybe
not
questions,
but
what
I
prepare
upfront
is
just
a
list
of
things
of
topics
in
case
the
conversation
is
getting
stuck
or
you
know
or
cold,
and
you
know
you
have
some
topics
there
that
can
revive
the
conversation.
So
so
yeah,
that's
what
I
do.
Usually
it's
usually
not
me
that
people
usually
get
engaged
into
the
conversation.
So
that's
fine.
C
A
Yeah
I'll
get
sold
with
myself.
Okay,
it's
all
it's
all
broken
yeah
the
worst.
Now,
I'm
not
thinking
about
doing
it
similar
to
this,
but
just
pinging
like
starting
immediately
just
saying
this
state
we're
gonna,
discuss
this.
Here's
the
zoom
link
more
or
less
and
here's
the
schedule
like
here's.
The
key
points
that
we
want
to
discuss
about
these
specific
issues
and
then
just
see
how
it
goes.
I
think.
G
G
C
C
C
No,
no,
it's
still
confusing.
As
it's
confusing
me
actually,
the
other
day
I
got
confused
twice.
It
was
like
double
confusion,
so
I
thought
I
was
confused
and
then
I
realized
I
wasn't
confused,
so
it
was
right.
So
I
was
double
confused
and
yeah.
It
was
weird
it
was
like.
Then
we
go.
We
need
to
get
rid
of
this
as
soon
as
possible.
F
C
Yeah,
that's
why
my
proposal
speaks
about
like
if
you
want,
if,
in
the
case
of
client
server
communication
like
with
typical
websocket
case,
what
happens
is
that
you
have
an
async
api
file
for
the
server
and
another
one
for
the
client?
You
don't
have
one
for
both
anymore
and
it
says
it
doesn't
say
what
it's
expecting.
It
says
what
it's
doing
so
it
says
I'm
sending
it
receiving
and
then
on
the
client.
It
will
obviously
say
the
opposite
right,
but
then
it's
clear.
It's
like
okay.
C
B
A
G
A
C
C
So
because,
aside
from
spec,
we
also
have
to
update
the
tooling
right
and
as
we
were
speaking
before
like
if
we
have
to
consider
that
now,
tools
have
to
take
a
collection
of
applications
instead
of
just
one
then
tools.
This
is
not
just
a
simple
change
to
doing
the
tools.
It's
something
that
you
do
in
you
know
in
a
day
or
two
right,
so
so
some
tools
might
even
lose
meaning
or
change,
meaning,
somehow
so
so
yeah.
So
it's
something
to
take
into
account
as
well,
plus
the
parser
itself.
C
I
think
we
should
be
releasing
intern-driven
parser
api,
so
people
can
adopt
it
as
soon
as
possible
and
then
once
we
release
version
3,
they
have
no
breaking
changes
on
their
code
right
so
that
that
would
be
the
idea,
at
least
for
people
who
already
adopted
it
right
for
those
who
don't
adopt
the
our
parser
and
our
intern
driven
api,
and
then
we
can
do
match
it's
just
a
major
version.
It's
breaking
change.
C
B
A
Yeah
I'll
try
to
keep
in
mind
that
we
have
to
be
more
visible
in
terms
of
what
needs
help
and
creating
these
issues
that
are
maybe
smaller
in
scope
or
whatever
it
might
be.
That
makes
it
easier
to
contribute,
regardless
of
what
time
you
have
on
your
hands
right,
I'm
just
gonna
write
it
down.
So
I
remember
it.
G
It
doesn't
have
to
be
like
super
long
essay,
rather
just
a
a
short
one,
with
the
most
important
information
like
how
we
organize
work,
that
we
have
meeting
that
we
have
that's
the
link
to
all
these
stuff.
That
needs
help
like
like,
like
simpler
way
to
provide
a
a
go
to
page
to
anyone
like
so
later
on.
Whenever
somebody
joins
and
wants
to
help
like
you
just
send
a
link
to
the
blog
post,
that's
I
would
advise
to
that.
That
would
be.
C
C
Yeah,
I'm
just
repeating
this,
because
I
I
want
people
to
to
stop
thinking
that
there
is
a
core
group
of
people
doing
the
work
and
the
other
ones
are
there
to
to
help
a
little
bit
right
here
and
there
it's
like.
No
there's
no
code
group.
I
mean
it's,
of
course
those
who
are
working
full-time.
They
have
more
time
to
do
stuff,
of
course,
but
yeah
they
are.
E
You
might
know
some
something
really
sad,
and
this
is
a
total
digression,
so
I
apologize,
but
you
know
we
had
this
really
great
article
on
solace.com
and
I
was
like
well,
let's
share
it
over
to
async
api.com
and
we
were
ranked,
I
think,
number
five
in
terms
of
like
open
api
versus
async
api
on
google,
and
now
we
are
like
not
even
listed
on.
Google
like
async
api
has
completely
destroyed
our
search
rankings.
So
yeah
I
mean
we
may
not
be.