►
From YouTube: 2022-04-28 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
C
B
So
we
discussed,
we
discussed
the
thing
about
the
spain
name
and
low
cardinality
and
and
what
we
could
do
and
what
what
options
we
could
we
could
use
yeah.
I
think
it
was
pretty
much
pretty
much
everything
around
that.
B
D
D
And
I
updated
the
old
tap
with
what
we
talked
about
last
time.
So
please,
if
you
have
some
time,
have
a
pass
over
this
and
see
that
it
makes
sense.
D
What
are
the
changes
to
the
in
regards
of
the
span
name
if
we
start
with
that
to
the
current
spec?
It's
basically
that
I
mean
when
you
look
at
the
example
here,
as
opposed
to
the
current
spec.
I
added
the
the
messaging
system
name
here
at
the
beginning,
that
is
not
there
in
the
current
spec
and
the
operation
name,
that's
the
same.
That
is
required
also
in
the
current
spec
and
the
destination
name
here,
based
on
our
discussion
last
time.
D
This
is
how
I
wrote
it
here
is
that
the
operation
name
only
should
be
added
if
it's
a
flow
cardinality,
and
if
there
is
no
lower
cardinality
destination
name,
then
it
should
be
left
out.
D
So
try
to
kind
of
also
make
this
a
bit
clearer
here.
Also
what
low
cardinality
means?
Basically
put
it
like
this
that
I
said
yeah
when
translation
should
only
be
added
when
it's
a
flow
continuity.
That's
usually
the
case
when
a
destination
name
is
a
meaningful
and
manually
configured
name
like
a
cure
topic
name,
and
it's
usually
not
the
case.
If
the
destination
name
is
an
auto
generated
identifier.
D
So
just
trying
to
make
clear
what
what
the
understand
by
by
low
cardinality.
D
Yeah,
that's
that's
how
the
examples,
how
examples
then
look
like
we
always
have
like
the
messaging
system
at
the
beginning.
We
have
the
operation
and
then
we
have
an
optional
destination
name
and
then,
maybe
today
we
can
talk.
I
think
we
said
yeah
the
last
time
we
will
talk
more
about
the
difference
between
messaging
system
and
messaging
protocol.
D
D
We
have
no
this,
we
don't
distinguish
between,
publish
and
create,
and
I
think,
there's
also
distinction
between
receive
and
deliver.
But
let's
have
a
look.
What?
D
Oh?
Yes!
So
in
this
in
the
existing
conventions,
there
are
only
like
three
operation
names,
and
here
we
basically
have
f5.
We
have
like
two:
we
have
this
publishing
crate
split
up.
We
have
saddle-
and
here
we
have
the
receiving
deliver
for
push
pull,
and
I
mean
those
basically,
those
correspond
to
all
those
to
the
spans
that
we
laid
out
in
this
when
we
talked
about
the
span
structure.
D
So
that's
how
it
comes
with
these
operation
names
here
and
then
I
added
a
section
about
the
span
kind,
which
kind
should
certain
spans
have
with
certain
operation
names-
and
this
also,
I
think,
should
be
pretty
straight
forward,
except
the
publish
and
create
there
is
some
some
some
iron
core
complications
or
some
additional
details
here,
but
for
I
mean
for
receiving
delivery,
it's
clear
there
are
always
consumer
spends
that's
what
we
want
them
to
be
for
create
create
is
also
is
order,
put
is
always
the
producers
and
and
for
publish.
D
I
was
not
sure.
Maybe
you
can
give
an
opinion
here,
but
for
with
publish
and
create
we
have
the
case.
Let's
look
at
the
bumpers,
we
have
the
case
where
we
just
have
a
published
span
and
it
links
to
the
consumer,
and
we
have
the
case
when
we
have
great
spans
that
link
to
the
consumer.
D
So
here
this,
the
link
here
can
to
the
consumer
can
either
go
from
the
public
or
from
the
great
span,
and
I
think
in
this
case
here,
if
the
link
goes
from
the
published
span,
I
think
it's
very
clear
for
us
that
this
published
span
should
be
of
kind
producer.
D
And
the
published
span
is
I
put
it
here
as
as
internal
in
that
case,
so
I
put
it
here:
is
that
that
the
publish
span
is
off
is
of
type
producer
if
no
great
spans
are
present.
Otherwise,
it's
internal,
because
I'm
I'm
I'm
not
sure
if
it
makes
sense
to
have
them,
publish
and
create
spams
or
those
spans
here
of
kind
producer.
D
Yeah,
I
think
one
thing
why
I
made
great
the
the
producer
here
is
that
you
have
this
link
here
and
I
think
the
link
should
always
go
from
a
producer
span
to
a
consumer
spam.
I
think
that
makes
it
easier
to
interpret
those
links.
I
think
it
would
be
actually
weird
if
we
have
a
link
going
from
an
internal
span
to
a
consumer
span
here.
I
think
that
would
confuse
at
least
at
least
two
pack
and
backhands.
Instead,
I
know.
C
Yeah,
the
the
the
idea
behind
producer
and
consumer
and
client
and
service
fans
are
to
to
try
to
show
system
boundaries
essentially
to
help
back-ends
understand
that
there's
a
boundary
system
boundary
there.
C
Since
we
don't,
we
don't
mark
serialization
events
like
inject
or
extract,
or
anything
like
that.
I
do
know
I
don't
know
the
details.
I
do
recall
there
was
some
some
people
having
a
look
for
like
client
server
spans
about
whether
it
would
be
acceptable
for
there
to
be
like
a
stack
of
client
spans
or
a
stack
of
server
spans
due
to
maybe
having
several
layers
of
instrumentation
that
struggled
to
communicate
with
each
other.
C
D
D
I
don't
see
any
complications
with
either,
but
maybe
the
area
I
don't
know
philosophically
more
philosophical
arguments
about
that.
C
I
think
the
other
less
important
practical
reason
is.
You
could,
theoretically
just
drop
all
the
internal
spans
and
still
have
like
a
very
coherent
topological
view
of
your
system
like,
like
the
edge
spans,
actually
encapsulate
everything
except
for
the
details.
So
that's
like
the
other
useful
reason.
D
Between
them,
but
that's
a
good
example
I
mean-
I
know
like,
for
example,
of
indexers,
will
just
draw
all
the
bonus
bands
and
only
look
at
the
producer,
consumer
and
client
yeah.
If,
if
create
here,
would
be
an
internal
span
and
would
be
dropped,
then
basically,
this
indexer
would
kind
of
not
see
yeah.
C
D
Producer
and
consumer
here
so
I'm
pretty
confident
that
every
stand
that
basically
has
an
outgoing
link
should
be
a
producer
and
every
span
that
an
incoming
link
has
an
incoming
link
should
be
a
consumer
of
kind
consumer.
I'm
just
a
bit
on
the
edge
of
this
publish
here,
because
yeah
I
mean
philosophically.
I
think
it
is
a
producer
span,
but
yeah
with
this
like
link,
it's
kind
of
a
span,
as,
as
that
said,
it's
not
interesting
for
indexers.
D
So
like
an
indexer
could
like
just
drop
this
publish
spam
so
for
an
index
it
could
be
an
internal
spam
but
yeah,
maybe
that's
like
discussing
in
a
in
a
wider
forum,
and
I
mean
for
me
personally
whether
this
is
internal
or
producer.
It
doesn't
change
much
in
the
layout
that
we
have
here
and
I
don't
really.
C
D
Yes,
so
so
here
base
it,
it
changes
for
basically
for
with
the
current
proposal
that
I
have
the
type
changes
in
between
the
scenarios.
So
here
publish
would
be
a
producer,
and
here
it
would
not
be
a
producer
right.
D
So
yeah,
I
I
leave
it
here,
then
as
it
is
for
now
I
mean,
if
you
have
any
doubts
or
cases
where,
where
you
think
that
my
problems
just
add
a
comment
and
otherwise,
I
would
say
yeah,
let's
see
when
the
writer
community
reviews
the
hotep,
let's
see
what.
E
Sorry
yeah,
I
just
love
the
lines
of
what
ted
was
saying,
but
about
auto
instrumentation.
I
just
wonder:
would
the
creator
of
the
published
fan
always
know
whether
the
things
it's
publishing
have
create
spans
or
not?
That's
the
only
thing
I'm
not
sure
about,
but
I
wonder
if
the
wording
maybe
should
be
more
like
if
it's
known
that
there
are
createspans
and
publish
the
internal,
but
is
it
okay
for
it
to
be
producer?
E
C
That's
where
having,
I
think,
I
believe,
when
this
came
up
in
other
scenarios,
we
decided
that
airing
on
the
side
of
multiple
producer
spans
is
better
than
ending
up
in
a
situation
where
you
have
an
internal
span
connecting
the
the
reality
is,
there's
probably
some
back
end
somewhere
that
gets
screwed
up
by
one
of
those
two
scenarios.
C
As
an
aside,
I
actually
think
the
this
whole
thing
is
kind
of
a
holdover
like
there's
a
lot
of
other
information
analysis
tools
can
look
at
if
they
want
to
tell
when
where
the
edges
are
between
systems
like,
I
think
I
I
think,
back-end
tools
should
look
at
the
resources
to
figure
that
out,
because
that's
a
much
more
stable
way
than
trying
to
like
glue
up
these
client
server
spans.
C
This
is
sort
of
like
like
a
zipkin
holdover,
actually
where
they
were
trying
to
actually
say
the
client
span
and
the
server
span
were
the
same
span
just
some
historical
detail.
They
were
trying
to
say
this
client
span.
The
server
span
actually
have
the
same
name
same
operation
name,
and
they
should
be
like
merged
into
one
span
and
that's
like
sort
of
the
historical
origin
of
all
this
stuff,
and
that
was
like
a
silly
idea
that
maybe
not
a
silly
idea,
but
not
a
super
tenable
idea
that
zipkin
eventually
moved
away
from
so
like.
C
I
think
we
went
with
like
better
to
air
on
the
side
of
you
know,
reinforcing
where
the
the
boundaries
are
versus.
What's
saving
internal
for
spans
that
you
could
truly
just
drop
from
like
your
ui
like
if
you
just
had
a
button
that
said
hide
internal
spans.
C
D
C
Yes,
it's
in
like
practical
terms
when
you're
trying
to
investigate
a
problem,
I
find
that
middle
view
is
sometimes
very
useful
if
you're
talking
about
a
very
large
system,
but
at
any
rate,
I
guess
my
point
is
like
err
on
the
side
of
producing
extra
edge
spans
like
if,
if
it's
something
might
be
an
edge
span,
you
should
say
it
is.
B
Yeah,
I
I
was
going
to
say
the
same
questions
when
I
said
about,
because
how
would
be
how
would
so
like
if,
if
I
pass
the
messages
to
the
publish
method,
and
they
already
have
the
create
context
inside?
How
would
that
know
unless
it
goes
over
all
the
messages
and
checks?
If
the
crate
is
there,
I
guess
might
as
well.
We
always
use
producer
maybe
to
publish
to
make
it
easier.
D
B
I
mean
we
also
have
that
the
text
that
says,
I
think
some
part
of
the
tap
that
the
create
the
create
spans
might
also
be
created
as
part
of
the
publish
so
depending
how
it's
implemented.
It
has
to
go
through
the
messages
anyway,
so
that
they
could
can
already
check
if
the
crates
is
is
in
place.
So
I
I
know
yeah.
D
I
basically,
I
probably
used
to
think
I
basically
think
with
this
published
spam,
regardless
of
the
existing
now
of
of
create
spence
or
not,
but
either
the
published
span
basically
adds
its
context
to
the
outgoing
message,
in
this
case,
like
the
published
span,
adds
its
context
to
the
outgoing
message,
and
in
this
case
the
publish
span
does
not
add
its
context
to
the
outgoing
message,
because
the
create
span
will
add
the
context
to
the
outgoing
message,
or
there
will
already
be
a
context
on
the
message
from
other
other
spans.
D
So
I
think
the
publish
fan
always
needs
to
make
the
or
the
operation
that
this
publisher
covers
always
needs
to
make
the
decision.
Do
I
add
my
current
context
to
this
message,
or
do
I
not
add
my
context
to
this
message
and
I
think,
when
the
publish
span
adds
the
con
its
context
to
the
message,
then
it
needs
to
set
its
its
kind
to
a
producer,
and
if
it
does
not
add
its
context
to
the
message,
then
it
that
that's
at
least
the
idea
now,
then
it
should
likely
leave
its
context.
D
E
Would
have
thought
the
way
I
understood
it
from
our
previous
conversations
is
that
the
publish
context
would
always
go
on
the
message,
and
it
is
the
context
that
if
an
intermediary
is
going
to
perform
tracing
that
hits
the
context
it
would
potentially
modify
as
it
went
through
and
that
the
creation
context
is
the
immutable
context,
sort
of
the
application
layer
context
that
is
processed
right
at
the
point
where
it's
being
delivered
to
the
application.
E
So
I
would
have
thought
that
the
published
context
should
always
go
on
the
message.
It's
just
two
different
contexts.
D
I
mean
here
in
this
all
in
this
examples
here
we
cover.
We
only
talk
about
this
creation
context
or
application
context,
so
there
is
no
like
transport
context
in
the
picture
yet
so,
regardless
of
whether
publisher
create,
regardless
of
whether
we
see
look
at
this
example
in
this
example,
here
it's
always
the
creation
context
that
is
there,
and
that
needs
to
be
like
immutable
on
on
the
message.
B
B
I
think
the
difference
what
what
I
think
that
what
one
is
is
asking
I,
because
I
also
have
the
same,
is
if
the
if,
like
in
the
middle
case,
the
publish
context
will
be
added
to
the
message
with
some
sort
of
key
that
is
for
the
that
was
to
be
for
the
create
and
then
later
on.
B
If
we
introduce
this
other
context,
that
is
for
the
intermediary,
then
it
just
gets
added
to
to
another
key,
for
example,
in
the
message
and
then
migrate,
another
span
for
that
case,
but
in
this
in
this
middle
case
now,
for
example,
I
call
publish
with
a
badge
and
then
all
this
all
the
methods
get
the
publish
spam
context
under
the
key,
create,
or
something
like
that
and
then
later
on.
If
we
want
to
add
another
span
that
is
mutable
for
the
for
the
intermediaries,
then
we'll
add
again
another
one
under
another
key.
B
I
guess
that's
what
the
that's,
what
I
understood
more
or
less.
E
So
as
drawn
here
in
the
in
the
bottom
diagram,
I
guess
it's
showing
that
the
crates
are
children
of
the
publish
span
right,
that's
what
it's
showing.
Yes,
I
I
is
that
always
I
wonder
if
that's
always
practical
like,
would
it
not
be
common
to
perhaps
create
a
message?
Create
another
message:
create
another
one,
create
another
one
and
then
say
send
them
all,
and
so
the
the
create
spans
would
all
have
ended.
D
E
D
I
mean
when
you
talk
about
the
transport
context
here.
Basically,
during
create
the
message
will
be
created
or
whatever
the
message
object
object
or
this
message
envelope
will
be
created
and
the
creation
context
sorry
will
be
stamped
or
will
be
put
on
the
message,
and
then
we
have
the
publish
operation
here
and
during
this
publish
operation.
Basically,
then,
the
additional
kind
of
transport
context
would
be
put
on
the
messages
and
that
that
might
be
a
trial
span
of
publishing.
D
As
I
said,
it
might
be,
then
mqb
or
mqtt
span
that
then
take
the
messages
here
and
put
an
additional
context
on
it.
So
here
we
have
them,
have
it
and
really
separated,
like
the
great
context
is
put
on
the
message
before
publish
and
the
transport
context
is
then
added
to
the
message
during
the
publishing
here.
E
E
D
I
mean
in
the
end
like
in
the
what
we
have,
what
we'll
have
here
with
with
version
one
is
just
we'll
just
have
like
an
immutable
context
on
the
message.
That's
that's
that's
how
we
will
end
up
on
the
message
level
and
for
what
we.
What
we
might
then
work
after
that
like
for
the
next
version,
is
that
we
have
the
new
dipper
creation
context
and
the
mutable
transport
context
on
the
message.
D
Basically,
that
is
kind
of
the
the
view
when
we
just
look
at
a
single
message
but
or
the
single
event,
but
it
and
that
is
kind
of
the
the
independent
of
the
span
structure
in
a
certain
way.
So,
basically
the
span
structure,
then
some
some
way
or
the
other
kind
of
needs
to
map
to
this
kind
of
a
message,
structure
or
kind
of
populate
populate
these
context
on
the
message,
and
it
doesn't
really
happen.
D
It
doesn't
really
matter
like
whether
this
great
here
is
a
child
of
publish
or
not
from
the
message
point
of
view.
Like
that's
on
the
wire,
I
think
that's
kind
of
we
give
like
a
a
freedom
here
to
the
instrumenter
to
kind
of
model.
This,
as
is
best
fit
for
them
yeah,
because
messages
can
create
be
created
before
the
publish
operation
or
they
can
be
created
during
the
publish
operation
and
the
the
instrumentals
should
be
able
to
model
that
sure
yeah.
D
So
yeah,
if
you
have
any,
as
I
said,
if
you
have
any
doubts
about
how
this
is
formulated,
just
maybe
add
a
comment
and
we
can
change
it.
Otherwise
I
will
leave
it
there
and
see
what
yeah
the
wider
forum
says
to
to
that
proposal.
Probably
there
will
be
some
discussion
about
that
when
already
we
have
some
discussions
here
so
yeah
there
are
some
questions
probably
to
be
expected,
but
I
mean
from
my
side,
as
I
said:
I'm
I'm
fine,
making
this
a
producer,
always
without
any
caveat
here.
A
D
D
I
made
settle
internal
here
because
I
think
the
client
server
or
the
client
spam
might
then
be
the
spam
that
happens
on
the
on
the
on
the
transport
level.
Instrumentation,
because,
if
settle
span,
if
settle
would
be
a
client
span,
the
settling
would
somehow
require
adding
like
a
context
to
the
message,
because
if
settled
would
be
like
the
client
operation,
then
the
scanned
operation
would
need
to
respond
to
some
kind
of
server
operation
in
the
in
the
intermediary,
and
those
two
would
need
to
be
linked
together
and
doing.
D
This
would
require
the
set
liberation
kind
of
to
put
a
context
on
on
the
message,
but
that's
not
something
that
we
have
defined
in
any
way
here.
I
think
that
is
something
that
will
happen
then
on
the
lower
transport
level,
and
that's
why
I
made
like
settle
internal
but
settled
that
might
have
like
once
we
add
the
transport
line,
instrumentation
saddle
might
have
like
a
child
span.
D
That's
again,
maybe
an
mqb
spam,
and
this
ban
there
might
be
like
a
client
spam
corresponding
to
an
mqb
server
span
on
the
intermediary
and
those
might
be
linked
together.
But
I
don't
see
like
a
link
or
parent
tried
relationship
from
this
saddle
span
here
directly
to
the
intermediary,
but
that
I
think
that
happens.
The
level
lower.
A
But
it
will
probably
not
be
instrumented
most
of
the
times
right.
We
will
just
have
this
internal
span
as
a
leaf.
A
It
will
be
like
the
last
operation
that
we
see
and
then
it's
internal,
it's
a
bit
confusing.
I
think.
A
D
A
Cause
confusion:
it's
like
when
you're
doing
a
outgoing
http
request
and
the
other
side
is
not
instrumented,
so
you
have
a
client
operation
as
a
leaf.
It's
it's
a
valid
use
case
but
yeah.
But
if
underneath
the
settle,
there
is
a
transport
span
and
it's
also
a
client-
and
this
case
is
a
bit
confusing,
have
it
in
other
places
as
well.
So
I'm
not
sure
what
what
would
you
do
in
this
case.
D
Yes,
I
mean,
I
think,
do
you
think
it
would,
if
you
think
we
have
transport
instrumentation
in
place
and
saddle
is
internal
and
then
settle
has
a
child
span,
that
is
the
client
and
that
links
to
the
intermediary.
I
think
that
is
that
is
not
confusing.
D
I
think
that
is
kind
of
the
end
goal
where
maybe
we
want
to
to
go
towards,
but
I
think
the
confusing
the
confusion
arises
when
this
transport
layer
instrumentation
is
missing,
is
that
is
that
correctly
summarized
like
the
the
the
confusing
situation
that
you
mentioned.
A
Yeah,
if
the
transport
is
missing,
then
we
just
have
this
internal
span
without
any
outgoing
indication.
Well,
in
reality,
we
had
like
out
outgoing
communication
with
an
external
service.
A
A
I
think
it's
the
most
robust
solution,
but
I'm
not
it's
not
a
strong
opinion
and
okay.
A
So
we
have
it
like,
for
example,
in
aws
sdk,
it's
an
instrumentation,
it's
creating
a
span
for
the
rpc
operation
and
then
underneath
it
we
have
http
and
they're
both
a
client,
because
the
aws
sdk
cannot
know
if
something
will
be
generated,
underneath
it
or
not.
But
the
essence
of
the
operation
is
something
that
is
like
outgoing,
even
though
it's
nested
a
few
obstructions,
and
I
think
that
also
http
clients
might
be
instrumented
and
the
http
library
underneath
them
can
be
instrumented,
then
this
problem
occurs
again.
D
Yeah
I
mean
I,
as
I
said,
I
have
no
strong
opinion
here
for
me,
it's
just
it
it.
For
my
understanding,
which
is
also
shaped
by
like
more
the
backhand
side,
is
that
when
I
see
a
client
span,
then
I
think
okay,
potentially
there
there
might
be
a
service
man.
That
kind
of
is
a
child
of
this
guy
in
spain,
and
I
think
here
we
settle.
D
That
will
never
be
the
case.
This
might
be
a
client
span,
but
then
the
there
will
always
if
there
is
like
some
link,
there
will
always
be
another
child
that
is
mqb.
That
is
a
client,
and
this
will
then
link
to
a
to
an
mqp
server,
but
the
saddle
span
will
never
kind
of
have
like
a
or
link
to
another
server
span.
D
That's
why
I
I
kind
of
put
in
turtle
here
in
the
first
place,
but
I
I
have
no
problem
making
this
a
client
spend
to.
Maybe
you
can
just
add
the
comments
to
the
to
the
to
the
tab.
Pr
and
yeah
sure
I
can
I
can.
I
can
fix
that
or
change
the
client
if
there's
no
other.
B
Yeah,
I
think
I
I
lean
towards
also
amir's
reasoning.
I
think
it.
I
think
I
already
even
saw
http
like
the
http
cases
I
mean
I
can
track
down.
Where
is
it
now?
But
I
think
I
already
saw
some
cases
like
this,
where
there's
a
client
spin
and
there's
another
one
below
you
know.
B
I
think
if
I
would
see
internal
like
this-
and
I
think
it
would
be-
will
be
strange
but
isn't
isn't
settle
operations
always
going
to
some
place.
So
there's
always
going
to
be
some
sort
of
service
fan
connected
to
it
or
or
or
some
some
other
component,
calling
a
server
to
to
acknowledge
the
message.
D
It's
actually
the
same
form
when
we
have
like
the
the
producer
span
here
when,
for
example,
publish
let's
say
it
will
be.
A
producer
span
will
add
its
context,
like
the
creation
context
to
the
message.
But
then,
let's
say
when
we
think
about
the
transport
layer,
context,
publish
we'll,
maybe
have
a
child
span,
that's
an
mqb
span
and
this
mqb
span
will
be
a
client
span
and
it
will
basically
be
then
the
parent
of
an
mqb
server
span.
D
So
then,
here
we
will
have
basically
have
publish
which
is
a
producer
and
then
underneath
we
will
have
an
inquiry
sent.
That
is
a
client
spam
and
it
links
to
the
server
and
for
and
publish
basically
the
producer,
because
it
kind
of
links
to
a
consumer
spam.
D
D
B
I
I
I
understand
both
both
solutions,
both
of
them,
I
think
they
make
sense.
B
D
I'm
I'm
open
to
whatever
makes
most
sense
to
people
here
so
yeah.
If
you
have
any
kind
of
comments
to
add
here,
just
to
add
it
to
the
old
tab,
and
I
will
make
the
the
changes
accordingly.
D
But
at
least
that
I
mean
it
was
a
good
discussion
with
last
time,
because,
basically,
it
helped
to
kind
of
at
least
put
something
consistent
here
for
span
naming
and
for
the
span
kind.
So,
basically,
we
have
kind
of
a
consistent
idea
of
how
we
we
want
to
handle
that
and
yeah
what
we
wanted
to
go
into
today,
a
bit.
What
are
the
dram
brought
up
last
time
is
then
talking
about
the
starting
talking
about
messaging
attributes
and
the
first
one
we
have
here
is
in
the
existing
attributes.
D
E
Yeah
and-
and
so
that's
my
concern
around
messaging.
system-
is
that
not
every
thing
that
would
generate
spans
would
know
its
system.
I
think
when
you
deal
with
standardized
protocols
like
amtp
armpt
or
a
standardized
api
like
jms,
you
won't
necessarily
know
what
sort
of
system
you're
operating
within.
E
You
know,
should
we
should
we
say,
like
I
said,
my
concern
is
defining
what
messaging.system
should
be
for
when
you
kind
of
don't
know
because
you're
using
a
standardized
api
or
a
standardized
protocol,
and
maybe
we
could
just
say
that
you
know
for
a
standardized
api
like
jms,
it
should
say
jms,
then
you
might
send
a
message
to
some
somewhere
and
it
might
the
other
side
of
that
trace.
Might
its
system
might
be
something
else?
But
that's,
I
don't
know
exactly
the
purpose,
but
I
assume
that's
probably
okay
right.
E
F
F
Because
it's
like
just
having
kafka
or
rabbit
mqs,
I
don't
think
I'm
not
sure
it's
helpful,
because
there
are
virgins
versions
matter,
and
there
are
it's
also
the
the
whether
the
api,
I'm
not
sure
the
api
matters
so
jms
is
not,
and
jms
is
just
an
abstraction.
F
It
speaks
about
the
client,
that's
an
entirely
different
story,
then,
because
then
you
would
have
here,
apache
proton
or
you
or
apache
cupid
proton
or
you
would
have
to
eclipse
paho
or
I
mean
whatever
the
the
the
protocol
client
is.
F
D
Or
for
for
at
least
for
the
operations
that
we
worked
out
now,
those
are
almost
those
are
basically
exclusively
currently
apis.
Yes,
I
mean
the
idea
is
kind
of
to
link
it
together,
like
with
the
broker
at
some
point
in
the
near
future.
Hopefully
this
should
be
added,
but
I
mean
what
we
worked
out
here
currently,
that
are
exclusively
cliently
client
apis.
D
F
I
find
I
find
system
misleading
because
it
or
ambiguous,
because
it's
not
clear
what
that
means,
and
I
think
you
you
have
a
you:
either
might
either
mean
the
client
or
you
mean
the
server.
D
Yes,
that
makes
sense.
So
basically,
if,
if
you
mean
the
client,
then,
for
example,
jms
might
be
a
a
system
too,
but
if
you
look
on
the
server
jms
doesn't
make
sense.
F
In
the
system,
I
think
it
would
never
be
well.
That's
the
question
of
whether
you
want
to
go
and
further
categorize
it.
So
gms
is
just
jms
is
just
an
abstract.
Spec
and
the
implementations
of
gms
are
the
various
providers,
all
of
which
are
different,
but
they
all
look
the
same
kind
of
towards
the
application
side.
F
But
there's
you
know
the
ibm
gms
provider
which
goes
and
speaks
the
repcue
protocol
and
then
there's
the
amkp,
an
apache
cubits
provider
which
speaks
the
mqp
protocol
and
then
there's
you
know
every
broker
kind
of
has
their
own
thing.
D
I
mean
one
one
thing
that
I'm
asking
myself
now
is:
when
we
talk
when
we
look
at
a
whole
trace-
and
we
see
we
see
like.
D
Then
put
it
out
before
we
have
basically
the
producer,
we
have
the
consumer
and
maybe
for
now.
Let's
just
talk
about
the
client
side,
because
I
think
for
when
we
talk
about
the
broker
itself,
I
think
the
it's
maybe
a
different
problem,
because
the
broker
will
always
know
about
kind
of
I
think
system.
In
that
context,
really
it
is,
but
on
the
client,
it's
more
kind
of
often
of
an
open
question
and
that's
also
important
data.
D
Yes,
and
I
think
when
we
then
look
at
the
at
the
complete
race
and
maybe,
let's
just
think
okay,
the
brokers
are
also
included
in
this
place.
In
this
trace.
We
have
like
a
complete
trace.
We
have
the
client,
we
have
the
producer,
the
consumer
and
they
need
a
meter
in
between
it
all
hangs
together.
D
I
think
we,
I
think
we
definitely
do
reckon
with
the
fact
that
there
might
be
different
messaging
dot
system
values
in
this
trace.
D
Just
just
wondering
I
I
guess
that
that's
that's!
We
cannot
assume
that
it's
all
the
same
throughout
this
this
this
one
trace.
I
agree.
E
With
that
yeah,
but-
and
the
biggest
question
is
especially-
and
I
think
it's
important
one-
since
we've
kind
of
promoted
messaging.system
up
into
be
a
piece
of
the
spam
name-
is
just
what
it
should
be
kind
of
for
the
standardized
clients
like
protocols
and
apis.
D
F
E
Yeah,
I
don't
I
don't
I
don't
know
for
for
me.
My
concern
is
like
we've
said
it
has
to
be
part
of
the
span
and
I'm
just
wondering
what
should
it
be
in
all
in
all
cases,
that's
kind
of
now,
and
maybe
we
should
revisit
whether
we
should
have
it
at
all
or
if
we're
talking
about
client
to
client.
Only
should
it
even
be
here.
F
F
Well,
if
you
publish
a
message
using
a
jms
client
of
a
particular
a
particular
jms
client
in
a
particular
version
that
maybe
have
differently
than
the
version
prior
to
it
or
later
so,
do
we
care
about
the
client
kind
implementation
here?
Is
that
what
we're
identifying
here
and
if
not,
does
the
generic
description
of
this
gms
help
us.
D
E
D
Not
sure
if
the
messaging
system
kind
of
whether
but
it
makes
sense
for
them
a
client
to
to
populate
both
messaging.system
and
messaging.client,
that's
what
I
mean.
B
Maybe
just
a
stupid
question,
but
since
we
talked
about
this,
so
there's
a
there's,
this
abstraction
in
there
this
there's
the
provider
that
talks
to
the
to
the
correct
protocol
does
this?
Is
it
possible
that
this
provider-
because
it
is
probably
what
will
be
generated
a
span
right?
Could
this
provider
also
tell
which,
which
messaging
system
it
is
talking
to
or
which
I
mean
he
knows
the
protocol
can?
Can
we
just
use
that
protocol
instead
from
the
the
actual
provider
that
is
dealing
with
things.
E
I
think,
generally,
if
it's
auto
instrumented,
you
could
possibly
I
mean
I'm
just
thinking
about
the
way
like
there
is
this
jms,
auto
instrumentation
library,
that
doesn't
it's
generic.
It
sort
of
injects
code
into
into
the
library,
and
I
don't
know
if
it
could
gener
it
could
know
or
not.
I
I
it
could
probably
extract
a
package
name,
as
I
think,
clemens
kind
of
suggested
earlier.
I
I
don't
know
enough
about
it.
It's
not
a
little
bit
enough
to
be
dangerous.
I
guess,
but
I
would
think
often
you
could.
B
Yeah
I
mean
if
it's
the
package,
if
the,
if
it's
the
library
name,
if
we
go
forward,
then
then
I
guess
might
be
as
well
as
we
do
today
with
the
scope
with
the
instrumentation
library
that
is
renamed
now
to
scope
that
the
the
instrumentation
author
has
to
provide.
I
guess
this
in
some
way
when
creating
the
the
trace
provider.
D
You
know,
as
I
think
that's
a
different
thing
here,
because
I
think
we
cannot
put
that
into
the
scope
because
yeah,
you
might
maybe
it's
fair,
but
it's
possible
definitely
possible
that
you
use
like,
if,
like
several
messaging
libraries
in
one
application
and
even
in
one
trace,
so
I
think
it
cannot
be
on
the
scope.
It's
kind
of
a
more
specific
to
the.
B
B
D
Yes,
I
mean
what
I
I
definitely
like:
clemens's.
D
Suggestion
to
use
like
the
guy
the
decline
version
here.
I
think
that
makes
definitely
sense,
and
that's
that's
also
much
like
a
much
clearer
defined
than
messaging
the
system.
I
think
the
client
and
the
version
it's
much
easier
to
specify
what
should
go
in
there
than
specifying
what
should
go
in
the
messaging
system.
I'm
not
I'm
just
not
yet
sure
if
the
messaging
system
is
just
like,
we
can
ditch
it
or
we
still
like
would
need
to
would
keep
it
and
define
something
that
could
go
in
into
messaging
system.
D
D
The
idea
is
that
you,
basically
you
see
that
just
a
span
name
without
any
attributes-
and
you
know,
okay,
this
is
kind
of
descends
to
kafka
or
descends
to
event
ups
and
this
band
kind
of
receives
from
I
don't
know,
rabbitmq
or
receives
from
sqs,
and
you
see
it
just
like
in
the
name-
and
you
know:
okay,
that's
what
this
this
man
is
about,
and
you
know
without
need
needing
to
look
at
attributes
and
kind
of
clients,
a
kind
attribute
for
kind
version
center,
just
like
in
in
one
location.
Okay.
D
F
Chemistry,
if
we
sorry,
if
we
want
to
make
this
super
generic
and
make
this
work
for
both
like
whoever
the
actor
is
so
we
client
is,
is
a
good
approximation,
because
you
know
it's
always
a
client
in
some
way,
but
this
could
also
be
like
if
the,
if
you
want
to
at
some
point
when
brokers,
become
aware
of
this
and
also
are
doing
things
out
of
their
own
out
of
their
own
activity.
F
For
instance,
if
you
have
a
push
broker,
that
kind
of
starts
sending
messages
to
subscribers
that
are
getting
messages
kind
of,
because
the
broker
initiates
connections,
then
it's
that
it
might
be
confusing
to
call
that
a
client,
even
though
the
broker
is
a
client,
so
it
might
be
something
like
an
endpoint
type
or
the
endpoint
anything
something
I'm
not
sure.
What
that
should
be
would
be
the
more
generic
thing.
F
So
you
have
a
you
have
clients,
you
have
servers,
those
roles
are
fluid,
but
what
they
have
all
in
common
is
that
they
are
the
endpoints
or
an
endpoint
implementation
on
either
side.
So
that's
the
that's.
That's
the
more
generic
term,
maybe
is
endpoints,
and
then
you
know
endpoint
implementation,
endpoint
type,
something
that's
maybe
something.
That's
not
so
terribly
long.
F
F
E
Yeah,
I
was
going
to
suggest
the
exact
same
thing
I
think
have
because
I
was
thinking
whatever
we
call
it.
I
think
for
a
broker.
We'd
probably
just
want
to
fill
in
the
same
field
with
the
name
of
the
broker,
and
so
I
think,
yeah
whatever
it
is
participant
actor
endpoint
or
who
knows.
Maybe
even
system
is
good
enough.
If
we
just
define
what
we
mean
by
it,
but
it
is,
it
is
a
very
generic
name.
E
I
think
it
does
lend
you
to
think
about
the
broker,
I'm
communicating
with
more
than
yeah
the
end,
the
participant
in
the
messaging,
the
actor.
So
I
I
agree
with
that,
and
it's
and
now
the
tricky
part
is
coming
up
with
the
right
name.
I
think.
F
Yeah
systems
I
find
system
a
bit
system,
certainly
with
the
example
that
that's
been
given
in
that
table.
That's
a
bit
broad
and
not
very
useful.
I
think
it
needs
to
be.
It
needs
to
be
very
concrete
in
terms
of
what
what's
contained
in
that
field,
but
yeah.
We
need
to
have
some
term
that
is
that
covers
both
the
client
space
and
the
server
space
system
seems
to
be
a
bit
broader
of
a
term.
Could.
F
Weird,
if
you're
not
in
it
like,
if
you,
if
you're
a
gms
person,
yes,
if
you're
anything,
but
then
the
provider
is
like.
What's
that.
D
D
We
we
already
like
a
minute
over
time
here,
just
trying
to
summarize,
and
maybe
we'll
try
to
put
it
down
as
a
discussion
basis
for
next
time.
I
think
we
have
like
just
trying
to
summarize
it
if
we
would
have
messaging.cayenne
that
messaging.com
version
we
have
kind
of
our
client
side
covered.
We
know,
okay,
what
kind
of
what
client
is
used
here?
D
That's
strictly
referring
to
the
client
side
and
if
we
would
have
something
like
messaging.endpoint,
that
would
refer
to
basically
the
broker
or
the
intermediary
that
we
sent
data
to,
and
that
would
basically
kind
of
tell
us
where,
where
kind
of
does
the
client
kind
of
send
its
data
to,
and
maybe
we'll
just
try
to
put
this
down
and
then
we
as
a
discussion
basis
for
next
time,
and
then
we
can
start
from
there
and
see
whether
it
makes
sense
or
where
we
want
to
go
from
there.