►
From YouTube: 2022-09-01 meeting
Description
Instrumentation: Messaging
A
B
A
A
I
added
this.
These
two
items
to
the
agenda,
so
one
is
my
pr
that
is
open.
There's
a
few.
I
think
there's
a
few
comments
that
we
still
need
to
resolve.
I
I
replied
to
to
them.
So
if
you,
if
you
folks,
can
take
a
look
and
see
if
it
helped
clear
anything,
so
we
can
so
I
can
resolve
the
comments.
A
A
Yes-
and
I
added
the
pr
from
ludamila
about
that
there's-
there
is
a
discussion
there
about
about
the
single
single
message
case
and,
if
we
add
attributes
so
if
we
use
links
in
in
a
sec
in
a
single
message
case
and
if
so,
how
to
add
attributes-
and
things
like
that,
so
I
I
put
it
here
because
there
was
a
comment,
so
I
think
we
reached
a
point
in
the
discussion
that
wasn't
getting
to
anywhere.
It
wasn't
going
nowhere.
So
I
I.
A
A
Yeah,
so
I
I
licked
the
pr,
because
there
was
this
discussion
here
about
the
about-
if
we
should
use
a
link
for
a
single
message
scenario
or
not,
and
so
amir
started
a
discussion
about
yeah,
but
for
batches.
We
will
have
things
so
we
have
links
and
so
on,
but
and
if
we
should
always
use
that
to
make
it
consistent
for
instrumentation.
A
So
I
guess
we
need
to
discuss
now
how
we
go
forward
with
this
and
I'm
not
sure
and
if
we
should
continue
or
like
if
we
should
clearly
start
working
or
focus
on
only
single
message
for
now
and
clear,
because
I
think
we
come
back
to
this
and
back
and
forth
and
we
didn't
like
solidify
the
the
decisions
on
single
message
or
maybe
we
did.
But
I'm
lost.
C
Yes,
so
my
concern
is,
for
example,
rabbit
is
mostly
used
to
like
you
cannot
send
a
batch
of
messages
with
rabbit
and
you
it's
not
recommended
to
consume
it
in
the
way
that
you
consume
more
than
one.
C
So
rabbit
is
basically
the
single
case
scenario
and
putting
instrumentation
needs
first
before
user
needs
seems
strange,
so
reddit
users
at
least,
would
want
probably
to
have
their
message,
attributes
stamped
on
the
publish
and
receive
spams
right,
and
if
we
allow
this
for
a
bit
right,
we
should
probably
say
that
it's
allowed
for
every
other
system
and
it's
the
trade-off
between
instrumentation
simplicity
and
user
convenience,
and
I
would
give
you
the
convenience
here.
A
I
also
agree
with
this
I
think
yeah
in.
In
probably
several
cases
there
will
be
just
single
and
simple
things
and
I
understand
at
the
point
to
make
it
consistent
and
so
on,
but
maybe
it's
not
a
bad
thing
to
have
it
also
somewhat
duplicated
or
different
because
will
yeah-
and
I
don't
know
if
it's
in
this
comment
or
somewhere
else,
part
of
the
review
here-
someone
someone
else
comments,
but
I
think
I
read
that
so
that
it
was.
A
I
think
it
was
important
as
well
talking
about
like
if
we
do
this,
are
we
basically
making
the
current
specification
unusable
or
unimplementable
because
or
not
unusable,
because
maybe
all
of
the
backends
are
most
of
the
backends
that
people
are
using
those
support
links
so
and
if
they
have
the
single
message
case,
they
won't
stop
having
or
not
having
what
they
have
already
currently.
A
D
Yeah,
I
think
that
for
sure
we
should
not
have
forbidden
this,
so
if
an
instrumentation
wants
to
do
it,
so
it
should
be
allowed,
in
my
opinion
at
least-
and
I
don't
think
as
well-
that
it
should
be
required.
So
I
think
we
should
allow
both
cases
to
to
set
it
both
as
a
parent
of
the
consumer
and
this
link,
I
just
want
to
add
that
sometimes
like
relying
on
on
a
spend
to
have
a
parent.
That
means
something
I
think
it's
a
bit
fragile.
It
can
get
messy,
really
really
quick.
D
So
I.
D
D
C
Yeah,
I
I
I
agree
what
what
I'm
saying.
Let's
agree
on
certain
things.
We
can
document
them
right
like
regarding
this
pr.
I
just
want
to
keep
the
bar
very
low,
just
a
small
addition
to
the
current
spec.
Then
we
can
add
things
about
links
and
clarify
them
better,
but
I
think
even
for
the
single
case,
we
should
be
a
bit
more
prescriptive.
D
C
D
C
Yeah
but
let's,
let's
just
focus
on
the
attributes
for
a
moment,
we
will
change
it
in
the
current
spec.
The
current
spec
is
wrong,
we'll
change
it,
but
if
we
focus
on
attributes
for
the
single
case,
can
we
say
that
instrumentations
should
not
must
but
should
stamp
their
attributes
on
spams
rather
than
links,
and
for
the
batching
case?
A
Yeah,
I
think
that
that
is,
that
is
fair,
like
I
think
we
were
just
considering
putting
the
attributes
on
on
the
links
for
a
single
case
to
be
consistent
with
the
batch
right.
A
But
I
assume
like
as
a
user,
the
batching
scenario
or
a
batching
trace.
It
would
be
different
from
anyway
from
a
single
message
scenario.
So
if
I
in
my
system,
I
have
both
things,
I
probably
I'm
already
like
familiar
with
they
being
different
and
it's
okay
and
first,
for
the
sake
of
simplicity,
just
to
make
sure
that
it's
the
same.
I
I'm
not
sure
if
it's,
if
it's
worth
it
yeah.
That's
one
of
the
things
that
I
that
I
thought
about
here
like
it's
easy
for
the
instrumentation.
It's
consistent!
A
It's
consistent
for
the
way
the
backend
will
do.
Okay,
yeah!
But
if
I'm
reading,
for
example,
this
like,
if
I'm
opening
a
backhand
and
to
read
the
message
things,
I
have
to
click
and
navigate
and
maybe
expand
the
link
or
something
or
something
like
that,
it's
it's
all
theoretical
and
it
doesn't
really
to
open
climate
change
because
it's
ui
and
there's
nothing
to
do
with
us.
But
maybe
we
should
think
about
it,
put
the
limit
to
the
middle
settings.
A
I
think
I
agree
and
there's
also
things
from
cost
right
but
like
if
we
have
this
ban
the
receive
span-
and
we
can
add
the
message
attributes
there
to
that
already,
then
why
not
just
do
it
right,
we'll
still
need
the
link
anyway,
but.
D
So
if
it's
a
single
like
rabbit,
if
it's
only
under
the
single
message
for
which
spend,
then
I
think,
but
if
there
was
a
mix,
if
sometimes
you
can
see
a
spell,
for
example,
for
a
I
don't
know
for
sqs.
Sometimes
you
see
the
expands
in
the
one
way,
and
sometimes
it's
in
another
way,
just
because
it's
batch
or
not
matched.
D
I
think
there's
also
value
for
consistency
for
data
that
is
produced
by
the
same
experimentation
library.
D
So
what
I
think
is
best
is
to
just
allow
it
if
people
want
to
to
do
it
and
find
it
yeah
sure
want
to
not
do
it
and
it's
also
fine,
but
I
think
we
should
say
that
both
options
are
as
bad
yeah.
B
Yeah,
I
agree
as
well,
because
I
I
just
think
that
in
the
case
in
the
single
message
case
that
you
know,
as
we
were
talking
about
it,
it's
simpler
to
have
the
attributes
on
the
span,
and
I
think
that
I
I
mean
I
don't
know
exactly
I'm
not
at
back.
I
don't
have
much
experience
the
back
ends
here,
but
I'm
assuming
that
there's
not
going
to
be
much
complexity
involved
in
the
back
ends
like
it's.
B
It's
basically
just
making
information
available
and
searchable,
and
it's
more
likely
that
there's
better
back-end
support
within
a
span
for
now
at
least
so
I
think,
being
able
to
put
it
on
the
span
having
the
option
to
put
it
on
the
span
when
it
makes
sense,
as
in
a
single
message
case,
makes
a
lot
of
sense
to
me.
I
think
there's
a
lot
of
single
message.
B
Messaging
systems
out
there
there's
a
lot
of
batch
based
ones
as
well,
but
I
think
just
making
sure
that
what
we
it's
nice
and
usable
for
the
single
message
cases
makes
sense.
A
And
one
thing
I
was
thinking
when
I
mean
what
we
were
saying
is
that,
for
example,
if
if
it's
a
library
that
that
allows
the
user
to
send
batch
and
single
message
like
the
same
library,
allows
both
cases,
maybe
we
can
write
something
in
a
way
that
says
like.
If
your
library
only
supports
single
message,
then
don't
add
links
like
this
and
if
your
library
supports
either
batches
or
or
single
message,
then
go
in
a
route
of
of
doing
this
way.
A
B
Yeah,
I
know
I
mean
I
I
I
at
the
same
time
as
someone
who
would
use
perhaps
use
a
library
that
could
do
both
if
a
particular
application
or
like
a
particular
user
of
that
library,
only
uses
it
in
one
mode.
Then
it's
still
consistent,
and
so
it
kind
of
comes
down
to
when
you've
got
a
mixture
and
the
same
you
know
domain
that
it's
more
of
a
problem.
I
I
I
I
hate
to
be
too
prescriptive
here
I
mean
I
just
to
me,
but
I
think
we.
A
Should
still
have
like
clear
recommendations
right
like
if
you're
doing
like
the,
if
you're
only
dealing
with
single
message,
then
it's
recommended
to
follow
this
bad,
because
it's
economic,
because
it's
it's
simple
blah
blah
and
for
the
matching
say
if
you're
using
batching
then
go
this
route.
Because
of
this
this
this
right
and
I
think
that
that's
that
should
be
it
right
yeah.
You
can
still
do
whatever.
B
A
A
Can
make
it
consider
that
open,
yeah
yeah
but
but
like
I,
wouldn't
leave
it
open?
For
example,
like
you
can
do
this
or
it
can
do
that
and
not
specify
like
what
is
best
right
or
what
is
what
is.
B
But
I
think
it's
hard
for
us
to
know
what's
best
for
a
mixed
library,
because
it.
C
Maybe
what
we
can
say
is
if
you're,
if
you're,
dealing
with
a
single
message
and
your
library
deals
with
a
single
message,
definitely
like
you,
should
stamp
attributes
and
spend
if
you're
dealing
with
batches
and
your
current
api,
that
user
called
or
you
see
that
it's
a
badge
bigger
than
one
then
definitely
do
attribute
some
links,
and
the
only
case
that
needs
special
handling
is
where
the
batch
size
is
one
right,
and
here
we
can
say
that
you
can
do
either
but
stay
consistent
within
your
instrumentation
library.
B
C
D
My
motivation
is
to
be
as
simple
as
possible
so
not
to
introduce
all
this
branching
in
the
worlding
like
if
things
do
give
something
else
to
something
else,
just
to
allow
both
of
them
and
to
let
them
implement
those
choose
what
they
what's
easier
for
them.
What
makes
more
sense
for
the
use
case,
and
maybe
they
can
never
configure
to
have
it
both
ways?
I
don't
know
just
think
it's
best
to.
C
Okay,
I
mean
we
can
just
try
to
document
it
in
apr
and
then
I'm
sure
there
will
be
a
lot
of
need.
Speaking
from
the
community
on
the
space
anyway,.
A
D
I
think
we
don't
have
to
do
it
as
part
of
this
one.
We
can
let
this
one
get
merged,
and
then
I
have
also
other
points
that
that
we
could
probably
open
and
separate.
Now
for
some
of
them,
you
commented
there
already.
A
Once
we
go
to
the
comments
I
didn't
just,
let
mostly
needs,
but
then
we
can
approve
and
get
them
get
emerged
or
at
least
on
our
side.
We
can
have
the
approvals
and.
A
Right
but
I
think
in
general
this
makes
sense,
and
I
also
agree
with
you
think
that
you
said
about
the
name
spacing
here.
So
I
think
it
looks
all
looks
well.
B
So
unfortunately,
I
just
haven't
had
a
chance
to
take
a
look
at
this
one
yet,
but
the
the
one
thing
that
I
was
wondering
about
is
sort
of
the
rationale
of
excluding
certain
values
and
why
some
were
included
and
I'm
not
like,
as
just
as
an
example
and
like
I
said,
I
haven't
looked
carefully
but
conversation
id
is
something
that
is
very
often
used
in
combination
with
a
reply
to
like,
in
a
request,
reply
messaging
pattern.
B
The
guy,
who
sent
the
request
to
know
which
request
this
response
correlates
to
so
inclusion
of
conversation
id
without
reply
to
was,
and
maybe
there's
other
uses
of
conversation
id.
But
this
is
where
I
think
we
need
to
explain
what
the
purposes
of
these
attributes
are
and
make
sure
that
you
know
we're
not
that
they're
all
coherent
and
we're
not
missing
any
that
we
should
have
in
here.
C
Yeah,
don't
I
agree,
and
we
should
put
it
the
downward
list
of
things
we
do
before,
like.
Maybe
we
need
to
create
an
issue
or
a
market,
it's
in
some
backlogs,
so
this
pr,
so
don't
think
about
it
as
as
a
something
that
that
brings
a
lot
of
value.
It's
the
way
to
do
a
micro
change
in
the
current
spec.
So
what
I've
done?
C
I
didn't
change
anything
in
the
current
spec,
except
for
shuffling
things
around
once
we
clarify
the
reply
to
scenario,
a
great
super
important
to
clarify,
even
for
my
sdks
that
I
own.
We
can
add
this
attribute
at
any
moment
after
we
won
before
we
won
but
agree.
It's
important.
It
does
not
like
add
in
another
thing,
would
explain
this
work
because
we
will
need
to
explain
all
of
this
to
the
community
and
do
a
bunch
of
other
things.
C
B
C
Yeah,
I
didn't
yet
change
how
it's
defined
in
the
current
stack.
Give
me
a
second.
I
will
open
it
and
read.
A
It
you
know
the
the
the
pr
that
that
blue
domino
open
here
is
just
to
split
or
to
create
a
separation
between
the
attributes
that
we
believe
they
they
belong
to
a
message
specific
and
and
so
that
it
highlights
and
change
the
name
spacing
of
it.
So
like
it
didn't
change
any
the
existing
semantics
or
or
meaning
of
anything
which,
just
simply
added
like
a
message.
Dot
namespace
to
attributes
that
are
are
pertaining
to
a
single
message.
A
B
Okay,
I
have
to
take
a
closer
look.
I
think
I
kind
of
misunderstood
some
intent
here
and
I
apologize
that
I
haven't
had
a
chance
to
look
yet
so
I
will
make
sure
I
I
do
this
week.
Hopefully
tomorrow
yeah.
A
Yeah
but
the
idea
is
like
that
is
just
to
to
set
the
stage
for
having
attributes
on
a
message.
So
we
know
when
we
get
to
the
like,
add
attributes
to
the
link.
Then
we
know
like
which
attributes
we
are
referring
to
and
then
we
and
and
bluetomina
decided
to
to
open
this
and
and
yeah.
B
A
C
Oh,
I
think
there
is
another
open
conversation
there
regarding
links
versus
events,
and
if
we
want
to
be
prescriptive
about
how
do
we
show
different
messages?
Do
you
guys
want
to
talk
about
it.
A
A
Do
yeah
so
if
there's
no
context,
we
have
the
idea
of
having
no
op
context
or
invalid
context,
something
like
that.
But
apparently
we
don't
have
that
in
all
languages.
I
think
and
then
christian
suggested
the
event
right.
If
I
got
it,
if
I
remember,
I
read
it
yesterday:
yes,.
C
D
Yeah,
I
think
it's
only
removing
an
if,
somewhere
that
this
allows
it.
We
just
have
to
convince
people
that
it
makes
sense.
C
Yeah,
so
let's
try
to
do
it
so
maybe
after
this
one
is
finalized,
maybe
I
can
draft
another
one
and
say
that
be
more
prescriptive,
saying:
okay,
you
should
have
links
you
should
have
links
on
receive.
You
should
have
links
on
process.
You
should
have
links
on
send.
B
C
C
Thank
you.
So
I
think
that
the
interesting
part
about
events
that
we
cannot
add
links
before.
Oh
sorry
after
spawn
starts,
but
we
can
add
events.
So
I'm
just
going
to
throw
an
idea
here
and
I'm
gonna
go.
I
mean
I
don't
think
we
are
going
to
work
on
it,
but
I
want
to
throw
it
anyway.
What
if
links
are
just
a
special
kind
of
event
and
we
will
need
to
add
context
to
events
and
then
events
can
be
used
consistently.
C
D
C
They
need
events
outside
of
span
api,
and
such
events
would
have
to
have
context
anyway,
but
I
don't
know
how
it
will
happen.
A
A
A
C
A
C
A
So
the
idea
is
to
consider
events
instead
of
links
right
and
then
enter
a
context
for
the
events,
because
the
events
can
be
added
before
on
the
spin.
C
Why
I
think
it
can
be
useful
because,
historically,
when
we've
tried
to
apply
this
link
link
scenario
to
very
highly
badged
services,
what
we
found
that,
sometimes
you
don't
even
know
the
relationships
about
between
two
spans
until
they
finish
so
they're
already
gone,
and
then
you
discover
they
were
related
somehow
and
there
we
thought
like
it's,
it
wasn't
our
some
internal
project.
C
They
measured
that
we
probably
need
links
as
a
separate
event
that
that
can
just
connect
to
things
at
any
moment
and
then
it
also
when
we
evaluated
it
on
the
back
end,
we
thought
that,
having
links
as
a
separate,
something
on
the
back
end
would
be
more
useful.
It
will
simplify
clearing
and
with
attributes
present,
it's
like
a
special
entry
somewhere
anyway.
B
I
I
do
wonder
if,
like
not
being
able
to
add
links
after
span
started,
is
always
you
know
kind
of
seemed
wrong
to
me.
My
understanding
is
that
the
background,
for
that
is
something
to
do
with
sampling.
I
don't
understand
the
details,
but,
but
I
presume
it
it
messes
up,
if
you
can
add
lincoln
after
the
spam
started,
somehow
messes
up,
maybe
sampling
decisions
or
something
like
this.
B
But
is
there
a
way
to
tell
like
what
okay,
this
link
wouldn't
affect
a
sampling
decision
and
then
allow
it
or
not
allow
it
or
something
like
that
based
on
if
it,
if
it
is
a
problem
or
not,
or
it
seems
like
overbearing
to
say
you
can
never
add
a
link
after
a
span,
a
link's,
just
a
relationship
and
and
like
lemieux
saying
why
can't
you
decide
after
span
started
that
oh
there's
a
relationship
here,
I
don't
understand
that.
D
It's
very
useful
to
prevent
loops.
So
if
you
follow
a
links
and
then
you
added
after
a
spanish
creator,
you
can
find
yourself
in
an
infinite
loop,
yeah.
B
That's
what
you
mean
yeah,
I
I
guess
if
we
added
the
concept
of
basically
a
link
to
an
event
like
a
context
within
an
advanced,
then
that
now
you're
opening
the
door
to
that
kind
of
thing.
If
it's
something
that
back
ends
are
going
to
interpret
and
try
to
let
you
follow
as
a
link.
D
A
B
C
And
I
guess
this:
this
is
a
thing
that
will
take
a
while
to
agree
upon,
and
I
think
there
are
two
questions,
the
first
one.
What
what
is
the
ideal
outcome
we
would
like-
and
this
is
ability
to
add
links
wherever
they
are
after
spend
starts,
but
in
the
current
moment.
So
I
want
to
try
this
just
doing
this
small
incremental
steps
to
the
current
stack.
C
If
you
guys
don't
mind
and
see
how
far
we
can
go
with
just
this
approach
and
then,
if
we
try
to
make
current
spec
a
little
bit
more
usable
and
say
that
okay
use
links,
maybe
later
on
we'll
we'll
figure
out
the
story
for
links,
maybe
they
will
transform
into
this
events
somehow
because
well,
why
not?
C
C
A
We
don't
know
like
it's
hard,
because
we
don't
know,
for
example,
if,
if
we
manage
to
have
the
the
links
to
be
added
after
creation,
I
think
we
only
need
for
one
case
or.
C
A
Yeah
for
for
one
of
the
receive
side
cases,
if
the
remember
if
it's
push
or
pull
but
yeah,
it
doesn't
matter,
but
I
remember
that
we
needed
this
for
one
case
right.
So
what
I'm?
What
I'm
feeling
is
that,
for
example,
we
do
all
this
work,
we
the
final
days
we
talk
about
attributes
on
links
and
so
on
so
on,
and
then
we
get.
A
Roadblock
that
that,
because
of
a
lot
of
reasons,
links
are
not
not
able
to
be
created
after
spain
creation,
then
then,
what
we
just
throw
all
the
word
that
we
did
right
and
then
you
also
see
that
way
or
no.
C
So
I'm
thinking
about
multiple
things,
the
first
one
is:
if
we
hit
this
roadblock
right,
then
we
should
pursue
events,
and
then
we
should
just
convert
those
links
to
events
and
add
the
context
to
an
event
unless
it's
already
there
by
the
time
so
think
about
the
current
event
api
on
spam.
So
you
can
add
event
on
spam
right.
C
So
what
ramsey
is
going
to
do?
They're
going
to
evolve
this
story
into
independent
event
right,
so
they
will
be
producing
the
same
thing
on
their
knees.
So
if
we
hit
this
roadblock
with
links-
and
we
have
a
workaround-
we
can
say
fake
the
start
time
on
the
span
write
that
link
start
the
span
after.
There
is
problems
with
that,
but
I
mean
we're
doing
what
we
can
okay,
so
we
can
later
on
think
about
the
stories
how
we
can
represent
links
as
something
else
on
the
wire.
C
C
If
it's
like
an
event
and
then
yeah
you
can
the
open
telemetry
sdk
can
then
represent
it
differently
over
the
wire,
which
would
look
like
an
event
and
while
also,
I
think
we
don't
have
enough
with
links
now
and
maybe
we
should
get
it
to
links.
Maybe
links
should
not
be
a
separate
api,
maybe
it's
an
event
api,
but
anyway.
So
what
we
don't
have
is
the
name
or
the
type
or
some
structure
that
will
tell
us.
This
is
a
messaging
link
and
not
some
other
link.
C
Somebody
added
randomly
for
a
different
scenario
right,
so
we
don't
have
like.
We
have
attributes
on
links,
but
that's
it.
There
is
nothing
defined
to
represented
type
some
generic
attribute.
I'm
sorry,
I'm
just
thinking
as
I
speak.
So
it's
confusing.
D
So
what
I
suggested
in
my
document
from
last
week
is
that
the
present
of
a
messaging.message.something
attribute
means
that
it's
a
link
that
represents
a
single
message
and
then
everything
is
defined
at
the
well
and
oh,
oh,
we
talked
about
having
like
a
required
attribute.
It
must
be
set
on
this
link
to
the
note
that
this
is
a
single
message,
link.
C
The
message
attributes
are
not
necessarily
available
all
the
time,
at
least
on
producers,
so
we
need
to
come
up
with
some
heuristic.
That
will
tell
us
this.
D
Yeah,
that's
why
originally,
I
suggested
to
add
an
attribute
like
a
void,
attribute
that
you
can
just
edit
okay,
the
value
is
not
important,
but
you
can
edit,
if
you
want
to
mark
this
delete
or
spam
as
a
single
message.
If
nothing
else
works
for
you
like,
if
you
don't
have
a
message
id
or
where
something
else
in
the
messaging
namespace
in
the
message,
namespace
and
just
to
add
something
that
you
can
put
there.
A
D
A
A
A
I
think
I
like
this
idea
that
is
trying
to
push
that
we
have
small
things
and
to
solve
small
problems
and
move
on
with
things
instead
of
going
on
to
on
long
discussions
like,
for
example,
this
case
I
think
the
attribute
makes
sense,
and
then
we
can
just
open
up
vr
and
edit
to
do
existing.
We
don't
have
to
finish
the
whole
tab
to
add
it.
A
C
D
For
maybe
redis
pub
sub,
so
it's
very,
very,
very
simple:
they
don't
have
ideas
as
far
as
I'm
aware,
so
you
still.
C
Yeah,
it
should
agree
first
on
the
lynx
pass
like,
should
they
clarify
in
this
current
spec
that
we
are
using
links
and
not
events,
even
if
there
is
no
context.
C
Yeah
and
like
it
doesn't
even
mention
anything
about
links
on
the
sand,
which
we
can
add
incrementally
again,
we
don't
need
to
require
context
per
message.
D
C
C
Anyway,
so
let's,
let's
clarify
this,
let
me
try
was
links.
I
will
send
another
small
pr
for
just
links.
Well
I'll
have
a
chance
to
discuss
it
before
I
undrafted,
so
we
have
some
consensus
there.
If
you
like
it
and
okay
and
the
next
thing
we
can
do,
we
can
add
an
attribute
that
appears
either
on
link
on
or
a
spell.
That
indicates
that
there's
a
span
that
describes
a
message.
D
D
Yeah,
I
don't
know,
I
don't
have
like
something
in
my
head,
but
I
assume
that
sometimes
maybe
you
don't
know
how
many
messages
are
involved,
but
you
know
that
it's
a
like.
You
know.
C
C
D
Yeah,
because,
just
when
you
process
it
and
you
want
to
like
classify
it,
you
know
you
want
to
know
if
it's
a
batch
or
not.
C
A
C
C
If,
if
there
is
a
pushback,
we
will
remove
it
we'll
say:
okay,
will
you
add
links
only
if
you
have
a
context
per
message
right
or
yeah
prepare
each
message
you
have
contacts
for
and
we
will
push
for
invalid
context
further,
and
this
way
we
can
still
make
progress
and
not
get
blocked.
D
And
then
we'll
open
a
piano
that
says
that
each
message
can
be
represented.
It's
linked
at
most
once
right,.
A
A
All
right,
I
just
loaded
down
this,
so
we
have
a
brain,
tumor
yeah
and
I
think
I
think
this
sounds
like
a
plan.
So
we
get
we
push
forward,
don't
go
to
have
this
one
merged
and
also
the
one
that
I
open
for
the
propagation.
I
think
that
also
is
important.
A
And
then
or
work
on
on
open
another
one
for
for
for
clarifying
links
and
introducing
this
thing
that
ludamina,
I
think
that's
a
good
idea
so
and
it's
small
and
doesn't
makes
it
it's
easy
to
review.
So
we
can,
we
can
move
faster.
I
guess
this
way
and
see
what
they
say
about
this
link
with
the
invalid
context.
C
A
Yeah
he
says
he
is
like.
I
don't
think.
Sdk
is
consistent.
Support,
creating
invalid
links
right
now,.
D
A
The
point
that
if
a
link
should
point
to
something
right
so
point
to
a
parent,
so
if
it
doesn't
point
to
parent
it
is
semantically
wrong.
So
it's
which
is
not
that
wrong.
Actually
it's
true
but
yeah,
but
I
think
it's
good
to
push
anyway
and
then
and
if
we
see
like
a
complete
pushback
or
maybe
we
get
more
insights
and
then
we
say:
okay,
this
is
no
way
to
go
so
then,
let's
pursue
other
way,
I
think
think
pro
dropping
or
checking
the
temperature
on
things
like
this.
I
think
it's
better.
B
C
Not
trying,
I
guess,
yeah
one
thing
why
I
really
want
to
try
things
like
that.
I
recently
just
accidentally,
came
and
answered
the
technical
committee
meetings
notes
and
they
seemed
to
have
a
lot
of
requests
from
different
stakes
to
find
a
sponsor
or
a
technical
committee,
and
they
were
like
okay
instrumentation
shake
how
they
are
doing,
and
there
was
a
point
there
they're
making.
They
seem
to
get
stuck
and
we
we
have
no
visibility.
We
don't
produce
something
that
community
can
see
and
like.
C
A
No,
I
I
agree,
I
think
I
think
it's
a
a
change,
a
better
change
of
approach,
doing
like
this,
and
if
it's
complete
completely,
not
good.
So
like
this
way,
this
idea
is
never
makes
sense,
because
it's
also
good
to
to
get
the
feedback
of
other
more
more
experienced
or
more
familiar
with
this
area
that
they
can
tell
us.
A
All
right
yeah,
so
this
was
the
discussion
about
that.
I
think
that's
the
big
one
that
is
still
open
and
the
other
one,
but
other
than
that.
I
think
there's
no
much
else.
C
A
Okay,
so
I
took
took
notes
while
we
were
talking-
and
I
tried
to
summarize
what
we
discussed
a
bit.
So
I
just
tossed
the
idea
here
about
using
events
so
and
not
about
the
different
pr
or
clearing
up
or
making
the
link
solutions
clear
what
else
anything
else
you
want
to
discuss
if
you
have
eight
minutes.
C
C
D
D
C
A
I
think
it's
a
good
idea
to
maybe
build
some
some
sort
of
summary,
so
we
can
debrief
johannes
when
he's
back.
A
B
Think
that
I
think
that
mostly
what
we've
talked
about
since
he's
been
gone
is
largely
how
to
deal
with
batches,
and
I
think
we've
made
a
lot
of
progress
there
and-
and
I
think
a
lot
of
what
we
talked
about
is
covered
quite
nicely
in
in
yeah,
neotep
describing
or
yeah
well,
bloody
mirrors,
written
up
and
then
also
yeah.
Just
the
idea
of
you
know
putting
yeah
it
links
and
all
the
stuff
we've
just
been
talking
about.
I
think
we're
is
really
summing
up
what
we've
discussed.
B
I
don't
know
if
anyone
else
remembers
any
other
significant
topics
we've
talked
about,
but
I
think.
A
We
discussed
a
lot,
the
the
destination
name
or
something
yeah,
but
we
didn't
get.
We
didn't
get
too
far
and
we
didn't
get
to
a
point
where
we
said
now.
We
should
make
this
required
or
not,
but
we
did
discuss
about
it
and
then
we
discussed
about
the
about
the
context
as
well
like
is
it
a
span?
Is
it?
Is
it
a
it's
painless
context
is?
Is
it
something
else
right?
A
So
we
discussed
this
as
well,
but
didn't
get
anywhere
and
we
discussed
the
batches
as
though
yes
a
lot
of
discussing
badge
and
links
and
things
like
this,
but
I
think
this
summarize,
I
guess
somewhat.
I
was
just
thinking
if
it
would
be
good
to
have
some
some
short
statement
or
some
short
group
of
things,
so
he's
he's
doesn't
have
to
read
all
this
in
the
first
day
or
something,
and
he
has
some
idea
like
what
what
have
we
been
working
on?
C
Sure,
okay,
yeah
sure
thank
you
yeah.
By
the
way
we
ended
up
talking
about
the
perma
such
attributes,
specifically
because
of
the
destination
name
right,
so
we
found
out
that
destination
name
could
be
per
message
or
per
batch.
C
At
some
point,
we
should
probably
discuss
how
we
populate
the
destination
name.
Yes
mostly
like,
should
we
duplicate
it
or
probably
not
or
how
backhands
would
find
it
if
it's
not
on
the
on
the
badge
span
right.
A
D
C
Yeah,
but
I
mean
you
you're
at
the
back
end
right,
so
you
receive
a
span.
You
understand
it's
a
messaging
span,
so
the
algorithm
there
you
either
look
for
it
on
the
span
right.
If
it's
the
same
for
all
messages,
why
would
you
publicly
populate
it
on
every
link
right?
So
you
look
there.
If
it's
not
there,
you
fall
back
to
her
message.
Links.
D
A
C
Yeah,
it
should
have
different
names
right,
so
if
it
appears
on
the
batch
span,
should
it
be
messaging.batch.destination
name,
it
should
be
messaging.destination.
D
A
D
Finger
and
one
for
a
badge
and
then
I
think
it
will
make
make
it
difficult
to
post
them
if
there
are
two
attributes.
That
means
the
same
thing.
D
D
C
Okay,
so
if
I
have
any
capacity,
I
will
try
to
play
with
the
destination
name
without
changing
without
name
spaces,
and
it
will
fit
nicely
into
the
current
stock
anyways.
A
Yeah,
I
I
think
it
it
works.
It's
just
this
like.
If
it's
a
bet
then
then
yeah,
then
you
then
you
don't
put
so
if
so,
if
it's
a
badge-
and
you
know
that
it's
not
the
same
or
something
like
that,
then
you
don't
put
there
or
I
I
don't
know
how
that's
this.
This
heuristics
will
be
able
to
find
out
about
this,
but
yeah.