►
From YouTube: Spec 3.0 meeting #3
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
C
C
A
And
yeah
replying
to
what
jonas
was
saying
it
was
about
zoom.
As
far
as
I
know,
lucas
told
me
that
it's
all
in
the
stream
restream,
we
have
to
say
restream,
otherwise
it
doesn't
caption
it
correctly.
D
A
Actually,
he
told
me
this
privately
hey,
you
have
to
take
care
of
the
live
stream.
It's
all
in
red
stream,
already
configured.
A
Maybe
I
don't
know,
let's
see
well,
I
was
going
to
say,
like
I'm,
happy
to
get
out
of
the
call
if,
if
we
hit
the
limit,
but
I
can't
otherwise,
it
will
finish
the
call.
F
G
E
E
E
E
We
even
have
a
logo.
I
think
here
no
dammit.
D
H
D
F
A
Background
yeah,
you
hear
the
mouse
click
and
then
yes,
a
second
after
is
hey
and
I
hey.
We
have
people
in
chat,
welcome.
A
A
E
D
D
D
D
A
That's
what
people
do
with
with
all
hands
calls
right
there
in
the
like
the
background.
While
you
keep
working
or
build
another
stuff
right.
F
H
A
A
D
D
D
Of
the
different
solutions
that
there
is
whether
we
actually
should
support
it
and
to
who
such
a
feature
would
be
beneficial,
for
example,
does
it
benefit
the
architecture?
Does
it
benefit
the
consumer
of
the
or
external
parties,
or
does
it
benefit
the
engineer
that
actually
creates
applications
or
whatever
it
might
be
so
yeah?
D
I
will
try
and
particularly
define
the
basically
the
same
as
an
agenda
for
this
meeting,
so
it's
more
precise
what
we
have
to
go
through
in
order
to
get
to
the
goals,
but
other
than
that
it
will
be
an
open
discussion
and
just
see
where
it
takes
us.
Basically,.
D
F
D
F
Some
permissions
anyway,
so
can
you
keep
the
tab
open
yeah,
please
thank
you
which
comment.
F
Scroll
down,
yes,
if
yeah
a
bit
upper.
F
Right
there,
one
one
earlier,
which
is
magic.
Sorry,
because
I
cannot
share,
I
don't
know
what
happened.
F
Well,
anyway,
there
are
like
few
comments
in
this
issue
about
the
proposal
to
solve,
publish
and
subscribe
confusion
that
fran
made
a
few
months
ago.
F
What
I
want
to
give
a
quick
update
on
this
is
that
there
are
some
work
that
has
been
already
included
in
2.3
and
some
other
spending
on
for
3.0,
but
still
there
were
some
some
issues
or
concerns
that
we
had
to
investigate
and
solve
so
recently
magic
raised
some
concerns
about
the
development
experience.
F
F
The
point
is
that,
as
I
said,
matcha
cries
some
concerns
regarding
development
experience
so
that,
with
the
changes
we
we
we
suggested
here
we
might
adding
some
penalty
on
this
experience.
User
experience-
I
I
agree
with
that,
but
I
don't
I
couldn't
find
a.
I
could
balance
between
providing
the
new
feature,
keeping
a
good
user
experience
on
on
the
solution.
A
Yep
so
from
my
side,
I
think
so
magic
reach
out
privately
after
these
comments
and
explain
the
the
real
issue
behind
this,
because
I
couldn't
understand
what
he
was
saying
and
so
apparently
the
thing
is
that
you
can
have
a
set
of
messages.
A
Let's
say,
10
messages
on
the
given
channel
on
a
given
topic
right
and
certain
certain
applications
will
publish
some
of
these
messages.
A
subset
of
this
10
and
certain
applications
will
subscribe
to
these
messages.
A
So
there
is
no
easy
way
to
know
which
one
say,
for
instance,
if
you
declare
them
on
the
channel
not
on
the
operation
like
which
one
am
I
publishing
and
which
one
am
I
subscribing
to
from
these
10
I'm
just
I
just
want
to
subscribe
or
publish
one
of
them,
then
my
response
was,
you
can
define
it
on
the
operation
on
the
operations
you
can
use
dollar
ref
mechanism
and
say
I
want
to
publish
only
this
specific
message
problem
with
this
or
the
ux
penalty.
That
we're
talking
about
here
is.
A
That,
on
the
on
the
channel,
you
have
a
dollar
ref,
pointing
to
ten
different
messages,
message,
one
two:
three
up
to
ten
and
on
the
on
the
operation.
You
have
a
dollar
draft
to
message:
four,
for
instance,
so
you
end
up
with
two
dollar
refs,
pointing
to
the
same
to
the
same
message.
So
it's
a
duplication,
it's
a
duplication
of
things,
so
you're
you're,
specifying
that
you
want
message
for
on
your
operation
and
on
the
channel
right.
So
like
there's
a
bit
of
repetition,
there.
A
I
mean
honestly
to
me:
I
don't
think
it
matters
a
lot.
I
understand
the
concern
that
you
have
two
dollar
reps
there.
Okay
might
be
a
bit
of
a
pain
that
you
have
to
reference
both
messages
into
the
same
message
in
two
places.
Another
thing
that
I
wanted
to
suggest
is
that
I
think
sergio.
If
I
understood
correctly,
this
was
your
proposal
that
we
don't
use
dollar
refs.
We
use
message
ids,
so
we
assign
ids
to
messages
and
therefore
on
the
operation.
You
reference
the
id
of
the
message
that
you
want
to
use.
A
A
Still
like
you
still
have
the
same
problem,
you
don't
have
two
dollar
refs.
You
have.
You
have
two
ideas
right.
The
same
idea
repeated
in
two
places,
so
duplication
is
still
there.
Just
not
the
dollar.
Rev
is
going
to
be
the
message
id
so
yeah.
I
mean
to
be
honest,
like
looking
forward.
I
would
love
to
move
out
from
using
a
lot
of
dollar
ref,
specifically
when
it's
inside
the
same
document.
A
You
know
without
having
to
use
a
dollar
ref
mechanism,
but
that's
another
discussion
so
so
yeah
like
I
can
unders.
I
can
see
that
we
go
through
the
message
id
option,
but
the
problem
remains
there,
like
the
application
is
still
there
and
if
we
make
dollar
ref
on
channels
and
the
message
id
on
the
operation,
then
you're
using
two
different
mechanisms
to
to
refer
to
the
same
thing
to
the
message
in
this
case.
So
this
could
be
more
confusing.
A
So
I
don't
know
like
I,
I
really
to
be
honest
to
me
like
I
don't
think
it's
going
to
be
a
concern.
I
don't
think
it's
going
to
be
a
problem,
because
what
we're
saying
there
is
so
here's
a
list
of
potential
messages
that
anyone
in
the
company
can
publish
to
this
topic
or
can
subscribe
from
this
topic.
But
this
message
can
be
flowing
through
this
topic
and
anyone
in
the
company
can
do
it,
and
this
particular
operation
is
about
this
specific
message.
A
Of
course,
there's
a
repetition,
but
I
think
it's
cool
like
it's
good,
because
it
lets
you.
It
gives
you
the
power
of
standardizing
governance
over
the
messages
at
company
level
or
at
domain
level.
If
you
want,
or
at
a
bigger
level
and.
A
And
how
can
I
say
like
it
still
gives
you
the
power,
even
though
you're
standardizing
at
company
level?
It
still
gives
you
the
power
to
to
tweak
it
to
to
be
more
specific,
like
for
this
specific
application
for
this
specific
operation.
I
don't
want
any
of
these
messages
or
all
of
these
messages.
I
want
just
one
right,
so
it
gives
you
this
power,
but
so
magic.
What
was
suggesting
is
like,
let's
get
rid
of
messages
on
on
channels.
A
If
we
do
that,
then
we're
penalizing
other
people
we're
penalizing
this
use
case
where
you
want
to
convert
all
your
messages
at
company
level
and
make
sure
that
that
not
like,
like
people,
cannot
just
publish
whatever
they
want
on
whatever
topic
right.
The
cool
thing
about
the
cool
thing
about
having
them
defined
in
channels
is
that
this
is
like
the
restriction
like
at
company
level.
You
can
pelvis
one
of
these
10
messages.
A
If
we
remove
this,
then
I'll
put
this
one,
you'll
publish
another
one
then,
and
it's
going
to
be
it's
going
to
be
chaotic,
because
my
definition
of
the
operation
is
going
to
be
in
this
file.
Your
definition
of
the
operation
is
going
to
be
in
another
file
and
unknown
files
in
unknown
places.
So
how
do
you
gather
them
all
of
them
and
make
sure
that
you
collected
all
the
potential
messages
that
can
flow
into
this
message?
A
You
don't
you
have
you
have
no
way
to
do
it,
because
you
always
fear
that
there
might
be
another
http
file
somewhere
where,
where
someone
is
defining
a
completely
different
message,
so
so
yeah,
I
think
it
might
be
a
trade-off
that
you
have
to
kind
of
duplicate
there,
but
it
gives
you
a
lot
of
power
in
this
case.
A
C
I'll
say
that
I
I
am
very
sympathetic
to
what
you
said
fran.
I
do
think
that
there's
challenges
in
that
you
know
what,
if
an
application
defines
that
it
sends
a
message,
that's
not
listed
in
the
channel,
you
know,
and
you
think
you
speak
well
to
the
conf-
the
need
to
govern
things
at
a
channel
level.
I
think
it's
a
very
common
enterprise
use
case,
but
you
know
that
still
doesn't
prevent
a
sort
of
rogue
application
from
writing
or
at
least
defining
the
rights
to
a
particular
channel.
C
C
I
wonder
if
there
is
some
sort
of
way
to
sort
of
create-
and
this
is
more
of
a
more
of
a
json
schema
thing
where
you
know
we
inherit
the
list
of
of
messages
from
the
channel
and
then
you're
allowed
to
select
one
from
that
list
of
particular
messages.
I
don't
know
if
there's
a
an
elegant
way
of
doing
that.
In
other
words,
you
have
a
list
of
potential
ids
that
are
defined
on
the
channel.
D
D
D
That's
a
great
question
because
we
can
do
it
with
json
schema
and
we
can
force
all
parsers.
Let's
say
that
all
parsers
use
our
json
schema
files
to
validate
an
async
api
document.
We
could,
in
theory,
I
think,
match
these
definitions
between
what's
defined
in
the
operations
down
here.
This
is
what's
defined
up
here,
but
if
not,
it
would
require
some
extra
check
from
on
a
parcel
level,
and
we
already
have
a
few
on
the
javascript
parser,
which
kind
of
cross
match
those
things,
I'm
not
sure
which
one
is
best
to
do.
D
C
Got
it
yeah,
I
mean
to
me
that
seems
like
a
promising
way
for
it.
I
have
not
spent
as
much
time
with
these
particular
comments
as
I
should,
but
it
sounds
like
a
really
interesting
way
forward.
D
A
quick
question
like
if
we
had
to
like
boil
it
down
like
the
too
long
didn't
read
kind
of
thing
is
because
we
want
reusability
for
channels
and
messages.
You
have
to
add
this
keyword.
F
I
would
say
it's
more
like
a
constraint
right
like
if
a
message
is
not
present
on
the
channel,
you
won't
be
able
to
use
it
on
the
operation
if
we
want
to
go
in
that
direction,
because
we
could
also
don't
force
that
that's
another
concern
raised
a
few
comments
earlier.
I
think
like
if
we
don't
force
that
whoever
wants
to
write
whatever,
like
it's,
it's
open
to
their
user
interpretation
right,
but
the
concern
was
again
on
on
development
experience
like
if
you
give
tons
of
options,
it's
gonna
be
maybe
harder
to
understand.
E
A
I
think
yeah
like
if
you're,
given
a
lot
of
options
like,
for
instance,
whatever
is
defined
on
the
operation,
might
not
have
to
be
defined
on
the
channel,
which
was
it
wasn't
my
proposal.
But
let's
assume
for
a
second
that
we
could
do
this.
So
you
can
define
something
different
on
operation
and
channel.
A
I
think
it's
good
I
mean
like
well
in
this
case
it's
going
to
be
yeah,
we're
going
to
end
up
with
a
lot
of
edge
cases
where,
like
like
I
mentioned
before,
like
like
in
the
case
where
people
are
using
it
only
on
operations,
but
not
in
channels
like
how
do
you
get
them
all
the
messages
that
have
that
are
being
published
to
to
specific
channel
to
a
specific
topic
you
can't
so,
but
in
other
cases
you
will
be
able
to
get
them
when
it's
defined
on
channels.
A
So
I
will
not
go
this
way.
I
will
be
like
constraining
like
you
said
that
so
my
proposal
was,
I
don't
know
if
it
if
I
was
clear
on
the
proposal,
but
it's
like
whatever
is
in
channels
it's
the
truth
and
then
operations
define
a
subset
of
what
is
there
right?
So
it's
like
either
all
of
them
or
just
one
of
them.
A
A
And
I
think
in
terms
of
user
experience,
it
might
be
worse,
but
you
may
I
mean
you
may
or
may
not
agree
with
me
here,
but
in
the
medium
long
term
I
will
love
to
see
people,
not
writing
async
api
by
hand
anymore
right,
so
that
will
be.
If
you
can,
if
you
want
to
do
it,
you
will
be
able
to
do
it,
of
course,
but
I
think
we
should
go
in
a
direction
where
people
have
enough
tools
in
different.
I
mean
async
api
tools
or
it
can
be.
A
You
know
like
solas
or
postman
or
whatever
other
tools
where
they
don't
need
to
write
async
files
by
hand.
That
means
that
this
duplication
concern
on
the
user.
Experience
disappears
because
you're
not
editing
it
by
hand,
so
so
yeah
and
you're
not
changing
it
by
hand
either.
So
so
yeah,
that's
not
really
a
problem
and
that's
the
direction.
I
would
love
this
to
to
take
like
people
like
the
same
way.
A
You
don't
edit
pdf
documents
on
your
code,
editor,
you
open
it
on
microsoft,
word
or
or
adobe,
acrobat
or
whatever,
and
you
edit
there
and
you
save
your
changes.
You
could,
anyway,
you
could
open
a
pdf
on
your
code,
editor
and
start
editing
it,
but
who
does
that
right?
So
I
think,
ideally,
we
should
take
this
direction
like
the
the
format,
the
async
pay
format.
A
It's
like
an
internal.
If
you
want
internal
format
in
the
internal
format,
right
that
nobody
should
be
caring
about
right
other
than
people
who
are
in
love
with
specs,
then,
okay,
these
people
are
I'm
sure
these.
These
people
will
not
complain
about
having
to
duplicate
things
right.
A
F
Yeah
I
I
just
want
to
write
a
quick
concern
that
I've
even
rise
earlier
trying
to
be
quick,
so
you
said
fran,
you
say
that
people
will
declare
define
their
operations
in
several
files.
A
A
F
A
To
I
want
to
like
point
to
a
difference
like
what
you
said
is
like
it's
not
ideal,
but
it's
possible.
It's
doable.
What
I
was
saying
is
impossible
right,
like
it's
impossible
to
make
sure
that
you
gather
all
the
operations
that
are
defined
in
all
async
pay
files
in
your
company,
because
you
will
always
fear
that
there
is
one
async
pay
file
that
you
didn't
take
into
account
and
and
therefore
you
will
always
live
in
fear
that
you
missed
something.
A
So
it's
you
know
like
how
do
you
call
this
like
it's
and
determinate
like
it
is
impossible
to
determine
the
state
of
something
like
100
sure,
while
the
other
thing
is
more
a
company
process,
and
this
is
something
they
have
to
take
care
about,
not
as
yeah
you're
right.
I
agree
with
you,
though,.
C
There
is
a
normative
assumption
here
that
we
are
that
you
should
know
exactly
which
messages
are
in
your
channel,
which
I
think
actually
is
a
good
normative
assumption.
But
I
I
agree
that
we
are
sort
of
forcing
people
to
adopt
a
certain
certain
model,
but
I
would
say,
if
you're
using
async
api,
to
define
your
your
infrastructure,
maybe
you've
already
made
that
normative
choice.
That
some
level
of
governance
is
a
is.
D
I
just
wanted
to
quickly
raise
and
not
an
issue,
but
if
you
go
with
the
direction
of
ids
from
messages,
we
have
the
feature
that
was
implemented
where
you
can
reference
a
server
and
a
specific
channel
together
has
a
bit
of
ambiguity,
which
is
not
that
well
defined
and
vladimir
have
have
raised
an
issue
on
this,
and
this
will
be
exactly
the
same
kind
of
issue
that
you
will
be
facing
with
with
channels
and
messages
that
has
to
be
well
defined
within
the
spec.
So
it's
just
to
raise
the
issue,
not
not
anything
else.
D
D
Okay,
so
next
up,
I
wanted
to
quickly
not
raise
up.
I
guess
raise
a
point
in
order
to
like
which
repositories
are
ready
to
accept
change
for
the
next
major
version.
The
only.
D
The
only
tools
I
found
so
far
was
that
the
parser
repository
has
this
next
major
version
branch,
all
of
the
other
is
or
other
all
of
the
other
repositories
do
not
have
this
in
place
yet,
meaning
that
we
are
unable
to
move
forward
in
changing
the
specifics
of
json
schema,
for
example,
for
the
spec,
and
we
are
not.
I
guess
we
are
able
to
do
it
for
the
password,
but
not
the
spec
repo.
D
F
Yeah,
I
want
to
add
something
before
you
jump
in
in
the
next.
I
also
added
a
comment.
There
is
a
slack
thread
that
I
created
like
for
you
yeah,
okay,
so
should
we
also
adopt
this
kind
of
the
next
major
style
of
branching
for
minors,
because
semantic
release
also
allows
that,
instead
of
using
the
tags
that
we
were
using
with
a
date,
you
know,
I
think
it
it's
worth
to
keep
just
always
a
branch
for
the
minor
and
one
for
the
major
I
mean
it's.
It
feels
like
comfortable
right.
D
F
Yeah,
I
guess
this
is
only
related
with
new
releases
of
the
spec
and.
D
That
is
actually
a
good
point.
I
didn't
thought
about
that
yeah
for
spec
releases,
where
we
have
to
have
all
of
the
changes.
So,
instead
of
waiting
for
the
last
minute
to
merge
everything
into
the
repositories,
we
do
it
continuously
into
these
smaller
branches
and
then
in
the
end,
we
just
merge
one
pi
in
each
repository
and
then
we
are
good
good
to
go
basically
right.
That's
the
idea,
as
I
understand
that
makes
sense,.
A
So
I
think
I
think
it's
it's
a
good
idea
and
it's
better
to
you
know
for
for
automating
stuff,
because
you
always
right
now
the
way
it
is
right.
Now
on
our
github
action,
we
have
like
a
pattern
which
is
asterisk,
asterix
bass,
release
branch
name.
A
And-
and
I
think
I
will
make
it
like
this-
and
the
json
schema
definitions
and
on
the
spec,
but
not
on
the
parser-
maybe-
and
I'm
gonna
explain
why.
So
I
think
we
start
trying
to
go
in
a
different
they're
in
a
different
direction
now
with
parser,
which
is
right
now,
when
we
have
something
to
add
to
the
spec.
A
What
we
do
is
we
add
it
to
the
parser
as
well,
and
we
try
to
ship
it
together
with
the
spec,
so
all
at
the
same
time
at
the
spec
and
the
json
schemas
of
the
spec.
So
the
three
at
the
same
time,
but
I
will
start
encouraging
that
we
start
adding
like
flags
on
the
spec
right
so
on
the
parser.
Sorry,
so
that
you
can
enable
certain
features
with
feature
flags
with
environment
variables,
depending
on
what
you're
doing.
A
So
certain
features
are
immediately
available
only
if
you
enable
enable
them
explicitly
right,
so
they
can
land
on
the
parser
in
a
decoupled
fashion,
and
you
don't
have
to
wait
for
the
spec
and
you
can
be
testing
the
spec
before
it's
launched
and
you
don't
have
to
create
these
long-lived
branches,
which
is
which
are
always
a
pain,
especially
if
you
start
rebasing
them,
and
things
like
this
so
so
yeah.
I
think
we
should.
We
should
try
at
least
moving
in
this
direction.
It
has
it
on
its
own
drawbacks
like
feature
flags
can
be
a
pain.
A
I've
been
there
in
the
past
and
especially
because
yeah
everything
is
fine,
I'm
gonna
add
a
new
feature
flag
and
I'm
gonna
just
add
my
code
here
cool
now
it's
released,
everything
is
released,
and
now
we
have
this
on
the
spec,
blah
blah
blah
and
suddenly,
oh,
I
forgot
to
delete
the
feature
flag.
You
know,
and
you
end
up
with
a
ton
of
feature
flags
there
that
you
don't
really
know
if
they
are
already
shipped
or
not
or
you
can
remove
them
or
not
so
yeah.
It
has
its
own
drawbacks.
A
So
you
probably
will
probably
have
to
create
some
process
where,
before
releasing
the
spec
or
at
the
same
time,
we
release
the
spec
the
new
version
of
the
spec.
You
remove
the
feature
flag,
which
still
needs
a
pull
request,
so
so
yeah
up
to.
F
Which
yeah,
but
I'm
I'm
thinking
about
it,
and
I
cannot
see
this
it's
my
fault
for
for
sure.
I
cannot
see
the
use
case
because
more
if
it's
a
feature
that
you
can
use
right
now
without
depending
on
a
spec
change,
you
will
release
that
on
their
master
and
that's
it
right.
Like
you
don't
care,
I
mean
you
don't
care,
you
know
what
I
mean
you
just
release
it
and
that's
all
so
in
case
you
depend
on
spec
change.
Schema.
A
Will
you
have
to
have
a
separate
version
of
the
schema
just
for
this
feature
when
you're
when
you're?
Using
this
feature,
you
don't
use
the
master
schema,
you
use
your
own
version
or
you
inject
some
changes,
which
is
I'm
not
gonna
get
into
into
the
implementation
details,
but
you
can
just
like
instead
of
using
this
schema
using
the
other
schema
right.
You
know
what
I
mean.
A
So
I
know
it's
a
pain
and
it
will
end
up
having
a
lot
of
schemas
and
the
more
feature
flags
that
we
have
more
schema
versions
that
the
parser
will
contain,
which
is
not
ideal
but
yeah
like
there
are.
There
are
ways
to
do
it
and
you
can
have
just
the
part
of
the
schema
that
changes
and
yeah.
A
D
D
F
Yeah
regarding
the
intel
driven
api
implementation
for
the
parser
jonas
made
a
wonderful
pr
with
the
first
implementation
of
it
and
we
iterated
a
bit
fran
suggested
some
changes
or
more
than
changes
in
code.
More
like
the
philosophy
of
the
api,
I
would
say
so.
There
was
some
back
and
forth
on
it
and
the
last
update
front
did.
It
was
a
good
suggestion
so
to
retake
the
intents
because
at
some
point
there
was
some
confusion
about
using
intents
or
discarding
intents
for
the
defining
api.
F
So
in
order
to
simplify
the
api
and
the
user
experience,
france
suggested
to
use
some
filter
methods
like
to
filter
operation
channels,
whatever
by
their
kind.
In
that
case,
so
anyway,
the
update
is
gonna,
be
that
I'm
gonna
take
this
work,
so
I'm
gonna
take
overtake
jonas
work
and
I
will
implement
this
and
keep
iterating,
so
I
will
most
probably
be
updating
you,
but
for
the
next
meeting
you
will
have
more
updates
about
it.
F
Yeah,
so
what
is
this?
The
intend
driven
is
it's
an
approach
we
want
to
take
for
declaring
the
new
api
we
want
to
implement
in
the
parsers
an
api
that
basically
is
based
on
user
intentions
rather
than
based
on
the
document
hierarchy
would
say
with
this
api.
F
We
want
to
make
it
better
in
terms
of
user
experience,
to
avoid
breaking
changes
as
much
as
possible
as
well
to
be
creator
compatible
from
at
least
from
now
on,
let's
say
starting
with
a
3.0,
even
though
we
aim
for
allowing
also
two-point
x
version
with
this
api,
but
the
the
reason
this
is
going
to
be
in
in
a
major
version
of
the
of
the
parser.
It's
because
it's
basically
breaking
everything
right.
It's
completely
new
api
for
the
parser,
and
this
is
related
with
v3
spec.
F
Yes,
because
we
are
basing
the
api,
even
though
it's
more
abstract
concept,
it's
not
based
on
the
document
hierarchy,
as
I
said,
but
still
the
concepts
send
receive
that
we
want
to
introduce,
for
example,
in
v3.
They
are
in
in
this
api.
So
that's
why
we
are
talking
about
this
in
the
v3
meeting.
F
Yes,
you
say
it
perfectly
so
yeah
we
have
a
new
branch
called
next
measure
that
right
now,
it's
being
automatically
released
thanks
to
luca's
work
on
that.
So,
if
you
want
to
test
it,
you
can
just
use
it
directly.
It's
a
new
tag,
but
it's
I
think
we
are
releasing
with
prerelease
tags.
So
anyway,
it's
in
that
release
in
github
releases
on
the
partial
gs
repository,
so
you
can
start
using
it
right
now.
In
fact,.
A
A
What
do
you
mean
by
like
the
existing
one
is
like
mapping
the
structure
of
the
document
right?
What
does
it
mean
right
like?
What
does
it
do?.
F
Yeah
sure
I
mean
the
current
api.
Basically,
it's
a
copy,
let's
say
of
the
current,
I
think
api
document
representation,
so
any
change
we
do.
There
are
two
things
here
that
we
aim
to
fix:
one
avoiding
possible
or
potential
breaking
changes.
So
if
we
introduce
new
features
and
like
a
new
measure
that
we
are
doing
with
v3,
the
api
will
be
completely
broken
right
because,
as
it's
exactly
like,
for
example,
we
are
introducing
extracting
operations
into
the
root
document,
so
this
won't
be
able
to
to
be
reproducing
the
parser
as
right.
F
It's
gonna
be
better
to
share
this,
because
otherwise,
if
you
can
share
this
a
collection
of
models
based
on
the
concepts
around
async
api,
which
is
what
is
a
channel,
what
is
an
operation?
What
is
a
server
exactly?
Why
improves
the
developer
experience?
Because
we
try
to
be
based,
on
intents
again,
as
I
said
so
intentions
of
the
real
user
instead
of
having
to
know
exactly
the
whole
document
hierarchy,
you
will
have
methods
on
your
api.
That
will
give
you
whatever
you
need
for
you
directly.
F
You
don't
have
to
know
100
how
the
spec
it
is
so
in
the
case,
for
example,
you
want
messages
that
are
being
sent
through
a
channel,
so
you
will
have
one
method
for
for
basically
giving
you
to
this.
You
don't
have
to
filter
manually
by
the
kind
of
operation,
and
so
on
did
I
explain
myself
well.
A
C
I'm
I'm
sure
I
would
know
this
if
I
looked
at
that,
but
since
I
have
you
here
so
the
return
format
for
these
queries
is
actually
the
json
that
is
present
within
async
api.
Or
is
it
a
new
format.
G
F
F
Well,
we
didn't
think
about
it
at
all
to
be
honest,
okay,
so
if
you
think
it
makes
sense,
I
would
suggest
you
to
create
an
issue
because.
C
G
I'm
afraid
my
my
questions
probably
won't
be
as
precise
or
interesting,
but
just
to
play
it
back
is
this.
Is
this
saying
we
want
to
have
an
api
for
developers
to
be
able
to
parse
a
document
and
have
a
layer
of
sort
of
abstraction
in
that
api,
so
that
a
two
dot
x
document
and
a
three
three
documents,
both
parse
from
the
perspective
of
that
client
developer,
using
the
parser
api,
because
there's
we've
abstracted
it
to
intent
versus
sort
of
very
close
to
the
metal
in
terms
of
the
root
document?
G
F
E
G
A
Yeah
yeah,
exactly
actually
the
the
idea
behind
the
internet
driven
api
is
that
we
shipped,
as
you
said,
like
the
the
workload
from
from
from
users
of
the
spec
towards
to
s.
Let's
say
so:
we
we
deal
with
it
ourselves,
and
so
this
way,
and
then
the
intention,
the
the
intention
behind
working
on
this
kind
of
api
is
that
people
can
migrate
to
future
versions
of
the
spec
in
an
easy
way
in
a
in
a
seamless
way
right.
So
they
don't
have
to
change
their
code
base.
A
They
only
have
to
upgrade
the
version
of
the
parser
they're
using
and
immediately
they
will
be
able
to
use
version.
3
version
4
version
5
right
unless
they
want
to
use
new
features.
Of
course,
in
this
case
they
will
have
to,
of
course,
code
the
features
but
existing
code.
They
have
for
version
two
or
for
let's
say
for
version
three
of
the
spec.
A
If
we
release
three
point,
one
three
point:
two:
four:
five:
whatever
the
same
code
on
their
side,
this
will
still
work
right.
It's
so
the
the
it's
a
responsibility
of
the
parser
to
understand
that
now
it's
not
a
3.1
file.
Now
it's
a
5.0
file,
so
where
do
I
have
to
go
to
and
find
this
information?
A
So
there
it's
here,
because
we
changed
the
layout
or
the
structure
of
the
document
cool,
so
I
have
to
go
there
or
there,
but
in
order
to
do
that,
you
have
to
abstract
the
calls
right
so
like
there
was
a
good.
A
good
definition
there,
like
the
intent
for
buy,
buy
five
watermelons
right
is,
is
go
to
the
store.
Pick
five
watermelons
pay
with
cat
go
to
the
counter
pay
with
cats,
put
a
weather
medal
in
a
bag
exit.
The
shop
go,
go
back
home,
blah
blah
blah.
A
You
know,
I'm
doing
all
the
stuff,
but
where
is
the
job?
Where
is
where?
Where
do
I
grab
the
five
watermelons
from
you
know?
How
do
I
pay
you
know?
All
these
things
are
will
be
like
should
be
abstracted
right,
so
it's
like
no.
I
just
want
to
buy
five
watermelons
do
whatever
you
have
to
do
behind
the
scenes
right
and
give
me
the
watermelons,
that's
it
so
it's
like.
I
want
to
find
what
how
many
messages
are
we
sending
to
a
specific
channel?
How
is
it
defined
in
version
two?
A
I
have
to
go
to
channels
and
then
going
to
every
subscribe
operation
and
then
inside
the
subscribe
operation.
I
have
to
find
the
message
and
do
this,
for
you
know,
for
each
channel
or
for
a
specific
channel
that
you
that
you
tell
me,
but
in
version
3
you
probably
have
to
find
a
not
probably
you
will
have
to
do
it
differently.
You
don't
go
through
channels
only
anymore,
you
have
to
go
through
operations
as
well
and
so
on
and
so
on.
A
So
so
that's
how
you
build
all
the
same
information
and
give
it
to
the
user.
The
user
will
still
receive
all
the
messages
and
array
of
messages
that
are
published
to
specific
topic
or
channel,
but
the
way
you
you
obtain
them
is
different
right,
but
their
code
base
will
just
say:
give
me
the
messages
on
this
channel.
A
That's
it
so
whenever
they
upgrade
to
version
three
version,
four
version:
five,
their
code
remains
the
same
right,
and
so
it
will
be
easier
for
them
to
migrate,
because
the
way
it
is
right
now
it's
the
parser
api
is
is
a
map
of
the
of
the
document.
So,
for
instance,
right
now
we
have
info
object
at
the
root
level
and
the
title.
So
now
you
do
async
api
dot
info
dot,
title
right
to
get
the
title.
A
What
if
we
move
the
title
out
of
the
info
object
or
we'd,
rename
it
to
instead
of
title's
name
right,
then
they
will
have
to
change
their
code
base
right
and
everybo
everybody
building
tools.
They
will
have
to
change
the
their
tools.
We
don't
want
that
right.
We
don't
want.
We
don't
want
to
be
so
coupled
to
the
spec
that
every
time
we
release
a
new
major
version,
we'll
be
fearing
that
people
will
not
want
to
migrate
because
they
already
invested
a
lot
into
the
existing
version
right.
So
yeah.
F
Something
worth
to
note
here
is
that
we
can
also
introduce
deprecations
on
methods,
and
this
is
an
interesting
point,
since
we
can
give
support
for
other
persons
with
a
warning
or
wherever
and
to
just
new
new
methods.
F
G
G
F
We
do
have
the
parser
api,
a
repository
where
we,
theoretically
we
will,
we
will
add
all
the
rules
for
specifying
what
an
intent
is.
That's
the
first
thing
it
it's
not
only
about
this
example.
I
wrote
about
the
watermelons,
but
a
guide
guidelines
for
the
community
to
evolve
the
api
itself.
This
is
very
difficult.
I
can
tell
you-
and
it's
probably
the
most
difficult
part-
how
to
train
kind
of
others
on
into
this,
but
definitely
it's
an
important
point
and
it
should
be
included
here
in
the
parser
api
partial
api.
F
It's
like
the
repository
where
we
will
define
this.
We
do
have
parser
gs
right
now,
but
any
other
parts
and
implementation
official
parsers
under
a
sec
api
umbrella
will
most
probably
use
or
should
should
follow
this.
This
api
and
all
the
rules
in
this
repository.
A
A
If
we
end
up
creating
a
java
parser,
the
same
interface
is
going
to
be
available
for
the
java
parser
for
the
go
parser
the
same
thing
I
mean
some
certain
things
might
change
in
the
in
the
way
that
you
know
to
adapt
to
the
language
like,
for
instance,
go
makes
it
mandatory
that
public
methods
start
with
uppercase.
A
So
I
mean
these
differences
are
trivial,
but
the
the
you
know
like
the
api,
should
be
the
same
across
languages
right.
So
if
we
manage
to
standardize
this
api
over
time
and
together
working
on
this
interface
layer,
what's
going
to
happen,
is
that
for
tooling
vendors
and
for
tooling
creators,
this
api
will
be
the
spec.
A
You
know
this
apis
is
going
to
be
the
you
know,
the
facade
for
the
spec,
and
so
you
can
evolve
the
spec
as
you
want,
without
breaking
anything
right
on
the
other
side.
A
Ideally
of
course,
and
there
will
be
breaking
changes
at
some
point,
I'm
sure
we
cannot
foresee
every
every
breaking
change
in
the
future,
but
but
if
we
can
reduce
them
to
to
ascertain,
let's
say
amount
right
like
at
least
the
stupid
changes
like.
Let's
move
this
here
from
here
or
rename
this,
or
that
I
mean
these,
things
should
be
cheap
to
do
on
the
spec,
and
we
shouldn't
be
fearing
that
right.
So
yeah.