►
From YouTube: 2022-04-07 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
A
A
If
we
can,
if
we
can
start
having
a
look
at
the
project
board,
I
kind
of
stopped
tracking
the
like
the
to-do
items
like
we
did
here
in
the
in
the
meeting
notes,
and
I
tried
to
put
it
all
in
here-
it's
pretty
much
the
same
as
last
time.
The
only
thing
I
did
that
other
and
I
added
in
column
here
in
progress
so
that
stuff
that
is
currently
be
worked
on.
A
So
we
obviously
we
have
this
old
tab,
that's
kind
of
a
bit
a
big
overall,
the
big
overtalk
documentary
capturing
our
discussion
results.
A
Then
what
we
are
currently
talking
about
is
the
settlement
instrumentation
and
those
last
two
items.
Those
are
related
to
these
pool
based
consumer
instrumentation
conventions
and
basically
the
links
like
these
changes
that
we
would
need
for
links
to
kind
of
structure.
This,
as
you
would
like
you
to
structure
so
for
this
to
wrap
up
this,
we
would
need
to
kind
of
come
to
some
agreement
with
bogdan,
and
I
actually
I
I
pinged
him
for
the
last
two
times
and
he
apparently
didn't
make
it.
A
I
forgot
to
ping
him
yesterday,
so
we'll
just
try,
maybe
to
sync
up
with
him
at
a
different
time.
I
hope
that
works
better
for
him
or
there's
the
advantage
that
we
don't
block
people
here
in
the
meeting,
because
discussing
with
him
would
be
basically
discussing
things
that
we
anyway
already
discussed
pretty
extensively.
So
we
have
some
kind
of
agreement
there
and
it's
just
getting
explaining
it
to
him
and
getting
his
opinion
on
that.
But
those
are
basically
those
last
two
points
here.
A
So
those
as
I
said,
we'll
try
to
sync
up
with
him
offline
regarding
that,
so
that
shouldn't
block
us.
So
we
can
basically
continue
looking
into
the
settlement
conventions
that
we
started
last
time
and
I
oops
I'm
gonna
do
that
and
what
I
last
time
we
had
a
good
discussion
and
I
tried
to
capture
the
results
in
the
old
tap.
A
So
also
for
other
settlement,
we
say
we
also
want
a
saddle
span
and
for
those
other
settlement
cases
it
is
kind
of
recommended
that
this
saddle
span
is
a
sibling
to
the
deliver
span
so
that
we
have
both
of
them
kind
of
grouped
together
I
mean
I,
I
laid
it
out
in
two
examples.
A
So
here
we
basically
we
have
to
deliver
spam,
that's
what
we
are
used
to
anyway
and
basically,
when
the
span
is
settled
during
this
kind
of
deliver
operation
in
a
manual
way,
then
this
settles
then,
would
be
a
child,
or
maybe
some
kind
of
grandchild
or
whatever
of
this
deliver
span
here.
A
So
here
we
see,
we
have
the
deliver
span
and
the
saddle
span
basically
is
a
child
of
this
deliver
span.
This
is
the
case
of
manual
settlement
in
this
push-based
instrumentation.
Of
course,
it
can
be
more
complicated,
like
the
settlement
can
happen
like
in
a
different
thread.
Maybe
after
this
deliver
is
done,
but
this
is
kind
of
the
other,
let's
say
the
happy
day
scenario,
and
then
there
is
the
second
example
I
added
here-
and
this
is
a
push-based
consumer
with
other
settlement.
A
So
it's
basically
pretty
much
the
same
scenarios
here
except
here,
not
the
user
is
settling
it
manually,
but
here
basically
based
on
the
return
value
of
the
deliver
span.
The
sdk
is
then
triggering
a
settlement
operation
and
what
we
recommend
here
to
make
this
span
siblings.
There
should
be
some
kind
of
ambient
span
that
is
created
by
the
sdk.
A
A
This
callback
might
have
trial
spams
depending
on
what
the
user
instruments
and
then
once
this
callback
returns,
the
sdk
calls
a
settlement
operation
and
this
we
have
covered
here
and
those
are
basically
siblings.
More
or
less
I
mean
here
we
had
some
discussions
about
it
last
time.
In
terms
of
the
semantics,
we
see
a
slight
difference
here
in
the
first
case
here.
A
This
delivers
span
basically
includes
the
time
needed
for
settlement,
because
we
have
this
settlement
as
a
child
span
here
and
here
in
this
case,
the
delivery
span
does
not
include
the
time
spent
in
settlement
because
it's
a
separate
span,
so
that's
kind
of
a
slight
semantic
difference.
I
am
not
a
difference
or
inconsistency.
You
may
call
it.
A
I
I'd
be
curious
about
your
opinion,
I'm
not
that
worried
about
it,
because
when
you
look
at
the
span
structure
here,
it
should
be
then
pretty
obvious
that
here
the
settlement
time
is
included
in
delivery,
and
here
it
is
not
it.
A
It
only
might
be
a
problem
when
you
look
at
maybe
traces
like
if
you
analyze
your
traces
in
a
different
way
that
you
just
look
at
like
the
overall
average
like
time
of
deliveries
and
in
some
cases
your
settlement
included
in
other
instances,
you
don't
have
it
included,
but
yeah.
As
I
said,
I
don't
think
it's
it's
that
big
of
a
problem.
I
think
the
advantage
here
we
have
here
is
that
you
look
at
the
trace
in
both
cases,
and
you
see
really
very
well
what
is
happening
on
the
on
the
application
side.
A
D
So
in
the
first
case,
you
kind
of
have
no
choice
but
to
include
the
subtle
within
the
scope
of
the
the
deliver
span
right
because
it's
yeah,
you
start
it
before
the
application
takes
control
and
now
the
application's
calling
settle.
In
the
second
case,
I
guess
you
have
a
choice
which
way
to
go
right.
D
D
So
maybe
that's
the
rationale,
but
one
other
thing
I
wanted
to
bring
up-
which
I
think
we
kind
of
agreed
upon
before-
but
I
don't
see
reflected
here-
is
that,
if
that's
in
in
the
auto
settlement
case
there,
if
the
settlement
is
sort
of
a
effectively
a
zero
span,
zero
duration
span,
I
think
we
discussed
the
possibility
of
including
information
and
delivery
span.
D
That
indicates
the
outcome
of
the
callback
and
that
it
was
auto
settled,
and
then
we
wouldn't
generate
a
settle
and
span
in
that
case,
I'm
not
sure
what
your
thoughts
are
on
that.
A
That
is
a
very
good
point
that
indeed
I
missed
it
here.
We'll
add
that
that
we
basically
say
a
settlement
can
either
be
a
span
or
it
can
be
an
it
can
also
be
captured
by
an
event
on
the
delivery
span
on
the
delivery
on
the
delivery
span.
In
that
instance
on
and
here
it
might
be
like
an
event
on
the
ambient
span,
actually
the
the
settlement,
I
I
will
that's
a
good
card.
I
will
add
that,
thanks
to
the
to
the
dock,.
D
B
Option
that
I
think
it
is
possible
that
the
delivery
span,
even
in
this
case,
will
be
shorter
than
the
saturn
like
will
end
before
the
settlement,
because
maybe
this
settlement
is
like
a
passing
operation
which
is
not
awaited
or
something
that
happens
later.
So,
even
though
this
will
probably
be
the
common
case.
I
think
that
I'm
always
following
possibilities
to
how
they
are
organized.
A
Yes,
definitely
so
those
are
kind
of
happy
day
scenarios
would
call
them
to
look
very
simple,
but
in
many
use
cases
yeah.
The
settlement
span
might
be
completely
discovered
from
the
deliver
span
here,
and
here
too
I
mean
you
might
basically
just
just
store
your
messages
here,
maybe
in
other
like
channels
or
cues
and
process
them
like
asynchronously
and
then
settle
happens
in
a
completely
different
thread
that
is
decoupled
from
this
deliver
span
here.
A
So
definitely
that
is,
that
is
an
that
is
a
possibility
and
we
will
try
it
with
this
example
here,
just
kind
of
to
illustrate
like
the
basic
way
of
thinking
and,
of
course,
things
in
the
end
will
be
in
many
cases
more
complicated
than
what
we
see
here.
B
Yes,
so
that
is
one
thing
and
regarding
the
link
between
settlement
to
the
river,
and
we
want
to
show
it
in
this
diagram
as
well,
because
here
the
settlement
is
always
the
child
of
the
deliver.
If
I
understand
correctly
or
sibling
of
the
delivery
so,
but
it
is
possible
that
it
will
not
be,
and
then
we
have
to
link
them
somehow
to
signal
that
this
settlement
is
for
this
delivery.
A
Yes,
so
for
for
links,
I
would
actually
like
to
to
discuss
that
today.
What
exactly
we
gonna
prescribe
here
for
links.
I
would
I
want
to
switch
then,
maybe
to
your
document
amir,
because
there
you
have
it
very
well
laid
out,
because
I
didn't
write
anything
down
for
like
linking
those
settlement
span
yet
and
yeah.
A
If
you
are,
if,
if
there's
nothing
more,
if
you're
kind
of,
if
you
agree
on
this
basic
layout
here,
then
I
would
then
I
would
suggest
we
switch
over
to
army's
document
and
and
talk
about
how
to
link
those
together,
because
two
two
things
missing
here
is:
first,
I
think
there
we
should
consider
also
like
batch
settlements.
A
Here,
it's
always
like
a
single
message
that
is
settled,
and
we
also
need
to
consider
the
the
possibility
of
linking
those
settlements,
bands
to
delivery
spans
and
maybe
publish
fans.
So
we
need
to
agree
on
what
to
prescribe
there.
A
Oh
and
one
example,
more
added
just
give
another.
Second,
I
also
added
something
for
the
yeah
for
the
pull
based
instrumentation.
So
here,
basically
it's
it's
anyway,
more
of
the
same
here
for
pull
based
instrumentations
for
anyway,
such
as
creating
an
ambient
span,
and
here
in,
like
the
simple
case
also,
those
settlement
spans
would
be
children
of
this
nbn
span.
A
That
also
has
the
receive
span,
so
it's
actually
pretty
similar
to
the
second
in
terms
of
the
structure,
to
the
second
options,
that
is
always
the
delivery
span
with
the
ambient
span
here,
just
instead
of
delivery
we
have
received,
and
then
the
settlements
are
also
children
of
this
of
this
ambient
span.
Here.
A
And
somehow
here
in
between,
I
left
this
out,
then
processing
might
happen
so
receiving
the
processing
and
then
settling
and
yeah.
In
the
happy
day
scenario,
it's
all
kind
of
happening
under
the
same
parent
span
here,
but
can,
of
course,
in
like
real
world
cases,
also
be
like
split
up
over
like
different
traces,
even
so
yeah.
That
was
the
third
example
I
added.
A
Okay,
then,
I
suggest
we
switch
over
to
amir
stock
here
and
talk
about
the.
A
Talk
about
the
case
of
linking
to
settlement
spans
together,
I
mean
army
first,
I
I
wondered:
did
you
have
any
thoughts
about
kind
of
a
batch
settlement.
B
So
I
think
the
linking
model
that
I
suggested
covers
it
very
well,
because
when
you
have
the
links,
then
you
can
have
like
a
settlement
spam
with
10
links.
Maybe
and
those
are
pointing
to
the
public,
spend
that
generated
them
or
to
the
to
the
createspan
or
whatever.
We
call
it
like
the
publish
per
message,
so
everything
can
be
concluded
by
following
the
links.
B
So
if
you
see
a
settlement-
and
you
don't
show
what
it
settles,
you
can
always
follow,
either
the
delivery
link
to
see
how
it
was
processed,
all
the
create
links
to
see
which
messages
are
involved
and
maybe
link
them
like
you
can
look
at
the
message
in
the
when
it's
sent
and
can
conclude
if
it
was
settled
or
not
like
if
you
find
something
pointing
to
it,
a
link
pointing
to
it.
So
it's
very.
B
It
covers,
in
my
opinion,
all
the
edge
cases,
because
the
settlement
will
not
always
sure
if
it's
a
sibling
to
the
delivery
or
a
child
of
the
delivery,
or
maybe
it's
in
its
own
place.
Sometime
later,
maybe
it
doesn't
even
exist
and
it's
valid
that
it's
not
exist
because
we're
not
doing
any
settlement.
A
Yes,
I
think
one
difference
here
that
came
to
my
mind
is
that
we,
when
we
talk
about
when
we
have
the
link
of
the
delivery
to
the
create
here,
and
that
is
kind
of
a
link
that
we
pretty
much
that's
pretty
much
a
hard
requirement.
A
I
mean
I
didn't
put
it
as
in
the
in
the
semantic
convention
system
as
a
must,
because
I
want
to
kind
of
avoid
using
must,
because
it's
very
strong
for
like
for
these
conventions
that
we
are
working
on
here
so,
but
I
made
this
should,
which
is
basically,
if
you
don't
have
any
good
reasons
not
to
do
it,
then
you
should
create
this
link
from
delivery
to
create
for
settlement.
A
I
think
the
situation
is
a
bit
more
difficult,
because
I
think
there
are
quite
s
quite
a
bunch
of
situation,
just
thinking
about
the
checkpoint
based
settlement,
where
we
cannot
basically
create
a
link
to
every
create
and
be
maybe
it's
possible
to
create
a
link
to
delivery,
but
it
will
be
impossible
hard
to
create
like
links
to
the
great
spans.
So
I
think
the
the
link
from
delivery
to
great,
I
think,
that's
kind
of
a
hard
requirement.
A
I
think
the
settlement
links
might,
in
many
cases,
be
just
yeah
a
best
effort
thing
that
we
that
we
kind
of
we
we
just
asked
kia
for
best
effort
here
to
create
those
links
if
it's
possible,
but
if
not,
then
I
mean
I
actually
wonder
here
whether
we
should
differentiate
between
the
individual
settlement,
where
this
creating
these
links
is
possible
and
between
checkpoint
settlement,
where
creating
these
links
is
not
possible.
In
most
of
the
cases.
B
Yes,
I
wrote
three
messaging
instrumentations
from
scratch
and
I
also
reviewed
many
pros
on
on
the
instrumentations
and
it's
very
difficult
to
sometimes
to
follow
the
spec.
Like
the
spec
says
you
must
do
something,
but
there
is
no
technical
way
to
do
it,
so
there
is
really
nothing
to
do
except
not
doing
according
to
the
spec,
and
it's
not
something
like
http,
where
you
know
that
you
always
have
a
status
code
and
the
method
and
the
horse.
So
it's
it's
a
lot.
B
B
A
Yes,
it
might
be
possible
in
the
rabbit
case,
but
I
know
of
some
checkpoint
based
systems
like,
for
example,
the
azure
event
hubs
where
it's
definitely
not
possible
you
might.
You
might
be
able
to
link
to
the
basically
to
the
message
that
corresponds
to
this
checkpoint
in
the
stream,
but
you
will
not
be
able
to
link
to
the
messages
before
that
are
also
settled
with
remove
moving
this
checkpoint.
I
mean
it's
what
it's
possible,
of
course,
but
it
would
be
really
lots
of
effort
to
kind
of
determine.
Okay.
Vr
was
actually
the
last
checkpoint.
A
What
is
in
between
and
then
actually
I
think
it's
not
it's
not
even
possible
in
our
cases,
because
you're
not
able
to
like
get
the
context
for
all
those
kind
of
messages
that
were
settled
so
but,
as
I
said,
I
think,
let's
try
to
formulate
it
as
some
kind
of
best
effort
recommendation
that
we
say:
okay,
we
recommend
creating
links
to
create
and
do
the
related
delivery
operations,
because
I
also
think
that-
and
I
think
we
quickly
touched
about
this
last
time
even
like
linking
to
the
delivery
here-
is
not
that
easy
in
all
cases,
because
what
you
have
in
in
settlement
here
you
have
like.
A
Basically,
you
get
the
message
more
or
less,
but
you
don't
really
can
associate
or
often
you
don't
can
associate
this
message
with
the
delivery
span.
This
message
came
from
so
you
would
need
like
an
other
mechanism
of
kind
of
additional
context
propagation
to
to
to
forward
this
delivery
context
to
the
settlement
span,
because
often
they
are
probably
not
going
to
be
just
the
apparent
child.
I
mean
in
some
cases
they
might
be.
This
is
the
parent.
A
C
I
I
mean,
I
think,
for
the
for
the
link
to
the
create
messages.
I
think
we
can
just
like
use
the
the
terminology
that
I
see
like
in
this
case
like
may
like
may
and
like,
if,
if
possible,
the
the
like,
if
possible,
instrumentation
may
add
links
to
to
the
crate
but
to
the
delivery.
C
I
I
feel
that
if
we
even
if
we
like,
even
if
we
say
that,
if
possible,
you
can
add,
but
then
we
will
have
to
probably
describe
how
you
would
propagate
this,
because
you
would
need
some
sort
of
new
co
put
the
deliveries,
context
inside
the
message,
so
you
can
able
to
access
and
then
that
would
need
to
somehow
describe
how
people
would
do
that,
because
otherwise
it's
gonna
be
a
bit
a
bit
of
a
mess.
C
So
I
I
I
wonder
if
we
even
should
add
this
in
a
suggestion,
because
if
we
add
a
suggestion,
I
feel
that
we
probably
also
need
to
to
investigate
how
this
would
be
done
and
and
for
example,
like
how
to
name
the
field
in
the
message
that
you
add
the
metadata,
for
example
right.
So
maybe
as
if
you
want
we
can
we
can
we
can
just
not
do
it
and
just
add
a
may
or
you
may
add,
link
to
the
to
the
great
masses
on
the
settlement.
That's
it.
I
guess,
sir.
A
Yes,
I
think
that's
fine.
For
me,
I
mean
we
can
mention
the
possibility
like
in
in
how
to
say,
non-normative
language,
but
I
mean
recommendations
anywhere
mostly
like
formulated
in
like
non-normative
language,
so
there's
no
may
or
or
should
or
must-
and
it's
just
basically
okay.
So
it's
really
it's
really
loose.
Okay,
yeah!
A
I
I
think
that
if
it's
a
recommendation,
I
would
formulate
it
very
loose
and
for
the
settlement
to
create
to
the
create
we
can
make
it
in
may
I
mean
I
mean
another,
an
other
thing
that
comes
here
to
my
mind
and
it
ties
in
what
like
what
the
boxton
said,
and
maybe
we
come
to
that
later.
When
we
talk
about
attributes,
but
we
will
have
then
here
we
will
basically
for
the
great
span
we
will
have
links
from
delivery
and
we'll
also
have
links
from
settlement
and
maybe
at
a
later
point.
A
We
then
would
need
maybe
to
talk
about
how
to
distinguish
those
links
that
that
was
some
point.
That
kind
of
bog
down
was
referring
to.
You
have
lots
of
links
pointing
around,
but
you
don't
really
know
exactly
about
the
semantics
of
those
things.
Of
course,
here
you
can
a
kind
of
this
one
link
you
could
just
could
just
look
at
the
destination
or
to
the
source
and
say:
okay,
here's
one
link
and
this
plan
is
called
delivery
and
there's
another
link
and
the
span
is
called
settle.
A
Okay,
so
we
know
what
this
link
is
about,
but
it
already
requires
that
you
have
all
the
links
resolved
and
maybe
you
want
to
for,
like
maybe
some
optimized
use
cases.
No
word
know
what
the
link
means
before
you
resolve
the
link
and
you
and
you
just
like
see
the
link.
Anyone
is
this,
like
the
link,
does
this
link
to
the
delivery,
or
does
this
link
to
the
settlement?
A
B
I
think
we
discussed
it
a
few
months
ago
and
we
talked
about
adding
link
attributes,
so
we
can
have
like
a
messaging
dot,
something
equals
delivery
or
messaging
sequence,
create.
A
A
We
should
basically
talk
about
how
to
kind
of
give
some
kind
of
semantic
meaning
to
those
links
that
we
are
creating
here
and
I'm
just
mentioning
it,
because
it
ties
in
with
something
that
bogdan
kind
of
suggested
when
he
asked
basically
for
some
kind
of
semantic
conventions
that
are
not
independent
of
messaging,
but
some
semantic
conventions
regarding
regarding
regarding
things
and
how
to
kind
of
give
some
better
semantic
kind
of
meaning.
E
A
Really
well
yeah
awesome,
okay,
so
I
I
think
for
the
settlement
discussion.
A
I
will
basically
put
it
in
the
spec
for
the
discuss
just
now,
the
basically
the
additional
possibility
of
it
being
an
event
and
also
what
we
this
loose
recommendation
regarding
links
here
and
then
maybe
we
can
review
one
more
next
time
and
see
if
everything
is
captured
properly
and
then
now
we
can
switch
over
to
discussing
about
links
in
general.
With
your
book
down.
A
A
I
think
last
time
we
we
stopped
here.
E
A
This
like
more
complex
scenario,
and
maybe
we
can
just
continue
here
because
this
scenario
here-
that's
the
one
where
we
would
need
the
I
think
for
links.
We
had
like
two
big
topics:
the
first
one
was
kind
of
giving
a
more
kind
of
more
semantic
information
about
links
in
general.
A
That
was,
I
think,
that's
a
big
over
topic,
and
the
second
part
is
what
we
are
basically
want
to
clarify
for
us
here,
for
this
model
is
the
possibility
of
adding
links
after
span
creation
so
and
for
the
adding
links
after
spank
creation.
This
here
is
basically
this
use
case
that
we
have
here.
We
have
this
receive
span,
I'm
going
to
link
it
to
the
related
published
bands,
and
only
we
don't
know
when
the
receive
operation
starts
which
publish
spans
to
link
to
which
is
different
here
from
this
deliver
operation.
A
Basically,
here
we
have
a
pool
based,
and
here
we
have
a
push-based
operation.
This
delivery
is
a
car
back
that
we
call
and
in
terms
with
this
callback,
the
messages
are
passed,
and
here
we
know
the
messages
already
when
the
callback
starts.
So
it's
not
it's
not
that
big
of
a
it's.
We
don't
have
this
problem
here,
but
we
have
this
problem
here
with
with
the
with
the
receive
operation,
because
at
this
point
we
don't
know
which
which
publish
operations
to
link
to.
E
Yeah-
and
I
think
I
think
we
also
discussed
there
one
of
my
main
concerns
about
this,
which
is
that
the
two
schemas
don't
look
the
same
for
me
like
if
you
look
at
the
two
two
different
trees
like
span
trees
that
you
produce
here,
they
don't
look
at
all
the
same
and
for
me
for
me,
like
this,
receive,
is
more
or
less
an
ipol
call,
and
somebody
is
waiting
on
a
socket
to
to
receive
something-
or
I
like
this
is
a
this-
is
a
very
simple
way
to
to
describe
the.
E
E
A
I
think
we
can,
I
mean
just
some
words
about
why
we
came
to
these
different
models
and
I
think
the
one
view
one
can
have
is
like
the
the
abstract
kind
of
messaging
point
of
view
where
you
say:
okay
at
some
point,
you
receive
a
message
at
some
point.
You
process
it
and
that's
basically
the
same
for
every
scenario.
You
receive
the
message
you
process
it
and
that's
kind
of
over
model.
A
What
we
saw,
then,
is
that
then,
for
this,
it's
the
same
for
push
and
pull
based.
Obviously,
but
what
we
saw
is
that
for
push
and
pull
based
like
for
the
person,
writing
the
code
and
doing
instrumentation.
It
looks
quite
different
because
here
for
the
pull
based
in
there
for
the
push-based
scenarios
out
here,
when
you
have
just
an
you,
have
a
push-based
sdk
that
passes
messages
via
callback.
But
you
do
the
user
point
of
view.
You
just
see
a
call
back.
A
You
don't
see
anything
else.
You
just
have
a
callback
where
messages
come
in
and
from
the
pull
based
view.
It's
the
the
look,
the
the
view
you
have
like
from
the
code
or
user
side.
It's
different.
You
don't
have
a
callback,
you
actually
have
to
call
this
receive
operation
and
then,
basically
you
are,
you
are
on
your
own
with
processing
the
messages.
E
Yeah
but
but
do
you
ask
so
so
now
I'm
curious,
so
you
know
in
open
telemetry
we
don't
have
only
tracing.
We
have
this
concept
of
of
of
context.
Correct
which
can
carry
trace
context
is
one
of
the
things
that
we
can
carry.
We
can
carry
packages
or
other
things.
So
now
I
understand
how
you
can
work
around
this
and
maybe
maybe
put
something
in
a
link
here
in
this.
But
do
you
want
to
inherit
anything
from
the
context
coming
with
the
push
m1
and
push
m2.
A
E
E
A
I
mean
the
the
context
here.
Basically,
in
both
cases
is
more
or
less
bound
to
the
message,
so
the
message
that
is
received
right
is
delivered
here
or
received
here.
The
context
is
basically
bound
to
this
message,
so
in
somewhere
in
the
message
metadata,
this
kind
of
context
information
is
in
there
and
every
and
every
kind
of
part
that
basically
every
span
or
whatever
every
process
or
operation
that
works
with
this
message
has
this:
has
this
creation
context
as
we
call
it
available
and
at
its
disposal?
A
So
it's
not
that
that
the
receive
span.
Basically
I
mean
the
package
is
an
is
an
interesting
case.
E
E
A
I
think
that
is
a
reasonable,
a
reasonable
idea
for
sure,
because
I
mean
that's
the
that's
the
generality
of
baggage,
you
want
the
receiver
to
kind
of
get
it
and
do
something
with
it.
Yes,.
E
A
In
the
pool
based
thing
here,
it's
not
possible
for
receive.
It
might
be
possible
for
process
here
or
for
later
it's
it's
in
the
pool
base.
You're
right,
it's
definitely
not
possible
for
the
receive
span.
If
you
want
to
do
something
with
the
package,
you
might
need
to
do
it
later
like
after
to
receive
spam
like,
for
example,
when
you
process.
E
A
Yes,
here
we
can
talk
about
basically
propagating
the
context
via,
like
the
the
the
in
application
context,
mechanisms
that
you
have
yes,
but
I
think
that
that
is
an
interesting
point,
but
I
think
it's
anyway,
it
kind
of
gets
very
complicated
once
we
have
like
a
badge
delivery
or
a
bad
receive,
because.
E
E
But
it's
important
that
we
we
propagate
not
only
the
the
trace
part,
we
probably
the
the
other
parts
of
the
context
that
are
part
of
the
the
the
message
anyway.
What
I'm
trying
to
say
is,
I
think
you
need
to
design
a
way
to
do
that
as
well,
and
the
reason
why
I'm
asking
this
is
because
that
will
push
you
a
bit
on
the
pull
base
to
have
to
do
some
delivery
thing.
A
D
A
E
A
Yeah
because
I
mean
another
problem
that
we
talked
about
before
with
with
messaging
and
it
was
way
before
is
when
we
talked
about
context
propagation,
we
basically
have
if
you're
really
accurate,
we
have
for
messaging
systems.
Actually,
there
are
two:
we
see
two
different
kinds
of
contexts
that
we
have
to
deal
with.
We
have
basically
the
the
at
the
creation
context
that
is
created
by
the
consumer
that
is
created
here,
but
then
you
might
have
here,
but
the
message
is
basically
create
the
context
you
put
that
context
of
the
message.
A
That
is
the
creation
context,
but
you
might
have
lots
of
stuff
happening
in
between
here.
You
have
an
intermediary,
maybe
you
passed
a
message
via
http
or
mqp
to
the
to
the
intermediary
here
and
it
in
the
future.
We
also
envision
that
it's
possible
to
instrument
this
transport
context
as
we
call
it
so.
E
Wait
wait
if,
if
that's
the
case,
I
don't
think
I
think.
If
that's
the
case,
if
it's
through
http
is
not
an
asking
message
or
is
not
a
message,
I
mean
the
context
will
be
the.
I
don't
think
the
message
will
have
you.
You
don't
go
deeper
in
the
way
that
you
have
a
context
for
the
carrier
and
you
have
a
context
that
it
is
carried.
A
A
I
think
if
you
wanna
have-
and
we
did
some
experiments
with
that,
if
you
want
to
have
some
like
full-fledged
messaging
operation,
where
you
also
instrument
the
transport
layer,
because
you
can
have
http-
I
mean
you
have.
Usually
you
have
let's
go
up
here.
A
Usually
you
have
this
intermediary
between,
which
is
your
broker
and
you
create
here
and
then
you
send
to
the
broker,
and
I
mean
this
publishing
might
happen
via
http
and
then
here
maybe
the
broker
itself
then
at
the
later
point
sends
out
messages
to
the
consumer
by
http
2..
So
you
have
an
http
request
here.
You
have
an
http
request
here,
but
still
you
won't
be
able
to
link
the
consumer
directly
to
the
producer.
A
Basically,
the
vision
we
have
here
for
like
the
further
future
is
that
we
say:
okay,
we
wanna
have
the
intermediary
instrumented
too,
so
we
kind
of
want
to
track
this
transport,
but
we
also
want
to
be
able
to
directly
link
the
consumer
to
the
producer
and
this
basically,
the
meteor
instrumentation
should
be
like
a
one-off
thing.
You
should
be
able
to
turn
it
off.
If
you
don't
need
this
detail,
but
you
should
be
able
to
turn
it
on
and
it
should
somehow
fit
into
the
overall.
E
A
For
this
yeah
there
is
for
the
transport
layer
instrumentation.
There
is
no
difference
to
any
to
other
to
other
rbc
cars.
I
think
the
only
only
difference
here
is
that,
even
apart
from
that,
no
matter
what
is
here,
you
always
want
to
have
like
a
consistent
way
of
linking
producers
and
consumers
together,
whether
that
lower
level
instrumentation
is
there
or
not.
C
C
Right
because,
with
the
tradition,
we
can
only
have
one
parent
span,
sure
that
was
also
some
of
the
reasons
and.
A
One
of
our
goals,
what
they
come
up
is
that
basically
it's
out
of
scope
for
now
for
us
to
come
up
with
an
intermediary,
instrumentation
and
kind
of
connecting
the
whole
train
together.
But
our
goal
is
with
whatever
we
come
up
with.
It
should
be
extensive
in
a
way
that
this
can
be
added
in
the
future,
because
there
is
definitely
demands
there
to
have
like
the
full,
basically
or
the
intermediary
training
instrumented,
and
we
don't
want
to
come
up
with
anything
that
kind
of
blocks
this
blocks.
These
possibilities.
E
So
so
one
approach
for
doing
that:
okay,
let's,
let's
see
this
intermediary
as
an
opaque
thing.
Okay,
what's
what
what
happens
is?
E
Ideally
we
create
the
span
here
in
the
publish
for
the
entire
batch
and
we
say:
okay,
these
are
using
links.
You
say
these
are
the
messages
associated
with
this
with
this
spam.
Okay,
now
this
pan
becomes
the
the
current
span
or
the
the
contact
span.
Okay,
yes,
this
concrete
pan
will
do
the
normal
rpc
like
path
through
the
intermediary.
Like
we'll
do
an
http
call.
There
will
be
something
there
will
be
another
http
call
to
the
receive
correct
so
so
now
this
is
the
span.
E
This
is
the
span
that
is
doing
the
calls
between
the
everywhere
yeah.
So
with
this,
so
we
have.
We
have
multiple
traces
coming.
We
create
a
new
trace
everything
sinks
into
this
trace.
That
is
now
the
right
one
and
now
at
one
point
we
start
to
split
it
again.
We
start
to.
We
need
to
fend
out
again,
so
we
fan
in
and
now
we
found
out
again.
E
A
Yes,
but
but
but
the
point
is
you
can
I
think
the
main
problem
we
have
here
is
that
we
we
can
never
really
100
rely
on
the
intermediary,
because
when
you,
when
you
talk
about
http,
basically
you
get
that's
an
http
request
here
and
you
have
a
trace
parent
header
on
there
that
comes
from
the
intermediary,
but
what
if
we
might
spread,
we
might
base
ours
back
on?
That
would
say:
okay,
we
require
that
the
intermediary
propagates
the
trace,
but
I
think
that's
something
that
we
currently
cannot
do.
E
E
What,
then,
I
think,
what
I
think,
what
we
will
do
essentially
is
most
likely.
We
will
not
have
a
chance
to
to
do
the
fanning
part
correct,
so
we
will
not
have
to
do
a
chance
to
to
to
to
do
anything
on
the
publish,
but
we
most
likely
gonna
have
a
chance
to
emulate
almost.
Similarly
on
the
received
side,
as
the
context
came
through,
the
intermediary.
A
D
A
That
is
a
requirement
that
we
kind
of
made
here
in
context
propagation,
that
we
don't
rely
on
the
standard,
abc
rpc
propagation
that
we
have,
but
we
require
that
publish
basically
props
the
context
onto
the
message,
and
this
context
is
then
propagated
with
the
message.
Whatever
happens
in
the
intermediary
comes
out
here,
and
we
can
take
the
same
context,
information
from
the
message-
and
we
don't
rely
on
our
pc
propagation
here.
E
A
The
context
of
the
delivery,
if
if,
if.
A
C
An
intermediary-
and
then
you
you
receive
this
from
from
from
that,
then
you
have
this
mba
because
you
receive
the
request,
then
I
guess
so.
Yes,
the
delivery
would
be
that
so
the
delivery
will
be
that
correct.
Yes,
I
I
I
understand.
So
that's
all
yes.
I
mean.
C
A
The
next
you
could
say
that
the
delivery,
basically
parents
to
like
the
intermediary
in
practice-
it's
not
that
easy
because
of
them
sdks
they
do
some
prefetching
of
messages
or
they
kind
of
receive
like
messages
on
a
different
thread,
and
then
delivery
is
called
on
another
thread
so
in
in
real
world
cases.
It's
not
that
simple,
but
in
ideal
cases
we
could
try
to
think
about
it
like
that.
Yes,
that's
a.
E
A
A
E
Correct
so
now
now
now
now
this
clarifies
at
least
for
me,
a
bunch
of
things
clarifies
that
what
it
happens
here
is
a
mechanism,
batching
messages
and
re
re,
the
opposite
of
batching.
I
don't
know,
what's
the
word,
but
essentially
you
you
batch
in
the
publish
and
you
you
unbatch
the
in
the
consumer,
so
so
so.
This
is
how
I
think,
okay
and
now,
how
do
we,
how
do
we?
How
do
we?
E
E
A
A
What
do
you
mean?
First,
you
mean
for
single
message:
you
will
just
link
create
a
parent
yeah,
everything
yeah.
So
so,
let's,
let's
forget
about
and
then
local
talk.
Let's
talk
about
batches,
yes,.
E
A
How
do
we
signal
that?
Let
me
I
mean,
for
example,
here,
for
example,
we
ignore
it
by
having
basically
two
links
to
different
publish
operations.
E
A
Not
necessarily
because,
basically
you
could
have
a
case
where
you,
where
you
produce
single
messages,
but
you
receive
or
you
are
delivered,
they
are
delivered
in
batches.
So
it's
not
it's
not
it's
not
at
all
required
that
that
you
here
receive
the
same
patch
that
was
produced
here.
So
you
might
produce
single
messages,
but
you
might
then
they
might
be
delivered
to
this
batches.
E
Fair
enough,
but
how
do
we
do
our
badge?
If,
if
we
just
put
two
links
there
does
not
mean
batching?
How
do
we
distinguish
that?
That's
not
batching!
That's
unbatching!
That's
that's
at
this
point
we
kind
of
so
we
have
to
somehow
we
need
to
model
this
in
a
way
that
the
back
end
would
be
able
to
understand
that
process.
M1
this
span
process
m1,
is
caused
by
the
publish
m1.
A
Yes,
that
is,
that
is
definitely
a
goal,
but
I
mean
for
process
here.
It's
kind
of
maybe
misleading
again
because
process,
you
might
not
be
messages,
might
also
be
processed,
might
be
processed
in
batches.
So
you
might
have
just
once
been
here,
actually
processing
several
messages,
so
we
cannot
even
require
having
different
process
bands
and.
C
A
D
A
Say:
okay,
you
put
like
attribute
some
process
bands
with
like
message
id
and
therefore
you
can.
You
can
distinguish
here
which
is
processed
here.
I
think
here
for
us
for
this
links
here.
A
The
the
main
goal
we
had
for
this
link
is
actually
that
we
can
say
okay
here
we
have
one
producer
trace
or
two
producer
traces,
and
here
we
have
one
consumer
trace
that
basically
consumes
message
from
those
con
from
those
producer
traces
and
we
and
we
want
to
basically
link
those
traces
together.
A
I
think
we
we
saw
in
our
discussions
that
it's
it's
very
hard
to
actually
go
to
the
span
level
and
say:
okay,
this
band,
this
message
is
produced
and
this
band
is
measured
is
processed.
Ideally,
we
we
would
want
to
have
this
kind
of
low
level
link
on
this
very
kind
of
granular
level,
but
it's
actually
hard
in
real
life.
So
we
kind
of
went
to
step
up
and
said.
Okay,
we
just
want
to
be
able
to
see
like
the
links
on
the
trace
level
and
we
see
okay.
A
Trace
the
span
is
published
in
this
trace,
it
is
delivered
and
for
getting
the
details
of
like
how,
where
is
this
spam
processed,
and
how
exactly
does
it
happen?
You
actually
need
to
it's.
This
is
very
case
specific
and
then
you
would
then
need
to
get
deeper
into
the
trace,
and
maybe
it's
it's
hard
to
have
any
automated
way
of
getting
this
insight.
E
A
E
Yeah,
I'm
I'm
coming
next
week
as
well.
Around
8
30.
E
A
Yes,
for
for
next
week,
I
will
try
to
dig
up
some
examples
that
I
did
because
I
actually
did
some
examples,
including
this
transport
layer
instrumentation
within
the
meteor
instrumentation.
We
had
some
kind
of
jaeger
traces
there
and
then
basically
to
trace
this
with
centimeter
and
without
the
intermediary,
and
maybe
we
can
quickly
walk
through
that
again
next
week.
A
So
we
have
some
kind
of
actual
visualization
of
because
I
think
that
that
that
that
the
case
within
the
meteor
instrumentation
that
was
kind
of
our
more
or
less
as
we
call
it
north
star,
where
we
have
the
whole
train,
basically
instrumented,
and
maybe
we
can
then
go
from
there.
E
E
Let's,
let's
discuss
next
week,
how
can
okay,
I
will
look
into
these
more
as
well.