►
From YouTube: 2022-11-10 meeting
Description
Instrumentation: Messaging
A
A
A
A
I
think
we
do.
We
have
speaking
on
the
agenda.
B
I
think
yeah.
Last
week
we
talked
about
the
open
PL
in
Spec
and
I.
Think
a
lot
of
people
have
reviewed
it.
So
maybe
we
can
go
over
the
comments.
A
Yeah,
let's
do
this,
but
we
have
Carlos
here
and
Carter
and
shrika
I
know:
Carlos
I
know
Carter.
But
what
do
you
guys
do
here.
C
You
yeah
totally
I
came
mostly
because
I'm
interested
in
the
messaging
or
tap
I
forgot
the
name
now
so
yeah,
so
any
around
that
from
the
messaging
progress
that
could
be
great
yeah
220.
It's
fun
instruction
for
messaging
scenarios,
but
yeah,
but
in
in
general,
we're
interested
in
the
messaging.
The
messaging
effort.
D
A
I'm,
sorry,
yes,
I
am
I'm,
sorry
yeah,
so
we
we've
done
a
couple
of
approaches
with
spot
depths
and
we
realized
that
the
initial
one
was
too
big
and
we
we
wanted
to
break
it
down.
So
like
the
current
way
of
progress
when
trying
to
make
we
focus
on
the
smaller
pieces,
for
example,
attributes
and
we
we
would
like,
maybe
to
batch
all
the
things
that
will
be
breaking
together
in
terms
of
attribute
names
and
it's
currently
in
the
pr.
A
But
beyond
that
current
semantic
connections,
they
work
reasonably
flying
in
terms
like
for
a
single
message,
but
when
we
get
to
batch
sending
receiving
processing
they
are
they
don't
provide
almost
any
guidance,
and
we
want
to
specify
this
for
batching
or
I.
Think
the
span,
structure
or
tab
should
focus
on
the
batching
part
of
it
yeah.
D
A
Structure,
relationships
between
spans
would
come
as
the
next
PR
we
didn't
decide
yet
how
small
of
the
pieces
we
wanted
to
be
right,
and
here
we
would
love
to
get
some
guidance
from
technical
committee
on
how
they
prefer
to
work
it
or
us
to
work
on
it.
D
Awesome
yeah
thanks
for
the
thanks
for
the
over
you,
Carlos
I'm,
not
sure
or
three
con
I'm,
not
sure.
If
you
guys
have
anything
foreign.
E
Just
curious,
let's
see
what's
happening,
want
to
follow
yeah
the
progress,
nothing
special.
A
Do
your
folks
have
linked
it?
I
can
share.
A
So
I
cannot
find
the
project
right
away.
B
So
what
we
thought
to
do
is
to
like
generate
a
lot
of
small
PRS
like
relatively
fast
into
the
specification
of
things
that
we
have
a
stronger
agreement
on,
because
there
are
things
that
we
don't
have
strong
agreement,
but
we
said
that
we
want
to
to
like
start
pushing
things
that
we
can
agree
on
as
soon
as
possible,
but
I
think
everything
is
currently
blocked
on
the
current
PR,
which
is
like
something
that
the
next
issues
are
based
on.
So
we
cannot
post
more
PRS
until
this
one
is
merged.
B
So
I
think
we
all
reviewed
the
the
pl
so
I
think
after
it
will
be
merged.
Maybe
we
can
try
to
get
into
a
higher
phase
of
like
creating
a
lot
of
small
powers
for
various
issues
and
I'm,
not
sure
we.
This
is
the
plan.
This
is
what
I
think
that
we
agreed
on,
but
I
could
be
understanding
it
not
correctly.
A
So
we
have
some
glorifications
here.
What
we
believe
should
be
in
the
first
stable
version,
and
what
comes
after
so
here
we
have
a
bunch
of
in
progress
items.
We
are
trying
to
clarify
as
pen
structure
we're
trying
to
formalize
attributes
better
yeah,
and
here
is
the
list
of
things
we
still
want
to
tackle,
but
mostly
like
the
overarching
goal
is
to
as
the
next
step
too
clearly
specified.
Batching
scenarios.
A
D
Yeah,
it's
definitely
been
helpful
to
me.
Carlos
I'm,
not
sure
if
you
have
any
opinion
on
how
they
structure
their
oteps,
especially
since
you're
on
the
TC
I'm,
not
sure.
If
there's
like
a
general
preference
there
or
any
guidance
you
can,
you
can
give
no.
C
I
think
that,
usually
for
devs,
that
are
very
specific
to
some
tasks,
that
or
area
that
the
PC
is
not
familiar
with.
Usually
we
wait
that
this
working
group
in
this
case
the
messaging
one,
goes
over
your
tab
and
once
you
have
agreed
on
something-
and
you
have
a
progress
on
your
site,
then
usually
after
that,
it's
moved
to
the
TC
to
review
that
yeah.
So
I
did
an
initial
pass
on
that
front.
C
Reviewing
that
yeah,
so
I'm,
just
trying
to
stay
in
the
loop
I
also
saw
some
questions
there
from
Bruno,
at
least,
if
I
remember
correctly
other
than
that
the
format
of
the
tap
is
is
totally
fine.
At
this
moment,.
A
You
know
right
and
I'm
trying
to
find
it.
I'm
sorry.
F
C
Hi
you
remember
this
PR
yeah,
okay,
I
I,
see
a
change
request
from
Dwayne
Paul's
other
than
that
I
can
go
and
do
a
review
Myself
by
the
way.
Sometimes,
if
a
PR
gets
too
crowded
with
comments
and
it's
hard
to
track
that,
sometimes
people
decide
to
open
the
pr
from
the
start.
You
know,
but
in
general,
otherwise,
yeah
I
I
can
review
that
and
give
you
my
opinion.
C
A
Yeah
so
like
Dwayne
is
here
and
we'll
clarify.
So
what
we
do
we
review
it
as
a
group
here
or
if
it
needs
offline
discussion,
we
do
it
in
this
call
and
then
I
think
we
have
a
couple
of
items
still
open
that
we
need
to
agree
upon.
A
We
will
clarify
it
and
maybe
I
can
send
a
new
PR
there
with
without
all
this
discussions,
and
then
these
group
members
can
approve
that
PR,
which
will
be
the
copy
of
this
one
like
without
the
comments,
and
then
we
can
ask
you
Carlos
to
review
it.
Would
this
work
better
for
you,
yeah.
A
So
I'll,
let
you
know
okay,
when,
when
we're
ready
to
when
it's
ready
for
review,
yeah.
C
A
Cool,
so
should
we
talk
about
progress
and
practice
more
or
should
we
switch
to
the
the
agenda?
We
had
to
keep
reviewing
this
VR.
A
A
Yeah,
you
don't
see
my
screen
now
right!
Oh
I'm!
Sorry!
Yes,
please
share,
because
my
internet
is
not
great
thanks.
C
G
Yeah
this
change
that
I
was
suggesting
is
because,
like
the
old
spec
only
had
temporary
and
we
kind
of
split
that
into
temporary,
which
denotes
only
its
life
cycle
and
Anonymous,
which
indicates
you
know,
implies
a
generated
or
name
that
isn't
well
known
and
so
I
think.
The
reason
the
old
spec
had
temporary
was
because
usually
temporary
destinations
have
generated
names,
but
that
may
not
always
be
the
case
and
so
I
think
Anonymous
is
a
better
term
to
use
in
this
part
of
the
spec.
Here.
A
I
didn't
have
a
chance
to
read
your
comments
yet.
Do
you
think
we
already
have
an
anonymous
name
on
that
tribute
right
and
it's
just
changing
the
description.
Yes,.
G
Yeah
and
for
message
ID,
that
this
has
kind
of
been
something
I've
been
wanting
to
bring
up
for
a
while.
You
know
it's
a
message
can
have
many
IDs
like
just
as
the
example
I
mentioned
here.
Jms
has
a
way
to
set
a
message
ID
on
a
message
and
that
message:
ID
happens
to
be
owned
by
the
application.
G
You
know
in
the
case
of
JMS,
a
provider
is
more
than
likely
going
to
sign
its
own
message.
Id
and
so
I
I
give
some
ambiguity
as
to
which
message
Eddie
we're
talking
about
here
and
I.
Don't
know
if
it's
best
to
say
because
the
description
says
it's
the
message
ID
in
this
used
by
the
messaging
system
and
so
I
wonder.
If
we
have
this
Con,
we
have
the
cost
of
messaging
dot.
You
know
curly
brace,
Sim
system.
G
Should
the
message
ID
be
under
that
to
indicate
clearly
this
message:
ID
is
for
that
system
and
then
I
also
wonder:
should
there
be
a
generic
sort
of
for
things
that
are
under
application
control
but
have
a
defined
meaning?
Let
like
a
JMS
message:
ID,
should
we
have
a
generic
messaging
dot
application
or
messaging.app
namespace
for
that?
Let's
just
talk,
maybe
first
about
the
message:
ID
and
postpone
the
discussion
of
a
separate
namespace
for
application
related
stuff,
but.
A
Can
you
help
me
understand
this
scenario
so
like
for
a
different
message
ideas
so,
as
a
user
I
create
the
message
and
I
specify
message,
ID
and
then
the
broker
would
assign
a
different
property
that
would
not
override
it.
So
when
I
received
the
max
which
I
can
could
potentially
get
both,
is
it
the
case
or
it
is.
G
Yeah,
that's
exactly
it.
The
broker
assigns
an
ID
that
it
uses
for
tracking
throughout
its
Network,
and
it's
it's
a
separate
ID
from
the
application
layer
of
message.
Id.
The
application
provided.
A
G
A
Okay,
I
I
would
like
to
take
a
look
at
maybe
some
examples,
because
at
least
in
messaging
systems
on
our
site,
it's
always
the
same
thing
and
maybe
looking
at
the
apis
will
give
us
some
idea
of
how
we
want
to
name
them.
A
No
application
can
provide
them,
but
broker
will
do
the
best
effort
to
use
it
or
it
will
assign
a
new
one
if,
if
it's
not
set
by
user.
A
A
G
A
Oh
interesting
I
see
what
he
means
so
like
we.
We
actually
have
three
somewhat
similar
Concepts
right
message:
ID
well,
the
sequence
number
offset,
or
maybe
even
correlation
ad,
what
that's
it's
for
different
purpose
right,
but
okay,
so
three
things
and
depending
on
the
broker,
this
three
things
were
differently
and
but
maybe
all
three
of
them
can
be
supported
as
in
case
of
amkp
I.
Think
that
message
well,
maybe
what
what
they
can
do.
A
It
can
do
some
research
it
can
clarify,
but
what
I
know
for
sure
that
in
our
case
sequence
number,
is
this
unique
thing
for
for
mqp
systems?
The
offset
is
not
unique
and
message
ID.
It's
it's
just
an
arbitrary
string.
Maybe
there
is
some
other
semantics,
but
we
cannot
use
sequence
number
and
call
it
message
ID,
because
it's
very
confusing
pronounce
the
sequence
number.
It
sounds
like
it's
a
number
right
and
the
message
ID
is
probably
a
string.
A
G
Yeah
and
I
I
I
may
be
biased
by
my
own,
familiar
with
our
messaging
system,
which
which
again
it
it
is
all.
It's
also
a
number
that
identifies
the
message,
but
I
mean
what
the
spec
says.
It's
expressed
as
a
string
I
mean,
so
you
could
express
a
number
as
a
string.
G
I,
don't
think
that's
a
problem
but
and
I
don't
know
too
much
what
other
Brokers
do,
but
I
would
tend
to
think
that
a
broker
is
not
going
to
like
a
broker
is
going
to
need
a
unique
identifier
for
a
message
and
it's
10,
not
I
would
tend
to
think
it's
not
going
to
want
to
rely
on
an
application
to
choose
something,
unique
and,
and
so
I
I
do
think
that
whatever
terminology
we
use
that
putting
something
in
the
trace
that
says
what
the
messages
kind
of
unique
identifier
is
in
the
messaging
system
is
a
useful
thing
to
have,
because
it
kind
of
allows
traceability
back
to
specifically
one
message:
you
know
guaranteed.
A
Yeah
I
agree
but
I
think
message
ad
in
GMS.
If
I
remember
correctly,
it's
it's
something
very
badly
defined,
because
it's
an
abstraction,
right
and
I
think
at
least
in
case
of
him
keep
these
maps
to
let's
check
your
name
but
I'm
I'm
not
prepared
to
have
this
discussion
out.
A
So
what
I
want
to
ask
is
the
following:
should
we
address
it
in
this
PR,
or
should
we
do
it
as
the
next
step,
because
I'm
not
even
changing
the
the
current
description
for
the
message
ID
and
it's
not
the
last
thing
we're
going
to
do
here.
If
you
want
to
get
your
perspective.
C
C
A
Yeah
I
think
this
one
might
be
worth
some
short
discussion
because
we
we
worked
and
reaching
on
this
question
for
a
while,
so
the
batch
size.
Currently
the
there's
PR
says
that
we
should
have
badge
size
every
time.
A
There
is
an
operation
that
can
be
batched
right,
so
it
might
be
user
who
started
the
call
and
sent
some
batch
of
one
or
receives
a
bachelor
appointment
right
so
for
receives.
We
always
need
the
batch
size
because
we
don't
we
cannot
have
default.
We
cannot
say
it's
one,
because
it
can
be
zero
as
well.
You
can
receive
nothing
right.
A
So
if
you
pull
so
then
for
receive
I'm
saying
the
instrumentations
should
always
set
it
or
must
set
it.
I
changed
the
language
here.
I
must
set
it
for
receive
and
should
set
it
on
other
operations.
But
if
it's
not
there,
it
can
be
one.
It
can
then
seem
to
be
one.
B
I'm
not
sure
we
should
go
into
these
details
like
there
can
be
many
messaging
operations
which
are
bad.
You
can
settle
messages
as
bad.
You
can
send
messages,
it's
batch
and
I.
Think
in
some
systems
you
can
specify
like
an
empty
array
and
it
will
I,
don't
know
it
might.
Work
like
what
I
want
to
suggest
is
not
a
limit
the
best
only
to
receive
maybe
to
relax
this
and
just
say
any
messaging
batch
operations
should
have
this
attribute.
That's.
A
What
I'm
saying
I'm
saying
that
received
must
have
it,
and
others
should
probably
but
I
I'm,
even
I'm,
tempted
to
say
that
if
it's
not
set
on
other
operations,
it
defaults
to
none.
A
A
But
this
makes
no
sense
right.
If
you
do
this.
This
is
a
bug
you
I,
don't
know
like.
If
I
was
an
SDK
author,
I
would
check
the
array
size
and
throw
if
it's
zero,
because
it's
clearly
a
mistake.
F
B
Yeah
like
like
what
about
other
operations,
I,
don't
know
like,
does
it
how
to
to
have
it
as
a
general
like
whatever
messaging
operation
did.
F
A
So
imagine
I
I
instrument,
an
SDK
and
I
support,
both
batch,
batching
and
non-batching
through
very
similar
apis.
Then
I
do
want
to
skip
batch
size
when
I
deal
with
one
message:
it's
good
in
terms
of
redundancy.
It
doesn't
bring
users
any
value
if
it
always
operates
with
one.
Oh
sorry,
if
sometimes
my
SDK
approach
was
one
message,
and
sometimes
it
operates
as
multiple
messages.
I
mean
what
is
the
value
of
adding
batch
size
on
every
spot,
especially
if
the
specific
user
doesn't
have
any
better.
B
I
think
what
we
discussed
in
the
in
the
past
was
that
batch
is
like
a
semantic
quality
of
the
operation
like
an
operation
can
be
patched
with
one,
and
if
it
was
semantically
called
as
batch,
then
we
still
want
to
capture
the
the
fact
that
it
was
a
badge
right
and
if,
if
the
operation
is
like
a
semantically
always
on
a
single
message,
then
we'd
never
want
to
to
have
it
right.
A
Yeah,
so
my
point
there
at
this
discussion
was
that
it
was
in
our
SD
case.
Well,
we
have
apis
public
apis
to
deal
with
batches
and
single
messages.
It's
like
a
convenience
methods,
but
in
turn
only
they
can
be
the
same,
and
it
would
be
unreasonable
to
ask
us
to
or
anyone
else,
to
instrument
all
all
public
apis
and
never
rely
on
something
common.
They
have
so
I
wish.
A
We
can
we
we
didn't,
ask
something
from
the
instrumentation
which
is
too
hard
to
implement
I,
don't
think
we
can
be
very
prescriptive
and
say
if
user
called
into
an
API
that
supports
a
batching
to
always
populate
batch
sites
and
outside
it's
great
to
be
a
bit
more
relaxed
initially
to
have
a
room
to
make
this
trick
later.
G
I
kind
of
agree
with
a
mirror
that
you
kind
of
want
the
semantics
of
how
what
the
application
called
and
I
guess
in
your
case
with
Miller.
Are
you?
Is
this
internal
when
you
call
a
non-batched
you're
saying
it
it
you're?
The
implementation
calls
are
batched
method
internally.
Is
that
yep
now
is?
Would
it
be
reasonable
to
just
sort
of
make
an
internal
private
method
that
does
this
batching
internally
and
create
an
external
batch?
G
Send
one
and
then
all
public
apis
are
responsible
for
setting
just
batch
size
or
not
setting
it,
and
then
you
can
go
on
and
call
this
internal
private
method
that
that
never
sets
batch
size
because
it
knows
it's.
G
The
the
caller's
responsibility
to
set
that
like
I
I,
know
we're
getting
a
lot
of
implementation
details
here,
but
at
the
same
time,
I'd
hate
to
have
implementation
details
Drive
the
spec,
because
I
do
think
that
if
an
application
called
a
batch
method
that
it
would
be
very
nice
that
the
batch
size
is
always
there,
there's
something's,
always
there
that
indicates
it
was
a
batch
operation.
A
I'm
not
saying
that
it's
something
like
that,
it's
difficult
to
implement
what
I'm
saying
that
it's
a
crazy
amount
of
work
to
be
fair,
like
asking
instrumentation
to
be
refactored
in
order
to
achieve
it.
It's
a
difficult
requirement
and
if
you
like,
don't
worry
about
me,
I
can
figure
it
out,
but
imagine
I
don't
know
Java
by
code
instrumentation.
A
They
need
to
know
in
advance
about
this
internal
Behavior
or
of
all
methods
how
they
work
or
they
need
to
instrument
all
public
methods
and
if
SDK
exposes
some
Handler
of
some
sort,
they
cannot
plug
into
this
and
they
need
to
plug
into
it
or
just
the
public.
A
G
I
I
think
it's
a
little
hardening
to
like
you
know.
It
sounds
like
you're
familiar
with
one
example
where
this
would
be
difficult,
I
mean
in
general,
I
think
this.
Whatever
specification
we
come
up
with,
you
know,
an
implementation
may
require
some
refactoring
to
adhere
to
the
spec
I
I'd,
rather
focus
on
in
terms
of
specification
like
what
what
Behavior
do
we
want
like?
G
A
A
Taxed
I
quoted
it's
the
current
language
that
that
goes
back
to
you.
It
should
set
it
on
celebrations,
but
must
said
the
mercy.
B
E
A
So
I
think
the
links
we
didn't
even
agree,
whether
it's
link
or
it's
event
or
sometimes
one
sometimes
another,
but
I-
try
to
clarify
it
without
links.
A
So,
like
I
I
kind
of
what
we
can
do,
we
can
always
demand
this
attribute
right,
but
then
it
won't
be
possible
to
distinguish
this
case.
I
mean
I
mentioned
that
here's
an
economy
situation
you
can
patch
that
consists
of
one
message
in
either
effects.
A
There
is
no
way
to
distinguish
the
batch
that
this
one
consists
of
one,
and
one
message
is
the
semantic
word,
the
same
thing.
B
Yeah,
but
if
the
function
you're
patching
is
dealing
with
batch,
so
maybe
it's
like
a
lower
level
function.
That
was
like
the
user
called
the
API
for
a
single
message
and
it
translated
into
this
batch
of
one.
But
this
is
the
operation
that
you
are
attacking
right.
So
what
you're
saying
that,
if
you
see
one,
you
assume
that
it
was
a
single
invocation
of
a
single
message
like.
G
A
A
We
should
not
make
require
attributes
to
to
help
users
decide
or
Define
what
API
called
it
and
name
can
be
used
for
it.
This
is
what
we
do
with
quotes
about,
send
messages.
The
configuration
of
understanding.
G
My
my
comment
is
going
to
be
that,
like,
if
I
wrote
a
batching
algorithm
to
achieve
some
efficiency,
because
sending
single
messages
is
expensive
and
I
wanted
to
rely
on
the
captured
Trace
data
to
figure
out
how
good
my
algorithm
was.
I
wanted
to
maybe
find
out
how
many,
how
many
times
did
I
send
single
message.
Batches
or
you
know,
get
some
distribution
of
how
many
messages
I'm
getting
in
a
batch.
G
It
becomes
a
lot
more
difficult
when
that
batch
size
isn't
reliably
there,
because
I
I
may
not
be
able
to
easily
distinguish
spans
where
from
an
application
that
is
using
a
batching
algorithm
versus
from
an
application
that
isn't
using
batching
at
all.
A
I
mean
if
you
can
have
a
default
value
in
your
query,
which
I
hope
you
can.
Then
you
should
be
able
to
query
and
running
their
applications
on
the
patch
sets.
A
By
searching
for
spans
that
have
batch
size
and
it's
more
than
one.
A
I'm
not
sure
how
this
problem
is
yet
really
easier
if
the
batch
starts
difficult
to
is,
is
set
even
if
it's
one
I.
B
It's
a
batch
API
and
it
gives
it
all
sides
of
measures,
so
it
looks
on
a
lot
of
spends
and
some
of
them
has
this
attribute,
and
some
of
them
lack
this
out
of
it
right,
because
what
the
instrumentation
will
do
it
we'll
check
if
the
batch
size
is
one,
then
it
will
not
populate
this
article.
B
F
B
The
instrumentation
doesn't
capture
it
or
because
it's
simply
always
called
with
one
and,
like
you
have
to
start.
Ask
yourself
some
questions.
Is
it
not
there
because
of
this
or
because
of
this
or
like,
if
we
say
like
whenever
it's
a
batch,
we
capture
it
and
everything
becomes
a
lot
simpler.
At
least
that's
my
opinion.
A
B
You're
all
talking
about
a
specific
example
right,
but
in
the
instrumentations
I
know,
I
know
if
the
function
is
batched
or
not.
Batched,
like
I
I,
know
which
function
I'm
patching
so
I'm
able
to
produce
this
information.
What
you're
describing
is
that
maybe
the
maybe
like
the
your
patching,
a
lower
level
function,
which
is
always
operates
on
batches
and
then
you're
not
able
to
tell
if,
if
it
was
invoked
with
one
message
you
can
tell
if
the
API
was
invoked
on
on
a
batch
of
one
or
a
single
message,
Api
right.
F
B
So
yeah
so
so
at
least
like
I
I,
think
the
spec
should
not
try
to
optimize
such
scenarios
because.
A
B
Unless
it's
one
then
like
I,
imagine
people
looking
at
Spence
that
came
from
the
same
invocation
and
the
database
doesn't
always
look
the
same
and
I
think
it's
a
bad
experience,
at
least
in
my
opinion,
but
but
having
said
that,
I
I
don't
really
like.
If,
if
you're
very
strong
on
this
side,
I'm
okay
with
it.
A
But
let's
try
to
find
out
the
words
that
would
work
for
that
could
satisfy
you
and
that
would
be
possible
for
me.
So
instrumentation
should
start
messaging
batch
sites
for
all
operations
right.
E
B
A
Clarify
received
her
name,
so
I
am
receiving
end
messages,
so
my
apis
to
receive
messages
looks
like
what
it
means
try
to
receive
and
messages.
Let's
say
five
in
ten
seconds
right,
then.
What
if
I
receive
one
should
I
sell
batch
size
or
not.
B
A
A
B
A
B
A
B
Yes,
so
what
I
know
about
the
rabbit
is
that
when
it
has
a
message,
it
notifies
you
that
it
has
a
message
and
it's
always
a
single
message
if
you
cannot
get
like
a
batch
of
messages
right,
so
the
semantic
of
the
received
is
is
single
message
by
definition
like
it
can
tell
you,
I
received
a
message
and
then
you
look
inside
and
you
see
no
messages
like
this
is
the
API
I
know.
Maybe
the
API
in
other
languages
is
is
different.
A
Right
I
will
find
you
a
proof
link,
but
they
can
assure
you
it's
there
and
I
have
several
other
sdks
that
support
this
Behavior.
Even
if
broker
pushes
messages
to
the
SDK
SDK
may
get
the
request
from
user
to
wait
for
more
and
it's
like
for
user.
It
looks
like
give
me
some
messages
receive
messages,
the
users
that
has,
of
course,
sorry
who
selected
but
basically
behavior,
is
complicated.
G
It
just
is
a
data
point
that,
like
the
Solace
apis
all
deal
with
single
messages,
there's
no
concept
of
batches
I,
I,
yeah
and
I
I
have
to
think
that
single
message
apis
are
somewhat
common.
I
realize
batches
are
as
well,
but
I
think
we
need
to
consider
that
there
is.
There
is
conceptually
a
difference
of
receiving
a
message
with
an
API
that
only
supports
single
messages
and
and
then
batches
as
well.
A
Okay,
then
we
can
I
think
there
is
this
part
somewhere
in
the
language.
I
will
check
with
there
that
if
SDK
supports
batching
said
batch.saturated
right,
so
if
it
doesn't
support,
maybe
we
can
make
it
clear
that
if
SDK
does
not
support
batching
of
any
sorts,
let's
not
send
batch
and
contribute
at
all
right
should
I
receive
zero
cases.
Important,
though
maybe
we
should
use
different
attribute
for
this.
How
do
people
know
that?
Okay,
you
are
the
SDK
that
does
not
support
batching.
G
Well,
I
I
think
that's
not
uncommon.
I
think
JMS
has
like
you
can
ask
you,
can
synchronously
call
a
receive
method
with
a
timeout
and
if
the-
and,
if
that
times
out,
you
receive
no
message
so
I
I
do
think
even
single
message.
Apis
the
synchronous
ones
would
have
that
concept
of
receiving
no
messages,
but
I,
don't
I'm,
not
sure
what
but
I
I
don't
know
what
it
would
have
span
without
any
message
attributes
Express
that
well
or
is
that
not
a
good
way
to
express
it.
A
Well,
I
mean
it
can
also
have
a
timeout
or
some
state
is
indicating
right
that
the
timeout
has
happened,
but
is.
F
A
Clear
indication,
maybe
I,
requested
10
messages
and
received
one.
Is
it
the
timeout
or
not?
Maybe
in
some
system
it
doesn't
came
out,
so
maybe
we
can
do
the
following.
It
sounds
like
we
don't
have
a
good
way
to
represent.
I
got
nothing,
but
users
can
rely
upon
the
lack
of
messaging
attribute
message.
Attributes
doesn't
indicate
nothing
was
received
right.
Maybe
we
can.
We
need
to
think
about
some
other
way,
and
maybe
it
doesn't
have
to
be
in
this
in
the
current
PR.
It
can
it's
an
addition.
B
Yeah
I
really
support
in
in
aligning
this
attribute
with
the
semantic
question
operation.
So
if
it's
you're
asking
for
one
message
and
you've
got
nothing,
so
the
semantic
is
for
one
message,
so
I
think
we
should
not
say
to
this
attribute
in
this
case.
Okay,.
A
So
then,
what
should
I
write
here
is,
should
right
for
all
cases
and
should
distinguish,
should
okay
shoot
for
any
batching
operation,
regardless
of
the
size
and
should
not
or
non-batching
operations.
A
Yes,
this
part,
this
is
what
you're
really
pushing
for.
B
C
A
I
think
most
of
the
questions
here,
other
than
that,
if
I
remember
correctly,
are
pretty
minor
and
we
can
take
them
offline.
There
was
one
question
that
we
can
probably
tackle
in
the
rest
for
a
minute,
so
there
is
a
duplication
for
per
message
attributes
they
are
in
the
table
that
describes
per
message
attributes
and
their
reference
them
into
spans.
Right,
so
I
want
to
explain
the
series
two
questions
from
the
different
people,
so
we
need
to
have
a
way
to
save
you.
A
A
A
B
I,
just
think
think
that,
as
a
like,
a
person
who
is
leading
the
markdown,
it's
very
confusing
to
have
the
same
attribute
in
multiple
locations
and
so
I'm
not
sure
about
the
technical
issues
with
the
yamla
I
didn't
catch
all
of
what
you
said,
but
also,
if
it's
possible
like
if
it,
if
it's
too
complicated,
then
it's
not
the
end
of
the
world
right.
A
B
Yeah
that
that
sounds
good
to
me
and
like
I
I,
have
one
other
important
issue.
I,
don't
know
where
we're
almost
out
of
time.
It
do
you
maybe
want
to
discuss
it
now
or
do
it
on
the
issue
or
next
week.
B
So
I
think
calendar
and
I
didn't
read
your
comments
for
me
yesterday,
I
I
should
read
them
offline
after,
but
what
I
want
to
suggest
is
that
on
every
single
span
we
can
either
have
like
a
batch
attributes
or
the
message
attributes,
but
not
both
of
them
together.
So
I
think
the
summer
awarding
there
that,
if
all
messages
have
the
same
value,
then
we
can
use
like
a
message
attribute
for
the
batch
right.
Yeah.
A
I
fixed
it
for
the
most
of
the
things
that
you
read
that
for
a
master
of
them
it
doesn't
make
sense,
but
if
in
conversation,
ideas
and
destination
name
and
Source
name
are
ones
that
can
be,
can
have
all
this.
The
same
value
on
the
batch.
F
E
B
It
but
I
think
that,
like
mentally
to
see
this,
the
attributes
for
both
batch
and
message
in
the
same
attribute
Silo
it
can
be
confusing
and
if
it's
only
for
conversation,
ID
I
want
to
rethink.
If
maybe
we
should
simplify
the
spec
and
not
allow
it.
So
we
said
that
if
it's
a
batch,
then
the
batch
attribute
should
be
there.
If
it's
a
single
message
semantic,
then
the
single
message
attribute
should
be
there,
but
I
think
it
can
be
confusing
to
users
to
mix
them
well.
A
All
right,
yeah,
I,
think
I
have
time,
but
I
we
have
other
people
here
and
I
wish
that
they
were
on
their
own
drumsticks.
Okay,
so
I
I
think
that
we
should
have
this.
What
we
agreed
today
is
important
that
we
have
two
different
semantics
single
message
and
batch
symmetics
right
and
for
single
message:
semantics.
We
should
expect
all
attributes
to
Beyond
stats
for
batch
semantics.
Where
I
mean
we
don't
even
need
to
tackle
this
right
now
right,
but
what
it
means
that
we
either
need
to
describe
them
separately
right.
A
G
G
I'll
I
might
set
a
correlation
ID
on
the
message
and
expect
the
response
for
that
request
to
include
that
correlation,
ID
and
so
I've
asynchronously
sent
10
messages
out
and
I
start
getting
messages
back
and
so
I
want
to
know
which,
which
message
is
this
related
to
and
then
I'll
look
up
the
correlation,
ID
and
say?
Oh,
it
responds
to
this
message
and
I'll
process
it
in
a
certain
way.
That's
what
it's
for.
B
Yeah
but
then,
if
you,
if
you
get
like
a
batch
of
messages
and
by
some
chance,
all
of
them
have
have
the
same
correlation
ID,
then,
is
it
so
important
that
we
can
like
use
it
in
this
attribute,
instead
of
repeating
it
for
each
message
like
I?
Don't
do
you
think
it's
common
to
to
even
get
a
batch
of
messages?
G
I
personally
have
no
experience
with
with
that,
so
I
I
could
I
can't
personally
say
how
common
or
uncommon
that
would
be
the
the
case.
We're
actually
going
to
use
most
often
is
in
sort
of
a
single
request.
Reply
scenario
there,
but
that's
not
to
say
that's
the
only
use
case
for
sure,
but
that's
that's
what
I've
seen
it
commonly
used
for.
B
B
Things
in
the
messaging
namespace
represents
a
single
message
and
I.
Think
like
going
an
extra
step
and
saying
if,
by
chance
an
attribute
that
represents
a
single
message
is
the
same
for
all
messages
in
a
batch.
Then
we
can
use
it.
Then
it
might
help
in
in,
like,
in
my
opinion,
a
very
small
amount
of
cases,
but
I
think
it
will
create
the
additional
a
mental
overhead
of
having
the
same,
like
name,
space
of
batch
and
single
message
in
the
same
Aspen
and
I.
A
Well,
I
think
that
if
you
are
sending
a
batch
of
messages
that
are
very
likely,
you
are
using
something
in
common
for
them,
and
it
could
be
that
they
are
the
same,
but
it
feels
to
me
that
for
the
things
we
are
not
fully
sure
about,
we
cannot
specify
them.
We
can't
keep
them
as
bad
as
possible
until
there
is
a
case
and
when
there
is
a
case
where
it
can
make
the
requirement
more
strict
right.
B
So
so,
in
my
opinion,
if,
if
something
is
common
to
a
lot
of
messages,
then
it
shouldn't
go
into
the
message
namespace.
So,
for
example,
a
destination
name
is
something
that
is
very
likely
to
be
common
toward
to
the
entire
batch.
But
a
message
payload
size
is
very
likely
to
be
unique
per
message
and
message.
Id
is
very
likely
to
be
unique
to
our
message
and
I
think
the
silo
of
of
like
The
namespace
Silo.
B
The
messages
message
namespace
should
indicate
things
that
are
unique
per
message,
and
and
that's
why
it
doesn't
make
sense
to
me
like
logically,
to
have
both
messaging
dot
batch
and
Method
messaging
Dot
message
on
the
same
spin,
but
I'm
open
to
be
convinced.
Otherwise,
if
you
think
correlation
ID
is,
is
very
likely
to
be
the
same
for
a
then.
Maybe
it's
not
there
should
shouldn't
be
on
the
message.
Namespace.
A
A
It's
typical
to
deal
with
correlation
and
deep
on
message,
so
maybe
we
it.
It
belongs
to
message
namespace,
because
the
message
namespace
describes
per
message:
attributes
if
you're
worried
that
okay
give
me
a
second
so
that
we
allow
it
to
be
on
the
different
things.
So
maybe
we
can
have
the
following
language
that
correlation
conversation
ID
appears
on
the
span
for
a
single
message:
semantics
right.
A
It
always
appear
on
links
for
batching
scenarios,
but
it's
recommended
so
the
instrumentations
that
are
worried
about
flooding
like
the
deal
with
hundreds
of
messages
in
a
batch.
They
can
cut
the
requirement
level
to
require
trade
for
the
per
message
attributes,
foreign.
B
Yeah
yeah:
that's
what
I
wanted
to
suggest.
So
if
we
get
a
batch
of
messages
and
they
each
have
a
correlation
ID
and
by
chance
they
all
have
the
same
correlation,
ID
or
or
by
Design,
they
all
have
the
same
correlation
ID.
So
I
want
to
suggest
to
to
record
it
on
the
link
so
like
on
the
same
level
of
the
like
I,
don't
know
like
the
message:
Dot
messaging.message.id
and
messaging
Dot
message:
dot
payload
size.
Well,
we
store
these
attributes.
We
will
also
store
the
correlation
ID,
even
if
it
repeats
itself
that
way.
B
So
we
know
that
that
these
these
attributes
cannot
live
together
because
it
might
be
confusing
and
I.
Think
it's
a
it's
a
it's
not
that
nice
to
see
as
such
spans
does.
It
make
sense.
Yeah.
B
You
comfortable
with
this
with
this
option,
or
do
you
disagree
with
it.
A
A
Yeah
I
will
need
to
experiment
with
it.
I
don't
think
it's
visible
to
implement
and
what
I
hear
from
people
around
that
it's
extremely
hard
to
follow
this
nitty-gritty
details
and
and
open
Telemetry
space,
and
if
I
don't
test
it,
if
I
don't
hand
hold
it
all
possible,
Edge
Keys,
then
there
is
no
way
I
can
guarantee.
Following
this
distinction.
B
Yeah
I
understand
your
concern:
I
I,
don't
have
a
good
answer.
I
think
it's
like
whatever
we
decide,
there's
gonna
be
like
a
a
case
where
it
will
make
the
the
instrumentation
data
less
accurate.
A
Yeah
so
let's
start
with
something
clear
and
simple:
I
have
to
go.
Thank
you
for
the
conversation.
B
B
So
so
I
will
review
the
open
comments
and
I
will
solve
the
ones
that
are
not
relevant
anymore
and
I
will
comment
on
those.
They
still
want
to
talk
about
and
then
and
I
hope
that
during
this
week,
maybe
we
can
pull
it
out
of
the
raft
and
and
start
reviews.