►
From YouTube: AsyncAPI SIG meeting 28 (July 21, 2020)
Description
This is the recording for the AsyncAPI Special Interest Group (SIG) meeting #28.
Attendees:
- Fran Mendez
- Francesco Nobilia
- Jonas Lagoni
- Jonathan Schabowsky
- Lorna Mitchell
- Marc DiPasquale
- Nishchit Dhanani
Moderation:
- Fran Mendez
Agenda & Notes:
https://github.com/asyncapi/asyncapi/issues/404
Chat Dump:
18:19:25 From Fran Méndez : https://github.com/asyncapi/asyncapi/issues/390
18:24:42 From Nishchit Dhanani : Sorry, My screen was hung.
19:00:42 From Lorna Mitchell : I need to skip to my next meeting. Nice to "meet" you all!
19:05:39 From Marc DiPasquale : Sorry I have to drop, but nice talking with you all as well!
A
Okay,
so
it's
not
recording!
So
again,
I
was
saying
that
for
people
watching
the
recording,
here's
here's
a
link
to
the
the
agenda
today
and
and
yeah
again.
If
anybody
wants
to
bring
into
the
table
like
something
in
the
beginning
of
the
meeting,
because
you
have
to
quit
I'm
happy
to
to
change
the
order
here
unless
jonas
has
to
leave
as
well.
A
D
A
B
Okay,
so
it's
regarding
the
request,
reply,
pattern
and
what
kind
of
view
it
should
have
because,
as
there's
still
an
ongoing
discussion
about
how
these
subscribe
and
publish
operations
are
to
be
interpreted,
and
when
I
have
request
reply
in
the
next
protocol,
I'm
a
little
bit
confused.
If
I
should
still
keep
this.
B
Sure
so,
let's
have
the
normal,
publish
and
subscribe
where
you
just
publish
some
measures,
and
you
forget
about
it.
Basically,
then
the
request
reply
is
regarding
that
when
you
basically
a
get
request
or
any
other
http
request,
and
you
expect
to
get
something
in
return,
basically,
you
expect
a
response.
B
So
that's
that's.
That's
the
basic
of
the
request
reply
and
since
we
don't
have
an
actual,
since
we
still
only
have
these
puppets
and
subscribe
operations
in
the
protocol,
I
have
to
add
some
bindings
for
the
protocols
to
specify
whether
whether
an
application
is
the
requestor
or
responder
to
a
request
reply
and
it's
in
this
context
and
I'm
a
bit
yeah.
I
would
like
to
just
what's:
it
called
scratch
the
standard
view,
but
then
it
might
be
confusing
for
people
that
using
it
for
the
first
time.
B
A
Okay,
oh
okay,
I
see
what
you
mean,
so
this
is
not
the
classic
request
response
like
in
the
client
server
model,
but
this
is
request
reply
over
messaging
right,
like
you,
send
a
message
to
some
channel
some
topic
and
then
you
expect
to
get
a
response
in
another
topic
at
some
point.
At
the
same
topic,.
B
Exactly
but
that's
the
same,
yeah
yeah,
oh,
but
that's
that's
all
handled
by
nets
internally.
So
all
you
have
is
that
you
request
something
and
then
you
get
the
message.
But
when
you,
when
you
have
to
specify
in
an
async
ap
api
document,
it
gets
a
little
bit
tricky.
If
I
have
to
use
the
same
view
that
we
have
yeah.
B
B
B
B
B
A
B
B
Yeah
so,
for
example,
here
the
api
should
like
the
original
thought
is
that
it
should.
It
should
wait
for
a
request
by
the
game
server
to
be
notified
when
the
game
server
has
started.
That's
basically
the
principle
of
this
channel,
but
the
way
I'm
describing
it
now
is
that
the
subscribe
operation
is
actually
what
it
publishes.
B
D
B
D
The
correct
one
I
mean,
from
my
perspective
every
other
asynchronous
messaging
system.
I've
ever
seen
has
a
channel
for
requests
and
a
channel
for
responses.
That
is
separate
and
I
don't
think
we
properly
model
that
in
async
api
with
publish
and
subscribe
anyway.
But
you
know,
I
don't
think
that's
actually
been
a
use
case
for
him.
Correct
me.
If
I'm
wrong,
no.
A
It's
it's
my
first
time
seeing
this
kind
of
button
as
well
like
using
the
same
channel,
but
it's
probably
done.
I
don't
know
behind
the
scenes
using
some
headers
on
the
messages
or
something
I
don't
know
like
it
might.
It
might
be
that
the
client
who's
keeping
this
messages,
but
yeah,
I
don't
know,
I
don't
know
how
this
will
work
behind
the
scenes
will
be
great
to
have
to
have
people
from
nets.
D
D
D
Like
my
point
is
is
like,
I
think
we
do
need
to
support
request.
You
know
asynchronous
request
reply,
but
like
having
the
request
and
the
response
go
on
to
the
same
channel
like
is,
that
is
that
a
case
for
you
know
the
nats
bindings.
You
know
having
an
extension
that
kind
of
deals
with
this
versus
the
actual
overall
model.
A
Oh
yeah,
no,
that's
that's
a
good
point.
I
don't
know
I
this
is
actually.
This
is
actually
something
that
we
need
to
consult
with
them,
because
maybe
this
is
abstracted
by
the
client
itself,
but
it's
not
abstracted
in
the
protocol,
maybe
so
so
yeah.
We
will
need
to
know
more
about
it,
maybe
about
how
this
work
behind
the
scenes
right
but
yeah.
We
need
to
have
something
for
requests,
reply
patterns
and
that's
actually
requested
by
okay,
can't
remember
now,
but
there's
an
easy
request
and
support
for
request.
A
A
Is
actually
the
reply
of
something
coming
from
this
other
channel?
There's
no
semantics
on
on
the
spec
to
reflect
that,
but
yeah
you
can,
as
per
the
spec
right
now,
it's
possible
to
have
a
palace
and
a
subscriber
like
jealous,
is
showing
on
a
single
channel,
which
means
that
somehow
it's
like
a
response.
A
A
Messages
you
published,
I
mean,
I
know
that
some
protocols
handle
that
as
well
like
amqp,
for
instance,
that
you
can.
You
can
say
that
you
don't
want
to
receive
the
channels,
the
messages
that
you
publish
or
was
it
jms?
I
don't
remember
now,
but
yeah
yeah,
there's
the
basics
out
there.
We
just
need
to
get
rid
of
this.
First
of
all,
we
need
to
get
rid
of
this
mass
of
the
palace
and
subscribe,
and
you
know
the
different
births.
F
A
By
the
way,
there
is
a
there
is
a
nice
discussion
happening
on
this
issue
here,
which
is
related.
You
know
it's
also
related
to
this.
I'm
sharing
on
the
chat
and
it's
related
in
the
sense
that
it's
about
the
meanings
of
publishing
subscribers.
As
you
can
see,
lorna
it
wasn't
you
only
so
this
is
so
long.
This
is
a
long
thing
already
like
since
ac
kpi2,
it
became
a
problem.
Actually,
since
the
beginning,
it's
been
like
this
since
the
beginning,
not
only
since
2.
A
and
yeah.
So
there's
this
discussion
about
the
meanings
of
public,
publish
and
subscribe
and
and
probably
introducing
some
more
some
more
verbs
like,
though,
just
to
probably,
if
I'm
understanding
correctly
jonas,
I
think,
as
per
your
request
here,
sorry
as
per
the
thing
you're
explaining
here
right.
A
When
you
see
it,
it's
like
that's
what
you
expect
it
to
mean
and
then
create
other
other
verbs,
like
request,
which
could
contain
a
different
kind
of
operation,
of
course,
but
yeah
but
like.
I
think
this
is
something
like
something
to
discuss
in
the
long
term
or
not
in
the
long
term.
Actually,
we
need
to
fix
this
as
soon
as
possible
and
probably
launch
version
three
earlier
than
we
thought
so.
F
D
Yeah
like
collaborate
and
keep
this
moving
along
right
because
I
do.
I
do
obviously
have
some
questions
on
sort
of
on
what
you
you
know
what
you
posted
a
few
hours
ago,
which
I
think
is
good,
but
I
mean
do
you
because
you,
you
kind
of
said
in
here,
like
don't
treat,
you
know,
don't
treat
this
as
a
proposal,
but
I
guess
I'm
just
wondering
from
a
process
perspective
like
how
do
you?
D
A
A
F
A
When
I
say
a
little
bit
more,
it
doesn't
have
to
be
much
more
it's
just
if
someone
wants
to
come
up
with
a
proposal.
I
was
planning
to
do
it
myself,
but
I'm
I'm
happy
to
coordinate
with
other
people
on
making
a
formal
proposal
like
hey.
We
should
change
this.
We
should
change
its
in
kpi
this
way.
So
we
stop
having
this
problem
and
and
to
solve.
A
And
yeah,
and-
and
actually
I
don't
think
it's-
it
should
take
a
lot
of
time
because
we
sold
only
if
we
do
not
focus
on
how
personal
three
is
going
to
look
like
it's.
How
we
want
to
tackle
these
specific
problems
right.
We
can
get
crazy
and
model
and
solve
other
problems
there
as
well,
but
we
don't
have
to
right
so
so
yeah
I
mean,
let's
just
the
same
way.
This
issue
was
about
adding
about
adding
a
a
a
property,
so
this
issue
was
more
about
a
specific
solution
for
the
problem.
A
I
think
probably
the
way
we
can
do
this
is
either
reconvert
this
issue
to
a
more
open
question
like
how
do
we
solve
this?
How
do
we
subscribe
easily
and
then
we
find
a
way
either
the
view,
property
or
change
the
meaning
of
the
birds
and
add
reverse:
we
reorganize
how
things
go
kind
of
go
right,
so
we
can
proceed
as
a
as
much
as
we
would
like
or
the
way
we
want.
But
what
I
want
to
say
here
is
that
there's
no,
don't
don't
always
wait
for
me
like.
D
Yeah
go
ahead.
Sorry,
go
ahead,
no
worries,
you
know
I
was
gonna
say
you
know.
Maybe
one
proposal
I
would
have
is
like.
If,
if
friend
you
either
want-
or
I
could
kind
of
like,
I
guess
what
I'm
looking
for
is
to
form
maybe
like
a
little
like
tiger
team,
or
you
know
like
a
little
group
that
focuses
on
this
particular
problem
and,
like
you
know,
have
a
few.
You
know
weekly
kind
of
meetings
to
see
if
we
can
sort
of
drill
into
what
what
would
ultimately
get.
D
F
I
was
immediately
confused
about
how
to
describe
that
because
I
was
like
am
I
publishing
or
am
I
subscribing
like
this
thing
is,
is
publishing,
but
that
thing's
listening
and
I
was
also
twitch
streaming
when
I
did
it
so
then
I
wasn't
feeling
smart,
so
it
was.
I
I
believe
that
this
is
the
gotcha
for
like
first
time
users,
so
I
have
like
got
my
first
game
badge
that
I
have
achieved
that
gotcha
and
now
I'm
ready
for
whatever
the
next
one
is.
D
Gotcha
yeah,
so
I
mean,
I
think,
like
kind
of
that's
what
I
was
thinking
was
like
you
know.
I
know
my
like
higginbotham
and
myself
have
been
doing.
You
know
event-driven
stuff
for
like
our
entire
careers,
but
I
think
we
need
to
make
sure
we
have
the
aspect
of
kind
of
the
the
person-
that's
maybe
new,
to
async
api,
but
but
comfortable
and
open
api.
Since,
since
a
lot
of
this,
a
lot
of
our
questions
are
coming
from
the
big
companies.
I've
mentioned
this
before
for
ann.
Where
it's
you
know
it's
it's.
D
You
know
capital
one
and
in
different
large
companies
that
already
have
very
strong
api,
led
sort
of
initiatives,
and
so
then
they
take
this
spec
and
go
wait
a
minute.
What
and
then
it's
mass
confusion
and
then
we
don't.
You
know
we
don't
have
a
clear
path,
so
I
mean
we're
we're
extremely,
as
you
know,
motivated
to
like
working
on
what
the
problem
is
and
then
you
know
we're
happy
to
you
know,
create
examples
and
all
sorts
of
stuff
and
get
that
bought
in
with
the
community.
I
just
I'm
looking.
D
What
I
don't
want
to
do
is
is
individually
or
or
from
a
company
perspective,
create
a
specification
and
then
everybody
even
ends
up
going
yeah
no,
and
then
we
kind
of
do
the
yeah,
no
yeah,
no
yeah,
no
thing
a
whole
bunch
of
times,
because
then
you
know
I
don't
feel
like
that's
a
very
collaborative
way
to
ultimately
get
a
problem
solved.
So
that's
kind
of
why
I
was
saying
you
know.
Maybe
we
need
a
little
bit
of
a
more
formalized
like
tiger
team.
D
A
A
If
you
want
put
some
examples
there
like
hey,
so
this
is
how
I
will
I
actually
love
to
fix
this
problem
and
some
kpi
right
and
and
and
also
why
I'm
saying
like
someone
takes
a
living.
This
is
because,
first
of
all,
if
we,
if
we
create
like
a
subgroup
of
people
managing
that
like
how
is
how
is
this
group
supposed
to
be
selected
like?
A
A
Actually,
why
we're
running
this
meeting,
sometimes
in
the
morning
and
in
the
morning
for
us
and
sometimes
in
the
afternoon
right
so
people
from
aipac
america's
king
alter
so
and
also
we
are
an
asynchronous
apis
initiative
right.
So,
let's
make
it
synchronous,
let's
make
it
like.
Let's
make
it
in
a
greeting
form.
A
Also
some
it's
going
to
be
easier
for
people
to
jump
in,
maybe
when
they
have
30
minutes
at
some
point
in
their
days,
because
people
are
busy
right
and
not,
everyone
is
actually
working
on
an
even
driven
company
like
you
do
right
or
like.
I
am
like
working
on
this
full
text,
so
so
some
people
are
have
good
ideas,
but
yeah,
it's
not
the
main
trunk
of
the
work.
A
So
so
I
will
make
it
like
more
distributed
and
more
async
kind
of
work,
and-
and
I'm
not
joking
here
with
the
async,
like
you
know,
and
in
written
form,
so
and
also
in
the
public
way.
So
people
can
see
what
has
been
the
rationale
behind
a
decision
just
to
just
to
illustrate
what
I'm
saying
and
I'm
sure
that
lorna
is
familiar
with
that
this.
This
is
happening
a
lot
on
the
open
api
community
right.
Like
you
get
proposals
for
the
same
problem,
you
may
get
three
or
four
proposals
for
the
same
problem.
A
I'm
looking
at
you
over
legs
so
right,
so
you
get
different
point
of
views
right
and
you
get
different
ways
of
solving
the
same
problem
and
then
you
see
how
people
you
might
get
into
with
one
idea
to
your
head
like,
oh,
why
not?
We
do
something
like
this.
These
people
are
stupid,
they
didn't
think
about
it
and
then
you
go
and
you
scan
all
the
discussions
like.
Oh
they
thought
about
it,
but.
A
A
So
maybe
it's
easier
to
understand
and
if,
if
it
seems
that
people
are
liking
this
more,
then
I
will
go
and
create
a
proposal
using
this
way
and
and
also
I
was
actually
going
to
present
this
proposal
anyway,
like
because
I
didn't
have
time
or
the
space
to
elaborate
properly
there
right.
So
so
yeah,
I'm
like
it's
it's
okay,
we
can
someone
just
has
to
start.
The
conversation
like
like
michael
did
in
this
in
this
issue.
Right
and
today
we
are
discussing
something
we're
discussing
something
different
right.
A
We're
discussing
how
to
fix
this
problem
using
another
solution
and
and
yeah.
This
is
I'm
sorry
if,
if
you
feel
that
this
is
slow,
but
I
do
think
it
has
to
be
somehow
slow,
I'm
not
not
necessarily
slow
on
purpose,
but
but
we
need
to
give
people
time
to
to
get
into
the
easy
to
understand
the
consequences
to
give
their
voice.
A
A
Yeah,
sorry,
if
I'm
not
clear
enough
like
I
was
thinking,
I
was
thinking
of
making
a
proposal,
but
I
know
that
you
guys
are
also
eager
to
solve
this
issue.
So
we
can
both
do
a
proposal
or
we
can
or
we
can
keep
ourselves
discussing
in
this
issue
and
then
any
of
us,
not
all
of
us,
do
a
proposal
with
like
summarizing
the
the
feedback
we
we
gather
in
the
in
disease
right.
So
that's
why
I
was
saying.
F
A
A
A
E
A
B
A
Yeah,
no
exactly
so
that's
my
point,
so
we
we
can
avoid
cluttering.
You
know
across
many
issues
or
having
the
same
discussion
in
many
issues
by
continuing
this
discussion
here
on
this
issue.
Right,
that's
one
way,
that's
why
I
was
saying
saying
that
we
can
always
change
the
title
of
the
issue.
So
that's
that's!
Okay,.
A
But
I
would
not
rather
start
a
new
issue
and
without
closing
this
one
right
so
because
then
yeah
the
discussion
is
going
to
happen
in
different
places
and
people
are
going
to
get
lost
and
and
yeah,
but
yeah
once
you
have,
or
once
we
have
like
kind
of
an
agreement
here
or
almost
an
agreement
on
how
this
will
look.
Like
you
see,
people
are
getting
some
you're
getting
some
traction
on
your
idea.
A
Then
you
might
open
a
new
issue
with
this
specific
solution
like
hey
this
is
we
use
this
one
as
a
as
an
index
like?
Here's?
Is
the
proposal,
one
here's
the
proposal
too,
and
because
people
will
have
different
opinions
right,
hopefully
we
don't
have
to
create
a
proposal
too.
We
can
all
collaborate
on
a
proposal,
one
right
and
that
that
would
be
perfect
but
yeah.
So
that's
I.
A
A
This
already
happened
in
september
so
that
I
had
to
decide.
I
had
to
decide
and
keep
it
like.
It
is
right
now
and
and
yeah,
and
I
just
decided
to
keep
it
the
same
way.
It
was
in
version
one
just
to
avoid
any
changes
any
and
explore
things.
So
now
we
have
time
to
explore.
Let's
explore
different
solutions
and
let's
try
to
fix
it.
F
I
just
it
seemed
like
there
were
some
common
themes
between
everyone's
suggestions
like
I'm
new
here,
so
I'm
not
going
to
write
your
proposal,
but
I
feel
like
well
what
I'm
not
clear
on
is:
is
there
common
ground
on
the
use
cases
that
we're
writing
new
proposals
for?
Are
we?
Are
you
all
solving
the
same
problem?
Do
you
need
to
start
from
a
bunch
of
use
cases?
I
don't
know
what
problem
you're
solving
I
just
got
here.
F
F
The
stuff
they
think
we
don't
currently
have
a
good
cover
for
the
reason
you
know,
for
example,
this
isn't
really
the
example.
That's
still
on
the
screen
share
is
not
really
straight
up
pub
subs.
So
do
we
need
something
different
for
that.
So
is
that
a
use
case
that
we
should
consider
when
we're
looking
at
making
changes
like.
F
A
A
A
Are
we
going
to
include
other
verbs?
So
in
my
opinion,
it
is
all
about
keeping
the
same
functionality
but
making
it
a
little
bit
easier
for
the
user
to
understand
what
patents
and
subscribe
means.
So
that's
that's
my
feeling
here,
but
yeah
we'll
have
to
write
it
down
and-
and
my
feeling
is
that
allison
subscribes
will
probably
be
like
published,
mean
that
my
application
is
promising
and
subscribe
means
my
application
is
subscribing,
which
is
the
opposite.
A
That's
what
we
have
now,
because
what
we
have
now
is
like
what
the
client
can
do
with
your
application
right.
Like
the
same
way,
we
do
with
open
api,
like
you,
don't
when
you
say
get
and
post
you
don't
your
application
is
not
making
a
get
request.
Your
application
is
accepting
get
requests
right.
So.
A
So
yeah,
that's
that's
similar
yeah,
but
the
thing
here
is
that
yeah
we
with
open
api
it
I
mean
all
these
problems
are
inherited
from
from
open
api
because
I'm
not
blaming
them.
I'm
actually
blaming
myself
for
this,
but
but
it's
all
it's
all
inherited,
and
the
thing
is
that
in
open
api
there's
something
implicit
that
is
never
declared
anywhere,
which
is
the
the
client
server
architecture
right.
The
client
server
communication
right
and
that's
not
always
the
case
in
in
messaging
right,
so
messaging,
actually
most
of
the
times.
A
A
So
it's
it's
a
different.
It's
a
change
of
paradigm
here
right,
as
opposed
to
messaging,
like
broker-centric
messaging,
is
usually
not
request
response,
and
it's
not
client-server.
It's
just
like
yeah.
It's
like
a
decoupled
network
of
nodes,
communicating
with
each
other,
so
so
yeah,
there's
no
concept.
A
So
the
thing
here
is
that
publish
and
subscribe
to
be,
I
think,
the
opposite,
as
we
have
now
and
the
more
I
said
the
best
or
the
don't
know
how
to
call
it
like
the
the
most
friendly
for
the
user
at
first
then
we
can
add
something
I'm
just
guessing
that
like
to
cover
the
same
functionality.
We
have
right
now
we
can.
A
So
we
get
two
new
verbs,
but
since
we're
getting
two
new
verbs,
then
we
have
to
establish
the
scope
here
and
since
we
get
into
new
verbs,
we
should
probably
be
getting
client
requests.
Something
like
this,
like
your
client,
can
send
a
request
to
you
right
which,
in
the
end,
it
will
be
similar
if
not
the
same
offline
panelists,
but
yeah
we
will
probably
we
should
probably
be
defining
this.
That's.
Why
that's
why
I
was
saying
this.
A
A
A
C
Something
I
think
that
makes
sense.
I
think
the
I
think
the
view
parameters
was
proposed
as
a
patch
right,
so
we'd
rather
come
up
with
a
real
long-term
solution.
So,
in
my
opinion,
I
think
I'm
fine
with
coming.
You
know
getting.
You
know,
coming
up
the
real
proposal
and
fixing
this
whether
it
be
for
v3
or
you
know,
whatever
we
decide
wherever
we
decide,
it
needs
to
be
made.
A
Exactly
yeah-
and
I'm
saying
this
because
I
know
it's:
it's
like
it's
frequent
to
see,
specifications
moving,
really
slow,
and
I
want
to
avoid
s
from
becoming
this
right
like
we
should
move
not
fast
like
super
quick,
because
it's
a
spec
and
we
don't
want
to
be
breaking
things
very
often
right.
But
I
would
like
to
be
for
us
to
to
agree
on
delivering
new
versions
of
this
bag.
More
frequently.
C
A
A
But
now
that
we're
growing
as
a
group
and
also
campaigns
supporting
it
and
people
working
full-time
in
this,
so
we
can
actually
do.
We
can
actually
start
supporting
a
person
too.
Even
even
though
it's
not
perfect,
we
can
keep
supporting
it
for
for
years,
maybe
or
until
we
deliver
version.
I
don't
know
eight,
I'm
just
convincing
another
right,
but
we
can
have
more
a
clear
program
here
on
the
on
long-term
support
versioning
right.
A
A
A
Process
for
instant
kpi
and
and
I've
been
looking
at
what
node.js
has
been
doing
in
the
in
the
past
and
there's
something
that
was
strange
to
me
in
the
beginning.
But
now
I
understand
them
a
little
bit
better
and
and
it's
this
so
no
gs
has
this
system
where,
for
instance,
the
the
even
version,
the
even
numbers
of
third
persons
are
long-term
supported
and
the
old
numbers
are
not
going
to
say
short-term,
but
yeah,
not
long-term
support.
A
A
An
opportunity,
or
as
a
learning
from
from
our
side,
I
think
it
will
be
interesting
to
to
do
something
similar,
because
that
means
that
means
that
we
can
deliver
to
the
public.
A
new
version
and
people
can
start
using
it
in
their
cutting
edge
projects,
which
is
probably
not
going
to
be
production,
granny
systems
and
of
a
finance
company.
A
It's
not
going
to
be
a
problem
right
and
we
give
people
the
opportunity
to
try
it
and
and
to
play
with
it,
and
then
we
see
what
problems
this
person
has,
and
once
we
find
these
problems,
we
fix
it
on
the
next
version,
which
will
be
an
even
number,
and
then
you
know
so
it's
like
as
a
way
of
so.
This
is
the
this
is
the
true
release
and
the
the
next
one
is
it's
a
release.
Where
that
you
can
play
with
right.
A
It's
a
little
bit
like
test
release
for
cutting
edge
projects
and
and
then
on
the
next
one.
It
will
be
again
the
nice
that
food
release,
and
also
releasing
more
often
like
putting
as
putting
ourselves
the
the
task
or
the
duty
to
be
releasing
a
new
version.
Every
six
months,
whatever
it
is,
even
if
it's
dispatch
version,
even
if
it's
just
adding
a
stupid
thing,
but
we
keep
we
keep
moving
right
and
I'm
saying
six
months.
A
I
just
wanted
to
share
this
with
you
that
that's
why
I
I'm
always
saying
like
don't
worry
about
breaking
the
spec
with
these
things,
because
I
anyway
think
we
should
have.
We
should
move
faster,
so
look
at
jason
schema,
for
instance.
This
in
schema
is
now-
and
I
don't
know,
is
it
eight
version,
eight
draft
eight.
I
think
it's
the
current
one.
It's
not
called
like
this,
but
I
think
it's
it's
v8
and
and
people.
A
H
I
was
quickly
checking
something,
but
I
have
a
question
regarding
what
lord
mentioned
before.
Do
we
have
a
clear
statement
on
the
problem
that
we
want
to
solve
with
producers
and
consumers
and
sorry,
publishers,
and
subscribers
do
we
have
to
what
is
it
a
clear
statement
of
the
problem
that
we
want
to
solve.
A
Some
people
don't
know
exactly
how
many,
what
percentage
of
people
see
the
spec
this
way,
but
some
people,
many,
I
can
say
whenever
they
land
on
the
spec,
they
see
padlets
and
they
think
their
application
is
fabulous.
Like
think
about
it,
if
you
were
generating
code
from
your
spec,
it
compiles
will
generate
a
publishing
message
like
passing
a
message
and
a
subscribe
will
generate
code
for
listening
right.
That's
yeah,
like
sounds
like
a
no-brainer,
but
wait.
A
You
want
to
tell
people
you
want
to
communicate
people
what
they
can
do
with
your
api
right,
like
the
same
with
that
happens
with
open
api
like
you
get,
you
see
a
get,
or
you
see
a
pause.
It
means
that
they
can
send
you
get
a
repost,
not
that
you
are
getting
or
posting
the
server
right.
So
that's
some
people
see
it
one
way.
Some
people
see
it
get
away.
A
Server
and
request
response
so
yeah,
so
I
guess
her
first
reaction
was
like.
I
don't
get
it,
but
this
is
confusing
and
it's
true
I
mean
it's,
it
is.
It
is
super
confusing,
and
but
the
problem
is,
if
we
change
it
to
probably,
if
we
change
it
to
the
opposite,
then
it
will
become
confusing
for
people
consuming
on
the
public
side
right
for
consumers,
that
you
don't
control
right.
F
Think
for
me,
it
was
quite
like
I
wanted
to
describe
the
things
that
my
mqtt
server
knows
about
and,
of
course,
it's
absolutely
not
from
that
point
of
view
it's
from
either
this
application
or
the
one
that
understands
what
that
is,
that's
it.
So
it
just
sends
messages
over
to
the
lights,
and
I
wanted
to
describe
that.
I
wanted
to
tell
I
wanted
to
describe
all
the
things
you
can
do
with
mqtt,
so
I've
got
like
some
plug
stuff
and
some
some
color
related
stuff,
and
it
turns
another
light
on
and
whatever
those
are.
C
C
D
C
I
think
that's
what
how
you
were
in
your,
not
your
proposal
frame,
but
your
suggestion
right.
I
think
that's
how
you
would
define
the
library
in
a
way
right
would
be
everything
yeah
and
then
so
yeah.
I
guess
what
we're
kind
of
talking
about
this
and
I
think
jonathan
asked.
I
don't
know
if
you
had
answered
yet
in
your
suggestion.
That's
not
a
proposal
were
you
when
you
said
library
that
would
be.
F
A
Yeah,
this
is
already
changing
there
and
yeah.
I
thought
I
I
had
to
make
it
clear,
but
if
you
look
at
the
example
you
see
there
there's
a
client
subscribe
birth,
it's
called
client
subscribe,
one
of
them
is
pelvis
and
the
other
one
is
client
subscribe.
That's
the
birth.
Let's
say
it's:
not
it's
not
the
birth,
it's
a
type
of
subscribing,
which
is
something
the
the
example.
A
You
train
a
train
service
or
something
that
or
api
that
you
can
actually
connect
and
subscribe
to
updates
and
you'll
get
whatever
information
about
the
updates
and-
and
if
you
look
at
the
example,
it
has
two
it
has
tablets.
Two
operations,
publish
and
client
subscribe
pad
list
means
that
my
application
is
actually
publishing
in
this
topic.
It's
sending
information
there
right
and
client
subscribe
is
a
way
to
communicate
to
clients
that
they
can
subscribe
to
receive
this
information.
That's
why
I'm
starting
this
with
client
subscribe.
A
C
A
A
There
are
four
verbs
that
I
can
use
or
for
actions
or
types
of
operations.
So
I
think
that
the
first
reaction
would
be
like.
Let
me
let
me
read
what
every
of
these
type
of
operations
do
right,
what
what
do
they
mean
right?
I
hope
that's
that's
what
happens
right,
but
yeah.
It's
not
it's.
In
my
opinion,
this
is
never
gonna
be
perfect,
like
there
will
always
be
people
confused,
because
some
people
learn
by
examples.
They
don't.
H
I
think
I
hope
this
answered
your
question.
Yes,
sir
girl,
right
yeah,
it
doesn't.
I
was
just
quickly
thinking
what
if
we
just
expanded
this,
the
spec
to
drop
a
templated
documentation,
sir,
so
we
expand
the
this
to
have
a
templated
documentation,
because
what
you?
What
what
you
mentioned,
is
that
whatever
whatever
verb
we
will
be,
we
will
use,
people
may
be
confused
and
even
if
they
they
just
read,
publish
and
and
subscribe
without
checking
the
other
two
we'll
still
be
confused.
The
best
thing
would
be
having
in
the
documentation.
H
H
C
This
way,
I
think
what
he's
saying
is
is
once
you
have
the
document
that
defines
your
application
or
library.
That's
the
machine
readable
one
right
yeah
and
you
have
a
template
that
generates
human
readable
documentation
from
that
in
the
human
readable
documentation.
It
should
say
what
the
verb
means.
I
think
that's
what
he
said.
C
A
And
once
you
are
typing
your
sync
api
file
or
you're,
supporting
it
from
somewhere
and
you
get
the
human
readable
documentation.
You'll
get
some
clear
text
there
saying
that
you
can
subscribe
or
you
can
publish
or
this
service
or
this
application
is
probably
not
subscribe
and
that's
yeah.
It
will
pop
out
like
oh,
no,
that's
not
what
we
want
and
then
people
would
realize
that
they're
using
it
yeah.
That's
totally.
I
I
agree
with
that.
Like
that's,
that
sounds
like
a
good
idea.