►
From YouTube: Request/reply discussion part 2
Description
Another meeting related to request/reply support in spec 3.0 version
A
B
Thank
you
very
much.
I
really
appreciate
it
so
yeah
welcome
everyone
for
the
second
request
reply
discussion
before
we
get
into
it.
Maybe
it's
good
time
to
maybe
short
introduction
if
people
want
to
introduce
themselves,
my
name
is
jonas
and
I'm
working
on
postman,
where
I
work
full
time
on
async
api.
D
I'm
going
to
do
that
just
because
I'm
new
here
so
I'm
a
knock.
I've
been
mainly
working
on
different
ap
management
tools
and
started,
exploring
guessing
kpi,
and
I
do
get
a
bit
of
free
time.
So
I've
been
trying
to
attend
some
of
these
meetings
get
to.
I
did
go
through
some
docs
and
just
getting
to
know
a
bit
more
and
and
everything
I
don't
request.
Reply
kind
of
you
know
sounded
interesting,
so
I'm
just
attending
these
meetings.
Thank
you.
F
E
B
F
F
I
will
not
repeat
it
completely
and
what
we
are
seeing
or
what
we
have
find
out,
how
we
can
solve
it,
and
you
can
see
here
samples
for
case
a
d
and
the
samples
for
case
b
and
c,
and
what
we
come
with
is
what
we
need
is
an
operation
and
the
operation
needs
to
know
where
to
it,
find
the
reply
topic.
So
we
specified
replay
section
containing
and
information
if
the
reply
topic
can
be
found
in
header
or
body,
because
mqtt
3
doesn't
support
headers,
so
yeah.
F
This
is
what
we
defined
as
well
as
we
defined
with
the
message.
If
it
is
a
request
message
or
just
normal
message-
and
we
said:
hey
the
if
you
have
a
special
format
requirement
for
the
replay
topic,
just
put
it
in
the
schema
of
the
header
yeah,
let's
go
over
here.
What
is
still
open
is
this
cushion
around
correlation
ids.
B
If
I
can't
pronounce
that
name,
I'm
going
to
call
him
that
so
nathan
talked
about
json
rpc
and
how
they
used
it
for
their
use
case,
and
one
of
the
things
that
I
took
notice
off
was
that
they
actually
use
a
property
in
the
payload
to
define
where
the
reply
should
head
to
or
where
it
should
be
replied
to.
So.
I
think
we
had
an
assumption
last
time
that
there
was
no
use
case
for
adding
it
for
the
payload
only
for
the
headers,
if
I'm
not
mistaken
by
the
for
the
correlation
id
right.
F
Yeah
and
a
fix
replay
topic,
but
if
you
don't
use
json
rpc,
if
you
just
use
plain
amputee,
you
may
want
to
have
it
in
the
body.
So
I
think
we
definitely
need
the
requirement
that
the
replay
topic
may
be
part
of
the
body
as
well
as,
if
you
use
plain
web
socket
or
just
udp,
tcp
or
whatever.
You
will
needed
to
have
a
part
of
the
body.
B
I
also
think
he
mentioned
that
he
wasn't
sure
whether
they
would
need
to
define
that
or
whether
they
wanted
to
do
it,
because
they
they
already
they
don't
explicit,
say
that
this
is
their
what's.
It
called
like,
like
the
reply
channel
the
only
thing,
it's
basically
just
a
property
of
the
payload
right,
but
the
question
is:
would
they
want
to
specify
that
the
reply
channel
is
part
of
the
message
payload
and
should
be
used
as
such.
F
C
Just
correct
me:
if
I'm
wrong,
isn't
it
the
idea
behind
reply
to
to
have
the
same
approach
as
correlation
id?
Wasn't
that
the
case
that,
like
so
in
correlation
ide
at
the
moment,
you
provide
information
called
location
where
you
can
specify
where
the
correlation
id
can
be
found
and
it's
up
to
the
user,
it
can
be
header,
it
can
be
payload.
C
F
B
So
in
the
message
subject,
of
course,
I'm
linking
the
2.2
version,
but
it
doesn't
matter,
I
think,
yeah.
It's
still
the
same.
We
have
a
correlation
id
property
on
the
message
subject
I
linked
it
in
the
chat
and
zoom
as
well,
where
we
already
have
a
property
for
defining
a
correlation
id.
I'm
not
sure
if
we
can
reuse
that
if
you
scroll
down
a
little
bit
more.
F
Yeah,
I'm
not
sure
if
this
is
good
idea
to
have
it
here
or
not,
because
here
you
just
say:
hey:
there
is
a
correlation
id,
but
you
cannot
specify
if
the
correlation
id
needs
in
special
format
and
yeah-
you
cannot
say,
oh
yeah
normally
is,
let
me
think
yeah
normally
it's
it
have
to
be
always.
So
if
you
haven't
correlationally,
you
always
have
to
send
it
back.
F
C
Yeah
you
specify
what
it
is,
so
you
can
say
it's
in
the
header,
it's
like,
because,
depending
on
the
on
protocols
on
systems
like
some
people,
just
send
it
in
the
message,
because
there's
no
header
and
some
people
just
put
it
in
the
in
the
header.
So
that's
the
you
have
a
special
expression
language
there
that
you
can
use.
Okay.
C
C
C
That's
what
I
was
referring
to
basically
yeah,
so
to
be
consistent
and
and
then
it
makes
sense,
because
and
that's
why
I
jumped
in
because
you
were
discussing
folks
like
if
it
should
be
in
the
body
or
in
the
header
et
cetera.
But
then
we
don't
from
the
spec
perspective.
We
don't
care
where
people
put
it,
we
don't
it's
up
to
the
user
to
specify
where
they
have
it.
B
F
F
B
B
Let's
say
you
want
a
logging
id
throughout
all
of
your
services,
from
where
it
gets
in
and
use
something
different,
that's
not
related
to
request
reply.
Then.
We
can't
really
reuse
like
this
correlation
id
property
per
se,
but
it
kind
of
needs,
like
you
did
above,
where
you
have
reply
dot
reply
topic.
F
C
G
B
B
Does
it
make
sense
to
introduce
multiple?
I
I
know
that
we
have
multiple
use
cases
here,
where
it's
very
specific:
what's
the
difference
between
them,
but
what?
If
we
took
it
per
protocol
and
said,
okay,
we
have
websocket,
we
have
http,
we
have
json
rpc.
We
have
navs,
for
example,
just
for
our
broker-based
example.
If
you
have
those
files,
four
scenarios
with
specific
protocols
with
specific
needs,
would
it
make
sense
to
create
examples
for
them
and
base
the
suggestions
off
of
there
and
see
how
it
applies.
F
In
general,
I
don't
think
it
makes
sense
to
have
an
operation
in
operation.
You
just
want
to
tie
together
the
request
message
and
the
response
message,
but
where
those
fields
can
be
find,
yeah
should
be
part
of
the
message
here.
You
define
the
wire
input
channel.
You
define
the
message
that
is
coming
in,
so
you
already
know
that
you
don't
have
to
define
it
here,
so
you
can
simply
say
hey.
F
F
C
F
If
the
channel
is
defined,
it
will
use
the
channel
and
if
message
is
defined,
it
will
overwrite
the
message
from
the
channel,
but
if
no
channel
is
given
all
other
attributes
from
the
channel
will
be
taken
from
this
channel
here.
So
if
here
is
no
channel
defined,
it
use
the
option
from
this
channel
like
server
and
so
on,
and
if
no
message
is
defined,
it
will
use
the
the
general
attributes
required,
so
either
a
channel
or
message
is
required
below
reply,
but
not
both.
G
F
F
C
C
G
G
H
This
will
be
like
another
channel
right,
it
will
be
pointing
to
another
channel
and-
and
it
could
be
one
of
those
two
messages.
What
if
this
other
channel
channel
with
different
server
is
already
defined
somewhere
else
with
other
set
of
messages,
it
would
be
overwritten,
it
would
be
overwritten,
yeah,
okay,
so
now
imagine
that
we
want
to
standardize
how
how
applications
talk
to
each
other
at
company
level
right
what
we're
introducing
here
and
then
standardize
how
things
communicate
with
each
other.
H
F
H
My
suggestion
will
be
that,
instead
of
having
a
one-off
with
dollar
ref,
we
have
a
list
of
message
ids
that
we
can
expect
there,
so
these
messages
will
have
to
be
defined
in
the
inbound
of
channel
with
different
server
right.
Otherwise,
so
it's
it
is
for
us
to
understand
that
it
is
for
us
to
say,
like
from
the
four
different
types
of
messages,
I'm
inventing
inventing
from
the
four
different
types
of
messages
that
I
can
accept
in
channel
with
different
server.
H
F
H
F
H
F
H
H
You
want
to
say,
like
I
want
to
publish
to
the
to
the
channel
I
want
to
publish
to
the
x
channel,
create,
I
don't
know,
like
user
creation
channel
right,
if,
if
you
can
overwrite
whether
it's
on
the
company
level,
let's
say
or
the
shared
channel
definition,
then
what's
the
point
of
having
a
shared
channel
definition
in
the
first
place,
because
you
can
override
it,
so
anything
can
happen.
You
cannot
even
rely
on
these
definitions
because
someone
can
override
it
at
some
point.
You
know
what
I
mean.
F
H
H
F
H
Request
reply,
but
to
me:
okay,
it's
kinda
related,
but
not
really.
I
mean
like
I,
I
mean
the
fear
that
I'm
having
here
is
that
if
we
leave
the
door
open
for
any
kind
of
overriding
to
happen,
then
it's
going
to
become
a
mess.
It's
going
to
be
a
it's
going
to
become
an
ungovernable
mess
you
know
and
and
that
that
is
going
to
be
a
that
is
going
to
be
problematic.
H
So
I
will
say
at
some
point:
if
you
want
to
add
some
new
kind
of
message
to
a
topic,
then
you
will
have
to
go
and
add
it
to
the
channel
definition
first
and
then
go
to
the
reply
and
say:
I'm
going
to
put
this
message
on
this
channel
instead
of
just
overwriting
right,
because
if,
if
we
don't
do
it
the
first
the
first
way,
then
anybody
can
could
be
pushing
whatever
they
want
there
and
there's
no
way
to
standardize
anything
and
and
yeah.
And
then
you
don't
know
what
to
expect.
H
F
F
G
H
H
H
H
H
H
We
can
reply
with
creation.
Successful
okay
in
china,
with
different
servers,
but
channel
with
different
server
is
defined
here
and
it's
not
allowing
another
message.
It's
only
allowing
this
right.
It's
only
allowing
this
these
two
right,
so
this
will
give
us
enough
information
to
understand
that
this
will
not
be
valid
right,
because
we
cannot
reply
with
another
message
because
it's
not
listed
here
right.
So
if
we
want
to
reply
with
another
message,
we
have
to
add
it
here.
First
right:
why?
H
Because
this
piece
here
might
not
even
be
in
the
same
chain
the
same
file
right.
This
piece
here
might
be
in
a
different
file
right,
that
is
shared
across
the
whole
company
right,
which
is
a
list
of
channels
right
and
a
lot
and
allowed
messages,
and
so
on.
So
this
you
know
what
I
mean
so
so
this
way
we
can
standardize.
H
B
G
H
B
F
H
H
So
so
what
we're
saying
here
is
that
in
this
channel
we
allow
create
user
in
this
other
channel.
We
only
allow
creation,
failed
or
successful
right.
So
here
when
we
reply
right,
we
only
allow
either
we
say
like
we
only
allowed
this
or
because
it's
already
it's
already
defined
in
the
channel.
We
just
completely
omit
it
right.
We
just
say
that
we're
gonna
reply
to
this
channel
and
anything
that
is
defined
in
this
channel
can
be
sent
right.
H
H
H
H
H
H
H
H
Validate
that
idea
is
going
to
be
much
easier.
Of
course,
if
I
mean
like
if
this
creation
successful
string
is
in
this
list
of
strings,
that's
going
to
be
super
easy
to
do
but
yeah,
and
I
think
also
the
the
spec
is
going
to
be
much
clearer
right
to
read
like
creation
creation.
Successful
is
a
message.
We
know
it's
a
message
and
we
know
we
have
components
messages.
So
it's
here
problem
is
we
break
dollar,
ref
and
so
editors
code
editors
will
not
be
able
to
offer
navigation
like
like.
H
H
H
Yeah,
I
don't
know
it
has
pros
and
cons,
but
what
I,
but
what
I
want
to
understand
as
per
this
discussion,
is
that,
can
we
actually
make
sure
that
whatever
is
in
the
reply
list,
it's
on
the
channel
definition
somewhere
else
like?
Can
we
make
sure
that
this
message
is
part
of
the
other
list,
because.
H
B
B
G
B
H
B
H
G
B
H
Yes,
we
want
to
yeah,
I
mean
it
can
happen
like
maybe,
failures
are
from
a
different
set
of
services,
but
this
service
is
not
notifying
errors,
it's
not
that
it
doesn't
fail,
but
if
it
fails,
we
don't
log
anything
or
we
don't
publish
anything.
So
so
the
message
here
was
we
will,
it
will
be
like
we
only
want
the
successful
one
right
from
this
failed
and
successful.
F
H
H
H
F
G
F
F
H
H
Not
working
anymore,
exactly
yeah,
you
only
when
you
have
to
when
you
have
to
create
the
topic,
for
instance
in
kafka
or
in
maths
or
in
any
other
broker,
you
request,
there
is
usually
a
a
a
a
team,
devops
team,
or
something
that
you
ask
them
to
create
a
topic
for
you.
If
that's
needed,
of
course,
like
in
the
case
of
mqtt,
it's
not
even
needed,
but
but
you
ask
them
to
create
allocate
memory
for
a
new
topic
for
you.
H
B
G
B
D
H
G
F
But
in
general
I
would
prefer
having
the
channel
as
the
reference
as
we
seen
before
so
channel
and
message
have
to
be
references,
so
you
get
a
round
of
those
id
thing.
You
simply
can
compare
in
the
past
object.
So
if
the
objects
are
the
same,
it's
allowed
yeah
yeah
it
can
be.
I
think
it
would
be
make
everything
easier
yeah.
I
love
the
idea
of
id
the
idea
of
ids,
but
it
makes
everything
a
lot
more
complicated.
G
H
H
A
Sure,
and
and
by
the
way,
todd
todd
beats.
I
joined
zoom
because
I
was
kind
of
lurking
on
youtube,
but
I
had
heard
jonas
point
out.
I
think
rightly
that
endpoint
or
address
sorry
address
needed
to
be
optional
in
the
definition
of
a
channel
for
those
brokers
that
use
sort
of
a
dynamic,
a
dynamic
topic
or
a
dynamic
subject
at
runtime
for
the
reply.
That
makes
sense
to
me.
B
H
H
A
B
A
A
A
A
Yeah,
maybe
it's
maybe
this
is
not
specific.
Typically
from
the
broker's
perspective.
From
the
brokerage
perspective,
the
correlation
id
is
the
same
as
the
dynamically
set
reply
to
subject
in
gnats.
So
there's
not
not
generally,
when
using
that
feature
of
nat's
protocol
for
request
reply,
there's
there
they're
one
and
the
same.
The
the
reply
message
gets
routed
very
specifically
to
the
requester
via
the
reply
to
dynamic
subject,
so
it
kind
of
plays
both
roles.
The
delib,
you
know
what
how
the
receive
happens.
B
A
B
So,
if
I
recall
correctly,
he
had
under
the
operation.
There
was
a
reply
topic
and
we
talked
about
whether
we
could
integrate
it
with
a
correlation
id
object
that
we
already
have,
but
for
nets
it
wouldn't
be.
I
don't
think
you
ever
would
define
it,
because
it's
it's
not
something
that
you
would
need
to
define
in
any
sense.
B
A
Yeah
yeah
exactly
the
the
pub
the
nats
pub
protocol
operation
has
a
optional
protocol
protocol
level.
Header
called
reply,
which
is
the
the
channel
concrete
channel
down
to
the
address
level
that
the
service
responder
will
reply
on
eventually
yeah,
so
typically
with
nats.
We
want
to
from
an
operations
perspective.
I
guess
we
want
to
be
able
to
refer
to
the
reply,
because
we
want
to
maybe
link
some
mess:
payload
schemas
that
are
allowed
for
the
service
responder,
and
so
they
could
be
interpreted
by
the
requester.