►
From YouTube: 2023-03-09 meeting
Description
Instrumentation: Messaging
A
A
D
B
E
E
A
E
Put
something
here
regarding
on
our
message
board
and
I
would
like
to
propose
that
I
work
on
reorganizing
our
our
board,
the
the
the
the
project
board
a
bit
to
be
closer
to
what
HTTP
does,
because
just
showing
what
the
HTTP
has.
They
just
have
a
list
of
backlogs
where
they
have
issue
for
each
item
that
they're
working
on
and
that
is
necessary
for
stability.
E
So
I
think
they
have
a
pretty
good
overview
of
of
what's
missing,
for
them
to
declare
the
cement
the
semantics
conventions
for
HTTP,
stable
and
yeah.
We
have
this
compound
board
with
several
columns,
which.
E
Sense
in
certain
regards,
but
I
think
it
would.
It
would
benefit
us
if
we
limit
the
scope
of
this
sport
here.
Just
of
this
project
board
trust
to
stability
and
not
have
like
V2
stuff
in
there
too,
and
maybe
have
like
a
flat
view
like
a
HTTP.
Has
it
here
that
only
works
on
issues
and
basically
has
all
the
the
PRS
that
are
relevant
linked
to
issues
here.
E
So
basically,
changes
I
will
propose
here,
just
to
only
work
with
issues
create
issues
for
every
work
item
that
we
deem
is
necessary.
Only
have
the
work
items
on
this
board
that
already
went
for
version.
One
like
for
stability
and
yeah
I
have
the
flat
View
that
we
have
a
list
and
that
lets
us
kind
of
see
our
progress
advanced.
E
Just
wondering
what
do
you
think,
because
if
you're
fine
with
that
then
I
will
I
will
I
will
make
that
change
and
try
to
create
issues
for
all
the
items.
E
Okay,
then
I
will
make
this
change
until
next
week
and
try
to
come
up
with
this
flat.
Word.
E
I
think
that's
also
in
basically
sets
us
up
well
for
timed
and
once
there's
HTTP
stable,
which
maybe
hopefully
happen
soon,
and
then
basically
we
go
to
next
in
line
so
that
we
have
that
we
have
a
good
idea
of
of
what's
missing
and
can
make
better
estimates.
E
Okay,
so
the
next
discussion
point
is
the
destination
and
Source
kind
attributes
here,
Lut
Miller,
put
up
a
PR
of
I
mean
it
started
with
just
allowing
additional
values,
not
just
the
closed
enum
for
this
kind
attributes,
but
then,
based
on
discussions
going
on
in
the
PR
and
also
in
our
group
last
week,
there
are
the
target
was
changed
and
basically
now
the
pr
removes
those
values,
destination,
kind
and
Source
kind
completely.
E
So
just
maybe
we
can
spend
a
few
minutes
chatting
what
that
we
talked
about
last
time,
but
maybe
a
Dwayne
did
some
evaluations
there
and
he
wrote
a
pretty
detailed
comment
on
slack
actually
saying
that
in
some
instances
those
attributes
can
be
valuable,
so
maybe
just
try
to
to
a
line
of
whether
it's
a
group
really
support
support,
removing
those
attributes
altogether.
A
I
think
I'll,
just
summarize
what
I
said
in
slack,
which
is
I,
don't
think
like
I
guess
what
I'm
leaning
towards
is.
That
kind
is
not
the
most
I,
don't
think
it's
the
best
way
to
record
the
information
and
I
think
the
important
piece
of
information
you
get
out
of.
A
It
is
the
messaging
pattern
model
style,
I,
don't
know
which,
which
word
is
best,
but
that
is
being
used
and
that
topic
implies
a
publisher
subscriber
model
and
that
cues
implies
point
to
point
and
I
think
that
information
could
be
useful
to
back
end,
because
you
can
recognize
strange
things
or
maybe
not
strange
but
interesting
things
that
are
going
on
in
a
trace
based
on
the
model
like
if
you
have
a
a
pub
sub
message.
That
goes
nowhere,
that's
kind
of
interesting.
If
you
have
a
point-to-point
one
with
multiple
receive
spans.
A
That's
you
know
somewhat
unusual
and
might
be
a
duplicate
message
candidate,
so
I
think
having
that
information
in
in
the
trace,
perhaps
not
as
a
source
for
destination.com,
but
it's
naturally
the
message
in
terms
of
the
the
messaging
model
or
messaging
pattern
being
used.
The
GMS
spec
uses
the
word
style.
I
put
some
links
to
references
where
JMS
explains
these
differences
in
terms
of
how
topics
and
cues
are
different
and
I.
A
Think
the
uniqueness
thing
is
valid
in
JMS,
but
not
compelling,
because
I
found
other
providers
that
allow
that
do
say
it's
kind
of
part
of
the
uniqueness
pattern.
Active
mq
mentioned
it,
but
everyone
agrees
from
what
I've
seen
that
it's
a
bad
pattern.
I
agree
it's
a
bad
pattern.
So
just
don't
do
that
the
fact
the
spec
says
that
it
should
be
unique
means
if
you
do
don't
follow
this
best
practice
and
you
have
topics
and
using
the
same
name
while
that
uniqueness
thing
is
broken.
C
If
I
look
on
the
traces
I
understand
the
important
difference,
even
though
blurry
to
be
fair,
the
difference
is
blurry.
There
is
a
spectrum
of
usage
patterns.
There's
keys
are
topics,
but
if
I
look
in
the
traces,
if
I
don't
have
consumer,
do
I
have
Telemetry
from
consumer
I.
Don't
know
if
I
have
multiple
consumers.
C
Okay,
there
are
cues,
for
example,
Azure
storage
queues.
They
are
super
damp.
You
go
and
get
the
message
and
then
you
have
to
decide.
If
you
are
the
one
to
process
it,
you
have
to
do
all
the
synchronization
on
the
consumer
group
or
ownership.
Think
yourself!
So
basically,
you
have
an
external
storage
where
you
kind
of
try
to
decide
how
you
take
ownership.
So
it's
super
normal
that
50
of
your
different
workers
will
go
and
grab
this
message.
C
Well,
they
can
leave
some
invisibility
time
out
on
it.
So
it's
not
super
concurrent,
but
still
it's
totally
possible
that
some
concurrency
happens
there
and
you
will
get
multiple
receivers.
It's
totally
normal.
They
will
back
off
it's
their
job
to
do
so,
but
it's
called
cues.
It's
usually
point
to
point,
but
it's
not
prescriptive
in
the
way.
C
How
like
people
use
it
right
anything
that
fits
into
the
API
so
I
don't
believe
that
this
information
can
be
definitive
and
I'm,
not
saying
it's
useless,
I'm
saying
that
we
don't
know
what
information
it
provides
if
we
want
to
see
broadcast
or
unicast,
let's
put
it
in
the
attributes
when
we
know
it.
If
we
want
to
say
order,
settlement
or
settlement
in
the
client
code,
let's
say
it.
A
Yeah
I
mean
I,
guess
I,
don't
understand
the
system
you
described
well
in
us.
I
guess
I
question
whether
that
is
a
point
to
point
messaging
model
that
you
described
or
not.
Should.
A
C
I,
don't
have
objections
here,
I'm
saying
what
I'm
saying
that,
let's
keep
let's
stay
focused,
we
can
introduce
attributes
later,
but
we
don't
know
exactly
what
this
that
that
we
want
to
express
and
once
we
have
scenario
in
mind
that
includes
the
how
the
user,
experience
and
back-end
experience
right.
We
can
add
it,
but
for
now
I
don't
think
this
attributes
that
we
have
kinds
are
helpful
and
we
just
can
just
drop
them
and
introduce
things
later.
A
It
will
well
I,
guess
I,
just
I
feel
like
I
described,
that,
which
is,
if
you
have
a
point-to-point
system,
and
you
have
multiple
receivers,
that
that
can
imply
that
it
might
be
something
interesting
that
that,
from
a
back
end
may
want
to
treat
specially
if
it's
possible,
for
something
to
be
received.
50
times
from
different
places
off
the
same
queue.
Then
I
question
whether
it's
a
point-to-point
messaging
model
or
not.
C
Okay,
first
of
all,
it
may
be
bad
for
one
system,
but
good,
but
reasonable
for
another,
given
the
differences.
Second,
the
scenario
we're
talking
about.
There
is
no
back
end
that
supports
any
messaging
semantic
conventions
that
we
work
with.
There
are
some
it
supports
previous
versions
right,
but
basically,
let's
focus
on
the
building
the
core
scenarios,
and
this
seems
like
a
nice
thing
to
have
which
can
be
added
later.
It's
not
the
essential
part,
and
also
it's
very
unclear
if
like.
Where
do
you
put
a
threshold?
C
How
do
you
decide
if
the
system
is
good
like
if
the
system
shouldn't
have
it
and
if
the
system
shouldn't
have
it
that's
three
messages
or
50
messages
right,
we
don't
know,
and
unless
we
know,
let's
not
add
attribute
for
it,.
A
A
I
I
mean
I,
I
would
propose.
This
is
an
optional
value
and
you
would
you
would
set
it
to
point
to
point.
A
If
the
expectation
is
that
it's
delivered
to
you
know
precisely
one
one
consumer
and
Pub
sub
would
be
if,
if
there
is
a
an
expectation
that
it's
being
delivered
to
multiple
places,
I
I,
I,
guess
I,
don't
see
the
harmony
I
I
like
the
fact
that
it's
present
in
the
current
spec,
if
we
don't
like
it
where
it
is
and
how
it
is
I'm
proposing
an
alternate
way
to
you,
know,
convey
the
information.
I
I,
think
it's
useful.
If
and
if
it's
optional
I
don't
really
see
the
harm
in
it.
C
If
it's
optional,
there
is
no
using
it
because
it's
in
users
must
opt
in
into
the
optional
attributes
to
see
them,
so
you
would
register
an
attribute
of
some
sort.
It
is
unclear
explanation
what
it
means
well,.
A
I
think
we
will
explain:
I
I,
don't
feel
it's
impossible
to
explain.
I
I
would
propose
that
you
know
if
we
add
it
that
we
provide
a
good
explanation.
C
Make
a
suggestion:
so
let's
do
this!
Adding
new
attribute
does
not
block
removing
the
old
one.
So,
let's
remove
old
one
and
I
cannot
write
explanation
for
a
messaging
that
model
and
I
encourage
they
doing
you
to
write
it.
If
you
think
you
can
right
so
yeah
awesome
sure.
D
Yeah
I
could
support
that
by
the
way
trying
to
give
my
third
party
opinion
and
I
remember
a
similar
situation
where,
like
you
know,
I
work
out
light,
step
and
I.
Remember
like
in
the
past.
We
wanted
to
support
something
and
there
was
no
support
in
hotel.
So
we
were
trying
to
share
some.
You
know
some
information
of
how
we
were
planning
to
use
that
information.
So
Dwayne,
if
you,
if
you
go
like,
maybe
you
don't
you
don't
have
to
actually
show
like.
A
Yeah
and
just
to
summarize,
like
I
like
I,
think
that
if
it's
not
it
like,
if
it's
not
in
the
spec,
no
back
end
will
ever
make
use
of
it
and
I
guess,
I
can
see
back
end
making
useless
information
to
highlight
interesting
scenarios
where
I'm
expecting
certain
things
to
happen
and
when
it
doesn't
follow
the
exact
normal
path.
That
back
ends
have
the
information
to
identify
that
and
perhaps
highlight
it.
So
that's
my
motivation
here.
A
That's
why
I
think
I'd
like
to
see
it
in
the
spec
and
I
can
provide
explanation
to
the
model
and
I
think
that
if
the
model
isn't
clear-cut
one
of
these
things,
then
in
the
future
we
could
look
to
add.
You
know
models
where,
where
the
we
Define,
what
it
means
and
when
you
should
use
it,
and
if
you
don't
fit
one
of
the
defined
models,
then
you
just
don't
include
it.
D
Yeah,
that
sounds
great
I
mean,
of
course,
probably
you
know
give
you
know
more
information,
but
I
think
that
the
intention
is
not
to
remove
this
with
it's
not
like.
We
think
it's
not
there's
no
value,
it's
just
that.
We
don't
understand
it
yet
fully,
but
the
plan
is
yeah.
Eventually,
you
know
if
we
can
understand,
you
know
more
details
about
these.
Just
to
add
it
back
so
anyway,
yeah
everything
is
great.
D
If
you
could
explain
like
everything
that
you
know
comes
to
your
mind
in
an
issue
and
we
can
consider
adding
that
sounds.
A
E
Yeah
Korea
I
think
we
actually
align
on
the
fact
that
we
said
Okay
a
destination.kind.
It
makes
no
sense
to
have
it
as
mandatory
attribute
and
then
further
on.
We
also
aligned
on
the
on
the
that
we
said:
okay,
messaging.com
detector,
it's
a
bad
name.
It's
it's
ambiguous.
We
don't
it's!
E
It's
not
really
clear
what
it
means
so
I
think
that's
why
we
also
say:
okay,
this
this
dot
kind
attributes
in
the
current
form,
don't
really
make
sense
and
are
very
ambiguous,
so
I
think
it's
fine
when
I
thought
Miller
said
when
she
goes
forward
and
removes
them,
and
maybe
then
we
can
build
something
more
stable
and
unambiguous
on
on
this
model,
but
I
think
it
makes
sense
to
go
forward
and
just
remove
the
current
ambiguity,
because
it's
just
a
sub-optimal
situation
and
then
see
how
we
can
then
improve
on
the
Clean
Slate.
E
So
yeah,
the
next
point
is
continue
going
over
comments
in
the
span
structure,
PR
and
the,
but
by
the
way,
what
I
wanted
to
add,
like
still
to
the
project
board
like
I,
think
one
advantage
of
having
like
a
project
board
like
this
with
issues
is
that
then
individual
people
who
have
bandwidth
can
just
pick
up
issues
from
the
board
and
work
on
time.
Mobile
I
think
I
will
try
to.
E
We
can
try
to
make
like
maybe
issues
that
are
smaller
chunks
of
work
focused
on
special
attributes
or
special,
like
areas
of
the
spec
and
then
maybe
this
will
also
help
us
to
parallelize
more
and
make
more
progress
here,
just
a
thought
that
I
I
missed
mentioning
before
so
continuing
to
our
span
structure.
Pr
lot,
Miller
thanks.
You
put
some
answer
like
some
comments
there
yesterday
I
didn't
have
time
yet
to
answer
or
to
react.
But
here
we
had
some
discussions
on
the
on
the
links
on
settle
bands.
E
So
yeah
I
think
here
we'll
just
go
your
proposal,
Luke
Miller,
and
have
something
more
just
worded
like
that.
The
users
should
add
links
on
the
saddle,
message,
operation
or
settled
on
the
settle
span
when
the
context
is
available
with
going
too
much
into
into
further
details.
So
just
if
there's
a
context
there
use
it,
you
should
use
it.
If
not,
you
cannot
use
it
anyway.
So.
E
Then
here
we
have
some
discussions
again
or
you
put
something
here
about
the
kind
for
the
publish
span
and
basically
the
observation
here
is
that
the
publish
span
so
that
the
producer
kind
indicates
that
it's
a
start
of
an
asynchronous
request
and
basically,
if
create
spans,
are
there
and
those
create
spans
more
or
less
as
child
of
the
published
span?
And
this
create
span
starts
the
asynchronous
request
or
request,
and
the
published
span
is
just
kind
of
the
parent.
E
For
this
create
operation
in
the
publish
band
itself
does
not
that's
not
does
not
start
any
async
request.
I
mean
that
would
go
more
into
this
direction
of
saying:
okay
produce
publishbane
is
a
producer
if
no
create
spans
are
present,
but
I
I.
Think
your
point
is
that
that
is
anyway.
Basically,
there's
no
read
point
in
mentioning
it,
because
it's
anyway
inherit
inherent
in
the
definition
of
the
spam
kind.
C
Oh
no,
no
no
I
mean
this
is
my
argument
for
the
first
of
your
suggestions,
where
you
just
remove
the
internal,
otherwise,
so
I
think
it's
good
to
document
yeah,
it's
kind
of
obvious
that
it
should
be
producer,
but
it's
good
to
document
it
as
for
as
for
the
kind
and
presence
of
createspads
I,
think
we
will
need
to
dive
deeper
into
this,
and
but,
according
to
the
current
state
of
open
Telemetry
semantic
conventions,
it
should
be
client.
C
Even
though
we
we
see
how
internal
can
be
useful,
but
we
don't
have
to
specify
it
here,
because
it's
not
up
it's
not
yaml
file.
It
I
think
it's
a
minor
discussion.
I!
Don't
think
we
need
to
spend
a
lot
of
time
on
it
until
we
actually
express
it
in
the
specification.
I
I
wonder
if
people
are
here
agree.
E
We
believe
it
unspecified
what
type
it
is
otherwise
now
awesome
makes
sense,
and
then
here
yeah
photo
settle
span.
I
didn't
get
to
make
this
change
yet,
but
the
we
said
last
time
we
will
remove
this
from
the
table
here
for
spend
kind
recommendation
and
also
make
this
more
make
this
more
more
unspecified
in
that
regard,
but
basically
saying
light.
E
C
E
E
E
Okay,
so
we
also
last
week
here
agreed
that
we
want
create
spans
that
are
not
trial.
Children
of
published
spans
to
be
linked
by
the
publish
operation
and
yeah
I.
As
I
said
in
the
last
week,
I
didn't
get
to
make
any
change,
but
I
will
make
this
change
also
update
and
some
of
the
diagrams,
and
then
we
can
review
this
again.
E
E
So
here
I
think
that
this
is
a
smaller
change.
It's
I
think
that's
mostly
terminology.
I
can
definitely
I
think
we
can
using
caller
instead
of
application.
I
think
we
can
make
this
change
right
away.
There's
no
objection
from
my
site
when.
B
C
E
So
here
that
is
the
ambience
ambient
context,
presence
and
I
think
you
made
the
changes
before
I
did
some
changes
to
the
pr
Let's?
Let's
maybe
look
at
those
to
the
diagrams
and
let's
see
how
this
is
about
the
ambient
context?
E
E
The
idea
is
that
everything
that
is
green
is
covered
by
this
conventions
and
everything
that
is
not
green
is
just
there
kind
of
to
help
understand
the
more
context.
Those
operations
happen,
for
example,
publish
and
deliver
span
that
is
kind
of
and
the
linking
between
them.
That
is
covered
and
required
actually
by
those
conventions.
E
If
you
go
further
here
this
ambient
span,
that
is
just
just
to
to
show
that
kind
of
these
deliver
and
settle
span,
usually
have
some
kind
of
are
part
of
some
common
Trace,
but
that
stress
they
are
here
to
kind
of
denote
that
there
is
obvious,
often
there
in
some
kind
of
common
structure
in
the
trace.
But
this
ambient
span
is
not
required
or
recommended
at
all.
C
Yeah
and
I
had
a
question
I
think
about
this
diagram
or
in
any
case
about
this
case.
So
delivery
is
when
messages
pushed
to
me
to
the
consumer
right.
So
it's
like
a
callback
where
messages
processed
inside
this
callback
right
so
I
doubt
like
in
some
cases,
for
example,
in
Google
Pub
sub,
when
they
they
use
HTTP
to
push
messages
right.
There
will
be
an
ambient
HTTP
and
server
instrumentation
span,
but
in
other
cases,
like
you
know,
cough
card.
C
If
there
is
some
callback
library,
on
top
of
it
rabbit,
Azure
things
they
want
to
have
one,
because
it's
like
there
is
a
thread
that
Waits
For
Stuff
to
come
stuff
comes.
It
notifies
the
user
right
so
I
doubt
that
ambient,
like
ambient
context
here,
I
think,
is
misleading
because
it
makes
us
think
that
deliver
and
settle
are
correlated,
but
they
are
not
in
in
general
case.
So
I
think
we
should
either
split
this
and
say:
okay.
In
some
cases
there
will
be
ambient
context,
but
in
most
of
the
cases
well,
probably
not.
E
E
Then,
let's
go
through
other
examples
in
here:
there's
Everything
Green:
it
says:
okay,
there's
no
ambiguity.
Neither
here
here
again,
I
think
that's
something
we
talked
about
last
time
here.
We
have
this
ambient
span
on
the
producer
side,
so
I
think
we
could
remove
it
here
too,
I
mean
here
we
basically
be
discussed
last
time
about
creating
a
a
link
between
those
create
and
publish
operation.
C
E
C
That
would
demonstrate
the
general
case,
and
maybe
if
we
see
some
confusion
for
people
to
if
they
don't
understand
how
they
are
related
to
more
like
for
the
producer,
it
would
be
a
common
case
to
have
ambient
context
right,
but
not
guaranteed
yeah.
So
maybe,
if
we
people
start
expressing
some
misunderstanding,
maybe
we
can
return
it
back
and
have
an
example
for
it
or
ambient
context
on
producer
or
I'm,
not
strictly
opposing
removing
it.
Maybe
just
setting
Wings
rules
are
fine
on
this
side.
F
Good
good,
good,
good,
making
it
grayed
out
or
or
like
streak
through
or
with
lines,
dotted
lines
or
something.
Then
we
could
add
a
legend.
That
is
something
like
this
is
optional,
or
this
maybe
not
there
or
something
because
I
think
it's
it's
still
interesting
to
have
in
the
diagram,
but
maybe
having
two
diagrams,
maybe
a
bit
more
confusing
than
than
having
one
I
don't
know.
E
F
F
In
the
other,
in
the
other
diagram,
but
where
you
we
want
to
remove
I
think
we're
moving
is
fine
as
well,
but
if
you
want
to
also
use
the
same
idea
there
and
then
maybe
invert
it
and
make
it
on
top,
so
you
can
clearly
see
that
they
will
be
judging
of
it,
but
then
make
it
like
crossed
out
or
something
or
gray
whatever.
F
Then
that
could
mean
that
this
okay,
this
might
be
here.
This
might
be
not
so.
E
Yeah,
let's
see
how
we
can
make
this
ambient
heal
more
more
grayed
out.
E
Mean
also
sometimes
a
better
ambient.
It's
a
good
name.
I
I.
Remember
that
the
at
the
ambient
name
confused
some
people
who
looked
at
those
diagrams
for
the
first
time,
so
it's
basically
just
basically
how
to
use
ambient
it's
just
kind
of
any
random
span,
that
kind
of
kind
of
word
or
any
end
random
kind
of
part
of
a
trace
that
kind
of
somehow
groups
these
bands
together,
that's
how
we
use
NBN,
but
it's
not
the
I,
think
it's
not
a
meaning
that
is
commonly
shared
by
lots
of
people.
E
I
think
both
the
the
thing
that
we
try
to
model
here
is
that
they
said:
okay,
usually
this
create
and
publish
spans
or
just
somehow
part
of
the
same
Trace.
That
is
my
understanding
that
they
say:
okay,
you're,
somehow
part
of
the
same
Trace.
There
might
be
more
like
spans
and
parallel
tried
relationships
in
between
but
they're.
E
Somehow,
when
you
look
at
the
trace,
you
somehow
see
connections
between
those
create
and
published
bands,
and
that's,
at
least
in
my
understanding
what
we,
what
this
ambient
is
supposed
to
signify,
but
it
seems
it
creates
more
confusion
than
it
creates
Clarity
of
what
we
want
to
convey
here.
I.
A
Mean
I
think
it
makes
sense.
I
think
the
expectation
is
that,
if
you're
about
to
create
one
of
these
spans
that
you
would
get
your
current
contacts
or
get
the
current
get
the
ACT
get
forget
the
terminology
but
get
the
current
contact
and
if
it
returns
you
something
then
use
that
as
the
parent
right.
That's
just
to
stitch
it
all
together,
as
opposed
to
creating
a
trace
in
an
island
right,
yes
and
and
as
drawn
here.
It's
shown
that
the
create
spans
are
children
of
ambient
and
I.
A
Think
the
last
time
we
discussed
this
ludmiller
provided
some
good
reasons.
Why,
especially
in
batch,
sends
you
want
unique
spans
to
be
able
to
it,
whereas
if
it
wasn't
a
child-
and
you
just
used
the
ambient
as
the
context,
then
you
wouldn't
have
anything
unique
if
they're
all
created
in
the
same
ambient
context.
But
if
you're
a
messaging
system
where
there
is
no
batching,
is
there
value
in
creating
a
child?
That's
effectively
zero
duration
versus
just
using
the
ambient
context,
as
as
the
creation
context.
E
I
I
think
the
example
that
you
were
referring
to
is
what
we
do
here.
For
example,
when
you
have
the
publish
span
and
you
just
use
you-
you
kind
of
publish
two
messages,
but
you
don't
have
a
creation
context
to
just
use
this
publish
span
as
a
creation
context,
and
then
two
messages
have
the
same
creation
context,
but.
A
E
A
Well,
I
was
thinking
more
just
like,
even
if
you
only
have
one
message
like
receive:
M1
has
a
link
to
create
M1
and
what
is
create.
M1
I
was
wondering
if
it
makes
sense
in
a
non-batch
messaging
system
that
that
create
M1
is
just
the
ambient
context.
E
I
I
think
I,
don't
fully
understand
the
relation
to
the
ambient
context,
but
here
I
think.
The
point
is
that
the
I
think
the
use
case
that
I
mentioned
here
is
that
the
user
calls
a
publish,
operation
and
and
publishes
a
message
message,
but
the
user
tells
the
publish
operation
use
this
creation
context
that
maybe
I
manually
put
on
this
message,
and
that
could
be
anything
that
is
up
then
to
the
user
who
decide
whether
it's
like
a
separate,
create
span
for
each
message
for
single
message
or
whether
it's
any
other
span
here.
A
Yeah,
okay,
I
I,
definitely
understand
that
use
case.
I
think
we
definitely
should
allow
applications
to
provide
a
creation
context
explicitly
or
give
them
control.
I
guess
I
was
thinking
of
you
know.
Often
people
rely
on
auto
instrumentation
and
don't
do
any
or
want
minimal
intervention
with
tracing
this
and
and
would
it
make
sense,
for
you
know
an
API
that
creates
a
message
to
say:
okay,
well,
there's
an
ambient
context,
I'll
sign
as
a
creation
context.
A
If,
after
that,
the
application
assigns
the
creation
context
of
their
choosing
okay,
it
would
overwrite
what
I
had
chosen
at
you
know
in
the
auto
instrumentation
and
then
on,
publish
I
would
see.
Has
one
been
attached
to
the
message
if
not
I'll
use
the
publish
context
as
the
creation
context,
otherwise
use
whatever's
there,
so
just
I'm
just
wondering
about
this
extra?
Does
it
make
any
sense
in
any
way
shape
or
form
to
have
an
auto
instrumented
API?
F
I
think
the
example
that
you
that
Johannes
showed
before
the
the
one
above
is
the
one
that,
if
it's
a
single
message
or
something,
then
you
the
the
ambient
will
be
the
published.
And
then
that
will
be
the
one
that
is
attached
to
the
message
and
then
the
consumer
would
link
to
that.
Isn't
that
what?
What
do
you?
You
mean
now
I
think.
A
So
yeah
I
guess
I'm
just
wondering
is
if,
if
you
were
created
If
the
message
was
created
before
and
there's
a
different
ambient
span,
maybe
in
the
same
Trace,
but
a
different
span.
F
A
F
I
think
I
think
that's
just
something
that
is
already
in
the
somewhere,
because
I
think
in
the
best
right,
because
I
think
we
wrote
something
that
if
the
message
arrives
with
already
a
context,
then
shouldn't
shouldn't
change.
It
should
just
publish
it
with
the
contact,
that's
already
there
and
then,
if
the
user
added
some
other
context,
that
is
a
bit
for
something
else.
Then
they
will
be
there
and
when
it's
propagated
and
received
will
link
to
the
other.
A
Yeah
no
I
agree,
yeah
I
wish
we
decided
that
and
I
guess
what
I'm
getting
at
is.
Is
it
100
the
application's
responsibility
to
provide
a
creation
context
you
know,
or
is
there
use
in
in
an
auto
instrumented
API
SDK
assigning
the
ambient
context
during
create
or
creating
a
child
of
the
ambient
during
when
the
messages
created
and
allocated.
B
A
F
A
message
is
creating
as
part
of
I,
don't
know
a
DB
query,
and
then
you
create
a
message.
Then
the
instrumentation
I
guess
has
to
yeah
I
guess
something
to
to
do
with
that.
E
You
guys
I
might
not
think
the
main
point.
Also
one
point:
one
point
that
we
can
make
is
that
we
and
we
actually
have
that
already
in
the
spec,
where
we
said:
okay,
when
Once
the
context
is
attached
to
a
message,
this
context
cannot
be
changed,
so
I
I
think.
One
thing
that
definitely
makes
sense
to
make
key
also
for
us
is
that
when,
for
example,
some
message
is
published
and
comes
into
the
publish
operation,
vendor
is
already
a
context
on
this
message.
E
Then
the
publish
operation
actually
must
not
overwrite
this
context
and
that
might
even
in
in
Mr
mechanisms
with
how
contexts
are
attached
to
some
messages
might
even
be
possible
because
it
might
be
some
read-only
attribute
on
a
message.
So
I
think.
If
there
is
a
context
already
on
the
message,
then
it's
not
overwritten
I
think
that's
something
we
can
assume
and
also
do
those
examples
that
you
that
you
see
here.
I
I
just
try
to
cover
lots
of
scenarios,
but
they
are
not
exhaust
exhaustive.
E
So
definitely
one
can
imagine
other
scenarios
that
are
there
and
if,
if
we
can
think
about
scenarios
that
are
not
covered
here
by
some
kind
of
image,
that
doesn't
mean
they
are
not
supported,
I
think
the
main.
The
main
thing
here
is
I
think
the
basic
requirements
are
that
for
each
each
message
there
is,
there
is
either
a
link
to
a
create
spam
or
to
some
kind
of
publish
span.
I,
think
that
is
the
that
is
the
more
or
less
only
requirement
that
we
have
here
and
how
they
are
organized.
E
E
E
Here
we
have
the
process
band.
Here
we
have,
we
already
had
quite
some
discussion
about
the
process
Pane,
and
that
was
actually
the
actual
Motivation
by
adding
some
colors
here,
just
to
say:
okay,
publish
delivery
that
is
covered
by
this
back
process.
Note,
that
is,
that
is
just
here
to
to
to
illustrate
that
the
artist
deliveration
can
there
can
be
one.
We
want
to
live
operation
of
several
messages,
but
then
they
can
be
found
out
on
the
processing
level.
E
F
F
No
worth
it
it's
okay.
What
what
the
thing
that
I
I
wanted
to
mention
is
that
I
learned
this
week
that
there
is
a
some
large
company
that
is
using
some,
the
not
sure
if
it's
node.js
or
Java
instrumentation
today
and
they're
running
some
some
problem,
because
they
they
don't
want
the
links.
F
So,
for
example,
they
don't
want
the
the
links
to
be
so
they
don't
want
to
have
two
traces
that
that's
basically,
that
was
the
point
from
the
the
person
that
joined
from
I
think
light
steps
some
time
ago
that
he
was
really
interested
in
having
a
single
trace.
You're
talking
about
Tyler
Tyler,
yes,
I
forgot
his
name.
Yes,
thank
you.
Yes,
that
Tyler
brought
it
up
and
I
learned
that
this
customer,
what
it?
F
What
they're
doing
is
it's
quite
interesting
I'm
just
telling,
because
maybe
you
find
it
also
interesting
that
they
added
a
collector
and
they
used
the
processor
in
The
Collector
to
take
the
to
take
the
the
the
first,
so
they
they
think
Max
batch
of
messages.
So
they
take
the
first
context
from
the
mess
from
the
first
message
and
there's
a
use
that
replace
the
the
the
the
the
parent
span.
With
with
that.
F
So
then,
when
they've
arrives
on
the
consumer,
all
the
consumer
processing
is
is
in
the
same
Trace,
so
they
they.
They
wrote
a
custom
collector
processor
to
do
this,
to
overwrite
the
span
and
and
have
that
which
I
found
quite
quite
interesting
and
they
they
the
the
reason
I
brought
it
up
because
they
probably
don't
want
this
and
I
think.
F
Having
a
have
have
like
have
the
the
producing
consumer
in
the
same
trace,
for
example,
and
one
thing
I
also
learned
is
that
it's
possible-
or
it's
also
used
used-
that,
for
example,
when,
when
receiving
you,
just
use
the
the
the
context
as
the
parent
and
this
I
think
we
all
we
already
discussed
using
this
or
this
alternative
to
make
to
make
everything.
The
same
in
the
same
Trace
to
just
use
the
context
from
the
message
as
the
parent
and
then
everything
is
the
same
in
the.
E
Same
Trace,
we
had
this
discussion
so
in
here
that
would
be
the
case,
so
here
it's
possible
to
to
basically
on
both
deliver
operations,
use,
Publishers,
parent
and
here
basically
with
the
situation
over
here.
We
want
the
link
because
it
creates
consistency
across
all
messaging
scenarios,
but
you
can
also
add
the
public
Spain
is
apparent,
and
then
you
have
everything
in
the
same
Trace.
So
that's
for
the
delivery
scenarios
and
I
think
we
also
have
this
for
the
receive
scenario.
E
We
have
it
here
too,
and
it
should
be
possible
for
I
think
we
have
it
for
a
received
scenario
somewhere
too,
but
I'm
not
sure.
If
not,
we
can
add
this,
but
the
the
point
is
and
I
think
that
was
something
that
came
out
of
the
discussions
with
Tyler
that
we
said:
okay
yeah.
E
If
if
there
is
cases
where
it's
possible
to
add
the
parental
guide
relationship,
you
can
add
this
in
addition
to
the
link
and
to,
and
so
you
have
everything
in
the
same
Trace
when
we
think
about
more
complex
example,
I
mean
here,
for
example,
those
two
public
operations
you
couldn't.
You
could
have
this
in
different
instances.
E
E
It
it
always
requires
that
all
your
basically
traces
go
through
the
same
process.
So,
yes,.
E
Between
actually
many
instances,
so
you
cannot
guarantee
or
is
even
impossible,
so
I
think
the
the
requirement
of
having
like
everything
in
a
single
trace,
I
think
it's
a
valid
requirement.
It's
just
not
feasible
for
con
to
kind
of
have
it
a.
E
And
consisted
of
all
scenarios,
so
basically,
what
you
try
to
say
is:
okay,
we
have
some
consistent
rules
that
are
applicable
to
all
scenarios.
They
don't
those
rules,
don't
guarantee
that
there
is
a
single
trace
that
covers
both
producer
and
consumer,
and
there
is
a
subset
of
cases
where
this
is
possible
and
there
we
basically
the
we
have
like
some
conventions
that
allow
that.
E
So
you
can
add
this
current
child
relationship,
in
addition,
and
then
still
have
have
have
a
consistent,
Trace,
so
I
think
that's
the
that's
the
strategy
that
we
are
following
here
with
this
approach
and
that
I
think
is
for
people
who
want
to
have
everything
in
a
single
trace,
not
the
best,
but
it's
as
good
as
it
can
get,
while
still
providing
some
consistent
guarantees
of
all
scenarios.
C
Ironically,
besides
the
a
lot
of
feedback
to
see
things
in
one
Trace,
yeah
I
heard
one
piece
of
feedback
to
actually
use
links,
because
otherwise
traces
become
too
deep
and
too
long
and
people
don't
want
it
so
yeah.
We
should
probably
tackle
it
later,
because
it's
we
should
provide
some
basic
common
denominator
right,
it's
time
to
go
too
deep
into
addressing
all
the
different
needs,
at
least
for
now,.
D
But
by
the
way,
just
a
small
comment
and
I
will
do
a
full
review.
This
hotel,
I
haven't
had
time
to
do
that
in
the
last
weeks,
but
the
one
thing
that
I
would
like
to
have
is,
as
Joe
mentioned,
maybe
something
optional
for
very
simple
use
cases
where
you
could
offer
like
these
potential
relationship
in
staff,
but
I
will
think
about
that,
because
that
would
be
like
super
simple
use.
Cases
I
agree
with
that.
The
majority
of
the
cases
like
having
that
in
the
trace
will
just
make
it
make
everything
explode.
E
Yes,
I
mean
they
can
look
like
the
simple
here
is,
that
is
one
of
the
simplest
use
case
yeah.
E
The
link
should
always
be
there,
because
that
creates
consistency,
but
you
can
also
have
the
parent
tribe
relationship,
in
addition
and
and
then
in
the
back
and
just
ignore
the
link,
and
then
here
basically
you
have
the
very
simple
use
case.
We
have
a
published
and
deliver
and
it's
all
in
the
same
Trace.
So
that
is
something
that
we
that
we
would
support
with
this
semantic
business
proposal.
A
When
it
comes
to
you
transfer
tracing,
which
I
understand
is
out
of
the
scope
here,
but
I
think
we
anticipate
that
transport
level
tracing
will
happen.
It's
just
we're
not
dictating
in
this
specification,
your
conventions.
What
span
should
look
like
at
the
transport
layer,
but
if
they
were
transportation
between
the
publish
them
want
to
deliver
M1
here
is
there
any
expectation
that
deliver
M1
would
be
a
child
of
you
know
the
transport
context
or
that's
entirely
up
to
the
produced
service
Telemetry
to
decide
how
to
link
this
in
with
transport
context,.
E
Forget
this
from
my
point
of
view
here
is
that
the
if
some
transport
context
comes
in
here
in
this
scenario,
this
link
definitely
might
break.
So
you
definitely
don't
have
like
a
direct
Parent
Trap
relationship.
Maybe
you
have
some?
Maybe
you
have
some
spans
in
between
and
have
some
kind
of,
ancestry
relationship,
but
you
will
not
have
a
direct
relationship
for
sure.
Okay,.
E
E
E
E
That
is
the
last
but
one
example
here.
E
I
can
also
try
here
to
make
this
this
more
like
a
family
or
grayed
out
and
then
maybe
next
time
they
can
go
over
to
these
last
two
examples
here
and
see
whether
maybe
we
want
to
remove
them
at
all
and
they
don't
make
sense.
I
mean
I
think
here
we
have
a
very
similar
case
to
to
here,
but
we
said
we
want
to
remove
this
here
to
create
more
clarity.
So
maybe
we
should.
E
We
should
be
consistent
and
do
the
same
here
remove
this
ambient
span
here
and
probably
also
here,
but
we
are
on
time.
So,
let's
maybe
finish
up
on
that
next
time,
I
will
try
to
incorporate
all
the
changes
from
the
comments,
resolve
the
comments
and
then
maybe
next
time.
Ideally,
we
can
kill
some
open
comments
on
this
PR.
Let's
see
if
somebody
else
comes
up.
E
So
if,
if
you
something
has
come
up,
if
you
have
time,
please
go
over
the
pr
review,
add
some
comments
and
then
let's
try
to
discuss
offline
and
ideally,
as
the
group
close
next
week
or
one
of
the
next
weeks
on
the
cell
tab.
F
C
E
So
then,
of
course,
the
two
of
us
again
so
I
I
would
say:
let's
try
again
next
Monday
and
if
we
don't
manage
these
three
people
next
Monday,
maybe
let's
take
it
off
the
calendar
temporarily
and
maybe
try
to
start
up
again
so
once
we
actually
have
a
deadline
for
delivering
stability.
Okay,.