►
From YouTube: 2022-08-18 meeting
Description
Instrumentation: Messaging
A
A
B
B
B
B
Yes,
we
don't
have
so
I.
Think.
Last
time
we
were
discussing
the
attributes
and
I
see
that
two
demeanor
kindly
prepared
yeah
the
ammo
and
table
generation.
So
I
guess
we'll
go
through
that.
I
just
wanted
to
make
sure
to
point
that
I
started
working
on
this
PR
to
move
the
pull
tab
to
the
specs.
So
hopefully,
I
can
I
can
open
the
spec
PR
next
week.
B
I,
don't
think
it's
going
to
be
a
lot
of
changes
so
I'm
just
taking
the
text
and
doing
some
light
modification
on
it,
but
I
think
it
should
be
fine.
Then
I'll
see
we'll
see
how
it
goes,
how
it
goes
over
there.
B
B
Okay,
no,
no,
of
course,
no
problem
all
right.
So
what
would
be
the
easiest
way?
Do
you
want
to
go
through
the
markdown
format
or
the
ammo
file.
A
Yeah,
so
maybe
I
I
will
share
some
big
findings
that
I
discovered
and
we
can
think
if
we,
what,
how
we
or
to
proceed
with
them.
So,
like
one
thing
I
found,
there
is
no
tooling
support
for
links
whatsoever,
so
I
expressed
links
as
events
for
now,
because
this
is
the
only
thing
I
could
do.
A
It's
not
a
big
deal
to
edit,
but
I
think
before
we
can
really
send
the
proper
PR
to
this
pack.
Eventually,
we
will
have
to
figure
it
out.
It's
not
a.
A
It's
simple,
yeah.
The
second
thing
I
think
we
we
kind
of
missed
a
few
important
things
So.
Currently
we
give
a
lot
of
flexibility
right.
We
say
you
can
do,
publish
and
create
this
once
pen,
you
can
do
it
as
a
different
spans
right
and
we
don't
strictly
clarify
the
batching
versus
non-batching
case.
A
So,
for
example,
when
I
send
a
single
message
and
if
even
if
I
have
two
sperms
for
a
message
and
for
publish
right,
how
do
I
express
attributes
should
I
put
them
on
link?
Should
they
have
a
link?
Should
they
put
them
on
the
published
span
right
and
I
think
we
should
try
to
put
attributes
on
fans
rather
than
links
where
it's
possible.
B
A
B
B
C
I
have
a
question
about
it,
so,
like
I
think
we
all
agree
that
the
spam
can
identify
like
a
single
message
and
that's
very
easy
right,
because
we
we
have
a
place
to
store
attributes
about
the
message
like
the
message
idea
and
the
the
destination
and
other
things
right.
So
this
single
span
can
be
either
like
the
publish
span
or
or
the
create
span,
and
everything
makes
sense,
and
it's
easy
right.
I
think.
C
Problem
is
when
we're
talking
about
a
batch
right
and
and
then
we
need
some
way
to
enumerate
all
the
messages
right.
C
But
if
we
have
a
batch
and
it's
too
expensive
to
create
a
spend
per
message,
then
we
can
live
with
the
not
having
the
Bell
message
context
in
the
trace,
so
I
think
we
talked
about
it
back
then,
and
it
made
sense
to
us
and
I
want
to
watch
what
the
god
and,
if
you
think,
something
should
be
changed.
C
B
Yeah,
so
you
mean
so
you
mean
using
the
publish
span
or
the
sense
pen,
whatever
I
think
it's
published,
that
we
settled
use
this
one
as
the
one
that
goes
inside
the
message
or
and
I'll
create
one
for
for
each
or
or
yes,.
C
Yes,
so
I
think
they'll
do
a
two
vectors
like
one
is
what
we
put
on
the
propagation
context
right,
and
the
second
is
the
way
to
express
multiple
messages
in
a
batch
like
for
for
the
users
right
like.
If
we
publish
a
batch,
we
want
to
know
the
messages
that
which
messages
are
involved
regardless
of
the
propagation
context
and
right
so
so.
A
A
I
thought
about
that,
even
if
there
is
no
creation
or
imagine
the
case,
I'm
very
server
side
when
you
receive.
A
C
A
Okay,
perfect
yeah,
so
imagine
the
key
on
the
receiver
end.
We
don't
have
any
span
at
all
for
the
crate
right.
We
don't
have
a
beer,
but
we
still
need
to
express
attributes.
A
So
how
do
we
do
this?
We
do
it
via
links.
So
the
link
to
to
the
context
we
received
had
information
about
the
message
right
message.
Maybe
anything
we
can
do
the
same
on
the
on
the
publish
if
we
get
a
message
from
user
with
content
and
we
create
a
link
to
this
context
and
it
has
all
the
attributes
about
the
message
which
works
for
batching,
but
it
may
be
too
complicated
for
a
single
published
case.
A
B
A
Don't
create
a
create
span
anyway,
because
there
is
already
a
context
on
the
message.
Yes,
then
we
can
still
Express
all
the
attributes
about
the
message
if
we
put
them
on
link
right,
we
have
a
link
from
publish
to
create
to
the
context
on
the
message,
and
it
has
all
the
message.
Specific
attributes.
A
C
A
C
B
Yeah
and
I
I
think
we
can
clearly
have
different
different
traces
depending
if
you,
if
you
have
a
badge
or
not
so
I,
think
we
can
keep
it
simple
right
if
there,
if
it's
just
a
single
message
and
put
all
the
attributes
on
the
same
spin,
I
think
that
should
I
mean
I
I
as
a
user
I
would
be
concerned
or
or
worried
that
this
would
be
I
think
it
would
be
easier
for
me
to
see
that
there's
just
one
span
and
I
don't
have
to
click
on
links
or
anything,
because
it's
just
one
right.
C
B
A
A
correlate
yes,
but
you
still
probably
want
to
know
that
which
messages
were
published
right.
You
still
want
to
know
message,
ID
and
destination
right.
C
So
I
think
what
we
talked
about
in
the
past
is
that
in
this
case,
if
the
user,
if
it's
too
expensive,
to
create
a
spender
message,
then
then
we
will
just
note
the
record
each
message
in
the
batch
we
just
recorded.
It
was
a
batch
that
we
sent
the
messages
a,
but
we
cannot
break
down
to
a
specific
message.
Maybe
we
can
store
like
numbers,
messages,
mm-hmm
or
something
like
this,
but.
C
A
Yeah,
so
maybe
I
have
a
suggestion.
Let
me
know
what
you
think
about
it,
so
maybe
we
can
specify
a
few
scenarios
and
I
think
we
have
a
list
of
examples
on
the
bottom,
but
scenarios
like
okay,
the
simple
case
single,
send
single,
receive
no
settlement
right,
this
the
most
simplest
case,
and
then
we
can
list
these
scenarios
and
draw
some
line
somewhere.
We'll
say:
okay,
this
is
what
we
absolutely
must
have
for
Vivani,
and
then
we
will
try
to
focus
on
those
as
it
seems.
A
B
But
the
thing
is
that
we
need
to
I
could
fly
with
derail
and
it's
because
we
can.
We
can
Define
the
easy
ones
but
debating
how
we
Define
it.
We
might
run
into
troubles
when
we
get
to
the
more
complicated
ones
or
there
are
two
different
apart
or
I,
don't
know
but
I
think
having
yeah
having
a
fit
on
the
ground,
for
example,
and
staying
sticking
with
with
the
let's
say:
that's,
that's,
let's
take
the
easy
ones.
B
A
Yeah,
and
also
even
if
it
will
become
too
complicated,
it
feels
we
have
two
very
different
problems.
I
have
this
messaging
anyway.
This
asynchronous
processing
right
forget
the
batching
and
then
the
other
problem
is
batching
and
there
is
a
third
problem
with
settlement
which
can
be
per
message
or
it's
just
a
point
in
time,
right,
yeah
and
then
there
is
also
problems
of
okay.
A
We
don't
we'll
give
the
flexibility
to
users
to
not
create
the
context
per
message
and
what
then,
in
theory,
we
can
distinguish
those
things
with
different
prefixes,
where
we
can
give
some
heuristic
to
the
back
end.
To
do
this
back
so
essentially,
I
think
it's
like
two
and
a
half,
or
maybe
three
specs-
that
we're
trying
to
tackle
at
once.
Yeah.
C
I,
just
I
wanted
to
to
to
ask
if
it
makes
sense
to
you
that,
like
a
Spam
can
only
present
a
single
message
like
can
only
contain
attributes
or
single
message
and
if
a
span
is,
you
can
only
link
to
other
spans,
which
presents
a
single
message,
but
but
it
cannot
contain
like
it
cannot
describe
multiple
messages
in
the
attributes.
Do
you
think
it
makes
sense.
A
What
I
think
I
tried
to
say
that
maybe
it's
good
enough
for
most
of
the
cases,
but
there
are
cases
when
you
probably
want
to
have
a
race
of
per
message
attributes.
We
don't
have
to
tackle
it
right
away
unless
there
is
some
popular
system
that
would
have
would
make
us.
Do
it
right.
C
C
Will
it
not
cover,
we
don't
have
to
talk
about
it
now?
If
we
want
to
talk
about
something
else,
you.
B
May
not
have
I
mean
I
think
we
are
agree
that,
having
like
always
having
a
span
represent
a
single
method
where
we
can
put
all
the
attributes
there.
It's
like
the
most
perfect,
perfect
easy
solution
right
because
we
can
create
it.
The
only
let's
say
downside
is
that
if
we
allow
the
users
to
create
the
great
great
span,
let's
call
it
like
that.
Then
they
have
to
know
all
the
conventions
that
they
have
to
populate
all
things.
B
That's
what
loot
media
said
before
that
when
we
get
to
to
publish
if
there
is
already
a
context
in
the
message
meaning
I
spend,
for
example,
we
cannot
like
add
more
stuff
to
it
right.
So
then
the
way
we
represent,
for
example,
the
message
ID
it's
by
Links,
but
like
always
having
this
band
I,
think
it's
the
most
easy
solution
right.
So,
but
we
have
this
problem
that
if
we
require
to
always
have
a
span
for
example,
then
we
will
require
that
users
when
they
create
a
mess.
B
They
have
to
create
a
scan
and
put
all
the
things
there
or
we
did
the
user
creating
thing,
and
we
say
now
the
if
there
is
already
a
span
inside
the
message
we
I
don't
know,
drop
it
or
something
or
we
create
another
one
based
on
it
and
populate
more
attributes
and
then
use
that
instead,
I
don't
know
something
like
that,
like
like
they're
doing
go,
for
example,
because
in
go.
You
have
this
context
that
flows
through
things
and
you
can
create
another
one
that
and
add
more
things
on
it.
B
So
then,
for
example,
I
can
create
a
context
passing
that
one
and
more
things
so
then
I
have
a
new
context
with
the
old
plus
the
new,
and
we
use
that.
But
I
don't
know.
If
that's
the
thing
that
exists
in
all,
it's
definitely
not
as
expecting
I
think,
maybe
maybe
it
is
I,
don't
know.
C
So
for
me,
it
makes
sense
that,
like
a
better
message,
attributes
can
either
go
on
a
on
a
spend.
It
represents
a
single
message
or
on
a
link
that
points
to
a
span
that
represents
a
single
message,
depending
on
the
on
the
context
and
the
like
is
feasible
to
do.
But
I
think
it's
a
very
like
a
simple
way
to
describe
it
that
at
least
missing
something
it
covers
the
by
all
the
the
complications.
B
Know
I
also
I
also
think
I
think
I
think
I
agree
with
that.
This
is
this
is
the
most
optimal
and
easy
solution,
and
if
we
don't
have
like
the
attributes-
and
we
want
to
add,
for
example,
message
ID,
then,
for
example,
when
we
reach
published,
there's
already
a
span
because
they
usually
created
it,
and
then
we
just
put
that,
as
is
in
the
message
and
use
the
attributes
in
the
link,
so
create
a
link,
create
a
link
and
then
put
the
message
specific
attributes
on
the
link.
B
But
my
concern
that
I
have
with
this
is
on
the,
for
example,
on
the
consumer
side,
we
don't
have
these
attributes
on
the
link
right.
We
only
have
this,
for
example,
message
ID
on
the
producer,
because
on
the
consumer,
we
don't
have
it
anymore
right.
B
C
Yeah,
so
so
I
think
it
also
follows
the
the
rule
right,
so
the
consumer
side
also
stores
the
link
to
a
spend.
It
represents
a
single
message.
You
can
also
store
attributes
on
this
link,
which
are
relevant
today
like
to
the
consumer
perspective.
So
if
you
know
it's
something
on
the
consumer
side
that
he
wants
to
store
their
message,
it
has
a
container
where
you
can
store
this
information
right.
So
it
makes
sense
to
me
yeah.
B
No
I
think
it
makes
sense.
I
think
I
think
this.
Having
always
having
this,
then
I
think
it's
the
most
thing.
That
I
think
is
the
thing
that
we
all
agree,
at
least
on
a
level
I
think
yeah
it
gets.
Blurry
is
when
the
span
is
like
seen
when
you
talk
about
singles,
zero
duration,
spans
or
or
case
where
users
don't
have
to
have
don't
want
to
have
many
spans.
Then
you
get
tricky,
but
if
we
remove
all
that
like,
if
you
remove
these
two
things,
then
it's
it's
no
brainer
right.
A
Yeah
so
like
we
can
so
the
only
thing
I'm
worried
about
that.
If
we
have
this
either
or
so
you
either
have
this
attributes
on
span
or
or
link,
it
creates
some
additional
work
right.
It's
it's
an
inconsistency.
Somebody
has
to
write
this
Branch
branches
right
and
and
just
trying
to
challenge.
If
we
need
this,
because
if
we
all
like,
we
can
guarantee
attributes
on
links,
you
can
see,
there
can
always
be
added,
because
this
is
the
span
we
create
at
the
I
mean
the
instrumentation
creates.
A
B
Links
for
the
matter
are
like
real,
fully
fledged
links,
I
guess
as
well
right,
yeah.
C
We
all
agree
that
if
it's
in
the
open,
Telemetry
specification,
then
it's
on
the
toolbox
and
we
should
be
able
to
use
it
if
it
makes
sense
to
us.
We
had
this
discussion
in
the
past
like
this
is
my
perspective
and
I
think
that
the
back-ends
that
don't
support
the
open,
Telemetry
API,
like
we
can't
this.
A
Yeah,
so
let's,
unless
we
discover
some
reason
too
try
to
say
that
per
message
attributes
are
on
links
and
then
we
have
just
fewer
variations.
C
So
I
think
like
it
will
depend
on
the
instrumentation.
Maybe
when
you
create
the
message
you
know
things
about
it
which
you
want
to
store
on
the
spam
attributes
and
then,
when
you
like,
publish
it
as
a
batch,
you
know
more
things
that
you
want
to
store
the
links
and
like
I,
don't
have
a
specific
example
to
give.
But
I
think
the
flexibility
will
need
to
be
given
to
the
instrumentations,
because
there
are
so
many
variations.
B
Yeah
I
think
we
can
I
think
the
real
Quest
that
we
need
to
answer
is
what
blood
Miller,
as
at
least
what
I
see.
Is
that
because
we
have
a
question
now
is
like:
do
we
always
use
the
attributes
that
are
message
specific?
Do
we
always
put
them
on
a
link,
or
do
we
put
it
on
a
link
only
when
it's
a
batch
so
I
think
that
that's
the
question
that
we
probably
need
to
to
answer
like?
Do
we
always
use
this
so
we're
consistent?
B
We
don't
have
to
have
two
branches
like
two
Demeter
set,
or
we
really
want
to
strive
for
Simplicity
and
like
when
it's
known.
When
it's
not
a
bachelor
scenario,
then
we
don't
use
links.
We
put
all
all
the
attributes
on
this
pen
the
same
one
and
leave
like
that
or
like
this
case,
and
then
when
it's
a
bet,
we
use
the
things
on
on
the
attributes
on
the
link
and
then
for
for
for
for
amir's
things
like
we
can
write
in
a
way
to
say
like.
B
C
I
think
we
should
always
favor
to
put
attributes
and
spends
while
possible,
and
we
should
recommend
the
instrumentation
to
do
it,
but
we
also
like,
in
the
specification
like
make
it
possible
to
store
things
on
the
links
which
are
not
possible
to
store
somewhere
else
right,
a
lot
known
in
advance
like
yeah
the
reality
is
so
complex
that
I
think
we
should
not
like
say
that
it's
not
allowed.
A
I
want
to
challenge
it.
I
want
the
challenge
that
we
need
this
flexibility
right
so,
like
you
mentioned
I'm
implementing
them
back
end,
so
the
the
possibilities
that
they
have,
that
there
is
a
attributes
and
message
then,
and
their
attributes
and
links
and
when
I
do
something
I
want
to
I
need
to
merge
them.
They
could
be
duplicated.
C
C
Because
the
message
spend
is
created
like
it's
before
the
the
link
is
added.
So
maybe
then
the
the
user
creates
the
message
and
he
knows
things
when
he
creates
the
message
and
then
he
turns
it
over
to
to
be
published,
and
then
we
know
more
things.
So
if
we
we
say
that
everything
must
be
stolen,
a
link,
then
it
makes
the
implementation
very
complicated
right
because
we
have
to
propagate
data
from
the
creation
part
to
the
publish
part.
Just
so
we
can
install
it
on
the
other
link,
attributes.
A
So
wait
a
second,
so
we
we
will
say
that
everything
that
this
spec
describes
should
be
on
links
right.
It
does
not
prevent
users
from
adding
more
information
on
on
stance
or
instrumentations
and
adding
more
information
and
spans.
What
we
are
saying
that
this
specific
attribute
like
message
ID,
is
expected
on
link
not
on
spam,
and
then
it
creates
some
simple
strategy
for
the
back
end
I'm.
Looking
for
this
attribute
there
and
not
somewhere
else,.
C
B
But
I
think
the
the
link
approach
is
the
ultimate
one
that
we
I
mean
I.
I
cannot
see
a
case
where
the
instrumentation
cannot
do
anything
that
he
wants
with
the
link
right
because
it
it's
about
to
send
is
about
to
publish
the
message.
It
has
the
message
at
that
point.
You
should
have
already
all
the
attributes
that
you
need,
like
the
message
Edition
be
already
generated,
and
so
on.
So
the
link
is
I.
B
I
mean
maybe,
if
we,
if
we
start
identifying,
which
attributes
that
we
100
know
that
this
message
is
specific
or
per
message
individual,
then
we
can
think
about
put
our
instrumentation
I'll
just
head
and
think
if,
if
we
see
that
they
are
available
at
that
point
and
if
not
then
I
think
it
should
be
possible
to
maybe
do
some
exercise
like
this
I.
Do
some
I,
don't
know
some
past
experience
or
some
yeah
common
sense,
I
guess.
B
C
You
know,
for
example,
I
can
think
if
we're
doing
like
a
batch
publish.
So
maybe
some
messages
succeeded
and
some
messages
failed
and
we
want
per.
A
C
C
Like
what
I
was
thinking
is
to
describing
an
Otep
that
spam
can
only
represent
a
single
message
and
if,
if
a
spanner
wants
to
Western
multiple
messages,
then
it
has
to
be
done
via
links
and
that
film
Message
attributes
can
either
be
stored
on
them.
On
the
singles
message
span
or
on
the
link
that
points
to
a
single
investment
spell
I.
B
B
No
I
think
I
think
this
is
what
iohan
has
wanted
to
do
with
the
other
app
that
he
mentioned,
but
if
somebody
wanted
to
tackle
it,
the
the
36
Tracy
structure,
I
think
this
would
be
there
probably
yeah.
That
is
what
you
said.
Probably
it
would
would
make
sense
to
to
be
in
this
in
this
step
as
well.
Let
me
explain
this
and
we
have
this
this
drawings
and
so
on.
Yeah.
C
Yeah
so
so
I
I
suggest
even
to
to
break
it
more
like
to
have
just
a
single
autop
just
to
to
to
agree
on
this
statement
and
and
see.
If
we
can
melt
it
and
then
it
will
give
us
like
a
solid
ground
to
talk
about
tomorrow.
Complicated
complex
issues
in
the
future,
like
in
the
in
the
future
meetings,
yeah.
B
I
think
I
think
that
would
make
sense.
Yes,
the
only
problem
with
the
old
Taps
is
I,
don't
know,
I
think
they
require
that
there
is
some
samples
right
or
maybe
for
us
not,
but
that
that
that
you
have
a
sample.
For
example,
if
you
want
to
open
an
app
to
change
something
in
in
this
pack
or
something,
then
you
need
to
have
some
sort
of
of
sample
in
in
different
languages
to
demonstrate
that
this
works.
B
This
makes
sense
it's
possible
to
implement,
for
example,
I
think
it's
even
says
in
the
somewhere,
because
I
was
moving.
The
Otep
now
and
I
was
I,
saw
this,
but
I'll
I'll
find
a
link
after,
but
but
this
one
actually
was
merged.
Now
we
didn't
have
anything
and
it
was
merged.
So.
C
Yeah
I
can
draft
something
like
that
makes
sense
to
me
and
we
can
and
then
we
can
maybe.
B
If
you
can
do
it,
I
will
be
great
I
think
to
discuss
in
the
last
in
a
more
constrained
document.
I
think
that
would
be
great.
That's.
A
B
B
A
Nice
and
regarding
examples
basically
have
the
implementation
of
not
not
perlink
approach,
but
not
that
should
do
its
per
link
but
links
in
our
sdks
and
has
been
up
and
running
so
at
least
for
once
sorry
that
has
the
keys.
We
have
implementation
in
four
languages,
all
right,
so
I
think
this.
This
is
that's.
B
Good
then
I,
don't
remember
where
I
saw
but
I
pretty
sure
that
I
saw
like
before
coming
to
the
meeting
that
I
saw
somewhere,
that
all
tabs
need
to
be
submitted
and
then
there's
supposed
to
be
some
demonstrating
sample.
But
I
can't
remember
where
I
saw
right
now,
but.
C
I
can
give
a
few
samples
from
cases
that
I
familiar
with
the
few.
A
C
Other
examples
but
I
think
it's
so
narrow
that
it
shouldn't
be
like
too
controversial.
Yeah.
C
B
C
B
Cool
all
right,
so
what
I
took
some
notes,
while
you
were
talking
just
wanted
to
make
sure
that
I
so
just
put
on
the
document,
so
we
have
some
memories
of
what
we
talked.
So
let
me
talked
about
the
links.
Not
me,
can
I
I,
don't
think
I
can
so
I'll
put
it
on
the
docker,
so
it
can
be
together.
B
B
Yeah,
so
let
me
pointed
out
that
the
links
are
not
supported
in
their
generator,
so
yeah
I'll
I'll
take
a
look
at
this.
Maybe
I
will
open
an
issue
and
the
in
that
repo.
So
when
you
said
it
it
doesn't,
support
links
is,
is
in
the
where,
where,
where
do
you?
What
did
you
want
to
represent
the
link
exactly
in
the
yaml
file.
A
I
can
now
share
my
screen
if
you
want
to
and
go
through
things,
two.
A
B
Yeah,
so
this
then
we
can,
we
can
talk
more,
but
so
then
we
have
the
case
for
a
single
message
and
where
to
add
the
attributes
right.
So
let's
be
discussed
as
well.
Briefly,
I'll
put
here
that
way,
let
me
see.
B
This
as
well
I
think
it's
a
good
idea
and
yeah,
so
we
discussed
also
this
always
use
the
queer
message
attribute
some
links
or
only
use
it
when
it's
a
badge
right.
So
this
is
a
point
we
need
to
discuss
as
well,
and
then
this,
which
attributes
are
message
specific
yeah,
so
I
think
this.
This
is
one
exercise
that
we
need
to
do
probably.
A
Maybe
we
can
do
it
in
in
the
same
way
where
I
can
try
to
find
what's
important
about
our
systems
and
maybe
take
a
couple
of
other
things.
Maybe
I
don't
know
I'll
see
and
if
you
folks
can
bring
up
what's
important
for
systems
you
are
familiar
with,
then
we
can
try
to
find
some
common
grounds
and
some
common
terminology.
B
B
Okay,
that
sounds
good
guys
all
right
a
whole
lot
to
write
this
down.
So
how
to
express
abuse
of
that?
Is
it
contact
Trace
structure,
no,
not
really
I.
B
B
Right,
okay,
so
these
are
the
notes
that
I
took
while
we
were
talking
now
just
trying
to
get
into
the
exercise
of
documenting
things,
yeah,
so
I
think
what
we
can
tack
on
X
is
is
this
I
was
discussing
what
Mira
was
saying
about,
that
she
will
take
a
look
and-
and
maybe
we
also
all
can
take
a
look
to
which
attributes
we
identify
either
in
the
current
specification
or
something
that
it's
not
there.
B
But
we
know
about
it
because
we
know
about
some
system
like
attributes
that
are
exclusive
per
message.
So
we
can
come
up
with
a
list
of
attributes
that
we
know
that
there
are
always
belonging
to
the
message.
B
So
this
will
help
us,
for
example,
like
think
or
identify
if
it's
always
possible,
for
example,
for
instrumentations
to
populate
these
attributes
on
the
links.
B
Yes-
and
we
also
discussed
this
the
single
method
case
so
where
we
added
to
this
yeah
and
if
we
shouldn't
focus
on
this
and
not
the
radio
too
much
into
more
complicated
scenarios,
so
that
we
can
also
think
about
maybe
in
prioritize
our
work
on
on
this
thing.
First,
the
user
of
the
easy
case.
B
First,
yes,
I
wrote
it
down
here
that
we
will
try
to
work
on
on
on
I,
put
a
tab
under
quotes
because
not
not
a
full-fledged
PR
or
that
just
some
ideas
in
the
shape
that
we
can
transform
it
later.
B
Right
did
I
miss
anything
else
that
we
discussed.
B
Yeah
we
have
these
questions
you
that
we
discussed
as
well
like
because
we
have
this
or
case
now
that
we
add
always
on
the
links,
the
attributes
always
on
the
links
or
in
some
cases
we
got
for
a
single
message.
We
had
understand
the
other,
so.
A
Maybe
we
can
capture
the
that.
What
we
think
here
makes
sense
that
if
it's
a
single
message
they
should
be
on
published
and
otherwise
they
should
be
on
links
on
published.
Then.
B
Yeah
did
we
agree
on
this
I
think
I
think
this
makes
sense,
but
I
also
think
what
you
said
that
it's
hard
having
this
branching
and
having
to
look
for
Edibles
in
different
places
also
makes
sense.
So
I'm
I'm
kind
of
divided.
A
And
I
mean
if
it's
not
a
batch,
send
then
you
probably
it
is
good.
Maybe
we
can
even
have
different
operation
names
for
a
batching
and
not
batching
yeah.
B
C
Want
to
also
add
that
it's
very
easy
to
think
about
the
situation
where
they're
both
like
the
dispense
exist
like
both
the
linking
spell
and
the
linked
span
is
and
then
all
the
data
is
available,
but
sometimes
one
of
them
could
be
dropped
due
to
sampling
or
just
be
missing.
For
some
reason,
there
are
a
lot
of
reasons
and
then
I
think
the
the
attributes.
C
Yeah,
so
so
I
don't
think
everything
should
be
like
a
duplicated
or
stored
only
in
one
place.
Maybe
the
message
ID,
because
it's
so
important
if
it's
known
in
both
cases,
it
can
be
duplicated,
but
I
really
think
the
we
should
give
flexibility
to
the
instrumentation
Auto
to
to
do
what
makes
sense
in
the
specific
use
case,
but.
A
So
we
can
use
should
right
if
we
say
shoot,
it
means
that
if
instrumentation
author
has
strong
reason
not
to
do
it
or
do
it
in
a
different
way,
then
they
are
absolutely
free
too
right.
But
it's
not
that
we
prescribe
how
to
do
it
or
we
don't
intend
to
cover
all
possible
things
that
can
go
wrong.
B
This
this
you're
talking
about
which
attributes
to
add
when,
like
in
the
in
the
receiving
and
the
publish.
C
Yeah
on
all
the
settlement,
or
maybe
like
there
was
this
guy
from
sqs
that
wants
to
instrument
the
internal
messaging
system
operations.
So
we
might
all
also
create
links
like
yeah.
I
can
see
a
lot
of
cases
where
people
might
want
to
create
links
to
a
message
when
they
describe
something
and
they
need
to
reference
a
specific
message
and,
oh
sure,
yeah
I,
think.
B
Okay,
but
is
this
so,
do
we
have
a
quarrel
that
for
this
or
do
we
want
to
think
more
that
for
a
single
single
message
sent
send
makes
sense
that
the
attributes
are
on
the
stand
directly
understand?
We
don't
have
links
for
this
case,
or
we
don't
feel
that
at
this
point
we
can
like
settle
on
this
yeah.
A
Maybe
we
can
use
it
as
just
the
work
in
soft
agreement
that
until
we
have
some
strong
reason
not
to
do
it,
we
agree
to
do
it.
Yes,.
B
All
right
for
batching,
we
don't
have
any
way
out
anyway,
so
we
have
to
use
Links
at
some
in
some
shape
or
form
so.
B
A
B
All
right,
so
this
and
and
I'm
able
I'll
try
to
work
on
this,
which
are
also
good
because
then,
next
time
we
can
brainstorm
on
all
of
this
and
maybe
produce
some
document
or
something.
C
My
question
is:
should
we
do
some
semantic
specification
on
how
to
Mark
a
span
that
represents
a
single
message
like
if
I'm,
a
backend
that
is
processing,
spends
and
want
to
identify
spam
that
to
be
sure
that
it
represents
a
message
like
what
is
the
logic
to
that
I
need
to
apply
like
if
I
see
a
specific
semantic
attribute.
It
means
that
this
pen
is
describes
a
single
message,
where
maybe
there's
some
other
rules
that
we
can
climb
it.
Maybe
it's
not
needed.
C
A
Agree,
oh,
we
need
some
heuristic
and
we
can
think
about
something
like
it's
either
an
operation
name
right
or
it's
an
attribute
or
in
theory
it
could
be
a
number
of
links,
but
I
feel
it.
It
would
be
a
difficult
one.
So
if
you
have
more
than
one
link,
then
you
sorry,
if
you
have
more
than
zero
links,
then
maybe
it's
a
batching,
but
then
it
closes
the
door
on
adding
other
links
that
are
not
to
messaging
attributes,
maybe
to
something
else
right.
B
C
B
B
Okay,
yeah
yeah,
another
operation,
I
think
I.
Think
I
see
what
you
mean.
Yeah
the
to
put
on
the
name.
I
would
not
do
that,
but
yeah
attribute.
C
It's
a
problem
to
use
the
operation
I
think
because
expanded
to
represents
a
single
message
can
either
be
like
a
create
or
a
send.
A
I
think
we
still
need
the
number
of
messages
anyway,
because
even
if
you
have
links,
Link's
number
is
limited
right
and
they
can
be
dropped.
So
it's
nice
to
have
a
number
of
messages
on
the
as
an
attribute
on
a
span
on
the
published
pen
or
receiver
set
or
anything
yeah.
A
A
And
also
I
I
can
assume
somebody
wants
to
create
the
metric,
which
is
like
size
bed
size
right
out
of
this
traces.
C
C
I
I
supported
it
sounds
good.
B
B
Okay,
just
trying
to
wrap
and
see
if
we
have
a
plan
how
to
do
that,
what
to
do
next,
so
the
attributes,
the
Otep
I-
think
the
the
idea
for
the
attribute
for
the
batch
I
think
that
makes
sense.
Maybe
we
should
also
put
that
in
the
list
the
attribute
or
or
kind
or
operation,
so
we
probably
should
probably
should
make
this
apparent
or
or
pay
more
attention
to
this
I
guess
next
time.
C
B
Just
just
message
me
on
slack:
if
you
want
share
the
document
with
me,
I
can
I
can
leave
comments
and
just
feel
free
to
reach
out.
It's
like
I
can
help
you
yeah.
A
Now,
try
to
evolve
the
yaml
file
I
actually
want
to
maybe
even
split
it
in
two
and
have
a
per
like
single
case
and
the
batch
case,
or
at
least
have
different
sections
for
it.
Okay,.
B
Yeah
for
the
link
that
you
said
it's
not
supported.
If
you
want
to
discuss
more,
we
can
discuss
on
slack
as
well,
because
we
I
think
this
tool
was
made
from
from
our
our
people
here
at
that
address.
So
they
have
a
lot
of
knowledge
on
it.
So
if
we
need
something,
I
can
quickly
ask
like
just
just
ask
General
opinion
how
that
would
be
implemented,
and
so
on.
So
we
can.
We
can
take
a
look.
B
Like
you
know,
I
can
always
switch
to
Christian
he's
the
one
that
worked
on
it.
I
think
most
so
I
can
just
reach
out
to
him.
B
All
right,
then,
I
think
we
we
are
good
for
today
you
have
a
plan,
yeah
I,
think.
If,
if
we
do
the
splitting
I
think
because
your
TAP
is
very
big
now
as
well
anyway,
and
maybe
with
the
smaller
spin
structure,
we
can
focus
on
the
cases
and
and
make
them
make
them
more
solid
and
and
prove
their
ideas,
and
that
we
can
merge
it
and
work
on
the
rest
of
the
things.
That's
probably
been
I
guess
just
attributes,
maybe
yep.