►
From YouTube: 2022-03-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).
B
Yeah,
so
he's
not
sure
if
he
told
you
what
should
we
do,
I
thought
we
can
go
through
the
agenda.
B
C
B
A
A
F
C
A
Okay,
can
you
see
my
screen?
Yes
yeah,
so
it's
nothing
fancy
it's
just
like
a
visual
representation
of
what
we
discussed
last
time.
So
there
are
three
categories.
A
message
used
send
context.
This
is
actually
what
the
current
specification
is
doing.
So
we
have
the
sense
pen-
and
we
have
this
deliver
spam
and
the
deliver
links
to
the
send
span.
A
D
A
For
example,
this
is
a
one-to-one
example,
so
it's
very
easy,
but
here
is
a
more
complex
example
where
both
the
producers
and
the
consumers
are
batched.
So
we
can
have
this
delivery
span,
it
might
link
to
multiple
sense
pens
and
it
might
have
multiple
links
to
the
same
senseman.
For
example,
if
a
sense
pen
sent
multiple
messages
and
the
consumer
read
a
few
of
those
messages
from
the
same
sender,
then
we
will
have
multiple
links
to
the
same
send
spam
and
we
can
have
another
deliver
that
also
links
to
this
same
send
spam.
A
So
practically
everything
is
possible
in
this
use
case.
So
does
it
make
sense,
do
you
know?
Is
it
clear
enough.
F
I
think
so
that's
the
the
delivery
part
that
we
somewhat
agreed
at
this
point
right.
That's
that's
how
the
the
the
consumer
side
looks
like
more
or
less
that
we
have
been
talking
right.
A
F
A
A
sense
pen
and
for
each
message
we
generate
a
spam
for
this
message
and
then
it's
very
similar
to
before,
but
the
deliver
spans
they
don't
link
to
this
sense
pen.
They
link
to
the
actual
message
that
was
produced
by
the
sender,
so
we
have
a
context
message
and
we
can
create
those
links
more
accurately
as
we
discuss
this
will
like
if,
when
the
publisher
want
to
know
who's
consumed
this
message,
then
it's
very
simple
query.
A
We
just
search
which
links
point
to
this
message
and
we
immediately
get
an
answer
to
this
question,
which
we
couldn't
do
here,
for
example,
if
we
want
to
know
who
consumed
the
message
here,
then
we
have
multiple
links
for
multiple
messages
and
we
can't
make
this
distinguish
of
which
links
refers
to
which
message.
A
A
Another
possibility
is
that
the
message
is
not
a
direct
child
of
the
spend
of
the
send.
Maybe
it
was
created
in
some
other
context
and
then
it
will
have
to
link
to
the
sand,
so
we
can
correlate
them.
Maybe
there
are
some
things
in
the
middle.
I
don't
know
it's
possible
and
the
other
option
is
that
the
message
spins
well
generated
before
the
spell
the
send
span
was
generated.
F
The
so
the
so
the
I'm
sorry
so
the
first
so
the
the
message
links
to
send.
So
the
message
is
created
before
or
or
after
I
I'm
not
sure
got.
I
got
it.
The
middle
one
yeah
this
one.
Yes,.
A
Yes,
so
if
the
message
is
like
produced
by
the
instrumentation,
I
believe
that's.
F
A
I
don't
have
like
a
practical
er
example
like
a
real
world
example
to
give
like
of
the
top
of
my
head,
but
it
is
possible
that
this
message
spans
they're
created
somewhere,
where
they
can't
directly
like
link
or
be
a
child
of
the
sand.
Right,
I
don't
know
if
it's
happening
on
different
contexts
on
different
threads.
B
F
F
Sense,
yes,
but
but
the
middle
case
you
you
mean
so,
for
example,
I
create
the
message
in
my
app
somewhere
and
then
and
then
the
messages
has
a
link
to
the
send
or
or
the
send
has
a
link
to
the
message
in
this
case.
A
F
A
Left
one,
but
we
can't
guarantee
parent
child
relationship.
I
don't
know,
maybe
we.
A
And
then
we
we
create
a
message
spends
on,
like
I
don't
know
like
later
on
on
a
different
context
on
a
different
race.
I
don't
think
it's
common,
but
for
sure
it
is
possible
to
sure
listen
artificially.
We
can
create
this.
A
My
point
is
that
we
have
to
specify
how
we
can
do
the
correlation
between
the
message
understand,
both
in
like
trivial
cases
and
those
edge
cases.
So
we
must
guess
there
is
a
link
to
be
able
to
cover
later.
F
A
Make
sense
in
the
last
diagram
it's
very
similar
to
the
to
the
first
one
so
in
this
diagram,
so
not
the
first
one,
it's
similar
to
this
one.
Here
we
create
a
span
per
message,
and
here
we
do
the
same
thing,
but
we
don't
create
a
span.
We
just
create
a
context
per
message,
so
this
is
why
it
looks
like
a
cloud
it
doesn't
really.
We
don't
have
a
spam
that
we
generate.
A
We
just
create
a
virtual
context
and
use
this
context
to
correlate
the
consumer
and
the
producer
and
to
enumerate
messages
both
on
the
producing
side
and
the
consuming
side,
but
we
don't
generate
the
actual
spam
because
it
can
be
expensive
and
it
doesn't
really
trace
an
operation.
It's
like
book
keeping
data,
so
we
use
some
trick
to
have
this
virtual
spam
yeah.
So
that's
that's
what
I
prepared
for
today.
If
you
want
to
discuss
this
or
something
else,
let
me
know.
F
Yeah
this
this
last
one
is,
I
think,
the
same
as
ludmila
did
a
demonstration
the
other
day
right
with
the
yeah.
This.
F
B
A
Thought
about
it
in
the
last
week
like
try
to
to
think
which
of
these
solutions,
I
think,
is
the
best
and,
to
be
honest,
you
can't
really
like
think
of
one
of
them
and
say
this
is
my
favorite,
like
they
all
have
so
many
issues
and
problems
like
it's
so
difficult
to
to
decide,
which
one
makes
more
sense,
at
least
to
me
and
I'm
kind
of
curious.
A
How
do
you
think
we
should
proceed
with
this
decision
so.
F
It's
really
tricky,
I
mean
the
creating
multiple
spans
is
the
easier
way
for
everybody.
I
think,
but
it's
just
the
status
quo.
I
guess
just
great
to
what
we
have,
but
it
comes
with
all
these
other
problems.
I
mean
not
problems
really,
but
just
it's
just
maybe
unnecessary
constant
and
data
right.
Just
talking.
A
Actually,
maybe
we
can
like
generate
a
table
with
the
three
options
and
like
a
poles
and
cones
just
so
we
have
it
old
enough,
then
we
can
agree
only.
A
Yeah
and
then
once
we
see
the
full
picture,
we
can
be
smarter
and
make
like
a
good
decision
based
on
the.
A
Because
is.
F
F
I
was
wondering
if
we
could,
if
we
could,
maybe
I
don't
know
work
together,
do
something
that
we
try
to
implement
each
of
these
cases
each
of
these
options
and
see
what
what
what
happens
so.
A
A
F
A
So
I
think
it's
it's
very
easy
to
agree
on
it
like
once
we
settle
on
the
batch
case.
It
will
be
very
easy
to
decide
what
we
do
with
the
much
simpler
case
yeah
I
can
have.
I
can
suggest
that
we
can.
We
have
like
two
cases,
one
for
batch
and
one
for
a
single
message
where
we
collapse
this
message
and
send
spam
into
a
single
spend
which
we
agree
how
to
market.
So
we
know
that
this
is
the
case
and
make
everything
simpler.
F
I'm
just
wondering
if
I
was
just
wondering
if
we
have
the
like
a
decision
that
maybe
that
would
help
in
in
modeling
the
other.
But
I
I
guess
that
I
guess
that's
not
true
yeah.
It's,
like
you,
said,
probably
it's
better
to
model
the
complicated
one
and
just
use
the
the
same
to
the
other,
to
the
side.
B
E
Yeah,
what
one
question
I
have
also
is
in
the
case
where
we're
batching
is
the
overhead
acceptable
for
attaching
a
context
to
every
message.
E
Well,
there's,
on
the
one
hand,
there's
the
overhead
of
of
you
know,
generating
all
the
ids
and
things
like
that.
On
the
other
hand,
you're
you're
bloating,
I
guess
the
the
message
is
going
to
to
have
a
size
increase
either
way.
E
Unless
we're
trying
to
store
two
contacts
on
the
message,
then
you
know
it's
some
additional.
It
makes
the
message
heavier
or
larger,
so
yeah.
B
From
what
we
know,
the
batching
mostly
applies
to
transport
level,
so
even
the
systems
that
do
have
a
batching
they
do
it
for
to
save
and
transport
not
to
have
the
same
processing.
So
the
assumption
is
that
they
still
want
individual
messages
to
be
traced
right
and
then
they
would
have
to
have
a
context
for
it
and
then
maybe
it's
a
good
option
that
we
we
allow
to
disable
this
or
allow
to
enable
this.
B
But
yeah
the
defaults
are
important,
but
I
think
it's
I
would
definitely
implement
it.
Customers
are
asking
for
it
from
us
from
our
sdks.
A
I
think
it's
a
really
good
point,
especially
for
like
a
very
big
data
messaging
systems
like
kafka.
Well,
the
message
can
be
very
small.
It
can
be
a
few
bytes
like
number
or
a
show
text,
and
then
we
add,
like
I,
don't
know
tens
of
bytes
adjust
for
the
context
for
it
each
message,
so
it
can
easily
be
very
large
part
of
the
traffic
only
the
context,
but
actually
I
don't
see
any
way
around
it
to
have
an
alternative,
because
the
alternative.
B
B
A
E
B
Oh
yeah,
I'm
sorry
yeah!
Thank
you.
Yes,
so
imagine
we.
We
sent
10
messages
from
the
producer
and
we
assigned
the
context
one
context
to
each
of
them
right.
These
messages
can
even
potentially
be
routed
to
different
places
based
on
their
properties
and
then
imagine
like
on
the
receiver
side.
B
When
we
get
them
well,
we
get
10
different
messages
or
they
routed
correctly,
which
one
we
failed
like
right.
We
don't
know
it's
from
the
tracing
perspective
at
the
same
message.
There
are
some
additional
properties
of
the
message
like
message
id
which
can
be
used,
but
that's
basically
a
substitute
for
correlation.
E
Yeah,
I
I
think,
maybe
that
that
part
is
one
thing.
E
I'm
curious
if
you've
explored
this,
whether
because,
on
the
one
hand,
creating
a
virtual
context
for
a
message
is
sort
of
like
replicating
the
message
id
in
a
way,
but
on
the
other
hand
you
know
message
id
is,
is
just
like
an
attribute,
so,
like
a
tracing
system
that
didn't
know
anything
specifically
about
messages,
maybe
would
lose
some
context
there,
for
if
that
makes
sense,
like
I'm
curious,
does
that
make
sense
like
like
about
how
the
message
id
is
essentially
the
the
virtual
context.
B
I
yeah
it
is
possible
and
I
think
we
joe
proposed
it
last
time.
So
my
I
don't
have
a
very
strong
opinion
here,
but
it
feels
like
we're
trying
to
use
some
legacy
thing
well
legacy
in
a
sense
that
exists
right
and
use
it
instead
of
correlation,
so
it
might
not
fit
into
spanidy.
It
might
be
very
hard
to
make
the
backhands
work.
It
will
be
very
special
treatment
for
everything
messaging
related,
but
it's
not.
I
think,
it's
totally
possible.
E
Might
be
better,
it's
there's
there's
something
just
a
little
funny
about
the
virtual
context
like
it
does.
It
does
make
a
lot
of
sense
from
the
perspective
of
of
you
know,
generating
ids
to
track
all
these
messages
and
link
the
graph
together.
So
it's
like
totally
fine
in
that
regard,
but
there's
the
aspect
of
creating
a
sort
of
we
it's
like
not
actually
a
facility.
E
I
think
we
have
currently
in
open
telemetry
in
the
sense
that
you
would
have
to
actually
like
create
and
record
a
span
when,
when
you
create
in
order
to
create
that
context,.
B
Know
you
can
create
the
context.
Well,
what
I
discovered
the
piston
java.
I
would
have
to
use
sdk
apis
for
it,
but
it's
only
for
a
degeneration.
The
span
context.
I
can
totally
create
it
with
apis,
just
because
we
would
create
it
if
we
need
to
parse.
Let's
say
incoming
http
request
headers
right
in
the
menu
instrumentation,
so
the
id
generation
is
not
a
big
deal.
We
can
tell
how
to
do
it.
We
can
expose
those
apis
potentially
or
like.
I
don't
think
it's
the
api
edition
problem
it's,
but
the
overhead
is
real.
Yeah.
E
Yeah,
but
we
would
have
to
introduce
these
apis.
I
guess
is
what
I'm
saying
it's
that
that's
a
just,
maybe
a
thing
in
the
matrix,
a
column
in
the
matrix
to
consider
is:
can
this
be
done
with
the
existing
open,
telemetry
api,
or
do
we
have
to
actually
add
something?
E
E
Right
right,
but
but
yeah
that
I
guess
that's
a
thing
thing
to
consider:
it
might
not
be
a
terrible
thing
to
to
expose
for
people.
I
I
like
the
idea
of
exposing
it
in
an
opaque
fashion.
Potentially
you
know
which
I
think
we
can
do,
in
other
words,
exposing
it
in
a
way
that
that
doesn't
expose
the
details
of
what's,
in
the
context,
potentially
beyond
what
the
current
api
currently
exposes,
but
just
having
the
ability
to
generate
one
and
then
inject
it.
F
But
what
time,
what
I'm
a
bit
more,
I'm
sorry
go
ahead
now
what
what
I'm
a
bit
more,
let's
say,
concerned
or
or
worried
is
that
I
mean.
I
know
that,
for
example,
links,
I
don't
think,
there's
white
support
for
it
anyway,
and
we
we're
still,
let's
say,
going
to
use
it
for
this.
But
if
we
use
this
virtual
context,
I
think
it's
even
like
another
item
that
is
not
well
supported,
and
I
mean
I
understand
that
we
shouldn't
be
like
pushed
back
because
nobody
supports
it.
F
But
it's
another
thing
that
is
on
the
line
and
then,
if
we
create
this
whole
thing
and
there's
no
support
for
users,
then
it's
I
mean
basically
useless
right
because
nobody's
supporting
the
users
cannot
use
it
or
there's
no
tool
for
actually
use
it.
So.
B
Yeah,
but
to
be
fair,
you
don't
the
this
virtual
context,
it's
not
a
new
problem,
so
imagine
you've
received
the
message
and
there
was
never
a
span
that
created
it,
because
it's
reported
to
a
different
system
right.
F
But
with
with
the
virtual
with
the
virtual
context,
would
you
put
in
the
message
and
then
and
the
consumer
side?
You
would
just
add
a
link
to
it
right,
but
how
would
this
work
if,
if
there
is
no
expand,
it
would
link?
To
I
mean
it
is:
it
depends
how
the
tools
that
would
interpret
this
this,
this
nuance
right.
They
see
the
situation,
how
they
would
how
they
would
show
this
to
the
user
right,
because
it
will
link
to
something
that
doesn't
exist
right.
B
Right,
whatever
saying
that
tools
should
be
available,
I
think
amir
announced
the
case
where
it
actually
needs
a
bit
of
more
support
to
like
index
those
together
like
knowing
that
there
will
never
be
a
crate
span.
I
agree
that
that's
some
work,
some
additional
work,
but
it
doesn't
look
like
it's
a
tons
of
work.
It's
just
the
one
edge
key
of
the
thing
that
we
would
have
to
support
anyway
in
the
back
ends.
F
F
Yeah
yeah
I
can
bring
to
I-
I
can
also
bring
to
the
people
here
at
my
company,
this
situation
to
see
what
they
think
about
it
about
this
virtual
thing
and
what
their
opinion
is
about
it
and
bring
it
on
bring
what
they
say
what
they
think
about
it.
Next
time.
B
No
not
actually,
I
can
also
talk
with
our
portal
experts
that
can
calculate
what
it
would
take.
Yes,.
E
Yeah
and
I
do
agree-
it's
not
it's
not
a
total
blocker,
because
yeah
like
everyone's
mentioned,
like
for
the
most
part,
people
have
not
implemented
links
at
all,
and
so
they're
gonna
have
to
go
back
in
and
it
would
be
great.
This
is
why
it's
like
helpful
for
us
to
like
come
with
a
complete,
stable
model
to
people.
E
And
on
the
api
side,
I
think
one
thing
we've
seen
is
we're
probably
going
to
have
to
provide
extra
tooling
in
the
api
anyways,
because,
unlike
in
other
scenarios,
where
it's
it's
fairly
straightforward
to
encapsulate
kind
of
all
of
the
span,
setup
and
management
it
it
seems
like
in.
There
are
definitely
messaging
scenarios
where
doing
that.
Encapsulation
is
is
difficult
unless
people
have
found
a
way
around
that
and
I
missed
it,
but
it
seems
like
there's.
F
Yeah,
so
in
this
thing
that
I
worked
in
the
beginning
with
the
cloud
events
in
the
go
in
the
goal,
for
example
sdk,
I
had
to
somewhat
expose,
for
example,
like
how
to
extract
the
context
from
the
event,
because
the
the
library
does
it,
but
I
assume
that
in
some
cases
the
user
would
want
to
do
it
in
some
special,
so
it's
x
exposed,
for
example,
all
right
you
just
the
the
for
example.
You
just
pass
the
event
and
and
call
this
function.
F
It
gives
you
the
context
and
the
same
way
around
you
create
a
context
and
give
it
and
I
put
inside.
So
I
don't
think
it's
too
bad
a
thing
to
do.
Exposure.
E
Yeah
but
like
yeah,
I
guess
in
like
the
batching
scenarios,
you
don't
you,
you
might
have
a
at
least
in
some
of
the
code.
I've
written
I'm
not
a
messaging
guest.
Certainly
in
the
batching
scenarios,
it
doesn't
seem
like
the
instrumentation
can
provide
a
a
bounding
like
a
closure
right
like
that
was
the
thing
that
there's
no
there's
no
closure
available.
The
end
user
in
batching
is
the
person
who's
created
the
closure.
E
It's
not
that
their
message
handling
code
is
like
encapsulated
in
a
callback
or
something
like
that,
and
so
attaching
the
contacts
there.
E
Maybe
it's
just
that
they
need
to
ensure
that
they've
set
up
the
closure
and
that's
all
they
have
to
do
and
then,
when
they
call
the
batching
api,
it
would
be
able
to
like
use
links
or
something
to
like
attach
the
message
context
to
the
closure
they've
set
up-
maybe
maybe
that's
all
that
has
to
happen
there
actually,
but.
F
I
think
the
the
the
problematic
is
that
some
some,
I
guess
some
languages
or
some
some
sdks-
they
do
allow
something
like
this,
so
it
would
be
totally
transparent,
but
I,
but
I
guess
some
other
other
other
languages,
and
so
on.
There's
the
case.
It's
not
really
like,
like
a
mere
demo
with
javascript,
for
example,
it's
just.
E
F
E
F
F
Yeah,
some
of
the
the
graphs
that
I
mean
you
just
showed,
I
think,
the
middle
one.
It
would
be
the
one
that
would
require
to
add
links
after
if
I
got
it
right
after
creation,
because
if
you
create
the
message
and
then
you
want
to
link
to
like
depend
which
side
you
want
to
link,
then
at
some
point
you
run
into
this-
that
you
wouldn't,
you
would
need
to
add
after
creation
or
maybe
not,
but.
F
A
But
we
can
do
the
link
the
other
way
like.
E
B
E
Where
you
are
exactly
yeah,
it's
on
the
receive
side
where
we
have
instrumentation
that
you
know
is
being
called
to
hand
you
the
messages
and
it's
handing
you
those
messages
in
the
user
context,
because
the
synchronous
call
and
at
that
point,
if
the
user
set
up
a
span,
these
messages
could
be
linked
to
it
automatically
by
the
instrumentation,
and
that
would
be
really
clean
and
easy.
E
But
that
only
works
if
we
can
do
it
after
the
fact
that
that's
like
specifically
how
that
scenario
is
designed-
and
I
haven't
thought
of
another
way
of
doing
that
with
batch
messages
that
wouldn't
require
the
end
user
doing
something
having
to
like
really
think
about
it
in
those
scenarios,
and
I
don't
like
that
that
part,
because
if
we
can
link
after
the
fact
that
context,
the
end
user
is
in
that
span,
context
could
have
been
set
up
by
their
application
framework
potentially,
and
so
that
keeps
us
in
this
world
where
the
the
application
developer
in
general
is
not
having
to
think
about.
F
E
A
Yep,
I
want
to
add
about
the
virtual
context,
like
the
thing
that
worries
me.
The
most
is
that,
with
a
adding
another.
A
Conceptual
like
we're
extending
open
telemetry
with
something
new
that
does
not
guarantee-
and
it's
like,
I
think,
there's
a
lot
of
value
in
having
like
the
mental
model
and
minimal.
So
users
doesn't
have
to
track
a
lot
of
possible
entities
and
their
connections
like
he
knows
that.
There's
a
link
it
links
to
a
spam.
So
now
we're
telling
him
yeah,
but
it
can
link
to
also
to
something
else,
and
he
has
to
keep
it
in
his
mind.
And
whenever
he's
writing
code,
you
have,
you
have
to
think
wait
a
minute.
A
Maybe
this
link
is
pointing
to
a
span.
I
can
search
my
index
in
the
database,
but
but
it
might
be
some
other
case
which
now
I
have
to
to
have
a
branch
and
a
handle
in
a
second
way.
So
of
course,
it's
completely
doable
like
technically
there's,
no
reason
it
shouldn't
work,
but
it
will
make
the
back
ends
more
complex
and
more
error-prone,
and
people
will
have
to
walk
out
there
on
the
back
end,
which
and
the
other
solutions
are
much
more
native
to
like
how
open
telemetry.
A
F
And
I
also
think
it
would
I
mean
I
I
think
I
I
the
the
the
things
that
you
said.
It's
like
what
I
wanted
to
express
as
well
before
is
the
same,
and
I
think
also
I
mean
this
would
have
to
be
approved
in
this
backwards.
So
I
think
this
would
also
cause
more
or
more,
but
it
would
cause
some
friction
or
because
it
would
have
to
like
it
would
have
to
somehow
persuade
the
others
that
this
new
thing
is
is
necessary
and
so
on.
B
Yeah,
I
would
like
to
remind
couple
of
reasons
why
I
came
up
with
this
proposal.
The
first
one
is
that
we
have
implemented
spam
per
message
and
we
get
consistent
feedback
about
it.
For
that
it's
super
confusing,
so
the
backend
will
still
have
to
visualize
it
in
a
way
that
the
messages
are
understandable,
somehow
right
so,
and
the
other
reason
is
that
that
creates
pen.
B
It
is
still
very
controversial
too,
because
it's
it's
an
artificial
thing,
and
I
I
I
don't
have
any
objections
of
the
this
option-
creates
fun
per
message.
I'm
just
pointing
out
that
there
are
problems
with
it
as
well,
and.
E
E
Unfortunate
but.
E
Yeah
I
it,
I
think
it's
maybe
the
it
correct
me
if
I'm
wrong,
but
basically
the
virtual
context
is
the
same
as
the
create
span,
except
we're
not
recording
like
a
tiny
or
zero
duration
span.
B
E
That
scenario
makes
what
we're
doing
a
little
more
generic,
in
the
sense
that
a
tracing
back
end
wouldn't
have
to
would
have
to
know
less
right,
like
that's
that's
the
case
in
years,
making
right
like
it,
you
you
have
the
issue
that
these
zero
duration
spans
are
stupid
and,
like
that's
al,
always
a
smell
in
open
telemetry.
Whenever
I
found
those
things
have
come
up,
we
found
some
other
way
of
doing
it.
So
like
they're,
a
smell
to
me,
but
but
it
would
essentially
mean
we
could
have
this
model
with
one
less
one.
A
I
think
also,
if
we
don't
create
the
message
spans
like.
If
we
do
create
the
message
spends,
then
we
have
the
advantage
that
we
can
put
some
stuff
in
this
message
spends
like
attributes
and
status.
So
if
we
have
like
a
message
id
destination,
I
don't
know
some
data.
A
That
is
spell
message,
then
it's
very
straightforward
to
add
it
as
attributes
on
this
message
span,
but
if
we
use
the
virtual
spin
and
also
the
attributes
and
also
a
status
code
like
if
a
single
message
was
not
published,
then
it's
very
trivial
that
we
can
set
the
error
code
on
the
on
the
status
of
the
message
span
and
we
can
create
a
duration
for
it
for
the
time
that
it
that
it
took
for
the
server
to
arc
us
like
to
send
the
arc
that
the
message
was
received.
A
A
B
We
have
attributes
and
links
right,
but
then
yeah
the
things
that
we
know
afterwards
are
problematic,
but
also
not
every
system
supports
partial
success
like,
for
example,
if
I
try
to
implement
the
spec,
and
this
spec
is
very
restrictive
in
the
way
that
this
is
the
only
way
to
go,
then
I
would
have
to
copy
this
the
same
outcome
and
duration
on
each
of
the
message
spans
it.
It's
not
a
big
deal.
We
can
do
it,
it's
just
still
not
not
perfect
solution.
B
A
Yeah,
I
think
it's.
It
should
be
valid
that
if
some
attributes
are
common
to
all
the
messages,
then
they
can
go
into
the
sense
span
and
they
don't
have
to
be
repeated
in
each
message
span
like
we
only
have
to
store
things
that
are
a
unique
bell
message
in
this
message:
spans
yeah.
A
If,
if
we
decide
to
go
in
the
virtual
context,
then
we
have
to
think
well,
we
stole
a
bell
message
attributes
and
we
talked
about
links
attributes
and
we
talked
about
creating
arrays
on
as
the
span
attributes
on
the
sunspan,
and
we
talked
about
creating
events
to
store
this
data
and
I'm
not
sure
what
will
be
the
consequences
of
this
approach
on
processing
and
visualizing
and
using
this
data
in
the
backends.
B
C
E
It's
funny
so
this
something
like
this
does
is
has
come
up
on
the
the
rum,
the
client,
instrumentation
sig,
this
sort
of
and
in
in
their
case,
actually
that's
a
place
where
we
actually
found
a
way
around
like
the
way
they
were
thinking
about.
Modeling
some
of
their
things
turned
out
to
to
be
better
doing
it.
A
more
traditional
span,
oriented
way,
but
they
have
like
client-side
events,
and
these
events
correlate
with
other
actions
in
a
causal
way.
E
Things
like
the
user,
pushing
a
button
or
doing
other
stuff,
and
it
was
like
the
exact
same
scenario
where
they
essentially
had
events.
They
wanted
something
like
an
event
system,
like
you
know,
which
we're
looking
at
using
the
logging
system
for
basically
expanding
open,
telemetry
logging.
To
say
this
is
actually
an
events
system,
but
essentially
having
an
event
that
also
had
its
own.
E
You
know
essentially
having
an
event
that,
had
you
know
a
equivalent
of
a
span
id,
but
it's
sort
of
like
a
session
id
and
an
event
id,
and
we
we
escaped
having
to
need
to
need
that.
But
it's
sort
of
like
I
see
something
similar
showing
up
here
with
these
messages
in
a
way
like.
If
we
had
something
like
that
going
on,
then
we
would
already
in
open
telemetry.
We
would
probably
be
grabbing
that
to
store
this
message.
Information.
B
I
see
how
it
can
work
like
when
we
create
a
message.
We
send
this
event
and
it's
maybe
we
can
even
use
message
id
for
this
common
thing
and
then,
when
this
event
is
act
from
the
server
from
the
broker,
we
can
have
another
event
saying:
okay,
it's
active
right
and
then
we
can
stitch
those
two
things
together
and
we
don't
even
need
to
measure
duration.
It's
on
the
same
machine.
It's
fine,
they
use
timestamps,
we
don't.
We
can
attach
attributes.
I
assume
to
those
things.
E
E
The
the
thing
that
I
didn't
like
about
it
was
it:
it
started
to
set
up
two
forms
of
making
a
graph
basically
of
causal
relationships,
and-
and
I
really
like
in
the
case
of
the
client
sig-
it
was
actually
like-
they
should
have
been
thinking
about
it
differently.
They
were
thinking
about
the
user,
clicks
the
checkout
button
and
then
that's
an
event
and
then
other
stuff
happens
later,
but
actually
user
clicking.
The
checkout
button
opens
a
span
that
measures
all
of
the
the
event
handling.
That
comes
after
that.
E
It
closes
when
it's
done
so
so,
in
their
case,
not
having
this
thing
available
actually
resulted
in
doing
the
rest
of
the
modeling
correctly.
E
But
I
don't
know
like
like
it's
just.
I
find
it
interesting
that
that
here
again
we're
in
this
situation
where
we're
saying
like
well
to
do
this
correctly.
What
we
need
to
do
is
create,
like
a
zero
duration
span,
essentially
like
we
don't
really
care
about
the
duration,
but
we
do
care
about
the
moment
it
was
created
and
we
do
want
to
have.
E
E
It
could
also
be
the
case
that
ludmilla
this
would
maybe
be
helpful
to
know
what
the
end
users
care
about,
if,
like
when
a
a
message,
is
created,
it's
created
in
a
context
right
like
an
end,
user's
doing
stuff
and
there's
a
context
available
there.
E
Is
it
the
case
that
just
attaching
the
existing
span
context
when
the
message
was
created
to
the
to
the
message
would
be
enough.
You,
you
wouldn't
then
be
able
to
track
back
to
individual
messages
right,
but
you
would
be
able
to
track
back
to
individual
create
contexts.
E
B
It
makes
sense,
I
understand
what
you
mean
at
the
same
time.
I
don't
think
so,
because
you
can,
you
can
wrote
these
messages
differently
and
you
would
like
to
know
when
one
of
them
fails
which
one
has
failed
and
where
was
it
routed
correctly,
for
example,
were
there
that
correctly
on
this
specific
message,
so.
C
B
E
Having
access
to
the
message
id
like
like,
in
other
words
like
that
final
piece
you're
talking
about,
is
that
the
operator
just
looking
at
this
data
and
then
identifying
the
message
id
themselves
and
the
tracing
system
doesn't
need
that
information
to
create
the
graph
correctly
yeah.
B
But
you're
saying
the
same
thing
as
if
we
just
wrote
traces
into
console
export
all
right
and
let
users
read
through
so
like
there
will
be
no
or
maybe
that
there
there
has
to
be
some
additional
visualization
that
allows
you
to
understand.
Otherwise
you
will
end
up
clicking
and
trying
to
find
by
method
right.
It's
right,
not
great.
D
Then
you
generate
that's
the
end
of
your
span
and
that
span,
but
if
that
acknowledgement
or
knack
hasn't
happened
yet,
then
you
don't
haven't
generated
a
span
and
no
one
can
see
what's
happened,
and
so
it's
almost
like
you
sort
of
want
to
create
an
event
to
say
I've
sent
it
and
it's
almost
like
it's
part
of
it.
It's
like
I
started
the
span,
but
it's
not
done
yet
right.
So
so
that's.
E
Actually,
a
a
protocol
problem
that
we
currently
have,
which
is
open
telemetry,
is
batch
oriented
instead
of
streaming.
This
is
like
this
is
a
giant.
E
I
have
not
been
trying
to
slay
at
the
moment,
because
we
have
so
much
other
stuff
on
our
plate
and
all
of
the
existing
tracing
systems
were
like
really
insensitive
and
consistent
about
having
this
like
batch
model
of
sending
spans,
but
this
comes
up
in
all
kinds
of
scenarios
where,
if
the
way
you
were
the
way
your
protocol
worked,
if
it
was
actually
a
100
streaming
protocol
so
that
it
was,
you
know
not
waiting
for
the
span
to
finish
right,
it
was
just
like
span.
Start
goes
out
on
the
protocol
and
later
span.
E
End
goes
out
on
the
protocol
and
something
further
down.
The
pipe
is
constructing
a
fully
realized
span.
Then
that
allows
you
to
visualize
all
these
scenarios,
where
a
span
isn't
ending,
which
actually
is
a
thing
that
comes
up.
It
comes
up
in
attempting
to
instrument
a
system
and
you
instrument
it
incorrectly.
E
B
E
Never
send
that
span
we
kind
of
get
around
it
in
some
places.
I
think
with
something
like
a
you
know.
You
can
have
like
a
span
time
out
right,
like
you
can
tell
your
system
that
you
know
you.
D
D
All
that
and
what
a
lot
of
people
are
pushing
for,
which
I
don't
like,
because
it
kind
of
comes
down
to
zero
duration
span,
is
saying:
we'll
do
one
span
when
you
send
in
another
span
when
you
hack
it
and
link
them
somehow.
But
it's
like
it's,
it's
not
the
right
way,
but
I
don't
know
what,
but,
but
at
the
same
time,
the
requirement
to
be
able
to
observe
that
that
the
client's
not
acknowledging
the
message
and
so
yeah
yeah.
I
haven't
decided
what
to
do
yet.
E
Yeah
exactly
that
it
does
seem
like
a
situation
where
you
do
want
to
time
out
anyways
right
like
if
this
client
never
comes
back
and
acts.
Your
message
you
still
have
to
handle
that
scenario
right
like.
D
If
it
happened
with
extreme
regularity,
it
could
be
a
problem,
but
frankly
we
just
you
know
for
years
and
years
and
years
this
has
been
acceptable,
behavior
and
that
would
be
sort
of
like
well,
because
we
want
to
add
tracing
we're
going
to
change
our
whole
protocol
under
the
hood
it
just.
It
feels
wrong.
E
E
Yeah,
I
I
think
it
sounds
like
I
mean
you
could
maybe
get
away
with
pilot
milla.
You
could
maybe
get
away
with
just
just
modeling
it
in
the
usual
way-
and
you
know
the
the
time
out
is
the
the
place
where
like
if
well,
I
don't
know
yeah
yeah.
I
I
think
I
think
we're
stuck
with
this
current
model,
like
the
streaming
model
I
just
described
by
the
way,
has
loads
of
its
own
problems,
just
to
be
clear.
E
It's
not
like
we
were
just
using
an
inferior
model
like,
for
example,
routing
becomes
awful
in
that
scenario
where
you
don't
have
complete
spans,
because
you
need
all
that
information
to
end
up
in
one
place
if
you're
going
to
do
further
span,
processing
and
thinking
about
it
right,
so
it
makes
your
it
makes
your
routing
system.
E
Not
just
to
be
clear,
it's
not
like
great
thing.
I
got
my
pocket,
but
that
that's
that's
it's
a
thing
that
comes
up
in
other
scenarios
and
right
now
it's
just
sort
of
like
a
limitation
of
how
tracing
works
is
like.
If
you
have
spans
that
never
end,
then
you
don't
see
that
information,
and
the
only
thing
you
can
really
do
is
have
like
a
max
span.
Global
max
fan,
duration,
set
on
your
tracer
yeah.
That.
B
D
D
E
F
Just
just
so
fyi,
so
I
added
the
agenda
that
we
or
I
don't
know
some.
Some
of
some
of
us
will
drive
this
matrix,
so
we
can
at
least
see
next
time
what
the
options
I'll
just
put
it
there
yeah
I'll
see.
If,
if
I
do
have
time
to
do
it
or
but
I
maybe
I
can
start
and
then
the
others
can
just
fill
up
the
details.
A
F
A
Yeah,
so
let's
synchronize,
if
we're
working
on
it
cool
all
right,
sounds
good.