►
From YouTube: 2022-08-25 meeting
Description
Instrumentation: Messaging
A
B
A
A
C
So,
which
one
amir's
or.
D
So
I
sent
you
the
document
on
the
slack
and
you
gave
me
a
very
good
feedback
and
the
comments.
So
thank
you
for
reading
and
helping
me
prove
it,
and
so
after
your
review,
I
did
some
changes
in
the
structure
and
added
some
additional
parts,
and
I
hope
it's
more
clear
now.
If
you
want
to
take
a
look
later
and
write
them
all
comments,
it's
very
welcome,
and
so
what
I
wanted
to
do
with
this
document,
which
I
hope
that
might
be
turned
into
an
author,
is
to
describe.
B
D
D
Things
that
I
think
we
all
agree
on
on
how
to
classify
things.
If
there's
a
single
message
or
batch
message,
I
think
it's.
It
will
help
us
later
to
to
have
these
definitions.
D
B
D
I'll
try
to
give
a
bit
of
a
background
like
what
I
didn't
want
to
do.
I
didn't
want
to
be
opinionated
opinionated
about
the
trace
structure
like
I
didn't
want
to
describe
that.
We
have
this
kind
of
span
and
this
kind
of
span
and
this
one
should
be
the
child
of
another
one
and
linked
to
something
else.
I
I
just
wanted
to
say
like
the
most
basic
things
I
can
say,
like
the
minimum
things
that
I
think
we
can
agree
upon
only
in
the
scope
of
a
single
versus
a
bad
sharing
message.
D
Yes,
so
basically
I
change
the
structure
I
have
the
motivation,
then
I
have
the
current
state
and
gaps
which
describes,
describes
the
current
semantic
conventions
and
and
why
it's
not
so
useful
today
and
and
then
I
have
the
proposal.
So
my
proposal
is
for
three
topics.
I
want
to
define
a
few
concepts
which
are
single
message
span,
batch
message,
spam
and
a
single
message
link
which,
after
they
are
defined,
we
can
use
them
in
the
future
in
other
hoteps
or
the
specification.
D
I
think
I
think
it
will
be
ending
and
the
the
other
thing
is
currently
at
a
spectrum
rewriting
our
ui,
and
I
ran
into
a
lot
of
issues
with
the
classifying
gas
spends
like
if
I
get
an
arbitrary
spin,
and
I
want
to
say
something
about
it.
Maybe
I
want
to
to
know
that
it's
a
messaging
span
or
that
it
relates
to
a
single
message
or
a
batch,
or
these
kind
of
things
it's
really
hard
for
me
currently
to
do
it,
because
there
are
no
rules
or
guidelines
on
how
to
do
it
like.
D
If
you
see
these
attributes,
it's
mean
this
about
the
span
and
if
something
else,
then
you
know
that
something
else
holds
like.
Currently,
people
just
do
what
they
feel
is
right
and
there's
no
like
a
consistent
structure
to
the
spend
attributes.
So
I
want
to
suggest
that
I
don't
want
to
suggest
like
specific
attributes.
D
I
just
want
to
suggest
that
two
namespaces
will
be
mapped
into
a
single
message
versus
another
namespace,
which
will
be
a
virtual
namespace,
and
the
last
thing
I
want
to
describe
in
this
sort
of
is
relationships
that
we
can
agree
upon
between
spans
and
links.
D
So,
for
example,
what
we
talked
about
that
if,
if
a
spam
represents
a
batch,
then
the
links,
the
links
that
describes
a
single
message
can
be
unambiguously
recognized
in
the
links
array
and
how
they
described
the
message
like,
for
example,
if
you
read
the
document,
I
want
to
suggest
that
each
message
can
only
be
found
as
a
link
once
and
if
we
have
the
total
number
of
messages,
and
we
can
see
how
many
messages
are
in
the
links
array,
then
it
is
possible
for
a
backends
and
uis
to
do
some
calculations
on
these
values
and
to
understand
if
all
the
messages
are
present,
if
some
of
them
are
missing
those
sort
of
things
and
yeah
so,
and
so
I
think
I'm
not
sure
ludmila
did
you
read
the
document
and
jess.
A
Yeah
yeah,
I
I
did.
I
have
one
question
I
agree
like
it
may
talk,
makes
a
lot
of
sense
and
having
this
perspective,
especially
from
the
back
end
like
listing
this
heuristics,
we
need
to
write
back
and
deficiently.
It's
super
important.
The
part
that
I'm
not
fully
understand
is
this
is
a
proposal
for
a
tap,
but
it
there
is
a
lot
of
intersection
with
this
huge
attack
we
have
already.
A
So
maybe
we
can
incorporate
like
if
we
can
distill
the
difference
and
we
can
incorporate
this
into
either
current
semantic
conventions
as
a
pr
or
into
this
or
tab
covering
the
gaps
that
are
not
there.
I
think
it
would
be
more
helpful
now.
D
So
you
suggest
not
to
to
publish
it
as
it
is.
It's
all
noted,
but
to
add
it
to
the
big
hotep.
A
Yeah
because
I'm
not
sure
like
what
what
our
pursuit
was
another
step,
I
think
we
discussed
adding
something
as
a
laptop.
C
Was
a
trace
structure
that
we
wanted
to
have
as
a
separator
typo
zone.
B
A
C
Yeah
when,
when
I
I
didn't
read
again
after
after
you
improved
it,
but
the
first
time
I
I
read
it,
I
was
like
it
all
made
sense,
but
I
was
feeling
like
I
was
feeling
a
bit
lost
on
what
was
the
the
goal
or
or
what
what
what
you
were
achieving
or
trying
to
achieve
with
it
or
what
was
the
like
the
like.
If
this
is
merged
and.
E
C
Read
after
you
after
you
changed
it,
so
maybe
now
it's
it's
clear,
but
just
from
you
explaining
now,
I
remember
that
there
was
a
big
thing
about
the
the
name
spacing
of
the
attributes
so
like
having
some
sort
of
namespace
in
order
to
find
out.
If,
if
a
span
is,
is
a
badge
or
if
a
spin
is
belongs
to
a
batch
spin
or
not.
C
So
this
this
was
kind
of
a
big
deal.
I
guess
in
the
text
when
I
read
it
so
and
then
the
other
thing
that
you
mention
now
that
that
it's
not
written
or
it's
not
explicit-
that
there
is
a
batch
and
another
batch
so
in
the
current
conventions
yeah.
C
So
I
I
wonder
if
I
think
making
the
splitting
the
output
that
we
have
into
multiple,
I
think
does
make
sense,
because
that
one
is
huge
and
I
was
even
thinking
if
we
should
even
close
that
pr,
because
it's
so
big
now
it's
it's
really
hard
to
follow
things
there.
C
But
anyway
I
will
read
this
again,
but
maybe
for
the
name
spacing
of
of
the
of
the
attributes
that
only
that
can
be
a
separate
attack,
because
then
you
can
introduce
like
it's
not
possible,
for
example,
to
differentiate
spans,
and
we
need
a
clear
way
to
find
that
this
fan
belongs
to
a
badge
or
dispense
belongs
to
a
single
match.
And
then
maybe
there
is
another
just
for
just
for
introducing
this
concept
of
the
name
space.
So
that
could
be
one
thing.
A
By
the
way,
a
regarding
the
splitting
part,
the
current
laptop,
what
do
you
folks
feel
if
we
start
to
bring
things
from
the
new
attack
to
the
spec
like
in
the
same
way
as
a
context
propagation,
but
even
in
smaller
pieces,
for
example,
we
will
discuss
batch
size
or
on
the
attribute
right.
However,
we
name
it
once
we
agree
on
the
name.
We
can
just
go
and
I
can
create
a
pr
to
the
spec
or
anyone
who
wants
it
can
do
it.
It
will
be
non-controversial
change.
A
Everyone
would
be
happy
about
it
and
maybe
after
we
reach
this
agreement,
we
can
just
go
there
and
then
we
we
don't
even
need
to
think
about
it.
After
we
write
the
version,
the
next
version,
because
it
will
already
be
there
and
if
we
discuss
message
attributes,
we
can
just
bring
them
there.
So
the
only
controversy
regarding
the
attributes
would
be
the
three
names
and
we
can
even
do
this.
C
Yeah,
I
I
think
it
makes
sense
to
split
and
and
bring
things
that
are
easy.
Let's
say
like
that
separately,
I
think
that
would
make
things
faster
and-
and
I
think
there
are
definitely
points
that
are
non-controversial
and
should
go
there.
I
guess
easily,
no.
C
Leave
comments,
but
so
do
you
want
to
like?
Do
you
have
a
clear
goal,
for
example
like
after
so
if
this,
let's
say,
if
you
open
this
as
an
o
tap,
what
would
would
you
be
reflecting
changing
the
current
conventions,
the
name
spacing
thing,
for
example,
and
and
what
else.
D
The
practical
er
stuff
is
the
database
names
like
I
think
after
this
is
merged.
If,
if
we
decided
that
we
want
to
push
to
to
emerge,
and
so
the
attribute
names
we
can
start
talking
about
which
attributes
should
go
into
which
namespace
and
then
it
can
start,
we
can
start
applying
it
on
a
on
a
current
instrumentations,
even
with
without
an
agreement
about
the
structure
and
other
issues
which
are
not
very
mature.
Currently.
C
And
so
just
defining
like
this
distinction
between
batch
attributes
and
in
single
essay
attributes.
C
D
Yeah
and-
and
the
other
thing
is
that
the
current
specification
it
lacks
a
lot
of
and
the
operations
like
settlement
or
a
send
batch
or
create
so
since
they're
not
specified,
we
don't
want
people
to
use
them
currently,
but
if
they
do
use
them
like,
if
someone
someone
in
his
instrumentation
is
instrumenting
the
settlement
operation,
then
it
will
be
clear
how
to
to
populate
links
and
how
to
populate
the
attributes
on
celebration.
C
D
A
I
don't
think
so
like
we
in
in
theory
like
I,
I
really
like
this
idea
that
we
can
start
speaking
out
specific
things
that
are
missing
and
then
imagine
like
current
specification.
However,
there
it
works,
it
does
not
talk
about,
spend
structure,
much
right
and
there
are
gaps
there.
So
if
we
add
another
area
like
settlement
clearly
specified,
I
don't
think
there
will
be
any
push
back
on
the
lack
of
this
structure
and
we
will
still
say:
okay,
there
is
a
link
right.
A
Okay,
these
are
the
attributes
you
put
on
the
span,
so
I
think
the
current
specifications
work
on
the
way
you
you
give
a
list
of
attributes
and
everyone
is
happy.
So
we
can
do
this,
knowing
that
we
also
need
to
cover
the
structure
later,
but
we
don't
have
to
do
it
right
now.
C
Yeah,
if
if,
if
that
that
sounds
okay
to
me,
if
you
think
that
it's
not
gonna
be
also
a
problem,
then
I
think
I
think
that
makes
sense.
Yes,
so
get
this
individual
parts
and
and
and
then
in
this
case,
maybe
we
don't
even
need
a
no
tap
because
it
can
just
be
directly.
I
spin
spec
vr.
I
guess.
A
B
A
I
think
in
the
specification
this
document
will
result
in
a
few
additional
attributes
in
the
yaml's
file
right
and
an
additional
section
for
settlement
plus
some
markdown
part
of
it.
C
Yeah-
and
so
maybe
some
small
part
like
explaining
this,
this
name
spacing
and
so
on
right,
but
for
this
for
this
part
only
for
this
namespace.
D
So
actually,
this
document
doesn't
talk
about
settlement.
It
only
talks
about
batch
versus
single.
So
maybe
we
can
write
another
document
to
talk
about
settlement,
but
I
think
it
will
be
like
a
based.
D
It
can
use
concepts
from
the
single
versus
batch,
because
settlement
operations
can
also
be
settlement
of
a
single
message
or
a
batch
of
messages.
So.
A
I
would
rather
write
it
as
a
pr
draft
to
the
stack
directly
and
we
can
circle
back
on
this,
and
I
will
share
it
because
you
will
also
give
me
feedback
and
because
I
I'm
I'm
trying
currently
to
instrument
settlement
in
my
sdks-
and
I
have
it's
just
very
handy
to
do
it.
Okay,
cool.
C
So
maybe
we
before
so
maybe
we
can
just
take
the
time
a
bit
to
discuss
the
name
spacing
thing:
how
do
you
envision
that
to
work
and
and
like
if
you
thought
about
about
it,
so
the
main
goal
is
for,
for
example,
to
to
distinguish,
but
to
do
some
heuristics,
based
on
on
on
the
name
of
the
attributes
to
find
out,
for
example,
if
this
the
span
is
a
bad
or
not
right
that
that
is
the
intention
more
or
less.
D
Yes,
so
basically,
what
I'm
doing
today
is
in
our
ui
when
I
get
an
arbitrary
span,
I
need
to
like
derive
some
classification
for
it,
so
I
can
process
it.
So
what
I'm
doing
is
I'm
looking
at
all
the
attributes
and
if
I
see
an
attribute,
that's
starting
with
a
messaging
dot,
then
I
classify
it
as
a
messaging
spam.
D
So
this
is
really
handy
and
it
it's
working
well
for
me,
and
it
allows
me
to
to
handle
a
variety
of
of
things,
both
things
that
follow
the
semantic
conventions,
but
also
things
that
are
not
completely
conformed
to
the
semantic
conventions
right.
So
let's
look
at
the
attribute
names
and
if
I
see
a
messaging,
I
know
that
it's
a
messaging
spin
and
I
found
it
very
convenient
and
what
I
want
to
suggest.
D
I
think
it's
it's
consistent
with
with
the
way
to
classify
other
spends,
so
just
by
the
presence
or
lack
of
attributes,
and
accordingly
I
want
to
suggest
to
have
a
messaging.birch
namespace
which
will
classify
a
span
as
a
as
a
batch
operation
and
and
then,
if
we
know,
for
example,
the
number
of
messages,
then
we
can
say
messaging.batch.a
number
of
messages
or
any
other
name,
that
we
choose
and
say,
for
example,
10
and
then
we
know
that
this
span
presents
a
batch
very
easily.
D
So
the
problem
is
that
there
is
no
a
single
attribute
that
we
can
query
right
and
that's
part
of
the
comments
on
the
pr.
So
there's
not
like
an
attribute
saying
messaging
dot
is
batch,
equals
true,
and
then
we
can
look
at
this
attribute
and
know
without
any
complicated
processing
that
this
match.
This
span
represents
say
something
to
something
else.
So.
B
D
B
D
For
example,
if
we
want
like
a
single
attribute
to
represent
this
is
batch
equals
true,
then
we
can
end
up
with
like
redundant
attributes,
because
if
we
already
have
something
else,
that's
saying
this
is
a
badge.
Then
we
don't
really
need
the
extra
attribute
to
say
it's
a
batch.
So
it's
a
bit
wasteful,
but
it's
it
will
be
very
easy
for
backhands
to
process
it
like
this.
D
C
Yeah
like
when
I
was
reading,
I
I
understand
that
the
that
is
necessary,
or
that
is
good
to
have
these
names
facing.
I
think
it
all
makes
sense,
but
I'm
not
sure
if
I'm
a
fan
of
the
of
the
like
looking
at
the
attributes
and
and
the
start
with
or
something
like
this,
I
think
the
I
think
if
we
had
an
attribute
that
would
tell
either
the
some
sort
like
what
you
said
is
that
true
or
for
this
kind,
maybe
we
can
use
that
or
something
like
that.
I
think
that
would
be.
C
That
would
be
make
things
more
easy.
I
think,
because
then
you
can
rely
on
that
attribute
and
and
yeah
blockchains
can
do
fancy
things
with
it
and
so
on,
because
then,
if
you
rely
on
that
one
on
what
on
one
attribute,
maybe
that's
not
there
and
then
what
do
you
do
right
then?
So
it
yeah,
since
we
are
defining
the
conventions,
I
think
it
makes
sense
that
we
have
a
convention,
and
we
like
expect
this
is
a
convention.
That's
some
concept.
That
is
important
right.
A
Yeah,
thank
you.
I
think
we
discussed
that
some
sort
of
a
batch
size
would
be
useful
regardless,
it's
not
a
redundancy
anyway.
D
Yeah,
so
I'm
not
sure
like
if
it's
always
possible
to
capture
it,
but
I
think
that
in
most
cases
it
is
possible-
and
this
attribute
can
be
populated,
right
and
and
also
the
messaging
dot
message
id.
C
Yeah,
I
just
don't
like
the
the
fact
that
we're
using
some
interaction
attribute
to
to
derive
the
meaning
of
something
like,
for
example.
If
they
attribute
a
message
id
is
there,
then
it
means
that
this
I
understand
that
it
it
will
work,
but
I'm
not
sure
if
I,
if
it's
not
sure
if
it's
like
something
that
is
cool
or
or
that
is
I
don't
know
clean
or
whatever
you
want
to
say
it,
but
the
the
size
might
be
cool
might
be
a
good
option.
C
I
think
that,
because
you
get
like
two
things
out
of
one
right
but
yeah,
but
if
it's
not
possible
to
always
tell
it
and
also
it's
a
problem.
C
But
like
if,
let's
say
that
we
come
up
with
a
new
attribute,
let's
say
it's
batch
two,
for
example.
Is
that
always
possible
to
to
to
like
to
know
if
it's
a
batch,
I
I
would
assume
so
right,
because
you
know
that
you're
sending
a
batch
when
you're
sending
it
so.
C
B
C
D
E
E
B
B
D
Yeah,
so
if
you
look
at
the
like
sqs
rpc
documentation,
there
are
so
many
operations
there
and
many
of
them
don't
relate
to
messages
at
all.
They're,
like
you,
send
like
a
request
and,
and
you
get
back
a
kiwi
url
or
where
maybe
you
can
configure
the
things
via
some
rpc
calls.
So
hope
is
not
specifically
about
the
message,
but
someone
might
use
the
messaging
semantics
on
these
operations
because
they
do
commune
describe
communication
with
a
message
in
walker
or.
A
Okay,
so
for
this,
then
you
still
have
messaging
system,
but
it's
not
a
badge
right.
It
doesn't
deal
with
messages
at
all
and
if
they
don't
have
a
one
of
the
listed
operations
that
we
have.
So
it's
like
some
generic
spam
that
doesn't
have
links.
I'm
I'm
not
sure
if
you
need
any
additional
heuristics
for
them.
D
If
the
messaging
operation
is
not
a
one
of
a
list,
then
it's
something
else:
it's
not
a
message,
a
single
message
and
it's
not
a
badge.
A
But
is
there
a
confusion
without
right?
So,
for
example,
you
have
we
have
spent
kind,
which
is
for
messaging
specific
things
as
a
producer
or
a
consumer,
and
the
rest
is
client
or
internal
right.
Maybe
that's
enough.
A
Yeah,
I'm
saying
that
when
I
read
this
telemetry
as
a
bro-
oh
sorry
as
a
backhand
right,
I
need
to
distinguish
batch
batches.
That's
for
sure!
Okay!
Then
there
are
questions
we
have.
Some
operations
like
go,
get
properties
of
this
queue
right
versus,
go
and
settle
right
or
go
and
send
a
single
message
right.
So
single
cent
versus
go
get
properties.
A
Do
we
need
to
distinguish
those
two?
What
will
change
on
the
back
end?
If
you
don't
distinguish
them.
D
Yes,
so,
for
example,
in
our
ui,
we
have
like
this
tab
that
if
it's
a
messaging
span,
you
can
see
details
about
the
message,
and
I
want
to
know
if
I,
if
I
want
to
show
this
tab
or
not.
So
if
this
is
an
operation
about
a
message,
I
want
to
say
what
everything
that
I
can
about
the
message
involved
and
if
not,
I
will
not
show
this
tab.
So
I
need
some
kind
of
like
logic
to
to
know
how
to
do
it.
C
Isn't
that
the
operation
name
is
for
this
now
or
could
this
be
used?
For
this
I
mean.
Maybe
we
have
to
extend
it
here,
but
yeah
like
send,
send
and
then
send
that,
for
example,
then
it's
soft
right
and
then,
when
it's
like
this
other
type
of
operations
that
are
not
using
any
message
or
doing
anything
with
messages,
then
we
would
probably
have
to
add
more
operations.
Maybe
here
maybe
like
commit
transaction
or
something
like
that.
D
Yeah,
so
that's
one
way
to
do
it
and
it
will
work.
I
think
the
downside
is
that
we
will
have
to
maintain
this
list
of
operations,
because
the
message
landscape
is
so
diverse
and
some
operations
will
pop
up
in
the
future
and
we
will
have
to
like
go
over
them
one
by
one
and
classify
them
saying
this
operation
behaves
like
this.
D
Another
operation
behaves
otherwise
and
then,
if
we
have
like
a
a
wall
that
that
is
not
so
fragile,
like
it
will
work,
even
if
people
in
the
future
will
do
changes
and
add
more
things
and
will
and
there
will
be
other
use,
cases
which
are
not
covered
and
everything
will
just
keep
walking,
there
will
be,
nothing
will
break
and
that's
my
view.
C
Okay,
but
so
the
messaging
system
can
be
used
to
to
quickly
find
out
that
if
it's
a
span
related
to
anything
with
messaging
right,
so
that
that
is
out
of
the
that
is
out
of
the
discussion
right
so
that
we
already
have,
then
what
we're
lacking
is
a
way
to
distinguish
if
it's,
if
it's
a
single
message
or
a
badge.
So
this
is
one
case
that
we're
missing
and
we're
also
missing
to
know
if
it's
an
operation
that
is
or
a
spam,
that
is
doing
anything
with
a
message
or
not
right.
B
D
B
A
Maybe
it
feels
to
me
it's
the
very
back
definition.
So,
for
example,
we
have
apis
that
ring.
You
walk
on
the
message.
It
seems
they
are
doing
something
with
the
message,
but
they
might
not
even
know
about
the
message
they
are
working
with
because
they
have
a
sequence
number
as
identifier
or
in
some
cases
they
might
have
a
message
and
it's
just
the
api,
the
the
choice
of
user
who
call
this
api
or
if
I
cancel
a
message
that
they
scheduled
before
they
deal.
They
do
something
with
message,
but
I
don't
even
know
they.
A
I
don't
have
an
instance
of
this
message.
I
only
have
a
secret
number,
so
it's
a
very
bad
thing
to
do
and
I
don't
think
you
can
do
the
very
reliable
experience,
because
even
the
instrumentation
doesn't
know
even
sdk
doesn't
know.
D
Yes,
so
I
think
nothing
we
we
are
specking
will
cover
everything,
because
the
this
landscape
is
so
diverse
and
complex,
but
like
I
think
that
if
we
know
that
it's
something
that
tends
a
single
message,
maybe
we
have
the
message
id
or
sequence
number
which
we
can
populate
and
then
it
can
be
used
to
correlate
to
other
spans
or
something
similar.
D
A
All
right,
yes,
so
in
some
cases,
depending
on
how
user
calls
this
api,
that
could
be
one
or
another,
but
if
we
step
back
for
a
second.
So
if
we
think
about
this
scenario
like
understanding
the
correlating
some
arbitrary
thing
to
the
whole
message
and
it's
processing
is
it
to
me.
It
sounds
like
an
advanced
scenario
and
maybe
we
can
come
up
with
some
optional
heuristic
that
instrumentations
can
populate,
but
it
doesn't
feel
like
it's.
It's
super
essential,
but
maybe
I'm
wrong.
I'm
sorry!
I
don't.
D
D
But
then,
if
we
just
look
at
an
array
of
links,
we
don't
have
a
a
good
way
of
filtering
out
the
links
that
refer
to
a
single
message
versus
other
links
which
are
like
describe
something
else,
which
is
not
a
single
message
right.
It's
like
we
just
see
an
array
of
links
and
there's
no
clue
about
what
they
mean.
A
We
can
also
have
an
attribute
on
link.
Well,
I
mean
type
is
good,
but
we
don't
have
it
and
maybe
we
won't
have
it.
It
requires
spec
change
right
and
product
change.
It's
it's
huge,
so
maybe
we
can
start
with
an
attribute
and
say:
okay,
this
attribute
on
a
link
means
that
this
link
is
represents
a
message
for
messaging
scenarios.
D
A
D
A
D
Yeah,
that's
that's
my
suggestion
like
we
can
either
select
a
single
attribute
and
say
this
attribute
is
required,
or
we
can
just
say
that
any
attribute
in
the
namespace
that
just
the
presence
of
it
say
something
about
whether
the
span
is
a
bachelor,
single
or
something
else.
A
D
D
C
It
would
be
nice
to
have
something
that
is
required
right.
So
so
it's
not
that
fragile,
but
yeah
having
to
come
up
with
something
just
for
this
as
well,
not
sure
if
it's
gonna
be
well
received,
as,
like,
I
said,
duplication
and
so
on,
like
having
an
attitude
saying
a
single
message
or
is
batch
true
or
false.
C
But
might
might
not.
A
Let's
see,
I
think
we
we
can
find
like
some
of
these
cases.
It
feels
like
if
we
clarify
all
the
way
there
until
this
attribute,
it
will
be
way
easier
to
justify
this
one
too.
C
I'm
not
sure
yeah,
no,
I'm
not
not
dismissing
it.
I
just
yeah.
I
think
it's.
If,
if
we
yeah,
if
it's
there
is
value,
then
we
just
have
to
say:
okay
now
we
use
this,
and-
and
I
think
the
only
thing
that
it
might
be
an
exercise
is
to
know
that
if
we
can
always
populate
it,
then
we
can
make
it
required
and
then
we
should
be
good
right.
C
A
B
D
One
is
like,
if
you
send
something
to
a
queue
as
a
batch,
and
this
batch
contains
one
item.
It's
not
the
same
as
if
you
use.
B
D
Yes,
but
it's
a
different
api
call,
but
it
will
be
interpreted
as
like
something
it
will
be
interpreted
as
the
same
thing
right
so
calling
a
an
api
function
to
send
a
batch
of
messages,
and
this
batch
contains
what
yes.
C
A
But
then
it
means
if
we
give
me
a
second.
So
if
we
want
to
always
distinguish
single
cents
from
the
batch
stand
on
the
instrumentation,
it
will
be
very
hard
to
enforce
it'll
be
very
hard
to
instrument.
A
I
can
give
you
an
example,
so
we
have
a
huge
convenience
api
surface,
but
we
have
one
method
that
sends
things
internally.
If
you
tell
me,
I
have
to
instrument
each
of
these
methods
to
distinguish
those
variations.
It
will
be
very
hard
for
me.
My
internal
method
sends
a
batch
regardless
right
and
I
instrument
my
internal
message
and
there
like.
Realistically,
I
wouldn't
go
all
the
way
to
distinguish
those.
I
might
populate
something
extra.
I
really
want
to
change
the
operation
name
to
match
my
api.
A
D
I
don't
think
that
there's
any
rule
that
we
can
really
enforce
like
everything
we
we,
we
say
that
we
can
find
an
example
which
which,
which
can
which
can
be
complicated
to
achieve
right.
So
I
think
we
should
come
up
with
the
guidelines
that
will
be
should
be
followed
when
possible
and
if
it's
not
possible,
then
there's
nothing
much
that
we
can
actually
do
right.
A
Yeah
but
then
what
I'm
saying
is
that
rely
on
that
presence
of
batch
size
only
means
that
users
wanted
to
send
a
badge.
It
want
to
be
a
good
heuristic.
A
A
C
It's
not
clear
right.
Yes,
it's
not
clear
anymore
yeah,
like
you,
don't
know
if
like,
for
example,
if
I'm
a
developer-
and
I
know
that
I
use
the
api
for
single,
but
then
it
shows
batch
that
tells
me
that
the
sdk
internally
uses
batches
and
and
that's
like
that
or
or
either
it's
it's
or
it
is
like
like
that,
or
is
it
unclear
right,
but
yeah?
It
will
be
this
situation.
Yes,
maybe
that's.
Okay,.
B
D
D
It's
the
developer,
calling
in
an
api
for
a
single
message
and
there's
then
there's
another
operation
like
like
below
it
that
send
this
operation
as
a
batch
to
the
server
right.
So
it
translates
the
api
call
into
some
a
single
message
into
a
badge
and
send
it
to
the
server.
So
if
we're
only
instrumenting
the
bottom
layer,
then
this
is
right.
This
is
really
a
badge
right
and
if
the
developer
wants
to
see
his
api
call,
then
issue
the
instrument,
the
api
layer
right.
So
it's
it's
not
a
problem
for
the
semantic
conventions.
C
C
D
Maybe
the
two
layers
are
instrumented,
maybe
all
the
api
layer
is
instrumented
and
and
the
networking
layer
or
the
protocol
is
instrumented
and
then
the
user
can
see
that
he
called
the
function
for
a
single
message
and
it
was
sent
as
a
batch
of
one.
A
Yeah,
I
have
a
suggestion-
maybe
this
I
think
we're
again
in
this
situation,
where
there
is
a
bunch
of
easy
stuff
and
we
focus
on
very
advanced
thing.
B
C
A
And
it
it
doesn't
mean
that
it's
not
important,
it
is
it's
just.
We
went
all
the
way
there
without
agreeing
on
simple
things,
and
then
we
we
can
do
it
later
after
we
finalize
the
the
story,
all
the
all
the
way
there
right
and
then
we
can
say:
okay
now
it's
time
for
this
extra
controversial
thing.
B
D
Yes,
so
my
suggestion
is,
I'm
not
even
talking
about
all
the
examples.
I
just
want
to
say
that
a
span
can
either
represent
a
bench,
and
this
is
how
we
are
identified
and
all
can
represent
a
single
message,
and
this
is
how
we
identify
and
and
don't
want
to
talk
about
specific
cases
like
I
leave
it
to
the
instrumentation.
If
it
wants
to
describe
this
or
the
other,
then
it
knows
how
to
do
it,
but
I
don't
tell
it
what
to
do
just
how
to
do
it.
D
If
how
to
use
attributes
to
to
to
say
what
it
wants
to
say.
C
D
A
I
mean,
for
example,
your
document
introduces
a
few
very
important
things
that
are
super
easy
to
just
go
and
do
the
batch
size
or,
however,
we
name
it
right.
If
we
can
agree
on
the
name,
somebody
can
send
the
pr
tomorrow
or
well.
I
mean
it's
easy.
Then
there
are
per
message
attributes
right,
and
we
also
need
to
talk,
maybe
about
the
the
batch
and
message
namespace,
because
the
topic
name
can
appear
in
both.
How
do
we
handle
this
right?
If
we
clarify
all
this,
then
your
document
can
go
directly.
A
Like
I
mean
change,
transform
can
go
directly
into
the
current
specification
right.
It's
an
addition.
It's
not
breaking
it's
just.
It
can
go
on
there
right
away
and
we
can
add
this
extra
thing.
The
distinction
for
a
single
message
versus
non-message
at
all
later
at
any
moment
right,
but
we
need
to
do
the
first
thing.
D
D
B
C
B
C
B
D
So
my
motivation
was
to
start
like
agreeing
on
things
which
are
very
basic
before
we
talk
about
like
attribute
names
like.
B
A
So
can
I
can
I
share
my
screen
and
show
what
I
came
up
with
regarding
the
attribute
names.
A
Yeah
and
I
have
a
little
person
here-
he's
going
to
be
going
to.
A
Thank
you
all
right,
okay,
so
I
invented
so
maybe
I
can
show
you
two
things
if
we
have
time
so,
first
I'll,
I
checked
what
what's
available
in
terms
of
message
properties.
B
A
A
So
what
I
found
that
there
were
by
like
message
id
and
I
came
up
with
message-
namespace
independently
and
here
I
first
did
it
and
then
I
I
saw
your
document,
so
I
think
this
this
this
makes
perfect
sense,
mommy
and
there
are
a
few
other
things.
I
don't
think
I
don't
think
we
need
to
add
each
of
them
into
the
spec.
I
think
we
need
to
pick
a
handful,
so
maybe
message
id,
which
is
already
in
current
step
correlation
id.
I
think
the
timestamp
is
an
interesting
one.
A
It
represents
where
the
message
was
created
or
in
some
cases
like
half
kids
were
or
yeah
when
the
message
was
enqueued
to
the
broker,
and
I
think
it's
interesting
because
then
you
can
calculate
how
much
time
message
spent
in
queue
or
waiting
till
it's
consumed
and
another
interesting
thing.
That's
led
or
delivery
thing.
A
This
is
an
attribute
it's
a
boolean,
but
in
some
cases
at
least
in
our
world
we
have
a
delivery
count
which
says
how
many
times
the
message
was
already
delivered
so,
but
it
will
be
specific
to
our
thing,
so
I
also
looked
into
like
what
are
their
or
what
attributes
specific
to
those
systems.
I
have
some
rough
idea
how
to
express
them,
but
I
think
what
we
can
start
with.
A
We
can
pick
handful
of
attributes
from
this
common
list
and
we
can
bring
them
to
the
spec
and
two
of
them
already
there
like
id
and
correlation
id,
so
maybe
just
the
timestamp
extra
or
where
delivered,
and
then
we
should
also
probably
change
with
the
namespace
with
message
namespace,
we
should
say
that
anything
specific
it
should
be
messaging.message.amqp.something,
for
example,
right
then
we'll
keep
the
the
namespacing
correct,
okay
and
then
basically
we
will
have
something
very
simple
to
agree
upon
and
we
will
say
that:
okay,
maybe
all
this
mqp
and
jms,
maybe
we
can
add
them
right
away
to
say
that
they
are
optional
or
say
that
users
can
configure
them
anyway.
A
But
basically,
this
is
the
list,
and
I
also
was
thinking
about
the
the
batch
size
thing.
So
if,
but
anyway,
we're
running
out
of
time-
and
I
don't
have
it
ready
but
anyway,
so
what
I
can
do
by
the
next
time
or
if
somebody
wants
to
do
it
as
well,
just
have
this
yamo
from
the
existing
stack
and
not
things
there.
A
I
have
an
extra
section
describing
okay,
this
is
per
message
and
an
extra
table,
and
here
is
the
batch
size.
However,
we
want
to
express
it.
I
don't
think
naming
is
controversial.
I
think
we
can
all
agree
on
the
naming
it's
super
simple,
but
that
just
to
do
this
work
and
after
that
we
would
also
like,
but
this
can
get
merged,
and
after
this
I
think
we
will
need
to
discuss
how
we
represent
her
message
attribute
that
can
also
be
per
batch
by
the
destination
name.
C
Yeah,
okay,
so
if
I
understood
what
what
what's
your
plan
or
what
your
idea
is
that
what,
for
example,
separating
having
namespace
for
messaging
message
in
in
batch
makes
sense
right?
So
I
guess
we
all
agree
on
that
and
what
you're
suggesting
is
that
we
already
bring
a
pr
to
add
the
message
like
name
space
like
you:
have
now
get
that
merged
right
and
then
open
another
one
to
add
the
batch
one.
A
Yeah
that
could
be
an
option.
We,
I
think
the
batch
I'm
not
fully
understanded,
yet
they're
the
the
need
for
batch
name
space
and
how
they
are
going
to
work
with
messages.
Just
I
don't
understand
it's
not
anything,
and
I
think
I
feel
I
need
to
more
think
more
about
it
than
this.
I
would
like
to
discuss
it
more.
B
C
D
Yeah
yeah
my
document
just
formalized
it
it's
saying
that
how
you
should
look
at
the
attribute
names
and
and
decide
if
it's
a
single
message
or
a
batch.
So
if
one
of
these
attributes
are
present,
then
you
know
that
like
if
it's
the
best
batch
of
messages.
B
D
C
So
your
document
is
more
around
how
to
gather
insights
or
how
to
find
to
to
have
some
here.
Is
it
based
on
the
attributes?
Okay,
but
yeah
yeah.
So
do
we
want
to
have
something
like
that
in
the
spec
in
the
first
place?
Is
that
something
that
is
like,
because
this
is
mostly
helpful
for
back
ends
right,
like
the
users?
Don't
really
care
about
it,
and
the
instrumentation
also
also
don't
care
much
about
it
right.
They
were
just
populating.
C
A
C
This
is
for
the
application
owners
that
is
important
right
now
for
the
application,
the
the
instrumentation
outers.
D
It
wants
to
to
output,
valuable
data
and
it's
valuable
and
if
it's.
C
Special
all
right,
yeah,
no,
but,
for
example,
having
a
text
in
a
spec
saying,
like
you,
should
interpret
this
attribute
as
a
badge.
It's
not
not
really
useful
for
for,
like
people
writing
instrumentation
right,
they
it
it's.
It's
used
for
them
to
know
that.
There's
this,
for
example,
size
and
if
they're
dealing
with
the
best,
they
should
populate
it,
but
they
should
like,
for
example,
if
there
is
this
attribute
span,
then
the
pen
is
a
bad.
Spam
is
not
interesting
for
our
instrumentation
author
right.
They
they're
not
gonna,
gain
anything
from
it
right.
A
Yeah,
so
the
instrumentation
authors
just
try
to
give
something
useful
for
users
right
they
under
their
and
users,
would
want
to
know
about
the
per
message
attributes
and
per
batch
attributes
and
for
instrumentation
order.
If,
if
you
ask
my
opinion,
what
I
like
is
a
clear
guidance.
Just
tell
me
what
to
put
there.
I
don't
care.
C
I
yeah
exactly
so
like
if
we
have
the
table
with
the
message
specific
attributes
that
we
say:
okay,
these
attributes
go
on
when
you're
dealing
with
single
message
and
these
attempts
go
when
you're
dealing
with
the
better
spectrum
messages,
clear
guidance.
I
know
how
to
write
my
instrumentation
right,
but
the
the
sector.w
is
saying
like
like
more
defining.
C
For
example,
if
there
is
this
attributes
in
the
span,
you
can
understand
this
span
as
a
single
message
span
and
if
these
other
attributes
are
there,
then
it's
about
to
spin,
it's
not
really
useful
for
for
the
users
that
are
consuming
it.
For
example,
the
people
writing
the
applications
either
for
the
people,
writing
instrumentation
right,
it's
more
for
backhands.
C
I
I
see
like
that
at
least
because
the
becketts
will
understand
this
speck
and
say:
okay,
I
can
use
this
as
a
as
a
I
don't
know
a
recommendation
or
a
guideline
to
to
extract
this
behavior
right.
A
It's
useful
for
users,
so
like
patterns
for
batching
on
our
site,
looks
like
this
users,
for
example,
put
messages
in
a
batch
until
it's
free,
it's
reached
its
max
size
and
then
they
send
them.
It's
useful
to
know
how
many
messages
on
average
or
the
distribution.
However,
many
of
them
right
and
I
want
to
know
okay,
this
batch
was
huge
and
it
represents
10
seconds
of
buffered
messages
or
on
the
receiver
side.
I
request
10
messages
and
I
got
one
in
time
like
I
of
the
timeout.
A
C
For
the
users
is
because
you
will
look
at
your
observability
back
in
and
you
will
have
all
this
information
right,
but
you
don't
care
how
this
information
was
was
acquired
or
how
it
was
came
up
with,
like
you
don't
care
that
you
see
a
nice
spin
and
there's
a
nice
logo
of
a
messaging
system
like
you
don't
care,
like
you
know
it's.
It's
definitely
useful
like
to
know
all
this,
but
me
as
a
user.
Looking
at
the
telemetry,
I
don't
care
how
it
was
done
right.
C
It's
useful
for
people
that
are
implementing
this
they're
defined
as
heuristics
that
define
these
things
like
the
latency
or
so
on.
They
they
rely
on
those
things
right,
but
it's
I
feel
like
it's
more
the
back
end
that
relies
on
this
like
to
know
how
to
things.
C
C
Not
really
sure
I
I
see
the
value,
but
I
because
I
never
never
saw
something
expect
that
it's
like
attracted
to
to
like
how
the
kids
derive
or
interpret
things.
For
example,
apart.
B
D
D
Yes,
people
can
consume
sensors.
Yes,
so
we
want
to
know
as
an
instrumentation
auto.
We
want
to
know
what
to
do
so.
So
so
the
the
other
side
can
yes,.
A
Yeah
cool,
so
what
I
think,
maybe
that
I
also
committed
to
the
settlements
part,
but
maybe
settlement
can
come
next.
I
would
like
to
drop
this
pure,
and
I
would
like
to
draft
also
the
batch
size
thing
there,
because
it's
super
uncontroversial,
it's
like
it
should
be.
There.
B
D
Yeah,
so,
okay,
we
can
talk
about
it
next
week.
A
few
questions.
D
C
Okay,
but
do
you
have?
I
just
want
to
make
sure
that
amir
is
happy,
that
we
didn't
yeah.
B
D
Yeah,
I
still
think
we
can
like.
I
can
try
to
edit
it
a
bit
and
maybe
suggest
it
as
an
author,
because
I
don't
see
why
it
has
to
come
after
other
things,
it's
very
basic,
but
we
can
talk
about
it.
Offline.
A
Okay,
the
opposite
right:
we
can
just
take
your
document,
the
the
essence
of
it
and
put
it
into
this
directory
first,
because
there
is
nothing
controversial
there
like,
we
will
talk
about
the
badge
name
space
and
how
to
have
the
same
things
in
the
batch
of
message
right
like
the
destination
name.
But
I
think
we
can
just
streamline
this
process
of
taking
things
from
our
discussions
into
the
spa
right
away
and,
for
example,
you
usually
need
it
for
huge
changes
that
are
controversial
and
it's
not.
C
Yeah,
so
just
just
to
to
finalize
that,
so
we
we,
we
do
have
a
plan
right,
so
we
will
send
small
prs
for
the
let's
say
batch
size.
I
think
the
name
was
okay
and
for
the
message
individual
attributes
is
that
understood
or.
E
A
Yeah
and
I
I'm
going
to
just
maybe
start
with
just
an
idea
and
correlation
id,
so
maybe
I
will
add
a
timestamp
as
well
and
then
this
list
can
grow
endlessly
right.
We
don't
need
to
agree
on
everything.
First,.
E
Yeah,
but
I
think
one
thing
we
need
which
is
kind
of
missing
is
what
these
things
are
like.
What
is
a
message
id
I?
I
know
it
sounds
like
a
silly
thing
to
say,
but
I
I
feel
like
we're
way
over
time,
but
I
I
think
this
needs
more
discussion.
Like
you
know,
there's
jms
has
jms
message
id,
but
many
messaging
systems
have
their
own
message
id
is
this
sort
of
like
an
application
message
id
or
is
this
an
id
for
the
system
to
uniquely
identify
the
message?
E
So
I
think
we
need
to
talk
about
some
of
this
and
I
think
every
attribute
we
put
in
there.
We
should
have
some
description
of
why
it's
there
and
the
intent
and
the
purpose
of
it.
So
someone
implementing
it
with
their
own
message
system
understands
how
to
fill
that
in
with
concepts
from
their
messaging
system.
So
I
this
is
a
great
start.
I
like
it,
but
I
just
think
before
we
kind
of
go
ahead
and
add
it,
we
we
we
have
a
bit
more
to
talk
about
and
more
details
to
flush
out.
C
All
right,
then,
let's
do
like
that
and
I
will
still
keep
take
a
look
at
your
document
once
again
and
we'll
think
of
offline
anyway.
D
B
E
E
C
C
Yes,
cheers
all
right
then
see
you
next
week,
then
yeah.