►
From YouTube: 2021-10-14 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
So
the
first
point
on
the
list:
we
have
the
old
tap
we've
been
working
on
for
the
past
weeks.
So
thanks
everybody
in
this
work
group
for
reviewing
it
you're,
still
trying
to
get
reviews
from
more
or
less
official
approvers,
because
we
need
four
of
those
and
yeah.
That's
just
a
process
that
might
be
still
going
a
bit
on
for
some
time
and
one
point
that
came
up
in
when
armin
from
dynatrace
reviewed
this
old
tap
that
I
wanted
to
raise
here.
A
He
found
he
gave
a
pretty
good
and
detailed
review
and
he
found
like
some
inconsistencies.
A
A
So
basically
this,
if
we
leave
the
sentence
here
like
it
is,
it
means
that
the
intermediary
basically
is
optional,
and
the
message
might
also
just
pass
from
the
producer
to
the
consumer
without
any
other
party
in
between
and
I'm.
A
So
we
have
to
make
this
document
consistent.
We
have
two
options:
either
we
just
change
this
sentence
and
say:
okay,
an
intermediary
is
required.
Actually
we
always
require
a
meteor
intermediary
for
these
semantic
contentions
to
work
or
or
we
basically
adapt.
The
rest
of
the
cementite
of
this
document
that
we
see.
Okay
message
can
actually
pass
directly
from
the
producer
to
the
consumer.
A
A
So
removing
this
possibility
to
transfer
a
message
directly
between
parties
and
always
require
one
or
more
intermediaries,
because
I'm
not
sure
about
like
now
messaging
scenarios
in
the
sense
of
this
messaging
system,
semantic
conventions
where
a
message
go
directly
from
the
producer
to
the
consumer
without
anything
in
between.
So
I'm
more
inclined
to
like
change
this
here,
but
I
would
like
to
get
your
opinions
or,
if
you
have
any
like
scenario
of
a
messaging
scenario
where
there
is
no
intermediary
and
just
to
be
clear
intermediary.
A
That
is
now
not
not
necessarily
like
a
separate
service
or
process
that
can
also
be
a
component
inside
your
application,
because
we
were
like
discussing
about
the
also
in
memory
messaging
systems.
Right
lighter
sense.
So
this
doesn't
require
to
be
like
a
separate
process
or
service.
That
can
also
be
a
component
in
your
application
that
separates
producer
and
consumer.
C
Yes,
I
I
was
just
double
checking
what
the
definition
of
intermediary
is
in
this,
and
we've
just
got
it
defined
as
a
something
that
receives
a
message
to
forward
to
the
next
receiver.
So
that
can
easily
be
something
external,
something
internal
and
it
doesn't
preclude
that
I'd
be
inclined
to
agree
that
it
makes
sense
to
just
take
off
the
that
it
may
pass
be
passed
directly
and
that
it
has
to
go
through
an
intermediary.
A
Yes,
at
the
same
time,
because
I
thought,
if
the
if
the
message
goes
directly
from
producer
to
consumer,
there
is
no
that's
not
really
an
asynchronous
scenario,
so
basically
the
producer
and
the
consumer
have
to
talk
to
each
other.
At
the
same
time.
To
achieve
that-
and
I
I
think,
that's
actually
not
what
we
are
modeling
here
with
this
with
this
back
any
other
yeah.
D
So
I
I
don't
know
if
the
the
use
case
of
like
erlang
message
passing
applies
directly
to
the
messaging,
that's
being
thought
about
here
and
and
spec'd
out,
I'm
kind
of
trying
to
catch
up,
but
the
in
that
case
you
know
it
is
direct
and
it's
certainly
still
it's
not
it's
a
synchronous
communication
exactly
so
I
yeah,
I
don't
know
exactly
if
it
should
be
a
case
that
says
an
intermentary
shouldn't
be
required,
but
that's
that
was
just
my
first
thought
of
finding
it
odd
to
require
something
up
in
between
what
is
the
case
that
you
mentioned
again
sorry
twist,
just
earlying
message
passing
so
between
processes.
D
C
D
A
Yes,
I
mean
we
had
some
discussion
or
regarding
this
back
also
with
can
in
particular,
and
we
have
this
in
the
out
of
scope
or
open
question
section.
We
have.
We
have
this
as
a
synchronous
message
passing
in
the
wider
sense,
where
we
say
very
basically
say
yeah.
There
is
this
we
have.
A
That
all
kind
of
is
a
is
in
the
realm
of
asynchronous
methods
passing,
and
I
think
the
erlang
thing,
I'm
not
sure,
I'm
not
familiar
enough
with
ireland
too,
but
I'm
not
sure
where
it
fully
fits
in.
But
I
think
for
the
point
that
we
are
trying
make
to
make
here
like
for
more
lower
level
or
the
programming
language
constructs
like
go
channels.
A
You
can
also
perfectly
model
like
a
synchronous
communication
by
goat
channel,
but
that
is
not
part
of
those
semantic
conventions,
but
it
might
be
like
a
different,
a
different
semantic
convention
that
just
deals
with
those
lower
level
asynchronous
message:
passing
scenarios.
D
Yeah,
I
think
it
kind
of
falls
in
the
both
kind
of
odd
in
that
way
and
that
it's
internally
I
mean
it's
used
essentially
for
it's
used
all
over
the
place,
but
it's
also
used
to
for
cross-service
communication
between
services
in
a
cluster.
So
I
think
it
probably
falls
into
both
and
will
be
kind
of
up
to
the
user
in
our
implementation
to
distinguish
the
two
when
choosing
semantic
conventions
to
use
makes
sense.
Luke.
A
B
Yeah,
I
just
want
to
repeat
proposal.
I
I
posted
somewhere
in
the
discussions
that
we
have
a
lot
of
the
specifications.
They
probably
share
a
big
portion
of
the
spend
structure
regarding
the
message,
creation
and
consent
processing
right
so
without
the
transport.
It's
for
cloud
events,
free
memory,
cues.
There
are
some
specifics
if
for
cloud
events
anyway,
but
basically
we
can
come
up
with
this
one
and
we
can
separate
this
core
piece
into
the
general
async
pattern
processing
and
we
need
to
make
sure
it
applies
to
all
of
those
things.
B
The
go
channel,
erlang
everything.
A
Okay,
so
your
proposal
basically
is
to
to
to
have
to
have
both
specked
out
and
to
share
as
much
as
possible.
B
A
So,
as
slim
is
possible,
and
basically
for
this
case
to
keep
it
as
limited
as
possible
would
mean
we
say:
okay,
we
keep
the
intermediary
as
kind
of
necessary
part
for
this
spec
and
then
basically
for
the
other
one.
For
this
general,
more
general
asynchronous
message
passing
in
that
case,
basically
intermediary
would
not
be
necessary,
and
that
would
be
then
the
more
general
case.
But
for
for
that
we
would
then
yeah
reuse
from
here,
but
we
what
we
can.
B
A
So
we
basically
have
just
created
and
processing
that
makes
sense
and
then
yeah
for
this
deck.
I
will
then
remove.
I
will
remove
this
this
part
here
and
we
will
just
require
an
intermediary.
Then
we
are
here.
We
have.
We
have
a
more
basically
narrow,
like
a
smaller
area
of
application,
for
this
spec
makes
sense.
If
everybody's
fine
with
that,
then
yeah,
I
will
make
the
change
to
the
pr
after
the
meeting.
A
Awesome
thanks
for
that
and
we
have
two
more
points.
I
have
wanted
to
kick
off
some
discussion
today
regarding
context
propagation,
and
we
have
also
the
cloud
events
cloud
event.
Spec
part:
did
you
put
it
on
the
trender
luke
miller,.
B
Yeah,
but
if
we
don't
have
time
to
discuss
it,
I
will
happily
stay
on
the
context
propagation.
I
think
it's
the
essentially
the
same
discussion.
A
Okay,
then,
let's
start
with
the
context
propagation
and
today
I'm
not
sure
how
far
we
get.
I
can
show
you
what
the
what
they,
what
I
started
there
and
maybe
let's
try
to
reserve,
maybe
the
last
15
minutes
for
the
cloud
event
stuff,
because
I
think
it
will
actually
yeah
there
will
be
common
areas
with
both.
A
So
I
started
this
document
here
so
as
we
were
now,
we
were
working
on
this
old
tap
and
it
was
nice
to
work
like
just
having
a
document
or
there
were
people
who
cannot
attend
this
meeting
to
keep
up
with
the
discussion
so
for
the
brainstorming,
the
brainstorming
phase.
That's
now
coming
up,
I
just
started
this
google
doc.
You
all
should
have
access
to
that.
So
please
please
check
if
that
works,
for
you
and
feel
free
to
change
the
document
or
add
comments
or
put
in
whatever
you
feel
she'll
go
in.
A
A
I
also
added
the
example
that
ludmilla
presented
last
thursday
and
I
tried
to
really
understand
and
also
visualize
what
is
going
on
in
those
examples,
and
I
tried
to
map
it
on
to
our
yeah
mental
model
here
that
we
came
up
with
in
in
in
the
first
o
tab.
A
So
let's
just
go
through
those
examples
and
see
if
the
mapping
I
came
up
with
makes
sense
for
other
people
too.
So
there
is
basically,
I
have
the
link
here
to
the
spec
itself.
So
all
examples
are
basically
taken
out
of
this
semantic.
Existing
semantic
conventions
and
the
first
one
is
your
topic
with
multiple
consumers
and
we
have
a
process
p.
A
That
writes
a
message
to
a
topic,
and
then
we
have
basically
two
other
processes.
Reading
reading
the
same
message-
and
here
we
have
how
that
would
look
in
in
the
span.
A
One
word
why
I
why
I
start
out
with
the
examples
I
actually
start
out
with
examples,
because
all
the
context,
propagation
logic
in
this
semantic
conventions,
it's
all
packed
into
the
examples
in
the
actual
convention
text.
There
is
not
much
mentioned
about
context
propagation
like
what
to
parent
and
where
to
make
links,
so
artists
meet
basically
is
packed
into
into
those
examples.
A
That's
why
I'm
kind
of
for
the
context
propagation,
just
starting
out
with
the
examples
and
leaving
the
other
conventions
aside,
because
it's
really
contained
in
there.
A
So
in
trying
to
map
that
on
our
model
I
mean
that
is,
I
think,
for
my
understanding
at
least
rather
simpler.
We
have
basically
three
spans,
as
we
saw
here
like
one
send
and
do
process
bands
and
the
process
bends
anyway,
very
nicely
mapped
to
our
process
state
the
sense,
then
I
mapped
to
the
create
state
and
not
to
the
publish
state,
because,
at
least
in
my
understanding,
the
publish
and
receive
states
here
are
pretty
close
to
the
physical
or
protocol
level.
A
I
think
in
my
understanding
like
if
we
talk
about
the
publish
phase
here,
that
basically
will
tell
us
yeah.
Are
we
sending
by
http
or
mqb
or
mqtt
and
same
on
the
receive
side?
And
this
this
span
here
doesn't
tell
us
that
at
all,
so
that
is
just
the
other.
A
Something
is
sent
to
a
certain
topic
with
a
certain
message
id
and
that's
why
I
put
it
link
this
to
the
create
to
the
create
state,
because
the
create
basically
is
kind
of
the
logically
talks
about
the
logical
message:
yeah
luke
miller,.
B
B
A
Yes,
definitely
in
the
current
center
in
the
current
spec.
Basically,
on
this
side
we
always
only
have
sent,
there
is
never
there
is
never
a
publish
state.
I
think
we
only
see
the
use
of
the
published
state
in
in
your
example,
which
is
the
last
on
the
list.
A
So,
and-
and
here
basically
the
when
we
talk
about
context
propagation,
when
we
look
how
the
context
flows
here,
it
basically
flows
from
here
to
create
to
the
process
state.
A
A
I
mean
that's
a
pretty
a
refreshingly
simple
example,
so
I
think
that
the
that
is
that
makes
sense
to
me
also
that
we
have
in
there's
other
things
that
middle,
for
example,
is
working
on
like
instrumentation
layers,
and
here
I
would
think
about
instrumentation
layers,
maybe
in
a
slight
different
sense
that
will
is
talking
about,
but
we
have
here
a
layer
of
creatine
process
and
the
publish
and
receive
would
be
like
a
different
layer
like
here.
A
That's
basically
an
application
layer,
and
here
we
could
possibly
talk
about
the
transport
layer,
and
I
mean
in
the
ideal
future.
Maybe
you
this
is
what
you
see
by
default
and
when
you
have
on
the
deep,
have
deeper
insight.
You
can
kind
of
configure
like
also
to
capture
data
for
the
transportation
layer,
and
then
you
get
those
additional
kind
of
spans
for
publish
and
receive,
and
you
maybe
see
some
hdb
or
mqb
spans
on
both
sides.
B
From
the
layer
perspective,
how
I
thought
about
it
that,
like
it's
not
the
layer,
is
the
combination
of
the
span
current
rate
and
the
the
convention,
so
the
create
is
a
processor.
Oh
sorry,
the
crate
is
a
producer
spent.
The
process
is
a
consumer,
spend
and
then
publish
and
receive.
In
my
mind
they
were
just
a
client
calls
because
it's
the
normal
rpc
call.
Why
would
we
give
any
special
meaning
to
them?
But
anyway,
this
is
not
that
important,
but
basically
they
can
all
be
messaging,
but
because
of
the
different
kinds,
they
are
still
different.
A
A
Oh
true,
you
would
have
like
the
producer
here
and
here
you
would
have
an
http
client,
yeah,
yeah,
okay,
but
for
for
now,
basically
what
I
wanted
to
capture
just
like
capture
the
example
and
and
protect
it
onto
our
model.
A
Now,
let's
go
to
the
next
one,
and
I
think
here
ken
can
help
us,
because
I
think
that
came
from
him
here.
Let's
go
to
the.
A
Spec
again
because
it's
easier
to
read
here
here,
we
basically
have
a
process
that
publishes
a
message
message
to
a
certain
topic
and
then
there's
another
process
that
receives
the
message
and
based
on
this
message,
publishes
a
new
message
to
a
different
topic
and
that
then
this
is
received
by
by
a
different
process.
In
turn.
A
So
we
have
those
five
spans
here
and
I
tried
then
to
put
this
here
into
also
map
this
on
our
model
and
that's
how
it
looks
like
here.
We
see
that
we
have
the
send
span
in
the
first
process
that
I
mapped
to
the
create
state,
and
then
we
have
different
spans
for
receiving
and
processing.
A
So
we
have
a
receive
span
here
and
then
we
have
a
processband
and
then
we
have
another
sense
span
which
is
kind
of
a
child
of
this
receive
span
and
also
in
the
third
process.
We
also
again
have
like
a
receive
span.
So
here
we
have
receive
as
more
like
a
logical
layer
or
container
that
the
that
wraps
the
processing
and
the
sending.
A
So
that
is
not
what
I
what
or
what
I
understand
this
otp
received
phase
to
be,
because
that
I
understood
it
more
to
be
close
to
the
to
the
physically,
like
transport
layer,
but
that
is
I
still
like
created
this.
A
So
here
we
basically
have
when
we
look
at
the
first
example
here
we
don't
have
any
receive
span.
So
here
process
is
a
direct
child
of
sent,
and
here
in
the
second
span,
in
the
second
example,
we
have,
we
have
the
receive
span
between
the
send
and
or
create
in
the
process
stage.
B
To
create
a
nice
visual
experience,
so
there
is
a
hack
in
this
place
where
they
receive.
This
trust
explain
it
last
time
when
they
trade,
they
record
the
receive
after
they
received
and
fake
the
start
time
of
the
spend,
and
then
they
they
link
what
they
received
to
the
span
and
then
they
they
cannot
link
it
again
in
process.
It
would
be
a
waste
of
the
resources
right.
So
basically
the
idea
is
okay.
We
created
this
spend
with
links
and
then,
let's
just
continue,
this
trace
that
we
created.
A
A
So
that's
all
parent-child
relationships.
So
it's
a
it's
a
interesting.
As
you
say,
and
it's
I
mean
I
I
I
get
definitely
get
the
from
the
visualization
point
of
view.
That
kind
of
makes
sense,
because
you
want
to
have
this
process
and
descent
kind
of
grouped
because
it's
triggered
by
the
same
message.
A
As
far
as
I
understand
the
example,
so
it's
kind
of
related
to
the
context
of
of
the
same
message,
so
it
makes
sense
to
group
it
together,
but
from
instrumentor's
point
of
view
it
even
seeing
those
first
two
examples.
It
would
already
hard
for
me
to
say:
okay,
when
do
I
create
the
receive
span,
and
when
do
I
not
create
a
receive
spam,
because
we
have
those
both
cases
already
here
now.
A
Let's
get
maybe
more
confused,
I
don't
know,
or
let's
get
enlightened
so
in
the
next
example.
This
is
about
batch
receiving.
So
here
we
have
a
process
p
and
that
sends
two
messages
to
a
queue
on
the
messaging
system,
and
then
we
have
another
process
which
receives
both
of
them
in
one
batch
and
processes,
each
message
separately.
So
here
we
see
we
have
a
process
b
that
creates
two
spans
and
process
c,
basically
receives
both
spans
in
a
batch
and
then
processes
them
sequentially.
A
A
So
those
are
kind
of
the
relationships
we
have
here.
So
we
have
the
parenting
here
like
the
again
like
the
maybe
the
container
receive
operation
or
the
here.
In
this
sense
it
could
be
like
a
physical
operation,
because
we
receive
a
badge
on
the
wire
and
then
yeah.
We
have
then
two
messages
in
there
and
we
process
those.
So
that's
parents-
and
here
we
have
the.
We
have
the
links
that
tell
us.
Okay,
where
was
the
message
created.
A
So
that,
to
me
kind
of
seems
a
bit
like
kind
of
consistent
with
actually
the
first
example
that
we
saw
in
innovator.
The
context
is
also
flowing
from
grade
to
process
here.
The
only
difference
here
is
that,
in
the
first
example,
we
can
directly
have
a
parent
child
worship,
a
relationship
between
descent
and
a
process,
and
here
we
we
have
a
link
relationship
and
the
reason
for
having
a
link
relationship
here
is
because
we,
we
group
those
two
process-
bands
under
the
same,
receive.
A
If
we,
if
we,
what
was
interesting
for
me
here
is
if
we
would
not
be
interested
in
like
the
batch
stuff
here,
they
could
model
this.
The
same
way,
actually
is
the
first
example.
It
could
just
have
a
cent
and
then
the
process
being
a
direct
child
of
the
send
span.
We
could
have
the
same
year,
we
could
have
to
send,
and
this
process
could
be
a
child
of
this,
and
this
process
could
be
a
child
of
this.
What
we
would
lose
here
would
be
the
batching
information.
A
A
Which
was
to
me
honestly
the
most,
how
to
say
exotic
example
and
what
is
happening
here
is
we
have
again
a
process
that
sends
two
messages
to
a
queue
and
then
other
process
which
receives
both
of
them
separately,
but
processes
both
messages
in
one
batch.
A
That
was
an
interesting
scenario
for
me.
I
not
sure
about,
like
real
world
use
cases
for
that,
but
yeah.
Let's
look
at
how
this
map
store
model.
We
again
have
five
spans
here.
We
have
here
the
spans,
like
the
messages
are
created
here
and
sent
and
then
are
received
separately
by
another
process,
but
then
are
processed
together
in
one
processing
stage.
A
And
here
this
looks
like
this
at
least
that's
how
I
interpreted
it.
So
we
have
two
separate:
send
operations
in
the
first
process.
Those
are
like
in
the
creation
state
and
then
we
have
two
receive
spans
on
the
other
process.
Those
are
directly
parented
to
the
send
spam,
so
that's
kind
of
a
bit
similar
to
what
we
saw
in
the
first
example
in
the
first
example.
A
So
that's
the
modeling
of
this
example,
which
I
have
to
say
the
example
itself
was.
A
This
was
the
most
confusing
one
for
me
because
I'm
as
I
said,
I'm
not
aware
of
like
use
cases
where
you
receive
separately,
but
then
process
in
a
badge
and
to
be
honestly,
I'm
not
sure
if
this
is
something
that
should
be
modeled
by.
A
The
messaging
semantic
conventions,
because
to
me
that
seems
more
like
something
internal
to
the
process
stage
like
when
you
process
messages
in
in
batches
but
yeah.
We
can
leave
this
for
further
discussions
and
maybe
there
are
use
cases
I'm
I'm
I'm
not
aware
of,
but
just
there
to
put
bullet
out
there.
That
was
kind
of
the
most
confusing
to
me
and
then
at
last
we
have
the
example
that
ludmilla
showed
last
time
with
every
monitor.
Here
I
can
actually
sorry
that's
a
bit
blurry
trying
to
make
it
bigger.
A
So
you
see
better.
That
is
I
just
copied
and
pasted
that
from
the
miller's
blog
post,
but
that's
basically
what
you
showed
us
last
time
here.
That's
one
of
the
the
first
case,
where
we
kind
of
have
an
attempt
to
have
separate,
create
and
publish
spans.
A
So
we
have
to
create
span
here,
or
at
least
that's
how
I
group
them.
So
we
have
basically
two
spans
on
the
consumers
on
the
producer
side.
The
first,
as
I
understand
it,
creates
the
message-
and
here
we
have
a
sense
span-
that
basically,
I
think,
corresponds
to
the
publish
stage
and
on
the
producer
side,
we
have
the
process
span
here,
which
is
has
a
link
to
the
create
span.
So
again
the
context
flows
between
create
and
process,
and
then
we
have
the
checkpoint
span
here,
which
is
kind
of
the
settlement
stage.
A
So
the
only
thing
that
is
not
really
missing
here,
but
the
only
area
that
is
not
covered
is
the
receive
area,
but
I
think
that's
fun
on
purpose.
A
So
that
is
basically
what
the
what
the
ludmila
showed.
A
Last
time-
and
here
I
mean
that
is
a
very
simple
example,
and
I
I
think
for
if
there
would
be
if
a
message
here,
for
example,
if
we
apply
this
to
one
of
the
other
scenarios,
if
a
message
would
be
basically
read
multiple
times,
we
would
just
have
multiple
links
here
from
the.
We
would
have
another
link
here
from
the
create
to
another
process
state.
A
A
Yeah,
so
that
that
was
what
I
prepared
here
in
this
document.
That
is
basically
meant
to
more
or
less
kick
off,
like
some
discussions
or
just
maybe
spark
some
ideas
about
the
context,
propagation
scenarios
and
I
mean
context
propagation,
it's
it
actually,
then
we
cannot
talk
about
context,
propagation,
we're
not
also
talking
about
span
structure,
so
it's
a
much
wider
wider
field,
but
yeah.
That
was
just
meant
to
be
like
as
a
starting
point.
A
So
if
you
have
any
like
thoughts
or
ideas
just
your
time
in
this
document-
and
maybe
we
can
then
next
week
start
to
from
this
starting
point-
we
can
start
out
to
discuss
and
see
how
we
can
come
to
a
maybe
or
ideally
more
streamlined
model,
because,
from
my
point
of
view,
even
the
four
examples
that
are
in
the
spec
are
not
all
like
consistent
in
in
how
in
how
in
how
things
are
supposed
to
be
grouped.
A
A
I
don't
think
that
that
was
kind
of
left
open
deliberately,
and
I
think
I
don't
think
we
should
leave
that
open
deliberately,
but
I
think
we
should
try
to
come
up
with
some
with
some
clear
rules
around
that,
and
also
maybe
that
involves
you're
just
extending
these
stages
here
by
another
stage
that
we
just
use
then
to
model
like
our
trace
trees.
A
So,
let's
see
with
what
kind
of
solutions
or
thoughts
we
can
come
up
with
here.
A
A
And
after
no
kind
of
thoughts
or
remarks
about
this
today,
then
I
will
hand
over
to
luke
miller.
B
Yeah,
okay,
cool!
So
then
let
me
share
my
screen.
B
While
you're
here
it's
perfect,
so
I've
tried
to
summarize
my
thoughts
on
how
the
the
what
we
can
add
to
cloud
events
to
identify
the
span
structure
and
the
context
propagation.
I
so
do
I
say
your
replies
on
on
slack,
I'm
on
cubecorn,
I'm
behind
I'm
sorry.
B
B
So
if
you
remember
the
the
first
example
where
we
have
just
the
creation
and
the
producer
trader
creation
and
processing,
it's
exactly
the
case
that
I'm
trying
to
describe
here
and
what
I'm
saying
that
when
the
cloud
event
is
created
that
we
should
create
the
new
producer's
pen
and
instrumentation.
I
to
your
comments.
Well,
it's
it's!
It's
it's
instrumentation
in
the
library
right,
so
it's
instrumentation
library
or
library,
business
reputation.
I
don't
know
how
to
speak
it
better.
So
wherever
this
instrumentation
happens,
this
should
this
is
what
it
should
do.
B
E
B
B
The
keyword
here
is
that,
okay,
if
it
had
a
context
already,
maybe
we
deserialized
it
from
some
other.
Maybe
it
was
routed
multiple
times
and
then
we,
my
suggestion,
is
to
just
completely
abandon.
Do
nothing
with
this
message.
We
don't
create,
spend
we
don't
do
anything
yeah
so
happy
case.
New
message
is
created.
We
create
a
producer
spam.
We
inject
the
context
into
the.
A
Is
it
not
to
kind
of
because
otherwise
we
would
have
to
overwrite
this
the
context,
information
in
the
extension-
and
we
don't
want
to
do
that
instead.
B
Yeah,
so
with
cloud
events,
the
thing
is
that
you
probably
there
are
multiple
hopes
on
the
way
for
this
message,
and
maybe
some
like
if
it
has
a
context,
somebody
instrumented
it
before
so.
The
best
thing
you
can
do
is
to
just
do
nothing.
A
Okay,
so
there
basically
cannot
be
any
nested
cloud
event
tree,
so
basically
what
the
we
saw
in
the
previous,
I
think
the
second
example
the
patch
patrick,
have
conquered
this.
But
then
the
other
process
reads
receives
a
message
and
then
sends
another
message
on.
A
Yes,
I
think
that
confused
me,
because
when
you
create
a
new
cloud
event,
I
think
the
this
distributed
context
extension
will
always
be
empty.
That's
true,.
B
C
B
E
Yeah,
so
I
think
it
should
be
like
when
you
create,
you
should
always
create
a
span
and
and
then
inject
into
the
or
add
the
context
to
the
distributed
extension.
E
And
then,
when
you
are
reading
it
either
you
receive
it
or
you
processing.
Then
you,
if
you
are
processing
it
before
so
when
you're
processing,
if
you
have
already
so
you
check,
if
there's
a
writing
extension,
if
there
is
one,
then
you
use
that
as
a
parent
spam
of
your
operation.
I
guess
that's
what
you
mentioned
below.
Otherwise
they
wouldn't
they
need
to
create
one
and
then.
E
So
if
there's
already
a
context,
you
don't
do
anything,
but
if
you're
creating,
then
there
will
be
no
context,
so
you
always
create
and
always
put
inside
right,
yeah.
E
Yeah,
because
what
I
was
once
when
I
read
your
your
your
your
your
document
there,
I
was
thinking
because
what
I
do
today,
I
so,
for
example,
if
I
send
a
cloud
event
via
via
http
I,
when
I
create
my
cloud
event,
I
I'm
already
creating
a
stand,
but
I
don't
put
the
contents
inside
and
then
I
just
use
the
client
to
send
and
then
the
client
creates
the
http,
auto
instrumentation
scan
and
then
on
my
receiving
side.
Then
I
continue
to
trace
because
it's
instrumental
as
well
with
http.
E
B
I
kind
of
think
the
short
cards
to
merge
the
creation
and
publishing
they
actually
make
sense
in
some
cases
to
like,
if
we
know
for
sure
there
is
just
one
message:
that's
sent
in
the
same
context.
If
you
know
this,
we
can
surely
inject
the
context
after
and
we
can
probably
avoid
creating
this
cloud
event
span.
I
guess
it
it
can
be,
but
we
need
to
play
with
it
and
see
how
it
works.
E
But
especially
in
cases
where,
where
it's
not
instrumented
with
http
and
I'm
saying
part
of
nch2p,
then
now
I
have
two
stance:
it's
not
a
problem,
but
but
if,
if
we
just
say
now,
we
just
have
one
and
it's
gonna
be
the
one
from
the
of
the
instrumentation
library
for
it
to
do,
but
I
still
think
it
makes
sense
to
someone
to
inject
this
context
into
the
event,
because
when
it's
receiving
the
other
part,
if
it's
yeah,
if
the
other
part
is
not
installed
or
something,
then
I
can
check
if
there
are
the
context
on
the
on
the
on
the
event
right
and
I
think
that's
useful.
B
E
Yeah
because
I
mean
for
the
next
video-
maybe
I
can-
I
can
come
up
with
a
trace
or
an
intent,
tracing
structure
that
I
did
for
the
project
I
was
working
on,
but
in
the
case
in
our
case
was
like
that
I
create
the
column,
scan
and
then
send
it.
Then
I
have
the
rather
than
stand
at
the
top
and
then
the
http
at
the
bottom
and
then
the
receiver
part
is
also
instruments.
E
So
I
have
the
http
receiver
and
then
it
puts
into
the
field
somewhere
and
then
at
the
start
point
you
better
the
point
that
I
inject
the
the
the
current
context
into
the
event
and
then
it
goes
to
the
queue
and
then
some
other
service
somewhere
picks
it
up
and
then
sit
down.
Okay,
I
I.
I
have
a
complexity,
so
I
complete
the
trace
and
then
my
trace
is
like
it's
not
like.
I
guess
what
you
mentioned,
that
you
have
here
when
you
have
parallel
or
parallel
spans.
B
Yeah,
I
think
it's
like
we're
intentionally
trying
to
avoid
speaking
about
transport
in
this
spec
right.
So
maybe.
E
B
B
B
And
I
suggest
to
specify
a
name:
I'm
not
married
to
the
this
convention.
I
came
up
with,
but
I
think
it's
worth
clarifying
that
it's
a
great
span
and
the
type.
E
Yeah
would
I
also
would
would
find
that
it's
useful
is
that
we
have
cloud
events,
that's
somewhere
there,
I'm
not
sure
it's
some
other.
I
think
christian,
my
mother
had
some.
E
I
don't
think
he
didn't
like
behind
convince,
but
I'm
looking
at
the
trace.
I
I
as
a
user.
I
I
say
that
it's
useful,
that
there's
like
cloud
events
and
then
event
type
and
then
create
at
the
end,
or
something
like
that,
because
I
can
clearly
see
that
it's
it's
it's
called
event.
It's
the
same
as
a
http
that
we
have
like
a
http
get
http.
B
B
B
B
Okay,
cool
and
then
we
have
a
less
controversial
processing
thing.
So
if
you
receive
the
cloud
event
and
has
a
context
or
even
if
it
doesn't,
if,
if
you
you
have
an
instrumentation
for
it,
you
create
a
new
consumer's
pen.
If
you
receive
to
one
cloud
event,
you
can
make
this
consumers
pen
as
a
child
of
it
or
you
may
link,
so
you
should
probably
should
create
it
as
a
child,
but
you
may
link.
If
you
receive
the
batch,
you
must
link.
E
So,
for
example,
in
my
case
that
I
I
was
doing
so
imagine
that
I
have
a
service
running
and
it
has
no
notion
of
anything
just
running
and
then
it
receives
a
message
from
the
queue
at
that
point
you
you,
you
mean
that
I
should
create
a
new
consume
span
and
then,
if
I
have
context
in
the
event
that
I
got
then
I
link
this
or
because
that
as
a
child.
E
Should
I
so,
for
example,
if
I
have
my
service
and
I
get
a
message
from
a
cube,
should
I
first
look
if
I
have
a
context
in
that
event
and
use
that
as
the
let's
say,
parentspin
and
then
I
create
another
expand
on
the
return.
E
Oh
yeah,
no!
No!
No!
Not
at
this
point,
that's
also
my
next
question,
but
just
forget
about
that.
It
should
be
so
like.
If
I,
if
I
have
a
service
running
and
then
I
I'm
subscribed
to
a
topic
or
something,
and
then
I
get
the
message
and
then
what
what
should
I
do
should
I
use
the
context
then
that
I
that
I
might
have
in
the
event
as
the
let's
say,
parents
then
and
then
create
a
consumer's
name,
like
you
put
there
as
a
child
of
the
standard.
E
Yes,
the
context,
okay,
okay
and
then
the
next
question.
So
if,
if
somehow
for
some
reason
when
I
received
when
I
crossed
the
event,
I
already
have
a
current
context.
Being
I
don't
know
somewhere,
maybe
it's
a
http
that
I
received
or
something
and
then
I
have
my
current
context
and
then
I
check
there's
already
a
context
in
the
event.
What
should
I
do?
E
B
I
think
the
one
in
the
event
should
have
a
higher
priority,
because
you
don't
know
how
many
hops
adventure
right.
It
could
be
direct,
http
communication
or
something
else
so,
but
you
might
be
interested
in
preserving
both
of
them
right,
so
you
received-
and
you
like
in
your
case,
I
guess
you
do
you
know
that
you
received
from
this
http
request
and
it
was
it's
basically
the
same
context
that
the
http
request
had
and
the
cloud
event
do.
You
know
anything
about
it.
E
Yeah,
it's
a
bit
more
complicated,
but
it's
basically
the
use
case
is
like
I
have.
I
have
a
service,
for
example,
service,
a
and
then
service
a
is
the
one
that
creates
the
cloud
again
and
sends
to
to
a
side
car
in
kubernetes.
So
I
have
an
apartment
and
I
have
a
side
car,
so
I
send
it
into
the
sidecar
via
http,
just
a
single
event,
easy
and
then
this
sidecar
receives
it
and
the
both
of
them
are
instrumented
with
http.
E
So
then
I
have
the
auto
instrumentation
http
event
and
then
so
in
that
case,
there
I
have
like.
I
have
still
have
a
full
trace,
it's
all
good
and
then
I
have
a
current
content.
So
what
I
do,
then
I
grab
the
screen
contacts
put
into
the
event
and
then
send
to
the
queue
right.
E
So
I
have
like
two
free
trades
at
this
point
and
then
the
other
service
is
receiving
it's
falling
from
the
keyword
or
whatever,
and
then
it
gets
it
at
this
point
and
then
what
I
do
at
this
point
and
then
I
read
the
thing
from
the
event
and
then,
as
you
mentioned,
that
I
I
do
I
I
already
do
the
same.
So
I
read
this
from
the
event.
A
I
hate
to
interrupt
you,
but
I
think
we
have
to
stop
now
because
we
are
just
in
the
last
minute
and
we
have
to
all
dial
out
to
unblock
or
to
stop
the
recording
so
that
the
others
can
start.
So
maybe
we
can
continue
the
discussion
offline,
maybe
even
a
draft
pr.