►
From YouTube: 2022-02-03 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
And
if
it's
only
the
few
of
us,
we
can
also
keep
this
meeting
shorter,
so
that
yeah,
I
just
don't-
have
to
catch
up
but
yeah.
If
you,
if
you
have
anything,
you
want
to
discuss,
just
put
it
on
the
on
the
agenda.
A
A
A
A
We
said
that,
for
version
1.0
for
the
first
stable,
we
will
leave
out
like
this
two
layer
context
model,
because
that
also
would
involve
like
working
out
how
to
deal
with
these
two
layers
in
all
of
the
protocols
that
we
want
to
support
and,
as
we
said
actually
for
what
we
want
to
deliver
in
version
1.0,
the
two
layers
are
not
necessary.
So
for
what
we
deliver
in
1.0,
just
the
consumer
and
producer
instrumentation,
we
can
just
do
with
the
one
application
or
creation
context,
layer
and.
A
Some
prototype
so
verified
that,
even
if
we
just
go
with
this
one
layer
for
now,
the
second
layer
can
be
added
later
on.
So
we
are
kind
of
we
are
not
blocking
anything
there.
We
are
just
yeah
reducing
scope,
a
bit
for
1.0,
so
I
made
those
this
changes
here.
I
just
mention
this
creation
context
layer
here.
A
That
is
basically
the
context
for
the
message
it
was
created
and
this
context
needs
to
be
propagated
to
the
consumer
through
all
the
intermediary
hops,
and
I
also
tried
to
kind
of
highlight
the
normative
language,
because
in
in
this
document
we
have
lots
of
explanation
and
actually
what
what
we
ask
for
it's,
it's
it's
actually
pretty
can
be
pretty
concise.
So
here
people,
you
said
a
producer
should
attach
creation
context
to
each
message
and
this
context
should
be
attached
in
a
way
so
that
it's
not
changed
by
intermediaries.
A
A
A
I
think
we
agreed
that
at
that
point
we
will
need
this
additional
context,
layer
to
kind
of
seamlessly
integrate
intermediate
instrumentation
and
produce
the
consumer
instrumentation.
A
And
then
other
change
that
I
did
it's
here
in
this
section
on
the
consumer
instrumentation
and
here
I
created
two
sub-sections
one-
is
for
instrumenting
push-based
scenarios.
That's
what
we
some
weeks
ago
talked
about.
I
think
amir.
You
worked
out
some
examples
there,
where
basically
we
have
this.
We
have
sdks
who
just
call
a
callback
on
the
client
side
to
pass
messages.
A
To
the
messaging
sdk's
push
messages
to
the
application,
and
here
we
have
we
had
this
deliver
span
that
basically
covers
the
duration
of
this
callback
and
but
then
luke
miller
worked
out
some
examples
for
was
these
full-based
scenarios
where,
as
where
the
client
application
calls
receive
a
calls,
receive
a
method
and
then
basically
receives
a
one,
zero
or
more
messages
as
a
result
from
this
car.
A
So
that's
basically
a
pool
based
sdk
scenario,
so
the
the
application
code
requests
messages
from
the
sdk
and
for
this
for
this
yeah
this
is
what
is
backed
out
here
is
based
on
what
luke
miller
worked
out,
got
this
document
here
and
for
now
I
specced
out
her
solution
too,
that
we
have
just
a
single
receive
span
and
this
receives
span
has
links
to
all
the
creation
contexts
of
the
messages
that
are
returned
by
this
receive
spam.
A
That
is
kind
of
kind
of.
A
The
main
difference
here
is
that
for
the
deliver
span.
Basically,
if
the
message
is
processed
messages
are
processed,
that
will
very
likely
be
child
spans
of
the
delivery
span,
whereas
with
with
the
receive
span
when
messages
are
processed,
those
processing
spans
will
most
likely
be
sibling
spans
of
the
receive
operation
just
because
of
with
the
deliver
span.
We
have
this
callback
nature
and
probably
spence
will
process
during
the
duration
of
this
callback.
A
The
in
that,
in
that
case,
they
can
be
children
for
receive
spends
that
is
not
possible
at
all,
because
you
are
the
receive
spend
just
is
already
ended
when
control
goes
back
to
the
client
application
so
for
the
receive
spend
basically
the
those
bands
processing,
the
messages
can
be,
can
be,
or
will
very
likely
be
siblings.
A
And
yeah
just
split
this
up
in
instrumenting
push-based
scenarios
pool
based
scenarios
and
then
just
general
consideration.
This
is
just
the
requirements
we
have
for
both
of
those
like
those
are
just
requirements
for
the
consumer
instrumentation,
regardless
of
whether
it's
push
or
pull
based.
I
still
need
to
clean
that
up
a
bit
the
wording
here
and
but
yeah.
That's,
that's
the
basically
the
the
main
structural
changes
I
did
based
on
our
recent
on
our
recent
discussions.
B
On
the
initial
part,
we
talked
earlier
you're
talking
about
there,
the
you
know
the
the
contacts
right,
the
the
transport
layer,
contacts
versus
the
application
or
create
context.
Yes,
you
meant
you
mentioned.
There
are
three
examples
of
attempts
to
standardize,
but
is
it
isn't
clear
to
me
that
amtp
and
mqtt
that
those
standards,
what
they're
attempting
to
standardize,
whether
it's
creation
context
or
the
htp
equivalent
of
trace
context
to
me
it?
B
I,
I
interpreted
the
antp
and
mct
specs
as
as
attempting
to
standardize
the
http
equivalent
of
trace
context,
and
it
so
happens
in
the
amtp
case.
You
kind
of
get
a
creation
context
out
of
it
because
of
the
immutable
properties
which
later
need
to
be.
If
it's
mutated
need
to
be
copied
into
annotations,
but
I
I
guess
it
yeah.
So
you
guys
it's
not
clear
to
me
whether
we're
suggesting
that
this
be
used
as
creation
context.
B
C
The
those
two
are
a
little
different
as
with
so
http
I'm
just
trying
to
draw
the
parallels
http,
the
message
exists
effectively
for
a
trip
to
the
server
and,
yes,
there
might
be
intermediaries,
but
ultimately
they
just
do.
They
might
do
introspection
and
add
some
headers
etc,
but
in
the
common
proxies,
reverse
proxies,
etc.
C
The
bare
message
of
mqp
is
then
forwarded
to
to
a
consumer
with
with
mqtt
mktd
is
is
a
bit
in
the
middle,
because
the
way
how
you
deliver
a
a
message
or
mqtt
the
the
frame
that
you
transport,
that
in
is,
is
effectively
if
it
is
only
for
the
one
interaction
with
the
broker
and
then
the
contents
of
that
frame
are
then
being
effectively
transposed
onto
another
frame,
which
then
is
delivered
to
the
client
in
amqp.
C
The
bare
message
is
being
copied
literally
to
the
other
side,
and
there
are
rules
around
the
immutability
as
you
as
you
state
of
the
properties
with
cloud
events.
It's
very
similar,
so
the
difference
between
mqtt
and
hdp
on
one
side
at
amqp
on
cloud
events
on
the
other
side
is
that
for
hdp
and
mqtt,
the
frame
along
with
its
metadata
is
a
utility.
C
That's
there
for
one
hop
for
effectively
the
immediate
interaction
between
the
client
and
the
server
while
for
and
for
cloud
events
and
for
mkp
the
message
that
the
core
message
is
something
that's
being
handed
over:
multiple
hops
as
is,
and
with
amqp.
There
is
this
notion
of
these
message:
annotations
and
delivery
annotations,
which
are
typically
used
as
hub
to
hop
attributes,
and
that's
why
they're
mutable.
B
Well,
no,
I
I
I
didn't.
I
don't
follow
every
detail,
but
I
think
generally.
I
agree
that
yes,
amkb,
has
these
cons
like
the
bear
message,
as
you
say,
is
the
completely
immutable
part.
That's
the
application
is
full
control.
The
annotations
are
for
hop
by
hop.
I
don't
understand
cloud
events
to
the
same
degree,
but
I
understood
some
of
your
analogies.
It's
not
clear
to
me
where
mqtt
fits
in.
C
What
I'm,
what
I'm
saying
mkgt
is
so,
especially
if
you
look
at
mpt
311
is:
does
the
absolute
bare
minimum
to
be
able
to
go
and
take
the
body
and
just
move
it
to
a
different,
a
different
to
the
other
side?
C
So
there's
not
much
of
a
notion,
so
even
the
cut
the
the
the
message,
the
metadata
that
you
would
flow
to
establish
a
context,
it's
not
even
available
in
npt
311,
which
means
you
have
to
you
have
to
have
it
in
the
payload
in
the
message.
So
there's
not
even
an
option
with
mpd5.
There
is
user
properties
that
you
will
then
flow
from
from
one
party
to
the
next
party,
but
there
are
also
no
hard
rules
for
how
to
handle
those,
those
user
properties.
So
you're
right
there
is
no.
A
B
And-
and
so
I
I
think,
user
properties
mp5
is
a
good
place
for
a
creation
context,
for
example,
but
I
think
if
even
if
we
look
at
mqp
and
what
its
technical
capabilities
are
and
how
we
might
interpret
that,
I
think
if
you
read
the
language,
if
I
remember
correctly-
and
I
was
a
few
months
ago-
I
read
it-
I
believe
it
kind
of
says
that
you
should
interpret
the
s
the
content,
the
the
context
out
of
the
message
by
first
reading,
the
properties
and
then
anything
that's
in
an
annotation
should
supersede
what's
in
the
properties.
B
C
So
that
stems
from
a
before
we,
I
think
understood.
I
was
part
of
this
before
we
understood
that
there
are
two
different
contexts.
B
C
And
we
should,
because
I
think
the
the
this
is
the
this
is
still
a
draft
right.
Yes,
that's.
A
C
Yeah
so
we
should
go,
we
should
go
and
change
that
as
we
need
it.
So
we
should
not
take
that
as
as
as
final,
but
basically
if
we
say
that
there
are
two
contacts-
and
one
is
this
and
the
other
one
is
that,
then
we
should
make
the
w3c
specs
follow
what
we
want
here
in
the
same
way
as
with
cloud
events,
the
the
agreement
is
that
the
the
trace
that
the
trace
extension
is
also
owned
by
this
group.
B
Yeah,
I
agree
with
that
and
then
my
concern
is
that,
with
the
listing
of
of
links
to
these
specifications
as
attempts
to
formalize
the
creation
context,
I
think
until
those
specifications
that
we
link
to
like
clarify
this
conte,
this
concept
of
a
creation,
context
and
yeah.
I
guess,
if
we're
gonna
include
it,
I
think
we
should
ensure
that
the
specs
we
link
to
have
this
wording
in
there
rega
regarding
a
creation
context,
go
right
ahead
and
change.
It.
A
Yes,
I
think
that
the
idea
here
is
that,
for
forgetting
this
version,
1.0
for
this
semantic
conventions
here
open
the
lamitrius
table,
we
kind
of
try
to
get
this
done
until
end
of
march,
which
is
very
optimistic
anyway,
and
for
for
getting
these
changes
through
like
in
those
quarter
cores
and
also
getting
actually
open,
telemetry
people
to
wrap
their
head
around
the
fact
that
there
are
cases
with
two
layers
of
context
that
need
to
be
handled.
A
But
I
think
the
idea
there
is
that
we
put
out
like
this
general
guidance,
which
is
version
1.0,
and
I
envision
that
we
then
have
other
basically
sections
or
documents
that
are
not
marked
as
stable
with
the
open
telemetry
stability
guarantees
and
that
cover
kind
of
recommendations
that
we
give
for
propagating
the
creation
context
with
those
three
protocols.
I
think
that's,
those
are
the
most
important
one
that
we
will
cover
and
I
think
that,
because
that's
not
something
we
can
from
open.
A
A
So
on
this
side
we
can
begin
to
stabilize,
whereas
on
the
instrumentation
side
we
would
still
have
kind
of
work
to
do
to
kind
of
also
bring
those
bring
those
wvc
specs
in
line
with
what
we
need
to
update
open,
telemetry
specifications
and
also
that's
what
I
kind
of
experienced
during
the
last
weeks
also
doing
some,
how
to
say:
adventurization
in
the
open
telemetry
community
to
kind
of
explain
to
people
why.
D
A
Exactly
so,
it's
it's
actually,
it's
kind
of
a
chance
for
the
broker
or
intermediary
to
continue
to
trace,
to
kind
of
propagate
its
own
context,
between
different
kind
of
intermediary
components
and
also
to
pass
kind
of
a
broker-specific
context
onto
the
consumer,
so
basically
to
create
the
whole
the
whole
link.
But
this
the
producer
consumer
link,
that's
based
on
the
creation
context
that
is
a
different
layer,
independent
of
this
context
that
will
be
passed
to
the
intermediary.
Yes,.
D
But
but
are
there
any
currently
any
any
brokers
that
are
instrumented?
That
will
accept
this
context,
or
is
it
just
their
preparation
for
the
future?
The
potential
use.
B
Are
you
sorry
I
mean
you're
suggesting:
are
there
any
asking?
Are
there
any
brokers,
except
which
context
the
creation
one
or
the
more
the
transport,
the
other
one,
the
transport
yeah?
I
mean
that's,
what
kind
of
what
we're
working
on
and
and
that's
why
it's
like.
I
just.
I
want
to
be
clear
that
there's
a
separation
between
these
two
and
I
understand
the
focus
of
this-
is
not
to
specify
the
semantics
of
this.
B
You
know
mutable
context,
let's
call
it
transport
context,
but
but
I
think
it
should
be
clear
that
such
a
thing
exists
that
that
that
that
the
creation
context
is
an
immutable
part
of
the
message
and
that
that
it's
that
there
would
be
a
trace
context
that
would
propagate
through
and
and
could
be
mutated
on
a
kind
of
hop-by-hot
basis.
D
B
Well,
I
I
think
there
still
could
be
some
value
because
the
creation
context
like
if,
on
the
producer
side,
we
have
a
separate
creation
span
and
send
span
an
instrumented
api,
even
if
the
brokers
aren't
instrumented
may
wish
to
say,
link
to
the
the
send
span
at
those
you
know
in
the
receipt
in
the
yeah.
I
forget
the
name
in
here,
but
not
the
delivery
span.
B
The
first,
the
first
fan
that
the
api
has
when
it
receives
a
message,
and
so
there
may
be
a
desire
to
either
have
a
parent-child
relationship
there
or
or
just
a
link
if,
if
they're,
two
separate
traces
outside
of
the
sort
of
more
application
layer
deliver
span,
having
a
link
to
the
creation
spam.
A
I
think
amir.
What
you're
saying
is
that
the
trans,
sending
a
transport
context
does
not
make
sense
when
intermediaries
are
not
instrumented
and
yeah
that
that
is
true.
Basically
the
transportation.
The
transport
context
would
only
be
is
unintended
to
be
used
by
the
intermediary
and
when,
when
there
is
no
instrument,
intermediary
kind
of
this
transport
context
will
will
not
be
used
for
now,
but
we
we
just
we
just
wanna,
be
open
to
that
kind
of
extent.
B
A
The
I
mean
the
idea
is
that
the
application
kind
of
that
the
instant
instrumentation
that
that
application
instrumentation
gives
gives
sensible
results,
regardless
of
whether
the
broker
is
instrumented
or
not.
B
Yeah,
but
I
guess,
if
the
app,
if
the
application
doesn't
know
or
if
the
sdk
that's
sending
the
message,
doesn't
know
if
the
broker
is
instrumenting,
that
particular
message
it
seems
like
it
should
always
include
it
on
the
assumption
that
might
be
used
by
the
broker.
D
A
D
Like
it
can
inject
some
context,
but
in
order
to
be
received
and
handled
correctly
on
the
other
side,
like
the
the
local
first
have
to
implement
it
and
tell
the
instrumentation
how
he
wants
to
receive
this
context
right.
So
it's
currently
all
at
your
theoretic.
If
I
understand
quality,
we're
not
going
to
do
it
tomorrow,
right.
A
Well,
that
depends
on
the
on
the
on
the
people
who
maintain
the
brokers
and
who
instrument
them.
I,
I
think,
also
that
people
who
instrument
brokers,
they
kind
of
pro,
maybe
to
a
certain
extent,
also
wait
for
getting
some
guidance
here,
because
currently
they're
hanging
pretty
much
in
the
air.
I
mean
they're,
getting
maybe
a
message,
and
maybe
there
is
like
a
context
somewhere
in
there
based
on
those
draft
standards,
but
there
is
nothing
that
the
broker
can
really
rely
on
from
the
outside
currently.
A
So
I
think
also
what
we
try
them
to
do
here
in
further
steps
is
actually
giving
them
some
kind
of
some
kind
of
very
basic
framework
they
can
rely
on
if
they
want
to
instrument,
but-
but
I
think
I
mean
you're
right
in
in
the
regard
that
I
think
currently
there
is
no.
There
is
not
much
out
there
in
terms
of
broken
instrumentation,
at
least
also
that
I
know
of.
B
Yeah,
I
don't
know
of
any,
because
I've
spent
some
time
looking,
I
do
know
active
mq
there's
somebody
looking
at
adding
some
kind
of
support.
It
doesn't
sound
like
anything,
that's
being
taken
too
seriously
at
the
moment,
but
somebody
is
working
on
that
and
and
I'm
not
aware
of
any
other
activity
on
that
front
besides.
Besides
us.
B
I
have
I
I
can.
I
could
send
a
link
to
the
discussion
thread.
It's
there's
a
an
intern
who
is
working
on
this
sort
of
as
a
side
project
under
who's
being
sort
of
mentored
by
clebert.
I
forget.
C
His
last
name,
I
know
several
layers
of
bosses
at
red
hat,
who
are
ultimately
driving
pretty
much
all
the
activemq
projects.
Okay,
so
if
there
is
a
if
there
were
a
need
to
nudge
this,
then
I
can
probably
go
and
write
email
and
ask.
B
C
Oh
god,
if
you
send
me
an
email
to
clemency
at
microsoft.com,
I
can
promise
you
that
I
won't
forget
it.
Okay,.
A
Back
to
your
question,
I'm
here
I
think
that's
also
in
the
in
in
that
spirit,
also
what
we
target
here
from
version
1.0
is
more
in
line
with
what
the
current
reality
is,
because
we
more
or
less
basically
require
this
creation
context
to
be
sent
around,
which
is
which
is
definitely
used
currently
in
instrumentation
scenarios
and
then,
as
the
future
possibilities.
A
We
have
the
additional
transport
context
layer
which
will
allow
like
to
seamlessly
integrate
the
intermediary
instrumentations
with
other
instrumentations,
but
it's
kind
of
mentioned
under
future
possibilities
that
we
will
kind
of
work
out
in
this
backhand.
That
probably
will
also
then
actually
be
be,
will
be
realized
in
in
broken
instrumentations.
D
Yeah
so
as
far
as
instrumentations
are
concerned
like
they
have
to
they,
they
create
context
or
the
immutable
context
is
required
as
long
as
it's
feasible
to
send.
A
A
Yes,
in
in
version
1.0,
we
will
probably
not
even
mention
the
transport
context,
so
that
is
just
here
a
future
possibility
that
can
be
added
then
in
future
versions
of
this,
of
this
backer
of
the
conventions,
but
will
probably
not
even
mention
it
in
version
in
in
the
actual
normative
text
of
version,
1.0.
D
A
And
yeah,
I
will
also
try
to
work
on
some
reverting
on
this
part
here
with
the
different
protocols
to
make
it
clear
what
we
discussed
about
them
before
that
we
will
basically
give
some
probably
some
recommendations
and
guidance
for
how
to
propagate
the
the
creation
context
with
those
protocols.
But
we
will
not
be
able
to
give
like
a
stain
a
stable
kind
of
a
stable,
normative
guidance
there,
because
all
those
this
work
is
still
working,
progress
more
or
less.
A
And
you
have
any
kind
of
consonants
or
thoughts
on
this
consumer
instrumentation,
like
with
the
push
with
the
separation
between
pushed
and
pull
based,
or
does
that
look?
Does
that
look
sensible
to
you.
A
A
This
is
still
yeah
anyway.
An
open
point
like
these
details
for
the
product
course
that's
what
we
talked
before,
that
we
need
to
kind
of
somehow
have
some
wording
for
1.0
how
we
relate
to
those
protocols
or
how
to
do
kind
of
the
specification
attempts
or
the
drafts
specification
drives
for
those
protocols
and
push
scenarios.
Here
I
put
as
done
here
pull
scenarios
still
in
progress
for
some
reasons.
I
will
go
in
here
and
this
intermediary
instrumentation.
A
We
added
this
here
with
this-
is
a
question
about
different
consumer
producer
traces:
how
to
handle
different
cases.
A
That
was
a
question
that
duan
brought
up
where
also
partly
mqp
specific,
where
the
question
was
yeah
the
consumer
that
receives
an
mqp
package
and
takes
a
transport
context
out
there.
How
can
the
consumer
know
whether
this
transport
context
originated
from
the
intermediary
or
whether
it's
just
the
transport
context?
It
was
kind
of
back
through
the
intermediary
and
was
added
by
the
producer,
and
the
meteor
is
not
instrumented
and
just
forwards.
A
This
context
this
I
mark
this
question
mark
post
version
1.0,
because
I
think
it's
a
question
that
is
also
related
to
to
this
future
consideration
of
about
context,
propagation
and
also
to
like
working
out
the
details
for
this
transport
context,
layer
and
also
coming
up
with
a
stable
version
of
this
mqb
w3c.
A
Spec,
so
that's
why
I
kind
of
I
believe
this
in
there,
but
the
will
mark
is
post
post
version
one
because
we
will
not
solve
this
problem
in
version
one,
but
in
upcoming
versions,
when
we
flesh
out
dope
or
try
to
answer
the
questions
that
we
talked
before
and
then
yeah.
We
have
attributes
here.
We
didn't
start
on
that
yet,
but
basically
that
is
the
the
current
state.
A
What
I
would
I
think,
the
next
steps
will
be
here
just
trying
to
like
wrap
up
those
pull-based
scenarios
and
then
hopefully
start
working
on
the
producer
instrumentation
flashing
out,
like
the
the
span
structure
there
and
then
you're
finally,
going
to
the
attributes.
A
Okay
and
then
last
year
they
were
here,
but
what
I
have
here,
I
I
made
a
little
prototype
for
those
poor
based
consumer
scenarios
like
just
a
minimal
prototype
similar
to
the
ones
I
showed
last
time,
and
we
have
here
in
the
middle
of
document
like
solution
two
is:
is
we
agree
down?
That
would
be
our
desired
solution.
A
A
problem
we
have
here
is
that
we
are
blocked
by
some
open
telemetry
limitations,
because
the
open
datametry
does
not
allow
to
add
links
to
a
span
after
the
span
was
started
or
after
the
span
was
created,
and
for
implementing
this
solution
too,
we
would
need
this
capability
of
adding
links
after
a
spam
was
created.
A
Solutions
three
that
ludmilla
recommended
here
is
basically
a
workaround
for
this
limitation
that
we
basically
have
this
span
that
you
would
have
here,
but
we
just
create
an
additional
span.
A
What
I,
what
I
put
into
the
into
the
old
tab
here,
that
is
basically
this
solution.
So,
let's
back
this
one
out,
so
that's
what
we
want
to
have
and
for
actually
getting
it
through.
There
would
be
some
changes
needed
actually
in
the
in
the
open,
telemetry
spec
about
span
creation
that
we
allow
creating
links
after
this
ban
was
created.
I
put
up
a
pull
request
for
that,
but
yeah
there
is
some
community
discussion
necessary
to
get
this
through
and
just
to
help.
A
In
those
discussions
like
I
try
to
come
up
with
some
instrumentation
prototypes,
showing
what
we
can
do
with
the
existing
open,
telemetry
instrumentation
and
here.
Basically
that
is
what
I
came
up
with
so
far.
That
is
based
on
the
example
I
showed
last
time.
It's
just
a
little
like
mqb
producer
broker
consumer
application,
and
that
is
actually.
A
Basically,
here
we
have
this
receive
span
that
we
have
also
into
specification,
but
the
problem
we
have
now.
We
cannot
put
links
on
this
receive
spam
because
we
start
to
receive
spam
and
then
message.
My
messages
might
trickle
in
during
this
receive
span,
duration,
and
at
the
beginning
we
don't
know
yet
which
which
messages
are
trickling
in,
and
we
don't
know
the
contexts
to
link
to
so
one
possible
solution.
Here
is
just
that
yeah.
We
just
create
a
span
for
each
message.
Each
message
that
trickles
in
like
here
we
have
one.
A
So
here,
basically,
we
have
this
receive
span
and
this
receive
span
returns
four
messages
to
the
caller
of
this
receive
operation,
and
then
here
we
have
four
child
spans
that
link
to
the
creation
context
of
those
messages.
So
that
is
basically
one
variation
of
what
ludmilla
kind
of
did
here.
As
the
solution
three-
which
is
a
workaround
for
solution
two-
and
there
is
an
other
example-
I
have
two
it's
this
one
yeah,
and
that
is
basically
simplification.
A
That
is
that
that
does
not
really
make
sense
at
all
and
actually
obfuscates
traces.
So
definitely
what
we
want
to
have
and
what
we'll
try
to
push
for
is
that
we
that
we
ditch
this
restriction
of
adding
gangs
and
that
we
allow
adding
inks
to
a
span
after
the
span
was
started,
because
with
this
we
just
would
then
have
here.
A
Then
we
see
here
because
there
could
be
messages
prefetched
before
receive
is
even
called,
and
then
those
kind
of
what
those
contexts
would
need
to
be
would
need
to
be
put
somewhere
too,
and
I
think
the
keenest
ways
just
to
have
yeah
from
the
for
from
the
instrument.
The
cleanest
way
from
the
instrumentation
side
is
just
having
a
receive
span
and
having
all
links
on
this
receive
spam,
because
that's
also
what
the
what
the
user
sees
in
the
application.
A
The
user
calls
receive
and
gets
a
list
of
spans
back,
and
I
think
that's
what
we
should
mirror
in
the
instrumentation.
There's
a
receive
span
with
the
list
of
spans
that
are
returned
by
it
and
in
many
cases
or
in
most
cases,
users
will
not
care
about
the
details
about
what
happens
underneath
and
for
for
those
cases
where
the
user
cares.
I
mean
we
leave.
A
I
think
our
specification
should
leave
three
hands
free
hand
to
the
sdks
to
implement
like
the
inter
instrumentations
of
the
internals
as
they
wish,
but
I
think,
as
a
smallest
common
denominator
and
there's
a
minimum
of
requirement,
it's
a
good.
It's
the
best
solution,
but
miller
came
up
here
with
just
having
this
single
receive
span.
That
then
has
links
to
to
the
creation
contexts.
A
D
A
Yes,
I
mean
the
question
is
also:
what
do
we
mean
by
delivery
here,
because
for
from
from
the
user
point
of
view,
the
user
trust
calls
receive
and
basically
vendor
receives
when
to
receive
a
call
returns,
the
receive
the
receive
card
turns
returns
like
a
list
of
spans
to
the
user.
So
I
think,
from
from
the
operation
perspective
it's
hard
to
describe
here.
What
does
delivery
mean
in
this
context?
A
I
think
in
in
most
regards
it
will
just
be
maybe
a
return
statement
at
the
end
of
the
receive
function,
and
I
I
think
in
this
context,
the
delivery
span
delivers
ban
here
doesn't
really
make
sense,
because
here,
what
is
the
work
that
is
done
during
this
delivery
and
what
is
the
duration
of
this
delivery?
I
think
it
makes
much
more
sense
to
to
include
this
in
just
into
this
receive
duration
that
we
have
here.
D
A
Because
it's
basically
it's
basically
this
this
this
scenario
here
I
mean:
that's,
that's
a
good
summary
how
ludmila
started
this
there's
just
this
receive
car,
and
it's
it's
hard.
I
think,
to
find
some
kind
of
description
or
justification
here
for
describing
a
delivery
operation
in
in
in
in
this
scenario,
which
is
different
to
the
to
the
push-based
scenario
where,
where
the
sdk
calls
the
callback.
D
If
the
receiver
would
get
like
a
callback
and
call
it
when
the
data
is
ready,
then
it's
does
it
make
sense
in
this
case,
because
then
you
have
like
delivery.
It's
just
the
duration
of
running
the
callback
function
right.
A
I
think,
then
we
are
actually
more.
That's
that's.
That
seems
to
be
like
a
hybrid
between
push
and
pull
based.
I
I
think
in
that
instance,
I
would
more
tend
toward
doing
the
to
tend
toward
doing
the
the
push-based
instrumentation.
D
So
it's
but
anyway
it
doesn't
really
matter
like
just
trying
to
think.
If,
if
it's
not
possible
to
add
links
after
spam
creation,
what
would
be
the
alternative
and
how
bad
will
it
be
like
me
personally,
I
don't
think
it
will
be
that
bad.
It
might
be
a
bit
more
confusing
and
a
bit
more
data
like
there
will
be
an
extra
spam,
but
it
will
make
things
more
structured
in
some
cases,
which
does
have
benefits
and.
A
Yeah,
I
think
the
main
problem
here
is
then
with
the
additional
spans
is
what
I
mean
every
span
should
map
to
an
operation,
and
I
think
the
question
here
is
to
what
what
operation
should
this
span
map
here,
that
the
this
band,
that
kind
of
then
has
the
links
on
it,
because,
with
the
current
limitation,
they
can
only
create
these
bands
once
we
have
all
the
messages
that
the
receive
span
is
supposed
to
return,
and
at
that
point
the
when
writing
instrumentation.
A
I
think
the
question
is
here:
what
what
what
operations
should
this
span
kind
of
encompass
at
this
point
and
what
duration
should
this
ban?
Have
I
mean
when
you
look
at
this
duration?
What
what?
What?
What
kind
of
what
conclusions
do
you
draw.
A
D
I
agree
that
it
doesn't
make
a
lot
of
sense.
It
can
be
a
bit
confusing
what
I'm
trying
to
think
at
aspect.
We
support
sampling,
vr
messaging
systems
like
if,
if
a
message
was
sampled
on
the
producer
side,
then
we
guarantee
that
we
will
continue
the
trace
on
the
consumer
side
and
I'm
trying
to
think
how
we
can
implement
it.
In
this
scenario,
where
links
are
added
like
after
spam
creation,
I
will
try
to
to
think
how
this
can
be
done
for
the
next
week.
A
That'd
be
great,
and,
and
maybe
amir
if
you
could
have
a
look
at
these
two
like
push
and
pull-based
scenarios,
and
maybe
here
and
maybe
see
if
that,
if
those
two
cover
the
scenarios
that
you
encountered
or
if
there
are
other
scenarios
that
are
not
covered
by
those
two
kind
of
cases
here,
because
it
it
seems
we
have.
You
described
this
one
case
where
we
have
the
receive
that
gets
a
callback
passed,
and
I
think
here
it's
it's
an
open
question.
What
actually?
A
We
would
best
do
there,
because
here
we
in
in
that
case,
we
would
have
some
kind
of
delivery
span,
that
maps
to
the
to
this
push
based
scenario,
because
this
delivers
band
that
we
specify
here.
Basically,
it's
supposed
to
be
created
for
callback
or
handler
that
is
registered,
but
we
also
somehow
have
this
pull-based
scenario,
because
we
have
this
invocation
of
the
receive
method.
A
A
So
I
will
try
to
push
this
pr
forward
there
for
the
spec
changes,
and
I
will
also
try
to
to
clean
up
the
pr
here
with
some
wording
there.
Still.
I
think
that
paragraph
can
actually
go
out
because
that
is
covered
here,
so
I
will
just
try
to
clean
it
up
a
bit.
I
hope
it
got
a
bit
clearer
by
separating
out
the
actual
normative
sections,
because
yeah
that
is
basically
the
normative
language,
and
here
we
just
have
explanation,
so
I
hope
that
helps
a
bit
and
then
next
week.
D
I
want
to
update
that.
I
started
there
working
on
transforming
the
existing
rabbitmq
client
in
node,
like
I
try
to
change
it
to
match
what
we
were
talking
about
on
the
last
few
months.
So
I
already
have
like
a
lot
of
questions
and
things
that
I'm
not
sure
what's
the
right
way
to
do,
but
I
think
maybe
for
next
week
I
will
be
ready
with
like
a
summary
or
a
diff
of
things
that
I
needed
to
add
like
to
change
from
the
current
implementation.
A
That
would
be
really
great
actually
army,
if
you
could
have
that
like
next
week,
maybe
focusing
on
the
consumer
instrumentation,
because
we
didn't
talk
much
about
producer
instrumentation
yet,
but
if
you
could
could
get,
could
give
a
summary
from
this.
Focusing
on
the
consumer.
Instrumentation
for
rapid
mq
would
that'd
be
awesome.
D
Yeah
so
actually
rabbit.
Mq
is
very
easy.
It
does
no
batching
and
it's
push
based
and
you
can
only
send
one
message
and
consume
one
message.
So
this
is
why
I
started
with
it,
because
all
those
complex
scenarios
are
not
present.
So
if
somebody
wants
to
to
discuss
it
out
of
the
thing
write
mean
slack
I'll,
be
very
glad
to
share
and
be
prepared
for
next
week,
that'd.
A
Okay,
if
there's
nothing
else
from
anybody's
side,
let's
say
the
and
three
minutes
earlier
today.