►
From YouTube: 2022-05-12 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
I
unfortunately
I
didn't
have
there
were
some
discussions
last
time
and
also
some
slack
discussions
with
duane
and
unfortunately
didn't
have
time
to
update
the
the
outdate
itself
here,
but
the
the
discussion
we
did
last
night
was
about
destination
and
the
confusion
that
this
term
causes
and
then
to
answer
suggested
to
have
like
messaging
to
destination
and
messaging
that
source,
basically
a
destination
would
be
the
qr
topic
or
whatever
the
message
is
sent
to
and
then
source
would
be
the
your
topic.
The
message
is
received
from.
A
I
think
that
makes
sense.
I
mean
the
I
would
say
the
pros
of
this
approach
is
that
yeah,
it's
it's
clearer,
like
the
term
destination,
it's
misleading,
so
it's
clearer
like
we
have
the
destination
and
we
have
source.
A
It's
also
provides
for
some
yeah
richer,
like
possibilities
for
richer
instrumentation,
because
even
on
the
because
on
the
consumer
side,
one
could
have
like
both
source
and
destination
as
attributes-
and
you
see,
okay,
that's
the
topic
or
queue.
This
message
was
sent
to
and
that's
the
topic
this
message
was
received
from
because
they
can
be
different.
B
I
have
a
question:
what
do
you
think
about
instead
of
destination,
we
will
have
messaging.q
name
and
messaging.topic,
and
that
way,
if
someone
is
sending
to
a
topic
and
reading
from
a
cute
and
there's
no
confusion,
and
we
also
can
don't
need
the
destination
kind
as
it's
embedded
in
the
key.
What
do
you
think
about
it.
C
My
thinking
on
that
is
that
I
would
like
to
avoid
being
too
prescriptive
on
terminology
and-
and
I
know
it's-
I
know
that
there's
pros
and
cons
each
way,
but
topic
and
q
are
concepts
in
certain
messaging
systems,
and
you
know
other
other
messaging
systems
have
their
own
terminology
and
by
embedding
certain
terminology
right
into
the
attribute
names
at
or
or
values.
C
I'm
concerned
that
we
kind
of
make
it
hard
to
adopt
the
spec
in
other
messaging
systems.
I
was
going
to
suggest
for
destination
kind,
that
maybe
we
have
some
examples,
but
that
we
don't
say
that
those
are
the
only
valid
values.
C
You
know,
for
example,
like
you
know,
rabbitmq
might
want
to
use,
you
know
a
topic
exchange
or
what
they
call
an
exchange
or
whatever
or
a
router
a
key
exchange
pair
or
something
and-
and
I'm
just
wondering,
I'm
jumping
ahead
a
little
bit,
but
I
was
wondering
if
we
want
to
allow
other
messaging
systems
to
extend
it
with
the
you
know,
recommendation
that
cardinality
is
kept
low
and
stuff
like
that
or
or
if
or
if
such
things
should
be
kept
to
messaging.rabbitmq
dot
whatever.
B
A
The
the
topic
in
queue
I
mean
actually
here
it
says:
destination
kind-
must
be
either
keyword
topic,
but
I'm
yeah.
I
might
be
doubtful
whether
we
should
keep
this
up
because,
firstly
I
mean
that's.
I
I
think
that
I'm
pretty
sure
that
comes
from
the
trey
mess
side,
because
lots
of
the
terminology
here
is
taken
from
trems
like
destination,
is
taking
from
there
and
everything.
Also
cuban
topic
is
taken
from
there,
but
I
I
think
the
well,
let's
see
what
what
this
one
remark
is
also
for
destination
kind
of
oh
yeah.
A
Basically,
it
says
destination
kind
is
more
or
less
optional
and
it
can
only
be
topic
and
queue,
and
it
is
only
required
if
a
message
is
sent
to
either
a
topic
or
a
queue.
A
So
if
you,
I
think
the
idea
here
is
that
if
none
of
topical
queue
matches
yours,
you
just
skip
this
destination
kind,
and
maybe
you
have
a
messaging
like
your
system,
specific
attribute
that
describes
where
the
message
is
sent
to
so
we,
for
example,
have
I
don't
know
I
mean
for,
for
I
can
just
talk
about
azure
event
types.
I
mean
there's
just
a
matter
of
of
terminology,
but
I
mean
it's
kind
of
similar
to
a
topic,
but
it's
not
called
topic.
A
It's
just
called
an
event
hub,
and
so
maybe
there,
if
we
would
be
strict
about
the
monologue,
we
would
just
say:
okay,
it's
not
either
neither
topic
nor
q.
So
we
don't
have
messaging
destination
kind,
but
maybe
we
have
then
messaging
dot
event,
hubs,
dot
destination
kind,
and
this
is
then
like
event,
laptops.
A
I'm
not
sure.
I
don't
really
like
this
very
much.
I
also
don't
see
like
the
the
immediate
use
of
of
this
destination
kind
attribute
at
all.
I'm
not
sure,
I'm
not
sure
how
much
I'm
not
sure
about
usage
scenarios
where
this
bird
is
really
benefits
the
user.
A
lot.
C
I
mean
the
problem,
is
you
can
have
topics
and
queues
that
have
the
exact
same
name?
I
think
that's
probably
where
it
comes
from,
and
this
allows
you
to
tell
identify
which
it
was
because
the
destination
on
its
own
wouldn't
do
that.
C
I
I
don't
I
I
don't
know
about
temp
destination,
I
mean
that's
the
next
one,
which
I
that
I
don't
see
being
of
use
to
identify
it's
simply
an
attribute
of
the
of
the
destination
and
I'm
not
sure
that's
as
useful,
but
it
could
be
maybe
to
know
that
if
this
doesn't
get
delivered
somewhere,
maybe
it's
because
the
the
endpoint
went
away
the
destination
went
away
right.
Maybe
that's
why
it's
there?
I'm
not
sure.
A
A
I
I
mean
one
thing
I
definitely
regardless
of
regardless
of
any
kind
of
semantic
details
we
come
about
here,
but
one
thing
I
definitely
would
would
change
here.
Is
that
a
kind
and
this
type
here
or
this
temporary
or
anonymous
flag?
As
we've
said
here,
I
definitely
think
we
should
have
like
a
gear
hierarch
hierarchical
layout.
Here
on
the
attribute
level,
I
think
if,
if,
if
we
say
okay,
we
need
those
two,
then
it
should
be
messaging
to
destination.kind
and
messaging.destination.anonymous.
A
Like
a
flag,
so
we
have
that
clearly
structured
and
probably
then
we
have
basically
used
the
same,
the
same
semantics
for
both
destination
and
also
for
source.
A
So
we
have
then
also
source
dot
kind
and
source
dot
anonymous,
but
yeah
the
the
kind
still
is
for
me.
It's
it's
a
bit
of
a
question
mark
because
I
agree
with
duane
that
it
might
make
sense
to
it
might
make
sense
in
terms
that
it's
necessary
to
uniquely
identify
the
destination,
but
I'm
a
bit
on
the
edge
here
about
just
restricting
this
to
two
possible
values,
either
q
or
topic.
That
seems
a
bit
now,
not
not
just
thinking
about
gms.
B
I
just
want
to
say
that
I
use
it
in
a
spector's
ui
when
I
get
a
span
and
identify
it
as
a
messaging
span.
I
construct
like
a
description
of
the
span
like
a
header
for
the
details
about
the
spam
and
I
say
something
like
a
consume.
B
B
Yeah,
I
think
it's
also
a
bit
of
of
a
waste,
because
we
have
this
attribute
on
every
single
span
that
we
send
and
it's
should
be
for
most
use
cases
and
static
and
from
what
I've
seen
it's
static
in
the
code,
and
we
just
send
it
again
and
again
and
again,
possibly
millions
of
times
to
just
not
show
it's
the
most
efficient
thing
to
do.
But
it
is
convenient
in
some
cases.
A
Yeah,
so
I
think
I'm,
what
do
you
mean
in
sense
of
static?
Is
that
basically,
you
can
infer
this
value
actually
from
the
messaging
system
or
from
the
messaging
broker.
So
if
you
have
some
given
brokers,
that
will
also
always
be
queue,
and
for
some
it
will
always
be
topic
and
there's
only
a
few
where,
basically,
you
cannot
infer
from
the
broker
name
to
this
to
the
destination
kind.
B
But
yeah,
what
will
we
write
for,
for
example,
in
a
rabbit
where
the
destination
is
a
combination
of
exchange
and
routing
key?
So.
A
Question,
let's,
let's
see
well,
there's
nothing,
there's
nothing
defined
here
or
so
for
in
terms
of
the
destination
types.
I
see
nothing.
A
I
mean
what
is
what
is
for
me
a
bit
confusing
is
also
that
that
we,
it's
kind
of
all
this
this
here
it
says.
Basically,
it
can
only
be
keyword
topic
and
if
it's
a
queue
or
topic,
you
must
specify
it,
and
if
it's
not
a
queue,
it's
neither
queue.
Nor
topic.
You
just
leave
it
out
so
that
that
is.
That
is
also
a
bit
kind
of.
A
So
I
I,
I
definitely
think
we
should
clean
this
up
and
probably
we
can
clean
it
up
by
by
opening
this
up
a
bit
that
we
say.
Okay,
we
have
this
messaging
messaging.destination.kind.
A
So
it's
not
I'm
not
sure
if
we
can
and
should
make
it
required
and
then
and
then
in
the
further
kind
of
system,
specific
details,
we
can
say:
okay
for
rabbitmq,
for
destination.com,
just
use
this
value
that
makes
sense
for
rapid
mq
and
for
event
hubs.
We
just
use
their
hub
or
event
hub
and
that
can
be
then
spelled
out
into
specific
requirements,
but
here
in
the
general
ones
we
just
leave
it
more
or
less
open
with
optional,
not
sure
what
you
think
about
that.
I.
C
I
was
gonna
say
two
things
I
think
one.
I
agree
with
your
suggestion
that
allow
for
those
values
to
be
extended
and
if
they
are
extended,
they
should
be
documented
in
the
system
specific
saying
this
like,
if
you
have
the
rabbit
mq
spec
saying
rabbitmq,
allows
specifies
this
value
may
also
appear
in
destination.kind,
and
you
know,
and
so
per
per
messaging
system.
C
You
would
define
extra
values
that
can
appear
there,
and
the
other
suggestion
I
was
going
to
have
is
that
whatever
we
decide
for
these
destination
dots,
whatever
things,
I
think
we
should
also
include
those
for
source
like
source.kind
and
and
source.temporary,
and
the
last
thing
I'm
going
to
mention
is
on
the
top
concept
of
temporary
versus
anonymous.
C
Those
are
two
actually
separate
concepts.
Right
temporary
refers
to
its
durability,
whether
it
can
come
and
go
anonymous.
First
to
whether
you
know
anyone
knows
like
the
opposite
of
anonymous,
we
call
well
known,
and
so
is
it?
Is
it
something
well
known
someone
can
just
publish
to.
You
can
have
a
well-known
temporary
destination
that
comes
and
goes
as
the
consumer
comes
and
goes,
but
anonymous
is
something
you
can't
really
know
unless
the
owner
of
it
told
it
to
you.
It's
usually
often
a
reply
to
in
a
request.
Reply,
message
pattern.
C
So
it's
it's
kind
of
created
with
a
very
generated
name,
maybe
with
a
uu
id
in
it,
and
you
have
to
tell
someone
what
it
is
for
them
to
be
able
to
send
to
it.
That's
anonymous
and
those
are
usually
temporary,
but
temporary.
Neurons
are
two
separate
concepts
which
we
may
want
to
include
both.
A
That
that
makes
sense
I
mean
for
me
that
that
makes
perfect
sense.
I
mean
for
me
anonymous
like
we
had
that
when
we
discussed
cardinality
and
this
I
basically
put
in
my
terms,
I
think,
for
me,
an
anonymous
destination
is
basically
a
destination
name,
that
for
me,
as
a
human
consumer,
doesn't
really
make
sense.
A
So
if
I
see
destination
anonymous-
and
I
see
kind
of
some-
I
don't
know
base64
string
here-
that
basically
tells
me:
okay,
don't
really
try
to
interpret
that
that
doesn't
make
sense,
whereas
when
it's
not
anonymous,
you
might
have
a
well-formed
name.
That
makes
sense
to
a
human
consumer.
C
Yeah-
and
I
think
temporary
is
useful
too,
because
if
you
see
a
message
get
put
on
a
temporary
cube
sent
to
a
temporary
queue
and
then
you
don't
see
it
get
consumed
it's
reasonable
to
assume
that
that
you
know
that
destination
went
away
so
it
just.
I
think
it's
some
helpful
information
as
well.
I
think
temporary
knowledge
are
both
useful.
A
Yes,
I
mean
what
actually,
I
then
would
recommend
here.
Maybe
what
we
do
is
that
we
basically
make
this
destination
and
source
kind
of
like
a
distinct
type,
and
we
can
say:
okay,
there's
both
destination
source
of
this
type
and
they
have
the
attributes.name.kind
dot,
temporary
and
anonymous,
and
that's
how
basically,
both
source
and
destination
are
defined.
It's
kind
of
like
a
type.
B
Those
attributes
will
be
like
accurate
and
not
guaranteed
to
have
low
cardinality
right.
So
if
your
destination
is
something
that
contains
id,
then
it
will
be
written
into
the
destination
right.
A
A
Yes,
so
basically,
if
you
only
filter
four
destination
names,
where
dot
anonymous
is
false,
then
you
very
likely
get
something.
That's
low,
cardinality.
B
Did
that
make
sense
yeah,
I
think
in
mqtt
you
can
send
messages
to
arbitrary
topics
like
you
can
embed
an
id
inside
the
topic
and
it
works,
and
it's
not
a
temporal
tempo
temp
destination.
It's
like
because
it's
not
auto
generated
it's
something
with
the
meaning,
but
it
is
a
high
cardinality
because
it
contains
id.
So
what
do
you
think?
How
should
that
fit
into
the
model?
Yeah.
C
No
you're
absolutely
right.
That's
not
there's
a
lot
of
messaging
systems
like
that.
I
I,
when
I
actually
when
I
said
that
I
think
that's
more
for
cues,
but
for
topics
you're,
absolutely
right.
Yeah.
A
I
think
we
don't
give
any.
We
don't
put
any
cardinality
requirements
on
those
attributes
here
whatsoever,
so
I
think
the
user-
maybe
it's
safe,
to
say
the
user-
can
never
assume
low
cardinality
on
those
destination.
Names
yeah,
because
they're
just
they're,
just
more
kind
of
their
main
aim,
is
just
to
be
accurate
and
not
to
be
kind
of
a
fast
period.
D
A
Yes,
I
mean
the
messaging
metrics
are
a
very
different
topic.
Then
maybe
one
day
we
will
get
to
that
yeah.
I
think
here
for
the
span
attributes.
No,
we
don't.
We
definitely
don't
assume
low
cardinality
there
because,
as
I
said,
I
think
here
domain
aim
is
accuracy
and
not
and
not
cardinality.
B
We
talked
I
remember
about.
Maybe
if
we
have
like
something
like
http
route,
which
is
guaranteed
to
be
local,
the
narrative,
then
we
can
write
it
in
a
different
attribute,
which
back-ends
can
can
use
to
do
some
aggregations
which,
which
is
what
will
be
written
into
the
name
as
well
to
the
span.
Name.
A
That's
a
good
question:
I'm
not
sure
if
it's
a
common
and
well-defined
enough
concept
that
it
merits
adding
it
here
to
the
to
the
general
attributes.
I
mean.
D
I
think
there
was
a
point
in
the
main
part
of
the
document
right
because
I
think
the
name
we
didn't
finish.
We
just
pause
it
for
a
moment.
Yes,.
A
D
Yeah
but,
but
if
it
is
that
case
that
amir
said
like
if
the
destination
is
is
a
is
a
low
cardinality
thing
and
it
can
be
used,
then
that
would
probably
be
together
with
the
name,
as
we
said
so
send
and
then
destination
name.
A
Yeah,
I
think
that
amir
suggested
something
different
from
destination.
It's
something
like
a
route
and
basically
this
route
kind
of
is
so
is,
I
guess
the
destination
name
will
then
somehow
be
built
based
on
this
route
by
probably
filling
in
some
kind
of
identifiers
that
are
embedded
in
this
route
like
a
similar
http
and
then
the
route
will
always
be
low.
Cardinality,
but
destination
itself
can
be
high.
Cardinality.
B
In
our
back
end
to
do
aggregations-
and
I
currently
use
the
messaging
destination
to
do
the
aggregations-
and
sometimes
it
doesn't
work-
it
just
gives
me
a
lot
of
results
and
I
have
to
like
write
the
if
statements
to
say:
if
it's
this
system,
then
don't
do
the
aggregation
and
stuff
like
that.
So
I
think
it
will
be
convenient
to
have
low
cardinality.
It's
like
the
http
route,
which
is
very
useful
because
it
has
guaranteed
to
be
low.
Cardinality.
B
So
there's
also
this
problem
in
http.
Sometimes
you
don't
know
the
local
denali
route
and
you
have
to
write
what
you
have,
but
no
matter
what
you
ride
there.
It's
guaranteed
to
be
local,
the
narrative
which
is
really
powerful,
and
if,
if
you
can't
feel
this
value,
then
you
have
to
write
something
that
that,
like
the
best
effort,
the
best
thing
you
can
do
that
will
not
cause
cardinality
to
to
be
infinity.
B
A
C
I
think
I
think
you
can't
make
it.
I
think
you
can't
make
it
mandatory,
but
I
think
it
is
a
useful
thing
like
it's
it's,
maybe
I'm
not
sure
if
route
is
the
best
term
or
or
if
something
like
a
template
is
a
better
term.
But
when
you
define
like
when
you
have
an
application,
you
define
topic
structures.
C
There's
often
like
you
know
things
that
are
kind
of
low
cardinality
and
there's
pieces
that
might
be
high
cardinality,
which
are
kind
of
a
variable
right
inside
your
program
like
order
id
or
you
know,
maybe
gps
coordinates
right.
You
put
those
in
a
topic
and
they're
at
defined
levels,
but
it
could
be
useful
to
kind
of
know
that
this
message
is
being
sent
with
this
topic.
Template
and
and
those
things
are
all
related
in
some
way.
Everything
has
the
same.
C
Template
probably
comes
from
the
same
application
or
whatever,
and
so
I
could
see
that
being
useful
to
aggregate
on,
but
I
don't
think
you
can
make
it
required
because
you're
not
it's,
definitely
only
going
to
be
the
application
itself.
That
knows
that,
and-
and
I
think
we
want
to
be
able
to
have
auto
instrumentation
produce
this
and
and
but
I
think
it
could
be
useful
if
you're
able
to
provide
it
that
it
might
be
a
useful
thing
to
include.
A
Yeah
I
mean
we
could
make
it.
I
mean
when
we
have
this
kind
of
generic
type
anyway
for
destination
and
source,
then,
along
with
dot
kind,
dot,
name,
dot,
temporary
in
dot
anonymous,
we
can
also
add
a
dot
template
or
dot
route
or
whatever
we
want
to
name
it,
and
that's
gonna
be
like
an
optional,
basically
attribute
on
this
destination.
I
think
I
I
guess
it
it
doesn't
make
much
sense
on
the
source,
like
I'm,
not
sure.
If
you're,
I
guess
you
don't
have
the
template
on
the
consumer
side
but
yeah.
C
A
C
A
C
E
Yeah
I
mean,
I
don't
think
they're
they're
they
they
would
call
it
a
a
channel,
be
a
parameterized
channel,
but
I
don't
really
love
that.
I
really
love
that
term
anyway,
so
I
mean
I
I
think,
param
destination
template
seems
as
good
as
anything
to
me
at
least
as
a
first.
The
first
shot.
B
B
So
so
you
write
it
twice,
but
when
you
write
it
into
the
local
denominator,
then
beckons
can
use
it
to
to
do
stuff.
When,
when,
if
it's,
if
it's
written
into
the
high
calibrinality
destination,
then
they
can't
assume
anything
general
on
it.
So
and
and
many
other
systems
sqs
also
like
the
destination,
is
always
low,
carbonarity,
but
but
beckons
can't
know
it
if
it's
not
in
the
right
attribute.
E
Yeah,
that's
interesting
yeah
for
us
at
least.
If
it's
a
wild
card,
carded
topic,
you
know
the
template
would
be
low.
Cardinality
probably,
but
the
actual
implemented
topic
would
be
would
be
high
cardinality.
So
I
do
think
that
is
an
interesting
distinction
and
would
be
really
really
helpful.
C
The
only
thing
that
I
I
see
a
lot
of
value
there,
the
thing
that
seems
unfortunate
is
that
you
know
that
the
topic
could
be
somewhat
long.
I
don't
know
like
100
bytes,
wouldn't
be
unreasonable
and
to
have
to
include
it
twice
for
those
use.
Cases
is
a
bit
unfortunate,
I'm
not
sure
I
know
of
a
I
I
if
you
want
both
pieces
of
information.
C
B
A
You
know
I
mean
what
we
basically
can
require.
I
mean
I
think
we
will
here.
We
have
this
message,
the
destination
and
it's
basically
required,
and
I
think
what
what
we
can
make
required
like
with
our
new
idea
that
we
have
here
messaging,
like
destination.name,
we
can
make
required,
but
I
think
any
of
the
other
attributes
we
came
up
with
be
the
template
or
the
kind
or
the
temporary
or
anonymous.
A
A
I
I
think
that
is,
that
is
how
it's
reasonable
from
the
instrumentation
point
of
view,
I'm
not
sure
from
the
backend
point
of
view.
Basically,
you
have
the
template,
then
there
possibly,
but
you
cannot
rely
on
it.
So
maybe
then
you
have
you
either
use
the
template
or
you
have
to
for
end.
If
you
don't
have
a
template,
you
do
just
use
the
destination
name.
A
Maybe
we
need
to
think
about
how
useful
that
is
from
the
back-end
side,
but
I
think
from
the
simulation
side
it
does
not
make
sense
to
say:
okay,
this
template
is
required
because
that
will
I
think
that
again
will
will
confuse
lots
of
users
and
and
make
them
kind
of
not
not
know
what
to
write
into
this
template.
A
I
think
that's
a
pretty
special
concept
that
when
you,
when
you're,
really
confronted
with
that
it
makes
sense,
but
in
in
most
other
scenarios
people
will
just
be
confused
by
it
and
not
know
what
to
do
there.
A
A
A
Protocol
is
probably
I
mean
we
had
the
discussion
when
we
talked
about
the
system
here
or
the
brokers
recorded.
We
said
yeah
that
in
many
instances,
the
or
in
some
instances,
the
system
or
the
broker
cannot
be
known
like
when
you
use
like
maybe
jms,
that's
instrumented
and
I
think
yeah
the
protocol
is
it's
it's
the
same
here
I
think
in
some
instances.
Maybe
you
will
know
it
when
you
create
a
spans,
but
in
many
instances
you
just
you
don't
know
it,
I
mean
that's
the
whole
purple.
A
A
A
level
deeper,
I
think,
for
the
for
the.
I
actually
think
that,
as
we
talked
here
in
the
very
beginning
that
we
are
working
here
on
the
application
that
we
made
distinction
between,
like
the
application
layer
and
the
transport
layer
and
actually
think
this
is
part
of
the
transport
layer-
and
I
think
it
might-
it
just
makes
sense
to
have
this
here,
because
currently
we
don't
have
this
transport
layer
kind
of
further
specified
or
even
present.
A
So
I
think
in
the
ideal
world
then
at
some
point,
then
we
wouldn't
need
this
here,
because
we
would
just
see,
like
a
child
span,
that
models
like
the
amqb
operation
or
the
mqtt
operation.
That
is
underneath,
but
I
guess
that
in
the
meantime
it
it
might
be
valuable
to
have
this
as
kind
of
a
hint
at
least
on
the
on
the
publish,
create
or
receive
spends.
A
Not
true,
if
you
have
any
thoughts
about
that
like
about
the
utility
of
this
and
the
any
thoughts
or
feelings
about
the
about
the
protocol.
Here.
C
I
I
think
it's
useful
to
have.
I
do
the
only
thing,
just
from
experience
working
with
some
people
to
implement
something
off
of
this
spec,
that
to
to
make
clear
that
it
should
be
only
the
messaging
layer
protocol.
It's
not
meant
to
capture
whether
it's
over
tls
or
websocket
or
tcp
or
or
anything
like
that-
that
I
think
we
talked
about
a
little
bit
before
and
that's
sort
of
in
the
responsibility
of
the
net
dot
whatever.
C
B
D
C
I
mean
the
reason
I
think
it's
useful.
You
know,
I'm
gonna
speak
for
my
solace
experience,
but
I
think
it
applies
to
others
as
well.
Is
that
you
have
a
messaging
system
if
you
have
a
messaging
system
that
that
has
many
protocols
like
both
in
and
out
and
cross
protocol,
it's
useful
to
be
able
to
see
that
a
message
maybe
came
from
an
amqp
and
is
going
out
to
htp,
and
although
that
is
broker-centric,
I
still
think
that
even
without
any
transport
layer
broker
messages,
you
can
still
see
an
amqp.
C
You
know
kind
of
publish
right
from
the
from
the
producer
side
and
http
receive
and
and
process
on
the
consumer
side
and
being
able
to
sort
of
understand
that
these
are
kind
of
very
different
clients.
I
think
could
be
useful
if
your
your
system
is
kind
of
all
one
protocol,
then
obviously
it's
much
less
interesting.
A
Yeah,
but
I
I
I
definitely
can
see
some
use
of
that-
I
mean
probably
not
really
like
in
terms
of
providing
like
visualizations
based
on
that,
but
I
can
see
use
of
that
in
terms
of
troubleshooting
like
when
you
see
okay,
especially
as
brand
said,
obviously
not
for
systems
that
just
like
use
one
protocol,
but
I
know
from
event
hubs.
For
example,
you
can
specify
like
how
different
protocols
of
how
you
want
to
send
a
message
and
definitely
when
something
goes
wrong
and
you
want
to
troubleshoot.
C
A
Yes,
I
think
that
that
makes
sense.
I
mean
again
I
mean
when
I
think
about
event
up
now.
I
remember
like
we
have,
I
think,
two
options
you
can,
but
I
think
it's
both
mqb,
but
it's
mqb
over
one
time
it's
over
tcp
and
then
it's
over
web
sockets.
I
think
that
actually
would
not
go
into
this.
I
think
that's,
that's
that's
what
we
said
you're
going
to
keep
out
here,
so
it
will
just
always
be
mqb
but,
as
we
said,
I
think,
for
for
systems
to
really
like
accept
different
protocols.
A
D
I
think
it
makes
sense,
but
it
will
only
be
populated
anyway.
Afterwards,
right
after
we
define
this
transport
layer,
semantics.
A
Not
not
necessarily,
I
think
the
I
mean
if
it's
available,
I
guess
right.
So
I
think
the
main
purpose
of
this
is
actually
to
have
this
present.
As
long
as
our
transport
layer
is
not
defined,
that
is
not
available.
The
people
can
still
have
like
some
way
of
kind
of
saying.
Okay,
that's
that
was
the
protocol.
A
I
used
I'm
just
not
trying
this
messaging
protocol.
I
guess
it
will
be
similar
to
like
destination
kind
that
we
just
say:
okay,
we
don't
have
any
like
enum
here,
so
that's
kind
of
you
just
put
in
here
what
makes
sense
to
you.
So
we
don't
restrict
this
to
just
a
list
of
value,
because
I'm
not
sure
if
we
can
come
up
with
like
an
exhaustive
list
here.
A
And
because
then
just
here
is
having
here.name
and
here.version,
I
think
otherwise,
probably
this
can
we
can
take
this
over
as
it
is.
B
For
example,
in
sqs
it
makes
a
lot
of
sense
because
you
are
accessing
endpoint
and
you
can
fill
this
value
with
any
point.
That
is
very
useful,
but
in
other
cases
in
a
I
don't
know
in
a
rabbit.
I
think
you
also
have
this
url
that
you
can
use
where
it
has
the
the
host
and
the
port
and
then
like
a
protocol
in
the
beginning,
but
I
think
for
kafka.
There
there's
no
way
to
construct
this
mobile,
I'm
not
sure
about
it,
but
I
think
it's
useful
when
it
makes
sense.
C
Yeah,
I
I
think,
because
it
can
help
you
figure
out
like
especially
without
any
sort
of
broker
level
tracing
it
can
help
you
figure
out.
You
know
what,
like
this
sort
of
identity,
help
identify
which
broker
the
message
maybe
got
sent
to,
but
what?
C
What
a
there's
a
lot
of,
I
think
we
need
more
guidance
on
what
this
is
meant
to
accomplish,
because
in
terms
of
a
you
know,
they
define
it
as
a
connection
string
here,
but
I've
like
I
know
like
for
us,
anyways
like
if
you
for
an
system,
your
the
application
and
the
the
sdk
is
configured
with
a
like
a
comma
separated
list
of
urls
that
it
should
try
connecting
to
and
it'll
go
to
whichever
one's
up
so
should
it
be
the
full
list
of
what
it's
configured
with
and
where
it
might
connect
to
you,
or
should
this
be
specifically
the
one
it
is
connected
to
when
it's
sending
the
message,
I
think
the
latter
probably
makes
the
most
sense,
like
the
actual
url
you're,
sending
this
message
to.
A
I
definitely
think
the
letter
makes
more
sense,
but
I'm
not
sure
if,
if
that
can
always
be
known
on
the
level
where
this
is
added,
because
I
I
again
think
the
problem
goes
already
deeper
like
in
the
I
mean
it's
kind
of
a
kind
of
touching
definite
transport
in
layer
instrumentation,
and
I'm
I'm
not
sure
if
in
any
case
like
here
on
this
on
this
top
layer,
you
can
know
which
of
the
list
is
actually
chosen.
C
I
wonder,
would
it
be
good
to
have
a
make
it
optional
and
then,
if
you
like
kind
of
similar
to
the
protocol,
if
you
know
it,
I
think
it
can
be
useful
information,
but
have
it
optional?
If
you
don't
know
it,
that's
fine
yeah.
A
I
mean
it's
optional
anyway,
whenever
a
bit
like
yeah,
I'm
not
sure
how
to
exactly
define
this
here,
just
as
dot
url,
dot
connection
string
and
for
me
it
feels
like,
if
there's
any
url,
you
can
associate
this
message
through
just
drop
it
in
here,
no
idea
what
it
is,
but
just
yeah,
if
you
have
neural,
then
drop
it
in
here
that
that
feels
a
bit,
maybe
useful
in
some
cases
from
the
spec
side
a
bit
weird
to
me,
I'm
not
sure
if
this
should
be
like
a
messaging
system,
specific
thing
that
kind
of
basically
for
let's
say
sqs
yeah.
A
You
have
kind
of
a
well-defined,
well-defined
field
for
this,
for
this
url
and
and
I'm
a
bit
on
the
fringe
here
for
just
having
like
a
generic,
messaging.url
and
yeah.
Basically,
it
can
mean
something
different
for
for
each
system
that
you're
using.
A
But
yeah
that
that's
that's
just
my
take!
So
I'm
a
bit
a
bit
confused
by
that,
but
yeah.
C
Yeah,
I
think
you're
right
like
how
it
looks,
might
be
very
different
depending
on
the
system
like
you
said,
and
maybe
that's
a
hint
that
it
belongs
in
a
you,
know,
messaging.rabbit
or
messaging.amc,
where
or
messaging.sqs
whatever
system
you're
using
might
define
something
that
is
useful
for
that
system,
and
maybe
it's
too
generic
here
in
in
the
top
level.
C
A
It's
pretty
generic
because
if,
if
I
think
about
how
would
you
use
this
attribute,
I
think
you
wouldn't
build
like
visualizations
based
on
these
url
attributes,
you
would
kind
of
aggregate
based
on
this
url
attribute.
I
think
how
you
would
use
it,
you
would
use
it.
Maybe
for
you
have
a
specific
trace
and
you
want
to
troubleshoot
this
or
get
info,
and
then
you
look
at
this
url
and
I
think
in
this
case
it's
much
more
useful
when
you
have
let's
say
messaging.sqs.uh.
A
Url,
instead
of
just
a
generic
messaging
dot
url
because
then
already
the
attribute,
like
name,
gives
you
some
kind
of
hint
what
this
is
about,
whereas
when
you
have
just
messaging.url,
I
mean
it
doesn't
tell
me
anything
so
I
I
would.
I
would
vouch
for
kind
of
taking
this
out
here
and
and
providing
like
more
specific
attributes
that
are
system
specific.
D
Hopefully,
not
your
your
other
good
things,
some
sort
of
bii
or
something
like
that
yeah
I
don't
know,
I
think
it
makes
sense
to
move
move
it
down,
go
remove
it
from
the
top.
Yes,.
A
A
D
I
just
had
to
remember
something
that
I
was
reading
the
discussion
from
from
duan
from
about
the
the
source
and
destination.
I
I
I
is
the
source
always
possible
to
to
like
is
our
consumers
over
always
like
they
do?
They
always
have
the
possibility
to
to
to
find
this
this
source
on
their
site,
or
is
should
should
that
also
be
required,
or
should
that
be
optional,
because
from
from
reading
the
discussions,
I
I
kind
of
got
the
feeling
that
the
destination
is
is
clear
that
is
required
but
source.
D
I
I
from
reading
all
the
different
different
messaging
systems
scenarios.
I
I
kind
of
got
the
feeling
that,
for
the
consumers,
the
the
source
might
not
be
always
possible
to
to
find
or
or
or
I'm
totally
wrong
about
it.
C
C
And
in
some
systems
like
kafka,
where
you
know
your
topics
are
very
low
cardinality,
I
think
your
source
and
destination
are
always
the
same
thing.
C
A
Yes,
I
think
the
source
on
the-
I
think,
that's
how
I
try
to
summarize
it
like
destination.
You
always
know
that
on
the
producer
side-
because
you
are
you
know
where
you
send
your
your
message
to
and
the
source-
I
think
you
always
know
on
the
consumer
side,
because
I
mean
you
don't
just
say,
get
messages
from
kafka,
get
messages
from
rabbitmq.
A
B
A
D
Okay,
that
is
clear
now
I
think
that
that
was
what
when
I
was
reading,
I
got
a
bit
confused,
but
that
makes
sense
now.
A
A
You
can
maybe
it's
worth
thinking
about
how
this
kind
of
models,
or
if
this
should
somehow
be
also
be
modeled
using
those
those
attributes.
A
A
You,
you
could
say:
okay,
it's
not
strictly
necessary,
because
when
you
look
at
your
whole
trace,
you
basically
see
your
consumer
link
to
the
producer,
and
you
see
where
the
producer
sent
the
message
to
so
from
looking
at
the
whole
trace
kind
of
having
the
destination
on
the
consumer
span.
2
is
kind
of
redundant,
but
maybe
it's
just
like,
or
I
can
definitely
see
actual
scenarios
where
it's
just
interesting
for
for
for
searching
or
filtering
that
you
say:
okay,
when
you,
when
you
say
okay,
I
kind
of
in
my
system.
A
I
reliably
have
this
destination.
Also
on
the
consumer.
Spans
and
destination
is
different
from
from
stores.
Then
you
could
just
search
all
your
consumer
spans
for
a
given
for
a
given
destination
that
I
I
can
see
how
that.
How
that
makes
sense,
and
thus
also
kind
of
the
redundancy
makes
sense
because
yeah
it
it's
hard
to
search
for
that,
just
based
on
the
complete
trace.
But
if
you
have
all
the
information
on
one
thing
in
spain,
it
might
be
quite
a
bit
easier.
A
But
yeah
I
will,
I
think,
you're
almost
at
the
end.
I
will
try
to
until
next
week
to
write
it
down
so
we're
basically
the
destination
and
source
and
also
the
protocol
stuff,
the
url
we
leave
out
for
now
and
then
maybe
next
time
we
can
talk
about
message,
id
conversation
id,
I'm
not
sure
we
didn't
in
our
own
tip.
We
didn't
introduce
the
concept
of
a
conversation
at
all.
A
A
A
B
B
A
E
A
So
thanks
everybody
and
see
you
in
two
weeks
and
have
fun
at
cubecon.