►
From YouTube: 2022-05-05 meeting
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).
A
A
When
actually
something
that
the
ted
put
on
last
week's
agenda,
I
think
I
think
it
was
him,
I'm
not
sure,
or
maybe
it
was
one
of
eu
who
put
it
on.
There
was
like
an
issue
written
by
somebody
about
the
that
context.
Propagation
over
cues
is
loosely
defined.
I
mean
are
currently
in
in
the
current
semantic
conventions
that,
in
respect
is
not
defined
at
all
when
v
in
our
o
type.
We
define
some
kind
of
basic
requirements
for
this
context
propagation,
but
we
didn't
work
out
any
like
we
didn't.
A
B
A
A
So
for
today
I
I
think
we
don't
need
to
look
at
the
project
board,
we're
still
working
at
the
same
basically
attributes
if
we're
still
in
the
same
field
yeah,
I
need
to
poke
bogdan
more.
He
said
he's
gonna
show
up
at
those
meetings,
but
he
doesn't
so.
I
will
try.
I
mean
currently,
I'm
stretched
a
bit
thing,
but
I
will
try
to
poke
him
again
and
maybe
sync
up
with
him
offline.
A
A
So,
let's
see
which
kind
of
line
of
work
or
which
line
of
discussion
is
done
first
and
yeah.
Last
time
we
discussed
like
general
attributes,
I
think
we
will
continue
there
today
if
nobody
else
has
attended
items
and
what.
A
I
did
there
were
some
reviews
on
the
old
tap
from
zhao
thanks.
I
tried
to
include
all
your
suggestions,
but
also
data
added
like
a
table
of
contents
here,
because
the
old
tip
is
getting
pretty
long,
so
helping
us
to
navigate,
and
that's
where
we
are.
I
also
put
in
some
first.
A
One
thing
that
we
said
last
time:
we
were
talking
about
messaging
system
and
we
were
talking
about
having
attributes
that
refer
to
the
messaging
library,
more
or
less.
That
is
used
that
we
have
like
a
library
and
the
library
version
referring
to
the
messaging
library,
and
I
think
we
actually
don't
need
to
mention
that
explicitly
here,
because
open
telemetry.
A
A
I'm
because
I'm
I'm
pretty
sure
this.
This
code,
name
and
scope
version
will
give
us
what
we,
what
what
we
talked
about
last
time
here.
A
A
The
first
thing
I
put
here
was
a
messaging
dot
operation,
because
that
is
something
we
have
well
defined
here
and
based
on
these
predefined
operation
names,
and
we
were
also
talking
last
time
about
this
messaging.system.
A
Basically,
this
this
attribute
not
basically
referring
to
the
library
that's
used,
but
to
the
end
point
that
you're
talking
to-
and
I
I
wasn't
sure
about
the
term
like
we
were
not
very
unsure
about
system
endpoint
was-
was
proposed.
I
put
broker
here
as
a
third
option.
I
I
don't
know
what
is
kind
of
the
the
the
best
name
for
that.
I
don't
have
a
strong,
strong
opinion
here,
so
either
broker
or
system
or
endpoint
is
fine
for
me,
as
long
as
we
define
it
properly.
I.
C
Think
the
difference
between
broker
and
endpoint
is
broker
applied
only
to
brokers.
I
think
the
idea
behind
endpoint
was
that
it
would
apply
to
either
a
you
know,
producer
consumer,
client
or
a
broker.
I
think,
maybe,
if
the
intent
behind
the
sort
of
producer
consumer
type
of
endpoint
was
to
provide
something
like
a
library
name.
Then
then,
maybe
due
to
your
point
earlier-
that
that's
sort
of
already
provided
elsewhere,
then
maybe
this
is
fine,
but
it
sort
of
brings
me
back
to
my
original
question.
A
That
is
a
good
question
and
I
think,
for
this
case
we
need
some
kind
of
some
kind
of
fallback
property
here
that
we
say:
okay,
if
you
don't,
if
actually
don't
know
what
the
broker
is,
then
just
use
the
label
other
or
something
else,
yeah
or
unknown,
maybe
or.
C
Other
yes,
yeah
now
is,
and
then
the
question
is
is:
if
broker
is,
is
broker
now
the
thing
that's
the
first
part
of
a
spam
name,
and
we
were
talking
it
would
be
system,
but
now
that
we've
given
it
the
name
brokers,
is
that
that's
what
we
propose
here?
Yes
yeah.
So
it's
kind
of
too
bad
that
anybody
using
like
either
a
standard
api
or
standard
protocol
api
implementing
standard
protocol
just
wouldn't
know
so
yeah.
C
A
Yes,
that
makes
sense,
and
I
mean
maybe
that
was
a
reason
why
this
system,
name
or
broker
name,
was
left
out
of
the
span
name.
In
the
initial
proposal
I
mean
we
could
still
not
shoot.
It
sounds
like
a
duct
tape
solution
now
but
yeah
we
could
say
okay
in
the
span
and
use
broker,
but
if
you
don't
know,
broker
use
protocol
and
then
you
have
mqb
send.
A
Because
I
mean
when
we,
when
we
go
further
in
the
list
of
like
attributes
that
are
currently
there,
there
is
also
an
attribute
that
specifies
the
protocol
and
a
protocol
version
that
might
be
an
option
to
say:
okay
use,
user
system
or
broker
in
the
span
name
and
if
that
doesn't
exist,
then
use
a
protocol.
A
D
This
problem,
so
in
christian
python
and
ruby,
it
is
very
common
for
to
have
a
library
that
does
like
abstract
messaging
and
you
can
use
whatever
driver
you
want
underneath
it.
So,
for
example,
in
python
the
package
is
called
celery,
it's
very
popular
and
you
just
configure
it
with
something
it
supports,
I
think
rabbit
mq
and
redis,
and
maybe
some
other
messaging
systems,
and
you
just
call
the
interface,
but
you
don't
know
what
will
be
used
underneath,
but
it
still
follows
the
semantics
of
the
messaging
system.
D
So
you
can
like
put
something
in
the
queue
or
read
from
the
queue
and
in
these
cases
we
like
it's
configurable.
It's
like
an
organ.
We
don't
know
what
will
be
used
underneath.
So
in
these
cases
it
can
also
be
complicated,
and
then
we
don't
even
know
like
the
protocol.
We
only
know
that
it's
like
an
abstract
thing.
D
Yeah,
but
I
like
to
tell
you
how
I
use
the
dbc,
the
messaging
system,
it's
very
convenient,
because
if
I
have
a
spam-
and
I
want
to
show
it
in
the
ui
and
they
need
some
kind
of
a
header
to
to
say
this
pen
belongs
to
x,
then
this
is
the
field
I'm
using
like
that's.
Why?
If
I
get
like
a
random
spin,
I
know
if
it's
vitamin
q
or
kafka
or
sqs,
so
celery
or
whatever
the
text
is
written
in
this.
D
In
this
attribute
most
of
the
time,
I
don't
even
care
like
if
it
says
x
or
why
I
just
want
something
that
I
can
show
on
the
ui
and
for
this
usage
at
least
it
can
be
very
convenient
to
just
cite
the
client
name
so
we'll
have
like
if
we
know
jms,
I
don't
know
jms,
but
we
can
just
type
jms
there
or
a
gives
some
value
to
some
people.
But
it's
not.
C
A
A
Yeah,
so
that
again
is
basically
the
name
of
the
of
the
library
more
or
less
that
is
used.
A
D
Usually
for
javascript
and
python
and
ruby,
which
I
know
very
well
what's
written.
D
Name
or
instrumentation
library
name
how
it
was
used
to
be
called,
is
like
the
registry
name
of
the
package
itself,
so
it
could
contain
something
like
telemetry
instrumentation,
a
kafka
or
like
it
can
come
in
various
shapes
and
then
the
backhand
have
to
wear
like
also
sit
somewhere,
say:
okay,
if
it's
from
ruby
then
like
replaced
at
the
beginning
with
something
it
has
to
execute
some
logic.
D
And
if
we
have
it
in
the
system,
it
can
be
very
handy
to
use,
because
it's
already
like
ready
for
to
be
used
in
ui
without
any
changes.
D
A
Yeah,
I
see
I
mean
definitely
have
it
seems,
there's
lots
of
lots
of,
I
wouldn't
say
problems,
but
lots
of
like
issues
with
using
like
this
populating
this
messaging.
That
system
here
I
mean
yeah,
using
like
a
generic
library
like
trim
s
or
salary.
That's
a
good
point.
I
mean
in
the
in
the
ideal
open
telemetry
world
out
there
I
mean,
I
think
the
idea
is
that
yeah,
you
can
create
like
this.
A
This
generic
layer,
b2ms
or
celery,
can
create
spans,
but
then
the
particular
implementation
that
is
used
underneath
I
mean,
can
still
like
change.
This
active
span,
like
those
those
kind
of
plugins,
then
could
add
attributes
to
the
active
span
or
even
change
the
span
name,
but
I
think
that
is
probably
something
not
true
if
that
is
something
that
we
can
require
and
rely
on,
and
that
makes
sense
in
all
in
all
instances.
D
A
A
So
that
is
so
it's
actually.
I
think
that
is
something
that
I
I
need
to
think
about
and
maybe
prototype
how
that
model
with
like
with
this
additional
generic
instrumentation
layer
fits
into
fits
into
our
scenarios
that
we
came
up
with
here.
A
I
mean
it's
probably
pretty,
might
fit
pretty
bad
here
because
for
publish
you
might
maybe
just
have
a
generic
like
celery
layer
and
then
for
the
crate
spans
those
come
from
from
the
actuary
plugin
underneath,
so
it
might
might
work
rather
like
for
those
scenarios
for
those
scenarios
where
we
just
have
like
a
single
published
span.
A
It
might
be
harder,
but
yeah
I
mean
that's,
that's
probably
another
benefit
of
having
like
this
flexibility
that
one
can
also
easily
model
those
kind
of
multi-layer
scenarios
where
your
burden
is
like
the
generic,
the
generic
library
or
api
layer
on
top
and
then
underneath
you're,
using
a
specific
broker-specific
plugins.
D
I
think
it's
also
an
analogous
to
the
like.
In
the
databases
we
have
the
db
driver
and
then
the
orm
on
top
of
it,
so
we
have
the
same
issues
there.
Sometimes
the
db
system
is
not
known,
because
the
ofm
is
generic,
it
can
works
with
virus
drivers
and
we
also
have
it
in
the
http.
We
have
the
low
level
instrumentation
of
the
framework,
and
then
we
have
some
client
on
top
of
it.
That
can
also
be
instrumented.
D
A
Yes,
I
think
this
luke
miller
was
working
on
this
on
a
proposal
about
instrumentation
layers,
but
unfortunately
it
wasn't.
A
Is
that
when
we
think
about
this
approach,
where
we
have
like
this
generic
to
a
master,
salary
library
and
then
the
specific
workings
plugins
underneath
we
might
actually
in
in
that
instance,
here
have
different
values,
end
up
with
different
values
for
that
endpoint
property.
A
Because
on
this,
like,
let's
say
salary
level,
we
don't
yet
know
where
we're
ascending
to
so
that
might
just
be
a
the
only
thing
we
could
write
into
would
be
other
or
celery
or
whatever,
but
then
underneath
here
in
the
actual
per
game.
We
know
where
we're
sending
to
so
here.
We
could
say:
okay,
it's
a
kafka
event,
hubs
or
sqs.
A
So
basically
we
would
have
in
this
one
trace
that
processes
more
or
less
the
same
message.
We
would
end
up
with
different
values
for
this,
for
this
property
and
then
also
different
values
in
the
span
name
for
this
system
or
endpoint
property,
and
I'm
not
sure
if
that,
actually
so
more
confusing
than
helpful.
B
And
there's
there's
also
the
thing
about,
for
example,
if
we
use
the
scope
now
the
scope
name
and
let's
say
the
user
doesn't
use
any
library,
any
any
abstraction
library
and
does
it
on
on
itself
or
if
the
library,
for
example,
is
not
instrumented
or
something
like
that,
then
the
span
name
could
be
just
the
application
name
and
and
not
like
the
library
name
or
something
like
that.
I
don't
know
if
that
is
even
a
real
case.
That
would
happen,
but
it
would.
A
Fine,
but
I
definitely
think
we,
I
definitely
think
we
should
not
use
the
scope
name
for
the
spending.
I
think
that
can
be
used
as
put
like.
We
have
the
attribute
that
helps
us
to
identify
the
library,
but
I
definitely
think
we
shouldn't
use
it
in
the
in
the
span
and
we
should
have
something
there.
That's
more
controlled
and
like
more
of
a
low
cardinality
right,
well
defined
value.
There
yes
makes
sense.
A
So
you're
thinking
I'm
at
least
for
me
thinking
about
those
scenarios
I'm
doubtful
again,
but
it
makes
sense
at
all
to
actually
have
the
the
system
endpoint
or
broker
name
in
the
span
name
at
all,
because
I
think
when
it's
just
in
an
attribute,
I
think,
on
this
level
it
makes
sense
that
you
have
different
values
there,
because
you're
this
level.
You
trust
you
don't
know
yet
you're,
just
like
say,
jms
or
salary,
and
on
this
on
this
level,
you
have
like
a
different
name,
because
you
know:
okay,
now
I'm
sending
the
kafka.
A
So
I
I
think
on
on
the
attribute
level,
it's
okay,
but
having
that
in
the
span
name,
I
I
I
can
see,
situations
for
users
actually
might
be
confused.
B
You
mean
you
mean
having,
for
example,
in
the
top
level,
publish
having
the
jms,
whatever
the
the
the
abstraction
abstraction
library
name
and
then
underneath
then,
when
the
provider
actually
has
access
to
the
protocol,
the
enhanced,
then
then
we
have
the
span
with
the
proper
yeah.
I
don't
know
yeah,
I
I
I
I
agree
with
what
amir
said
like
when
using
this
this.
B
Database
work:
this
is
something
that
happens
as
well
and
there
in
there
it
is
okay.
I
think
I
already
seen
it.
I
think
it's
fine
for
for,
like
a
user
to
see
like
a
span
from
from
from,
I
don't
know,
entity
framework
or
some
other
and
then
have
a
lower
level
of
spend
for
sql,
for
example,
with
the
sql
query.
Sometimes
logged.
A
B
A
B
B
A
C
Yes,
because
the
destination
sort
of
an
optional
part,
if
you
know
it,
you
can
include
it
but
yeah,
I
don't
know.
Maybe
that's.
Okay,.
A
Yes,
so
again,
here
we
had
like
compared
to
the
original
or
the
current,
so
many
conventions,
the
current
semantic
conventions.
There
is
als
there.
Always
they
ask
for
a
low
cardinality
destination
name
always
so.
If
there's
some
auto
generated
like
id
in
the
destination
name,
we
just
ask
to
somehow
normalize
that
into
a
low
cardinality
value
and
kind
of
we
we
said.
Okay,
we
take
a
different
approach
here,
so
we
just
say:
okay,
if
there
is
this
high
cardinality
destination
name
with
some,
maybe
auto
generated
id
in
it.
A
We
just
make
this
optional
and
then
yeah
you're
right.
We
would
end
up
with
really
like
with
just
the
one
word
expanding.
It's
maybe
either
deliver
saddle.
C
A
That
is,
that
is
indeed
a
good
question
and
I
think
for
let's
check
again
what
the
http
does,
because
I
think
http
does
something
similar.
E
A
I
okay,
that
is,
that
is
mostly
for,
like
for
server
instrumentation
yeah
for
client,
instrumentation,
yeah,
it's
http
and
then
the
method
name.
D
I
think
for
spam
names
like
from
what
I've
seen
so
far
with
existing
instrumentations
and
by
reviewing
instrumentation
like
the
span
name,
is
not
really
enforced
in
any
way.
It's
more
like
a
recommendation,
but
when
you
come
to
implement
it
you
just
if
something
doesn't
feel
right
like
if
it's
too
confusing
and
your
specific
instrumentation
would
benefit
more
from
some
different
name,
which
means
more
to
users.
D
Then
I
see
that
it's
okay
like
it's
like
if
it
makes
sense
it's
okay,
to
write
whatever
you
want
in
the
span
name.
At
least
this
is
what
I
see
in
the
community
currently,
so
I
think
we
too
should
give
general
guidance
about
local
denali
and
what
data
we
think
is
good
to
have
in
the
spanish
and
maybe
recommend
it
if
it
doesn't
make
sense
or
if
it's
some
other
format.
That
makes
more
sense,
then
it's
okay
to
use
it,
because
I
don't
expect
any
automated
processing
to.
D
C
C
I
wonder
if
we
allow,
for
the
first
token
or
word
in
the
span
name
to
be,
you
know
a
descriptor
of
some
kind
and
we
could
suggest
it
could
be
the
broker
name
or
the
protocol,
but
some
short
description,
that's
low.
Cardinality
of
you
know
what
is
doing
the
messaging,
whether
it's
a
standard
api,
a
protocol
or
a
broker.
C
D
A
A
Breaking
the
implementation
of
this
conventions
so
that
that
freedom
is
there,
I
think
we
should
still
try
to
come
up
with
so
at
least
when
we
don't
can
come
up
with
like
if
we
say,
okay,
that
doesn't
work
for
all
cases,
we
should
try
to
have
like
some
recommendations
that
will
cover
most
of
the
cases.
A
So
we
have
some
some
consistency
here.
C
Yeah,
I
agree
with
that.
I
think
that
you
know
you
may
know
the
broker.
You
may
not,
and
you
may
know
the
protocol
you
may
not,
and
so
we
can
kind
of
highlight.
I
think
that
broker
and
protocol
are
good
choices,
perhaps
and
and
maybe
a
description
of
the
api
being
used.
You
know
a
low
cardinality
description
of
the
api
being
used
might
be
a
good
third
option,
but
yeah
keeping
the
normative
text
simple,
like
what
you
have
and
having
some
suggestions
in
the
non-normative
text
is
probably
a
good
approach.
C
Because
again,
I
think
if
we
don't
provide
enough
guidance
for
someone
who
doesn't
know
tracing
inside
and
out,
they
wouldn't
know
have
enough
understanding
of
when
they,
when
would
be
a
good
idea
to
break
the
suggested
rule
that
the
should
rule
and
when,
when
or
if
you
know-
I
don't.
I
don't
clearly
know
this-
the
messaging
system,
if
we
don't
have
any
guidance,
someone
who
doesn't
know
tracing,
wouldn't
know
what
they
should
use
instead.
But
so
I
think
I
think
this
is
what
we're
talking
about
is
a
good
idea.
A
They
may
be
appended
in
the
end
if
it
is
low
cardinality
and
I
think
the
the
unknown
we
currently
we
currently
have
is
just
like
what
what
kind
of
generic
or
what
identifier
would
do
we
put
at
the
beginning
here,
because
we
don't
want
to
just
end
up
with
a
spandex
just
settle
or
deliver,
and
I
mean
what
I
will
just
propose
here
is
that
maybe
we
also
leave
this
as
an
open
question
and
maybe
reverb
revisit
it
once
we
are
through
with
like
other
discussions
about
other
attributes,
because
we
still
have
like
a
list
of
attributes
there
and
I
think,
as
we
might
discuss
those
we
might
like
get
the
maybe
other
things
might
come
up.
A
That
will
help
us
to
to
make
a
decision
here,
because
we
still
have
have
attributes
here
that
are
like
messaging
the
protocol,
so
that
maybe,
when
we
discuss
when
we
discuss
after
we
discuss
those,
maybe
we
can
have
like
make
a
more
informed
decision.
D
D
D
A
I
mean
I
I
I
think
that
is
I'm
not
sure
if,
if
we
need
to
spell
that
out
here
specifically
and
I'm
not
sure
if
that
sounds
more
like
a
special
case
to
me,
so
I'm
not
sure
if
you
want
to
have.
Basically,
this
is
a
general
rule
for
all
cases.
A
I
think
if
we
want
to
have
this
as
a
more
specific
rule
for
certain
cases,
then
I
think
it's
just.
I
I'm
not
even
sure
if
you
should
explicitly
spell
it
out
here,
because
I
think
the
short
formulation
gives
you
enough
freedom
to
say,
okay,
this,
for
my
particular
like
library
or
system.
This
operation
name
is
too
confusing.
So
I
just
add
something
here,
because
I
have
a
good
reason
to
kind
of
hear
not
to
exactly
what
is
spelled
out
here.
A
Oh
I'm,
not
sure
army,
if
you're
more
kind
of
kind
of
thinking
about
making
this
a
general
recommendation,
that's
to
be
followed
in
all
cases.
D
I
think
that
people
usually
that
when
they're
not
very
experienced,
they
just
follow
the
spec
blindly,
so
they
say
okay
here
I
have
to
set
the
operation
and
they
just
use
the
operation,
and
sometimes
they
don't
like.
They
said
this
is
the
spec.
This
is
what
they
will
do.
So
I
think
just
another
comment
like
if
something
else
works
better.
If
publish
is
not
native
to
to
your
system,
then
it's
okay
for
the
spanish
to
use
the
ascend
or
whatever
that
makes
sense.
C
Yeah,
I
think,
just
as
someone
who's
recently
tried
tried
to
digest.
You
know
the
original
specification
here
and
try
to
implement
against
it
and
who's
not
familiar
with
tracing
that,
if,
if
the
main
per
and
main
purpose
of
the
span
name
is
going
to
be
kind
of
human
consumable,
and
it's
not
critical
that
it
follow
rigid
format
and
that
it's
meant
to
be
machine.
C
You
know
that
has
to
follow
this
or
to
break
something
somewhere,
and
the
main
point
of
it
is
that
it's
low
cardinality
said
it
can
be
analyzed
and
queried
and
stuff
like
that
that
I
think
maybe
providing
that
guy.
It's
like.
Maybe
that
guidance
doesn't
belong
here
because
that's
probably
true
of
all
spam
names
and
all
of
tracing.
C
A
I
think
for
messaging,
maybe
less
so,
but
also
to
a
certain
extent
that
when
you
change
like
when
you
use
different
messaging
systems
like
it's,
let's
say
you
have
like
you
use
a-
I
don't
know
event
hubs,
and
then
you
change
so
something
else
you
use
like
kafka.
A
You
should
still
like
you
shouldn't
get
like
a
completely
different
spending.
In
both
cases
I
mean
there
should
be
like
some
consistencies
in
between,
like
between
different
messaging
systems,
that
that
you
get,
and
I
think
that
is
kind
of
the
reason
for
putting
like
some
kind
of
guidance
here.
As
I
said,
messaging
is
kind
of
more
like
there's
more
variety
there.
A
But
if
you,
if
you
think
things
just
about
http,
I
mean
there's
lots
of
http
libraries
out
there
and
when
you
use
like
a
different
http
client,
you
shouldn't
get
a
completely
different
span
name
and
I
think,
to
a
maybe
lesser
extent,
it's
also
true
for
messaging
system.
So
I
think
that's
that's
the
main
purpose
of
this
kind
of
recommendations
that
we
can
up
here
that
there
is
yeah
at
least
some
kind
of
consistencies,
some
kind
of
consistency
into
spending.
B
Yeah,
I
think
it's
more
of
the
user
experience
as
well
like
yeah.
I
I
bet
that
there
is
large
system
that
that,
in
the
same
transaction
talks
to
different
messaging
system,
maybe
because
there's
I
don't
know
the
business
reasons
for
talking
to
different
ones,
and
if
you
look
at
the
whole
trace,
then
let's
say
I
use
kafka
and
rabbit
mq
at
the
same
time
in
my
in
my
system.
B
A
Yes,
but
as
I
said,
I
would
recommend
that
we
leave
the
span
name
for
now.
We
and
we
kind
of
try
to
discuss
some
for
the
attributes
and
then
maybe
like
when
we're
through
with
the
attributes.
Then
we
kind
of
revisit
the
span,
naming
guidance
that
we
give
here,
because
I
will
by
today
I
would
at
least
like
to
let's
see
if
we've
been
here,
maybe
talk
about
destination
and
see
whether
there's
any
anything
controversial
controversial
about
this
attribute,
because
also
in
the
regions
back,
it's
a
required
attribute.
A
A
First,
checking
with
you
whether
kind
of
the
name
is
in
any
way
uncare
if
destination
is
a
proper
name
for
that,
and
also
the
question,
if
you
really
can
like
assume
that
this
messaging
destination
can
be
populated
in
all
cases.
So
here
for
this
one,
we
don't
care
about
cardinality.
We
just
care
about
accuracy
here,
so
if
the
destination
is
kind
of
a
very
complicated
auto-generated
name
that
should
still
be
put
here
in
this
attribute.
D
D
So
we
have
to
like
combine
those
two
fields
in
some
way
and
I'm
thinking.
If
the
spec
should
someone
somehow
handle
this
situation,
maybe
we
can
have
like
a
destination
general
and
then
messaging
destination
dot,
something
to
to
extend
the
destination
with
more
parts
that
are
semantically
related.
C
I'm
just
wondering
in
terms
of
the
rabbit
mq
choice
there
like
the
destination,
is
a
string,
and
so
could
they
would
another
option
for
rabbit
mq
to
be
to
encode
both
of
those
information
into
a
string
somehow
in
some
way
that
they
chose?
Is
that
another
option
for
them
instead
of
adding
another
attribute.
A
Yeah,
that's
a
question
here.
That's
where
I
would
tend
to.
I
would
rather
see
that
as
kind
of
a
a
problem
that
needs
to
be
solved
here
in
this
rabbitmq
specific
section,
then
in
like
the
generic
in
in
the
in
the
generic,
basically
attributes
section
that
you're
currently
working
on
because
yeah.
Basically
we
have
one
exception
here,
but
I
think
we
don't
want
to
design
the
generic
layout
around
this
exception,
and
I
I
think
I
agree
with
duane
there
could
be
for
rabbitmq.
A
C
I
don't
know
if
this
yeah,
I
agree,
I
don't
know
if
this
spec
covers
it,
but
I
do
think
we
should
say
that
messaging
dot.
I
don't
know
vendor
system
provider
whatever
should
be
a
a
common
place,
that
a
specific
messaging
paradigm
can
put
extra
attributes
related
to
it
specifically,
and
they
should
be
free
to
define
that.
However,
they
like
it,
because
I
don't.
C
Would
want
all
of
that
to
come
back
into
the
spec?
I
don't
think
we
want
to
start
adding,
or
maybe
we
do.
Maybe
we
do
start
adding
for
all
of
the
different
messaging
platforms.
You
know
what
extra
information
should
be
included,
or
are
we
trying
to
keep
this
just
more
generic
messaging
and
each
messaging
platform
that
does
its
own
thing
from
there.
A
I,
what
I
definitely
would
like
to
do
is
that
that
we
have
a
document
for
the
generic
conventions
and
the
specifics
for
each
messaging
system
should
be
in
a
separate
document,
so
we
still
might
have
that.
What
is
here
for
kafka
for
rabbitmq,
but
it's
not
in
the
in
the
main
document,
it's
separate
documents
with
maybe
different
kind
of
stability.
A
Like
standards
I
mean,
maybe
our
like,
even
if
our
our
kind
of
generic
conventions
are
stable,
you
can
still
like,
add
experimental
stuff
for
other,
or
you
can
have
a
different,
basically
document
state
for
the
other
ones.
A
B
A
Yes,
I
think
that
is
a.
That
is
a
good
example.
Actually,
I
think
we
don't
have,
for
example,
specific
area
lambda,
basically
it's
kind
of
an
extension
to
this
fas
conventions,
and
I
think
we
want
to
have
something
similar
for
for
messaging
here,
so
yeah
for
for
the
destination.
I
think
I
would
definitely
like
to
keep
this
as
a
single
attribute
and
maybe
just
change
just
the
rapidmq
specific
conventions
so
that
they
basically
pack
all
that
is
needed
to
uniquely
identify
the
destination
in
in
in
one
attribute.
D
But
then,
if
somebody
wants
to
know
like
the
broker
or
the
routing
key,
you
will
have
to
pass
this
messaging
destination
field
in
some
some
consistent
way
right.
A
I
I
think
you
can,
then
I
think
it
can
be
concatenated
into
destination,
but
then
for
rapidmq
you
can
still
have
additional
separate
fields,
message,
rabbitmq.exchange
and
key,
and
so
you
can
then
also
query
the
individual
parts
without
needing
to
kind
of
split
the
parse.
B
But
then
in
the
generic
message
destination,
then
all
the
messaging
systems
they
always
have.
I
guess
something
that
fits
in
in
all
cases
for
this
field
right
and
then
they
have
more
specific
things
like
this
routing
key,
but
the
message
destination
always
makes
sense
to
all
of
them.
I
guess
in
some
level.
A
Yes,
I
think
that's
even
when
not
knowing
the
messaging
system
or
the
messaging
broker
or,
however,
we
will
call
it.
I
think
destination
should
have
like,
should
have
like
the
the
common
semantics
and
we
say:
okay,
it
kind
of
really.
This
is
the
only
basically
attribute
that
we
need
to
identify
the
destinations
and-
and
there
is
no
other
attribute-
we
might
look
at
at-
maybe
some
other
cases
to
make
this
to
make
this
unique.
B
Because
I
think
we
discussed
this
the
other
day,
but
it
was
in
in
relation
to
the
same
name,
but
in
the
application.
If
this
is
static,
it's
it's.
B
It
will
be
possible
to
use
it
to
to
add
it,
but
in
in
a
so,
for
example,
if
I'm
using
this
abstraction
libraries
to
send
the
messaging
to
to
talk
to
the
to
the
messaging
system,
is
it?
Is
it
possible
there
to
know
the
the
destination
that
doesn't
know
that?
I
guess
it
knows
right
so
like
to
be
able
to
create
this.
This
stance
and
populate
this
destination
is
this
something
that
is
this
abstraction
libraries
are
always
aware
of
it.
B
I'm
just
thinking
if,
if
we're
not
making
this
required,
for
example,
if
it's
implementation,
we'll
we'll
run
into
problems
open
it
populating
it
because
last
time
we
discussed
that
if
we
use
this
display
name,
it
could
could
be
problematic
because
some
layers
don't
have
access
to
the
destination.
B
No,
I
don't,
I
don't
have
it
except
I'm.
Just
I'm
just
wondering
now.
D
D
B
C
So
and
one
thing
that
I
find
I
found
a
bit
confusing
with
the
concept
of
destination,
is:
it
makes
perfect
sense.
Of
course,
when
you're
sending
a
message,
it's
either
the
topic
you're
sending
to
or
the
or
the
queue
once
it
gets
to,
let's
say
the
queue
and
then
someone's
consuming
from
it.
So
the
broker's
sending
it
to
the
client,
the
consumer
from
the
queue
is
the
destination
describing
the
consumer
or
describing
where
the
message
is
coming
from.
C
My
conclusion,
after
thinking
about,
is
that
it
should
be
describing
the
queue
it
came
from
right
like
it's,
but
but
it's
kind
of
not
the
destination
at
that
point
and
then
at
some
other
spans
like
settle
as
well.
It's
I
think
you
would.
You
would
want
to
say
the
queue
that
you're
you're
settling
the
message
from,
but
it's
the
term
destination
gets
slightly
confusing
those
contexts.
A
I
I
definitely
agree
because
what
is
the
destination
on
the
producer
side,
it's
more
or
less
the
source
on
the
consumer
side,
but
I
I
think
here
we
want
to
have
the
the
same
term
refers
to
both.
I
think.
Basically,
you
have
the
queue
name
and
the
same
on
producer
and
the
consumer
side.
Also
it's
the
source
on
on
consumer
side.
So
that's.
C
Yeah
just
like,
as
long
as
we
define
that
I
think,
and
then
one
other
thing
just
to
consider
is
that
in
you
know,
pub
sub
model
a
a
producer
might
produce
to
a
topic
foo,
and
that
causes
the
message
to
end
up
on
a
cue
called
bar
and
so
and
maybe
other
keys
as
well,
and
so
you
know
you'll
end
up
with
a
trace.
That's
that
might
say
that
the
message
was
sent
to
foo
and
then
a
consumer
would
get
a
message
from
bar
and
that's
all
one
trace.
I
think
that's
all!
C
B
Yeah
so
yeah,
but
but
the
case
that
you
discuss
is
interesting.
I
mean
like
if,
if,
if
the
broker
sends
the
message
or
is
pushing
the
message
to
the
consumer,
what
what
will
be
the
destination
then
like?
What's
that?
Because
the
the
broker
doesn't
know
about
any
consumer
right
so.
C
B
But
but
do
you
you
mean
using
like
some
sort
of
not
hard
code
but
some
static
value
when
it's
pushing
to
to
consumers?
Like
I
don't
know.
C
A
Yeah
and
and
again
this
only
makes
basically
this
destination.
We
shouldn't
like
confuse
things
here
with
the
intermediary
instrumentation,
because
we're
just
talking
about
produce
producer
consumer
here
so
also
on
the
consumer
side.
Basically,
this
this
keyword
topic
will
be
that
we
are
getting
the
message
from
that's
basically
a
source
we
call
it
destination.
I
mean
it
gets
even
more
confusing.
Then
we
also
take
the
intermediary
into
account
because
from
the
intermediary
destination
might
be
something
very
different
again.
C
A
description
of
me
who
received
it
because
I'm
where
the
message
ended
up
or
is
it
where
it
came
from?
And
I
think
in
that
case
I
think
it
doesn't
make
sense
that
it's
where
it
came
from.
So
I
think
in
the
same
sort
of
yeah
go
ahead.
B
No,
but
it's
confusing,
I
think
it
would
be.
It
would
confuse
a
lot
of
people
like
if
I
see
a
consumer
or
I
receive
spam,
and
then
there
is
a
destination
attribute.
I
I
I
don't
know
what
what
I
would
make
of
it.
I
would
be
really
confused
about
it.
To
be
honest,
I
would,
I
would
say
source
would
make
sense
in
that
case,
to
call
it
messaging.source
or
I
don't
know
yeah
or
from,
for
example,
not
not
destination.
C
I
think
that's
fine
too,
I
guess
we
would
just
have
to
say
then
and
we
can
defer,
because
I
know
we
put
a
span
name
on
the
side,
but
that
then
you
would
only
have
either
one
of
a
source
or
a
destination,
and
you
would
put
whichever
one's
present
in
the
span
name.
That
would
be
fine
if
yeah,
if
we
like
that
better
yet.
A
I
don't
really
have
a
strong
opinion
there
I
mean,
I
think,
where
this
term
here
come
from,
I
think
it
comes
from
jms,
because
many
terms
here
are
kind
of
basically
based
on
tremendous
but
yeah.
I
will
I'm
not
sure
whether
the
best
solution
here
is
to
kind
of
basically
have
three
options
here
either.
We
just
add
like
a
good
description
here,
to
make
it
clear
what
it
is,
or
we
split
it
up.
A
C
Yeah
I
I
like
the
idea
of
one
attribute
whatever
it
is,
maybe
the
name
could
be
improved.
I
I
was
struggling
to
think
of
a
better
term,
however,
but
because
then
then
you're
gonna.
If
we
decide
to
keep
the
next
one
destination
kind,
you
probably
have
to
have
you
know
destination
kind
sources,
it
kind
of
blows
up
if
you
can't
keep
it
to
one
term
whatever.
That
term
is.
A
Yeah-
and
I
mean
I
one
reason
I
also
like
to
keep
like
one
one
attribute
here-
is
that
yeah
you
have
it
on
the
producer
and
the
consumer,
and
it
basically
refers
to
the
same
thing
like
you
have
like
kyofu,
and
you
have
kyufu
in
the
in
the
producer
and
you
have
it
in
the
consumer.
A
C
Actually,
I
I
sort
of
like
I
was
just
thinking
about
this,
a
bit
more,
a
point
you
raised
earlier,
so
you
made
me
something
you
said
earlier,
john.
That
made
me
think
about
it.
Was
you
know
a
message
can
be
sent
to
a
topic
foo
then
land
on
a
topic
bar
and
then
get
delivered
to
a
consumer,
and
at
that
point
the
destination
of
that
message.
Like
the
topic,
the
thing
you
published
it
to
is
still
foo
but
you're
receiving
it
from
bar.
C
Both
of
those
things
are
probably
useful
pieces
of
information
like
the
original
destination,
because
the
that's
that's
immutable
on
the
message.
The
consumer
sees
that
topic
foo.
It
also
knows
that
it
was
bound
to
bar
and
it
received
from
bar,
and
I
think
understanding
it
came
from
that
queue
is
useful.
C
That's
always
the
same
thing
right,
they're
point
to
point
so
where
you
said
you
sent
it
to
is
where
you
got
it
from,
but
in
pub
sub
models
where
you
get
it
from
might
not
be
the
same
thing
you
sent
it
to,
and
so
maybe,
depending
on
the
messaging
paradigm.
If
the
source
is
different
than
the
destination
and
the
consume,
you
would
have
an
additional
attribute.
Perhaps
would
that
make
sense?
Sir?.
A
Yes,
I
mean
that's
actually
a
good
point,
because
that's
a
kind
of
ambiguous
here,
because
yeah
when
you
have
the
case
where
you
sent
to
foo,
but
you
received
from
bar
and
then
on
the
consumer
side,
it's
actually
not
clear
what
to
put
into
message
destination
because
you
know
both.
A
You
know
the
message
was
sent
to
foo
and
you
know:
okay,
I
got
it
from
bar
secretary,
but
what
do
I
put
in
here
into
this
destination
attribute
it's
kind
of
not
clear,
so
one
last
question
here
mostly
to
to
you
to
end
like
this.
This
scenario
where
you're
like
sent
to
fu
and
power
like
basically
where
this
source
and
destination
names
are
different,
is
this?
Does
this
happen?
Often
in
your
experience
is
that
the
regular
scenario.
C
You
know
I
don't
know,
come
across
these
terms
like
event,
mesh
and
stuff
kind
of
this
is
a
new
event-driven
architecture.
It's
a
it's.
A
best
practice
is
to
have
these
things.
You
know
loosely
coupled
sort
of
the
more
traditional
older
style
messaging
is
much
more
point-to-point,
but
you
kind
of
and
and
so
but
let's
say
it's
evolving
rapidly-
that
that
they're
very
decoupled
and
that
they
would
be
separate
in
many
cases.
A
Yeah,
okay,
that
makes
sense,
so
I
will
try
to
read
up
a
bit
on
this,
maybe
also
we
can
involve
clements
into
that
next
time,
right
at
the
beginning,
when,
when
he
joins
and
get
his
opinion,
but
that
seems
we
need
some
more
definitely
more
clarification.
If.
B
B
If
any
of
you
guys
have
some
links
or
some
examples
of
this,
maybe
you
can
share
as
well,
so
we
can
also
redone
on
the
on
this
particular,
for
example,
case.