►
From YouTube: 2022-05-26 meeting
Description
Instrumentation: Messaging
B
Hi
all
good
morning,
everybody
or
good
evening,
let's
give
it
two
more
minutes,
then
let's
get
started.
B
C
A
So
yeah,
I
posted
the
link
to
the
gender
in
the
chat.
Please
add
your
name
here
agenda
for
today.
This
first
point
somebody
put
it
on
for
last
week.
A
I
think
so
some
people
pinged
me
about
this
open
lineage
and
I
told
them
to
to
participate
in
this
meeting
and
bring
that
up.
I'm
not
too
familiar
with
it
and
I
think
the
people
who
put
it
on
there-
nobody-
they
are
not
here
today.
A
So
I
think
we
just
then
moved
this
on
to
next
week,
because
I
I
don't
know
enough
about
the
documentation
kind
of
yeah
to
have
a
discussion
here.
So
I
think
we
need
somebody
to
to
explain
to
us
about
that.
What
exactly
the
goals
are
here.
I
think,
as
far
as
I
understand
from
some
like
first
discussions
ahead,
that
this
open
lineage
also
needs
some
kind
of
context.
A
Propagation
and
the
question
they
are
asking
is
whether
they
can
use
the
same
mechanisms
as
we,
basically
as
we
use
in
open
in
open
telemetry
but
yeah.
I
I
don't
know
much
for
the
details
about
requirements
here.
So
if,
if
there's
nobody
here
who
can
lead
this
discussion,
we
will
just
yeah
skip
that
and
then
the
remain
like
two
things
here.
A
There
is
our
ongoing
discussions
about
the
attribute
names
and
there
is
the
question
from
the
from
the
ruby
side
and
I
would
type-
and
I
will
just
say,
let's
start
off
with
that
and
then
and
then
use
the
remainder
of
the
of
the
time
for
the
for
to
continue
our
discourse.
Discussion
about
the
general
attribute
names.
A
So,
sam,
if
you
want
to
kick
us
off
here,.
D
Okay,
I
apologize
internet's,
not
good
if,
if
I
stop
being
audible,
just
put
it
in
the
chat-
and
I
can
just
come
back
next
week.
D
If
it's
not
doable,
amir
already
knows,
what's
up.
D
We
had
a
pr
from
someone
that
was
basically
trying
that
we
already
are
pushing
context
down
into
on
the
producer
side
of
like
a
message
being
in
queue
dude
in
sqs,
so
there
is
the
contexts
available
and
on
the
receiving
end,
basically,
the
pr
makes
the
the
worker
process,
that
is,
that
picks
the
the
message
off
of
the
queue.
D
That
will
automatically
create
a
span
of
the
producer
process,
and
that
seems
totally
reasonable.
Your
consumer
will
be
not
linked,
but
will
be
a
direct
descendant.
So
if
you're
looking
at
the
spans.
C
D
D
Oh
geez,
okay,
let
me
see
if
I
can
move
closer
to
the
router,
but
I
may
just
need
to
come
back.
C
C
C
But
when
we
deal
with
the
batch
scenarios
when
we
do
batch
receive,
then
this
current
specification
states
that
it
should
be
a
new
trace
with
links
right
and
some
good
reasons
for
that
and
now
in
the
ubi
sdk.
There
are
a
lot
of
instrumentations
that
give
you
the
option
to
choose.
So
you
can
choose
if
you
want
your
consumer
spans
to
be
a
child
of
the
producer
or
to
start
a
brand
new
space
from
scratch.
C
Yeah
so
like
I
can
like.
We
talked
a
lot
about
the
pros
and
cons
of
each
option
like
and
we
I
think
we
decided
that
it's
very
complex
and
there's
a
lot
of
reasons
to
do
it
one
way
or
the
other,
but
for
orbit
or
what
there
is
a
pr
about
the
sqs.
C
Well,
it's
doing
it
like.
According
to
the
current
spec,
there's
a
batch
receive
and
it's
receiving
a
batch
of
messages
and
creating
a
new
trace
for
this.
The
whole
batch
right-
and
there
was
a
discussion
about
maybe
adding
an
option
to
choose
if
you
want
to
do,
parent-child
relationship
or
a
new
trace
for
those
consumer
spends
right
yeah
so
like.
C
I
think
I
think
the
question
here
is
because
current
specification
is
is
clear
about
the
way
to
do
it,
and-
and
I
think
there
are
a
lot
of
good
reasons-
why
to
do
it
this
way,
but
the
guys
that
will
be
seeing
they
suggested
that
they
will
support
both
options,
and
I
think
this
is
what
the
discussion
is
about.
C
A
So
basically,
the
I
think
the
key
is
here
that
basically,
the
in
for
uber,
like
the
user,
can
configure
how
they
want
to
have
their
spans
kind
of
correlated
either.
Do
we
want
to
have
a
child
span,
or
do
I
want
to
have
a
link
to
the
to
the
producer
and
what
the
ask
is
here
to
basically
be
we
kind
of
codify
this
possibility.
Also
in
the
spec
that
the
spec
basically
say
it
says:
okay,
you
can
have
a
child.
A
C
C
C
So
the
trace
starts
with
this
receive
operation
right
and
then
we
get
back
like
10
messages
and
then
each
message:
if
it's
not
linked
to
this,
receive
but
linked
to
the
consumer,
then
this
receives.
Suddenly
it's
like
a
floating
operation.
You
see
this
receive,
but
there's
no
correlation
to
what
went
on
with
it
afterwards
right,
it's
just
like,
like
a
ghost
trace
that
has
no
context
to
what
really
happened
in
the
application.
A
Yes,
I
mean
the
in
the
I
think
the
current
spec
actually,
the
current.
The
current
version
of
the
spec
gives
you
that
that
possibility,
so
the
current
version,
that's
in
the
follow
for
the
messaging
semantic
conventions,
give
you
that
option
that
you
say:
okay,
you
just
process
a
single
message.
This
can
be
a
child
spam
of
the
producer.
I
think
I
think
that
is
the
first
example.
C
A
I
think
for
for
batch
receive
it
often
isn't
even
possible.
I
mean
you
cannot
have.
You
cannot
have
multiple
parents
on
on
on
on
on
a
single
span,
so
in
those
in
in
some
cases
it's
not
even
possible
to
kind
of
use
the
parent
child.
A
A
So
here
we
have
an
example
with
receive,
and
I
mean
what
the
current
spec
says
or
in
this
example
here
that
you
receive
is
kind
of
parented
to
the
producer
span
and
then
the
processing
spans
are
like
children
of
this
receive
span.
I
mean
there
is
that's
the
that's.
The
kind
of
I
think.
F
D
That,
if
you
can
hear
me,
that's
this
page,
I
was
just
like
what
do
you
actually,
what
is
correct,
like
I.
D
A
I
can
show
you
what
we
are
working
on.
We
are
working
on
kind
of
cleaning
it
up
and
in
terms
of
this
cleanup
like
the
conclusion
we
came
to
is
that
we
said
okay,
we
we
always
link
producers
and
consumers.
I
mean
there's
some
examples
here,
and
I
mean
what
is
common
to
order
examples.
We
never
have
a
parent
client
relationship.
We
always
have
links
from
the
producer
to
the
consumer
and
yeah.
There
are,
as
ambry
said,
there
are
pros
and
cons
links,
parent
fight
relationship.
A
I
mean
the
pros
for
links
is
that
when
we
prescribe
to
use
links,
this
can
be
consistent
over
our
scenarios,
no
matter
whether
you
are
using
batches
or
single
messages,
and
I
think
an
other
benefit
of
using
links
here
in
the
messaging
scenarios,
even
if
you're
just
processing.
One
message
is
that
I
mean
in
the
in
the
usual
like
happy
day
case
you,
you
send
a
message
and
immediately
after
that,
the
message
or
you,
you
kind
of
publish
a
message
and
if
immediately
afterwards,
like
the
consumer
kind
of
takes
the
message
and
processes
it.
A
But
right
there
are
cases
when
there
is
a
significant
kind
of
time
span
between
the
between
the
between
the
publishing
and
the
between
the
producing
and
the
consuming.
I
mean
that
can
be,
minutes
can
be
hours
can
be
days,
and
if
you
then
model
this
with
a
parent-child
relationship
that
might
cause
confusions
or
problems
like,
then
you
have
a
trace.
A
So
that's
that
were
that
there's
some
some
of
the
reasons
why
we
said.
Okay,
we
wanna
kind
of
clean
this
up
the
kind
of
a
bit
of
confusion
and
chaos.
That's
here.
We
know
that
for
some
limited
cases,
parent-child
relationships
seem
to
make
more
sense.
But
in
terms
of
kind
of
the
consistency
and
keeping
it
like
consistent
of
all
scenarios
and
keeping
like
clear
and
and
being
able
to
give
clear
and
consistent
guidelines,
we
just
say:
okay,
we
use
links
throughout
and
we
don't
kind
of
in
the
spec.
A
We
try
to
kind
of
remove
this
preventative
relationship
between
producer
and
consumers.
A
D
A
D
Yeah
I
what
you're
saying
about
standardizing
on
the
link
makes
a
ton
of
sense
to
me.
We
just
we
have
users
that
expect
different
behavior,
so
we'll
have
to
just
figure
out
what
we
or
what
our
position
is.
I
guess
as
a
sig,
but
I
don't
want
to
talk
too
long,
because
I
know
my
audio
is
intolerable,
but
this
is
super
helpful.
Would
you
mind
just
dropping
a
link
to
the
otep
in
the
chat?
C
F
D
Configurable,
perhaps
on
a
per
workload
basis
would
be
the
only
solution
there
like
if,
if
it
were
possible
to
say
okay,
this
batch
workflow
should
be
you
know,
parent
child
or
just
this
batch
workflow
should
do
links,
whereas
this
you
know
one-to-one
workflow
should
do
parent-child,
I'm
not
exactly
sure
how
that
configuration
would
work,
but
yeah
certainly
parent-child
for
batch
work.
If
you
have
a
million
jobs
like
it,
doesn't
you
don't
want
them
in
one
trace,
so
I'm
totally
with
you.
D
I
think
it's
just
if
we
could
offer
it
as
a
configuration
option
on
a
then
the
user
could
pick,
and
maybe
you
know
you
could
imagine
yeah
anyway,
that
that's.
C
D
Yeah,
yes,
I'm
I'm
used
to
thinking
about
code
and
not
the
specification,
but
now
that
you
say
that
I
I
see
what
you're
saying
and
yes
for,
I
think
for
batch
processing.
You
know,
however,
that
gets
defined.
It
would
be
a
link
and
if
it's
a
single
consumer,
then
having
the
option
for
parent
child
would
be
nice.
C
Yeah,
so
I
think,
regarding
the
original
pr
about
adding
desk
us
capabilities
to
ruby,
I
think
there's
no
option
to
do
it
right.
If
I
understand
you
correctly
to
do
it
with
parent
child.
D
We
would
need
to
know
we
would
need
to
know
if
it
was
batch
or
one
to
one
and
that
just
depends
on
how
people
are
using
sqs.
I
think
right
because.
D
I
will
look
into
that
for
sure.
Yeah.
A
Okay,
cool,
I
thought
it
was
that's.
I
mean
very
helpful
for
us
to
sign,
because
it's
because
it
seems
I
mean
it's
good
for
us
to
refresh
the
discussion
we
had
and-
and
I
think
it
shows
us
that
I
mean
it
kind
of
confirms
me
a
bit,
because
it
definitely
shows
that
the
linking
is
kind
of
the
more
unproblematic
way
to
correlate
producers
and
consumers.
Because
I
mean,
if
you
do
the
parent
triangulation
fbi,
it
can
it.
A
A
Like
the
just
one
thought
of
about
your
configuration
options,
I
mean
it
seems,
the
configuration
options
are
interpreted
in
a
way
that
you
say:
okay,
everything
you
can
configure
is
like
spec
conformant,
but
I
mean
maybe
just
for
like
as
a
if,
if
we
kind
of
succeed
to
push
this
through
what
we
have
here
and
then
the
spec
allows
only
links
I
mean,
maybe
for
some
ruby
users
you
can
then
still
say:
okay,
you
can
configure
parent
child
relationships,
but
that's
just
not
spec
conformant
you
can,
you
can
kind
of.
A
D
Totally
that
that
makes
sense,
I
think
so,
I'm
only
one
person
on
the
sick,
so
I
can't
I
can't
speak
for
everyone,
but
that
makes
sense
to
me
that
it's
just
offspec
behavior
assuming
the
hotep
gets
in
so
and
I
we
we're.
I
think
it's
totally
fine
to
do
that,
especially
in
instrumentation.
D
F
D
You
want
to
go
off,
spec
come
with
us
kind
of
thing,
so
that
is
super
helpful.
But
I've
got
the
link
to
the
otep
and
I
can
circulate
that
with
the
ruby
folks
and
if
people
feel
really
strongly,
then
we
can
comment
on
it,
but
it'll
be
really
nice
to
just
have
this
settled
in
the
spec
one
way
or
the
other,
and
then
we
can
be
very
clear
with,
as
you
say,
the
configuration
option
we
can
just
say
hey.
This
is
offspec,
this
is
inspect
and
then
it's
just
very
cut
and
dried.
A
D
A
That
does
not
make
sense
and
yeah
I'm
sorry.
I
know
we
are
currently
in
the
weird
in
between
state.
We
have
like
this
in
the
spec
and
we
we
all
know
it
doesn't
really
make
sense.
It's
not
really
consistent
and
yeah.
I'm
I'm
actually
not
sure
about
the
timeline
when
we
will
be
able
to
to
get
this
in,
but
yeah
we're
working
on
it.
D
No
well,
thank
you.
Thank
you
for
doing
this
work.
It's
really
it's
good
to
know
that
you're
thinking
about
it
and
thanks
for
for
letting
me
come
and
chat,
and
I
really
do
apologize
for
my
audio,
I'm
not
at
home.
C
Dropping
by
yeah
just
want
to
add
another
issue
that
we
talked
about
that
currently
people
prefer
not
to
use
links
because
there's
not
not
a
good
support
for
it
like
in
current
backends,
but
and
we
discussed
it,
discussed
it
and
like
we
decided
that
links
are
part
of
open
telemetry
and
we
don't
want
to
suggest
not
using
them
just
because
the
backends
don't
support
them,
because
eventually
the
vacants
will
support
them
right.
C
So
the
the
argument
about
not
using
linux,
because
they're
not
supported
by
back
ends,
it's
something
that
it's
we
don't
feel
comfortable,
taking
a
specification
decisions
based
on
this
argument
because
they're
not
going
to
disappear
right
there
here
to
stay
and
they're
going
to
be
used
in
many
use
cases.
So,
if
someone
doesn't
like
links,
we
should
figure
out
how
to
resolve
this
issue
and
not
stop
using
links
that.
C
So
I
think
that
I
think
jager
now
has
a
good
support
for
links.
So
if
you
send
it
to
ace
that
has
links,
you
can
jump
very
easily
from
like
from
a
trace
to
the
trace
that
it
is
linking
to,
but
that's
for
new
versions
of
jaeger.
But
some
people
are
using.
D
C
C
A
So
it
was
just
dropped
more
less
and
I
think
that's
what
amir
says
that
that's
why
some
customers
might
prefer
the
permanent
trial
relationship,
not
for
kind
of
modeling
reasons,
but
just
for
based
on
backhand
limitations.
D
Cool
well
that
makes
that
that
makes
sense
to
do
a
mirror
and
we'll
have
to
so.
We
have
our
own
back
end
and
ui
at
shopify,
so
we'll
just
have
to.
I
mean
we're
not
right
we're
talking
about
adding
functionality
to
to
instrumentation
that
doesn't
exist
yet
in
this
instance,
but
we'll
just
have
to
make
sure
that
we
end
up
supporting
links
full
feature,
delete.
A
Okay,
so
thanks
for
stopping
by
so
as
I
said,
though,
please
comment
on
the
on
the
old
tap.
If
there's
anything
you
don't
like
about
it,
and
then
we
can
continue
the
discussion
there,
maybe
involving
other
people.
D
Awesome
well
thanks!
So
much
and
I'll
see
you
on
github,
I
guess.
F
A
Okay,
so
I
think
we
are
a
smaller
group
today
I
was
actually
schwa.
I
think
he's
off.
I
was
talking
to
ludmila
recently
and
she
said
she's
gonna
join,
but
she's
not
here
either,
but
I
think
we
can
still
go
over
some
some
things
regarding
the
general
attributes
and
one
thing
that
I
started.
A
Here
we
have
those
in
the
attributes
and
I
think
we
didn't
even
get
to
discuss
them
yet
in
detail.
A
There
are
the
protocol
and
protocol
version
attributes
and
I
actually
discussed
that
with
shortly
with
ludmilla
offline
and
she
suggested-
and
I
think
that's
a
very
good
suggestion-
actually
moving
those
product
protocols
out
of
the
messagings
back
and
making
this
a
more
generic
concept,
because
I
mean,
for
example,
we
have
already
like
net
the
prp
network,
peer
name
and
she
suggested
moving
this
protocol
attributes
out
of
the
method,
messaging
spec
and
having
some
net.protocol
dot,
name
and
net.protocol.version,
and
then
basically
from
there
we
can.
We
did
those
attributes
canton
specified
there.
A
They
can
be
specified
there.
Basically,
they
will
be
specified
as
some
kind
of
application
layer
protocol
that
can
be
used
for
and
then
we
can
use
this
here
messaging,
but
that
can
also
be
used
in
other
instances,
for
example
for
databases.
You
also
might
have
your.
I
don't
know.
Let's
say
you
have
your
azure
cosmos
database,
but
you
use
as
a
underlying
protocol.
You
use
mongodb
to
access
that,
so
you
can
kind
of
then
use
the
same
attributes
to
to
model
that
in
in
other
parts.
A
So
I
started
an
issue
for
this
proposing
that,
and
there
is
some
like
yeah
some
discussion
so
far,
but
mostly
positive
feedback.
So
probably
I
will
push
for
the
drought,
I'm
not
sure
if
you
have
any
like
other
thoughts
here
or
if,
like
from
your
point
of
view,
it
would
make
sense
to
have
this
like
messaging
to
keep
this
protocol
in
protocol
version
messaging
specific.
We
could
still
do
that.
Even
when
those
net
dot
protocol
exists
exist,
we
can
say
you're
okay,
but
for
messaging
we
want
to
have
our
own.
A
I
don't
see
any
strong
reasons,
but
yeah
I'm
open
for
any.
G
I
I
I
was
just
thinking
that
it
makes
a
lot
of
sense
to
me
to
have
protocol
and
version
in
messaging
because,
like
it's,
referring
specifically
to
the
messaging
protocol
and
there's
a
whole
protocol
stack
involved
in
getting
a
message
from
one
place
to
another,
and
I
do
think
it
makes
sense
to
shore
up
the
net
dot
domain
with
more
protocol
information.
But
I
would
think
that
makes
more
sense
to
things
like
tcp
and
tls
web
sockets.
A
I
mean
in
the
that
there
is
already
when
we
go
to
the
net
stuff.
There
is
already
an
attribute
for
the
transport
protocol
that
is
used,
so
that
is
already
there
so
just
net
the
transport-
and
you
can
say:
okay,
that's
tcp,
udp
or
whatever,
and
this
other
network
protocol.
A
That
kind
of
that
would
be
added
that
would
be
specified
as
an
application
layer
protocol
and
all
our
all
messaging
protocols
that
I
know
about
like
be
it
mqtt,
amqp
and
also
http.
They
classify
as
an
application
layer
protocol
and
that's
why
the
deal
was
okay.
We
can
have
here
an
attribute
that
is
for
application.
A
But
I
I
think
that
the
the
process
will
anyway
be
a
two-step
process
there
in
terms
of
this
issue,
because
this
this,
why
I
propose
this
and
by
luke
miller,
proposed
this
to
me.
That's
not
only
for
messaging,
that's
also
to
clean
up
hdb
to
a
certain
extent,
because
then
http,
you
can
protect
http
version
in
this
in
this
in
this
attribute
here
and
what
we're
going
to
do
here.
A
We
in
the
first
step
we're
going
to
add
this
network
protocol
attributes
to
the
specification,
or
I
will
put
up
a
pr
for
that
and
then
in
the
second
step
we
will
evaluate
whether
we
can
re
whether
we
can
and
should
replace
existing
attributes
with
this
ones.
So
we
will
first
we
will,
I
think,
we'll
try
to
get
that
into
the
spec
anyway,
and
maybe
once
it's
in
there,
we
can
evaluate
whether
we
want
to
keep
specific
messaging
attributes
for
this
protocol
or
whether
we
want
to
kind
of.
G
Yeah,
I
think,
fractionality,
you
explain
it
more,
I
think
I'm
I
I
like
it
better
it
being
in
the
net
dot
protocol.
It
might
make,
I
think,
in
some
places
in
the
original
spec,
it
calls
out
to
certain
net
dot
values
being
relevant
yeah
like
here,
and
perhaps
it's
worthwhile,
just
kind
of
mentioning
those.
As
you
know,
here's
where
you
would
put
your
messaging
protocol,
you
know
if
that
makes
it
into
the
specs
yeah.
I
I
think
that
doesn't
make
sense.
Now
you
mentioned
it
now.
You
talk
about
it
more.
A
I
I
think
it
also
makes
basically
it
makes
things
more
consistent
across
different
semantic
conventions
because
yeah
it
would,
it
would
be
it's
a
bit
cumbersome
now
that
or
the
different
areas
of
their
own
protocol
like
you
have
basically
messaging
the
protocol.
Maybe
you
have
something
like
database,
the
protocol,
or
even
http,
like
this
information,
is
like
baked
into
like
http.flavor,
and
there
you
set
the
http
1.0
http
2.0,
and
that
will
be.
A
I
think
it
will
be
beneficial
to
have
like
a
consistent
way
across
the
semantic
conventions
to
specify
this
so
that
that's
that's
some
ongoing
work
to
kind
of
and
and
as
a
side
note.
I
also
think
it
it
makes
this
protocol
attributes
more
more
better
specified
having
it
there,
because
here
we
actually
say
the
name
of
the
transport
protocol
in
the
existing
spec,
but
technically
speaking,
mqb
and
mqtt
doesn't
fit
in
for
messaging.
A
G
Yeah
that
specific
description
of
messaging.protocol
caused
some
internal
confusion
with
with
us
when
we
were
trying
to
implement
against
this,
and
so
if
we
were
to
keep
it,
I
would.
I
was
definitely
suggesting
improving
the
text,
but
I
think
yeah.
It
makes
sense
to
move
it
up
to
the
net
specification.
A
I
think
yes,
I
think
we
will
end
up
with
something.
That's
definitely
then
better
specified
than
what
we
currently
have
here,
because
that
is
pretty,
I
think
for
somebody
who
does
not
come
from
the
messaging
side
like
what,
when
and
when
they
see
transport
protocol.
Do
you
think
about
something
different,
so
yeah.
C
I,
like
it
yeah
yeah,
I
like
it
too.
I
I
just
want
to.
I
have
no
concrete
example,
but
sometimes
there
can
be
like
an
http
and
messaging
on
the
same
spin
like
the
same
set
of
photo.
Build
can
can
be
at
the
same
time
on
the
same
span,
and
then
the
net
protocol
can
cause
issues
like.
We
can't
really
tell
what
it's
referring
to.
A
Yes,
I
know
what
you
mean
that
actually
came
up
in
some
discussions
in
the
pr
like,
for
some
christian
here
mentioned
examples
that
you
can
have.
Actually
you
can
have
two
application
layer
protocols
on
top
of
each
other,
like
you
can
have
this
opnp
I
mean
he
gave
some,
maybe
it's
a
bit
obscure,
but
it
definitely
happens
and
you
can
have
xmpp
by
http
or
upnb
by
http
and
both
kind
of
all
those
xmd
xmpp
and
also
you
can
be
qualified
as
application
layer
protocols
and
basically
use
another
application
layer
protocol
underneath.
A
So
in
this
case
this
it
can
be
ambiguous,
but
I
think
it's
as
I
see
the
solution.
It's
not
like.
I
I
I
wouldn't
design
like
the
overall
solution
to
kind
of
to
make
the
overall
solution
more
complicated
to
cover
these
special
cases,
because
we
even
have
for
the
neto
transport.
I
mean
you
pack,
basically
here
in
this
exam
you
pack
two
protocols
in
ip
and
tcp,
and
I
mean
you
could
do
a
similar.
You
could
do
a
similar
thing
here.
A
You
could
just
when
it
comes
to
the
dotted
quartet
name,
you
just
specify
at
a
xmpp
underscore
http
or
or
you
have,
or
you
have
a
separate
spans,
but
but
but
I
think
it
would
be
over
engineering
to
kind
of
come
up
with
a
solution.
I
mean
crystal
mentioned
something
here
that
you
can
actually
have.
A
Protocol
network
protocol
be
an
array
of
a
string
array
and
then
in
this
array
you
can
put
multiple
protocols
in
there,
but
I
think
that
is
over
engineering
to
solution
and
kind
of
adapting
us
to
maybe
the
one
or
zero
to
five
percent
of
cases
where
this
would
be
necessary.
G
I
I
do
think
that's
a
generic
problem
with
protocols
in
general
is
that
you
know
they're
very
it's
a
very
layered
concept.
I
do
feel
that
combining
them
with
underscores
is
not
a
great
solution
because
it
makes
it
hard
like.
If
I
were
to
look
at
the
transport
domain,
I
feel
transport
has
the
same
problem.
I
don't
see
any
way
with
what
they
specified
to
indicate
whether
or
not
tls
was
used.
I
think
that's
a
pretty
important.
G
You
know
and
I
could
be
wrong.
I
know
I
don't
know
it
inside
out,
but
but
I
don't
recall
seeing
anything
when
I
read
this
and
you
know
you
could
say
well,
I
could
go
tls
underscore
tcp
underscore
ip
or
something
like
that,
but
it
makes
it
hard
to
find
if
I'm
interested
in
say,
searching
traffic
in
a
back
end.
That
was
secure
right
and
use.
G
Tls,
like
it'd,
be
nice
to
build
a
search
for
an
attribute
that
had
tls
right
and
versus
tls
over
what
well
you
don't
really
care,
and-
and
so
it's
it's,
it
feels
like
the
the
nice
thing
to
do
to
make
things
searchable
on
the
back
end,
where
you
might
be
interested
in
one
aspect
of
a
protocol
in
a
given
scenario,
is
to
have
them
as
somehow
separate,
and
I
don't
know
I
don't
know
enough
about
back
ends,
but
I
I
think
it
gets
hard.
G
It's
tricky
if
you
combine
it
all
into
one
string
to
separate
things
out
and
it
seems
like
I
don't
know
how
much
better
the
string
array
proposal
is.
But
I
I
like
the
idea
of
the
string
array.
It
sounds
like
a
nice
way
of
you
know
expressing
a
stack
which
is
you
know,
that's
what
protocols
are
it's
a
stack
of
things,
but
yes,.
A
I
mean
I
mean
the
the
I
think
the
proposal
with
arrays
here,
that's
more,
it
is
technically
possible,
like
open
telemetry
allows
you
to
have
basically
attributes
that
have
arrays
as
values,
but
I
don't
know
if
any
backend
that
supports
that
yet
so
so
and
and
there's
also
many
other
problems
that
he
specifies
here-
that
you
would
also
need
to
be
able
to
append
to
an
array
of
an
attribute,
because
maybe
you
don't
know
the
two
protocols
right
away.
So
I
think
the
race
is
more
like
an
academic
to
use
array.
A
I
think
it's
not
realistic
at
at
this
point,
and
actually
the
more
realistic
mechanism
is
just
to
to
have
like
to
model
it
via
spans,
so
that
this
attribute
can
use
so
that
it
makes
sense.
I
mean,
for
example,
in
these
scenarios
here
where
we
have.
Let
me
see
where
the
examples
where
like
here,
for
example,
you
might
have
then
an
xmpp
span,
but
on
this
band
like
the
protocol
might
say
http.
A
So
you
have
the
information,
then
there,
okay,
you
have
to
you
know,
then:
okay,
I'm
using
xmpp
and
the
underlying
protocol
that
the
protocol
is
set
to
http.
So
I'm
knowing
okay,
I'm
kind
of
I'm.
I
have
the
information
there
and
the
same
thing
happens
can
be
done
or
support
here
up
in
p,
because
it's
http
2.
and
I
think
the
I
mean
all
all
the
examples
that
the
christian
could
find
were
basically
other
protocols
you
would
using
http
underneath
and
the
actual
thing
for
http.
A
A
So
I
think
that
that
net
dot
protocol
is
actually
usable
for
for
protocols
where
there
are
no,
for
which
no
semantic
conventions
exist.
Yet
because
when
we
talk
about
mqb
and
qtd,
there
is
no.
There
is
no
instrumentation
for
those
protocols.
A
There
are
no
semantic
conventions,
so
you
just
you,
you
will
not
get
spans
for
those,
so
you
just
like
put
it
put
it
into
this
attribute,
but
I
think
for
all
for
all
like
protocols
like
http,
where
there
are
semantic
conventions
and
where
there's
lots
of
instrumentation
out
there
in
most
cases,
I
think
people
will
end
up
with
the
nested
spans
anyway
and
having
all
the
information
there.
A
So
so
I
think
there
is
I
I
can
currently
not
think
of
any
case
and
I
think
you're
very
rare,
where
actually
you
would
want
to
put
multiple
protocols
into
this
net.protocol
attribute.
A
But
but
let's
see
I
will,
when
I
put
up
the
pr
for
the
spec,
maybe
I'm
pretty
sure
this
will
come
up
and
maybe
other
people
will
have
different
kind
of
scenarios
there.
That
actually
would
would
make
sense.
A
But,
but
I
think
the
main,
the
main
aim
is
just
of
this
network
protocol
attribute-
is
just
saying
that
okay,
I'm
using
this
protocol
underneath
there
is
no
there's
no
way
to
create
a
span
for
that.
So
I
just
put
it
into
into
this
network
protocol,
which
is
our
exact
basically
case
for
mqb
and
mqtt,
that
that's
our
use
case
and
maybe
one
day
there
will
be
mqb
spans
and
then
this
protocol
will
kind
of
for
mqb.
At
least
this
attribute
will
be
obsolete
more
or
less
because
then
you
see
the
mqp
spans.
A
A
A
We
made
here
between
destination
and
source,
and
she
came
up
with
some
very
good
remarks
regarding
that,
because
she
said
I
mean
we,
we
already
saw
here
that
in
terms
of
destination
like
rabbit
and
q,
the
destination
actually
is
it's
two
things.
It's
the
exchange
and
it's
a
routing
key,
and
what
luke
miller
said
is
that
for
most
basically
for
almost
all
messaging
systems,
you
have
like
this
destination
to
really
uniquely
define
this
destination.
You
need
like
two
parts
of
information.
I
mean
yeah,
the
the
queue
name
and
the
topic
name.
A
That
is,
of
course,
one
part,
but,
for
example,
for
kafka.
You
would
also
need
to
know
the
kafka
instance
that
you
are
connecting
to
because
the
other,
maybe
you
have
multiple
kafka
instances
running
I
mean
sqs-
is
actually
this.
This
url
here
is
actually
a
good
example,
because
here
you
have
this,
this
queue
here
that
would
go
under
destination
here,
but
you
also
have
this
identifier,
I'm
not
sure
what
it
is
in
sqs
terminology,
but
it's
basically
the
I
guess
it's
the
name
of
your
kind
of
maybe
set
up.
A
A
I
mean,
of
course,
when
you
have
the
context,
you
know
where
this
queue
is,
but
but
actually
without
this
information
that
might
be
ambiguous,
and
that
also
that's
also
by
luke
miller,
said
sorry,
and
it's
also
valued
miller
said
probably
why
this
url
is
here,
because
in
those
cases
this
url
gives
you
this
information,
and
she
you
ludmilla,
was
actually
saying
that
she
will
look
into
like
two
different
systems
and
think
about
whether
it
makes
sense
to
split
up
destination
in
general
and
have
basically
kind
of
this
part
as
an
attribute.
A
But
this
part
too
here
and
because
I
think
I
I
think
we
talked
last
time
about
just
omitting
url,
because
it
seems
very
kind
of
opaque
and
it
can
be
lots
of
things,
but
actually
think
that
is
one
reason
why
it's
there,
because
you
need
it
to
you
uniquely
identify
where,
where
you're,
connecting
to
sorry
dwayne.
G
G
I
mean
like
just
I'll
talk
about
solace,
which
has
you
know
the
name,
the
name
or
address,
of
a
broker
that
you're
connecting
to,
and
within
that
broker
we
actually
have
concept
of
vpns,
which
is
like
a
bunch
of
kind
of
it's
just
a
name
within
that
thing
you
connected
to,
which
is
like
a
separate
instance
broker
within
a
broker
almost
right,
and
so
those
two
things
you
need
to
uniquely
define
it.
G
I
think
that
that
is
exactly
what
the
url
sort
of
concept
is
meant
to
address,
and
I
think
that
it's
a
good
concept,
because
it
kind
of
defines
in
a
way
a
broker
instance.
I
think
url
might
not
be
the
best
term
and
description,
but
I
think
that
that
makes
sense-
and
I
think
that
applies
equally
to
the
destination-
for
like
it's
sort
of
a
map.
It
ties
into
the
destination
for
a
producer
and
for
a
consumer.
G
It
ties
into
the
source
side
of
things
rabbit's
a
little
different
because
and
to
the
extent
I
understand
it,
I
think
maybe
you
understand
rabbit
better
than
I
do,
but
my
ex
my
understanding
of
the
exchange
is
that
it's
it's
not
kind
of
tightly
coupled
to
a
broker.
Instance
right,
like
I
think
you
can
have
multiple
exchanges
and
and
they're
not
like
separate
instances
of
anything.
G
I
think
cues
can
draw
from
different
exchanges
so
that
it
there
there's
no
separation
between,
like
certain
cues,
can
only
these
exchanges
and
these
queues
are
all
in
this
bubble,
and
this
exchange
in
these
could
almost
bubble.
I
think
there's
kind
of
a
an
any
to
any
mapping
that
you
can
have
between
exchanges
and
queues.
G
Yeah
so
I
mean,
I
think,
the
something
like
the
url
concept,
but
I
don't
like
kind
of
like
url
as
it
feels
wrong
to
me,
but
but
some
description
of,
I
guess
the
broker
instance,
but
but
but
that's
where
it
doesn't
fit
well
with
mq,
because
this
exchange
is
like
a
different
concept
that
I'm
familiar
with
with
other
brokers.
A
Yes,
but
trust
your,
I
think,
one
take
away
ahead
from
the
discussion
with
luke
miller.
Definitely
is
that
yeah
we
cannot
just
plainly
say,
like
we
actually
tried
to
do
that,
which
was
plenty
skip,
skip
messaging.url.
A
G
What's
what's
interesting
to
think
about,
and
I
I
know
we
we
aren't
getting
into
you
know
intermediary
tracing,
but
this
kind
of
information
that
would
be
in
the
url
when
you
get
into
intermediary
tracing,
I
think
of
it
as
being
that
stuff
kind
of
ends
up
getting
into
the
service
service
name
and
service
instance
id,
but
but
for
a
client
right.
The
the
service
instance
id
and
stuff
is
not
at
all
kind
of
where
you're
sending
it
to
so.
G
If
we
move
some
of
the
url
stuff
into
source
and
destination,
I
think
it
may
not
make
sense
to
be
part
of
the
source
and
destination
in
the
context
of
an
intermediary,
because
that's
more
like
the
intermediaries,
you
know
service
name
and
service
instance,
but
but
we,
but
so
just
something
to
think
about.
If
we
do
migrate,
some
of
that
to
source
and
destination
maybe
think
about
not
having
it
be
required
just
so
that
it's
a
little.
C
What
do
you
think
about
having
an
array
for
the
destination
name
with
all
the
different
parts,
and
that's
why
it's
really
generic
and
each
implementation
can
store.
A
G
Space
in
between
them
or
something
and
then
have
a
separate
messaging.rabbit.,
you
know
exchange
and
routing
key.
That
sort
of
that
removes
the
ambiguity
that
happens
when
you
concatenate
these
strings
together
into
one
attribute.
C
Two
messages
and
if
we
start
using
different
attributes,
then
it
will
make
the
life
very
hard
for
the
back
end.
G
C
G
C
D
C
G
C
D
G
So
shying
away
from
string
arrays
because
they're
not
well
supported
back
ends,
is
kind
of
not
consistent
with
our
decision
to
not
shy
away
from
links
because
they're
not
supported.
On
the
other
hand,
we
sort
of
have
to
ask
ourselves,
I
think
part
of
the
the
link's
decision
was.
These
things
are
just
very
powerful
and.
G
That
we
think
that
back
ends
are
going
to
kind
of
be
forced
to
support
them,
and
I
wonder,
does
the
same
argument
apply
to
strings
like?
Are
they
very
powerful,
very
likely
to
be
widely
used
and
therefore
back
ends
are
going
to
be
forced
to
adopt
them,
or
are
they
always
going
to
end
up
being
a
niche
thing
that
the
spec
allows,
but
but
not
enough
use
cases
have
required
their
use
that,
but
they
just
don't
end
up
being
well
supported
over
time.
C
E
C
A
I
think
I
think
we
need
to
wrap
up
for
today.
I
need
to
go
so
I
think
we
continue
can
continue
the
discussion
next
time,
a
little
thing
with
miller.
I
hope
she
comes
because
she
had
some
like
other
remarks
about
like
the
attributes
became
became.
They
came
up
with,
so
it
would
be
great
because
with
her
and
another
thing
just
that
I
forgot
to
mention
before,
like
this
big
old
tap
that
we
have
here,
I
will
actually
start
to
sprint
this
up,
because
it's
getting
fairly
long
and
people
will
have
kind
of.
A
I
think
problems
reviewing
that,
so
it
will
actually
start
out
to
break
out
the
context
propagation
in
an
old
tap
that
will
be
a
short
one
and
the
first
one
and
then
the
trace
structure
I
will
break
into
in
the
separator
tab,
because
those
are
all
areas
where
we
basically
finished
our
discussions
already.
So
with
context
propagation.
A
We
finish
with
straight
structure.
We
mostly
finished
only
open
question
being
like
the
the
link
stuff,
so
we'll
have
those
two
out
tabs
and
then
there
will
be
a
third
old
tab,
basically
for
the
for
the
span,
names,
kinds
and
attributes
and
the
thing
that
will
actually
make
it
easier
for
people
to
review,
because
when
we
put
like
the
whole
big
thing
out
there,
I
actually
think
many
people
who
are
not
that
deep
into
messaging
will
will
be
scared
by
that.