►
From YouTube: 2022-01-27 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
B
C
You
work
for
the
same
company
four
thousand
miles
away.
I
can't
understand
why
you
don't
don't
know
exactly
where
his
whereabouts
are
yeah.
D
E
Then
I
think
we
can
get
started.
Look
miller
said
she's
gonna
join
but
might
be
a
bit
later.
I'm
here
he
pinged
me
and
said
he
cannot
make
it
today
so,
but
I
think
let's
not
wait
for
luke
miller,
it's
five
past
already.
So
let's
get
started.
E
I
will
share
my
screen
so
the
last
time
we
were
talking
about
the
context
propagation.
We
were
talking
about
those
two
layers
and
some
people
asking.
Is
it
really
necessary?
Can
we
go
without
that
and
I
said
yeah
I
will.
I
will
work
on
like
a
small
prototype,
to
illustrate
some
cases.
We
have
there
and
I
I
managed
to
do
something
until
today.
It's
a
very
small.
E
It's
a
very
like
small
client
like
producer
broker
consumer
kind
of
prototype,
it's
it's
using
using
mqb
and
it's
written
using
this
apache
proton
library
and
I'm
going
to
go
into
details.
I
will
just
show
like
the
traces
created
from
that.
Basically,
it's
pretty
simple.
It's
like
four
messages
sent
and
from
the
producer
to
the
consumer
via
the
broker
and
those
four
messages
are
then
on
consumer
side,
batched
and
then
basically
delivered
as
one
batch
to
the
application
code
and
the
trace.
E
I
tried
to
keep
it
as
minimal
as
possible
so
to
make
it
easier
for
us
to
go
through
and
this
first
basically
what
I
show
here,
it's
the
same,
it's
the
very
same
use
case,
but
with
a
slightly
different
instrumentation
each
of
the
three
times
so
for
the
first
use
case,
it's
like
it's
the
it's,
the
just
a
minimal
instrumentation
that
we
basically
require
with
our
current
idea
of
those
semantic
conventions.
E
So
what
we
already
have
written
out
there
for
consumer
instrumentation
is
this
deliver
span?
Basically,
that
is
when
the
when
the
let's
say,
sdk
messaging
library
on
consumer
site
just
receives
like
gets
messages
and
then
passes
them
on
via
callback
to
the
application
code.
E
E
Four
messages
are
are
handed
over
to
the
application
code,
and
thus
we
have
four
links
here
and
what
is
missing
here?
We
don't
have
a
process
ban.
E
I
left
this
out
just
for
the
sake
of
simplicity,
because
we
didn't
make
that
the
hard
requirement
in
in
our
current
idea
and
the
process
span
here,
would
then
need
to
be
basically
created
by
the
application
code
and
might
also
then
have
links
to
the
respective
context
of
the
message
that
is
processed,
but
the
only
hard
requirement
that
we
have
for
this
scenario
in
the
current
spec
is
just
having
this
thing.
E
Single
deliver
spam
that
hands
over
the
messages
and
having
the
links
and
if
we
can
follow
the
link
and
then
we
end
up
in
in
the
producer
also
here
we
didn't
really
talk
in
detail
about
producer
instrumentation
yet,
but
when
we
know
we
need
some
kind
of
create
span
because
there
we
need
to
get
the
context
from
and
then
maybe
we
will
have
we
will
have.
We
will
have
some
kind
of
a
stand.
E
Sense,
man,
so
that's
kind
of
still
like
a
bit
up
in
the
air,
but
basically
the
idea
is
here:
we
can
link
from
this
delivery
context
with
the
message
we
can
link
to
where
the
message
actually
was
created.
So
we
have
this
consumer
producer
link.
I
think
that
is
that
is
kind
of
this
smallest
common
denominator
that
we
have.
That
is
okay
from
the
consumer.
We
want
to
link
to
the
producer.
C
E
E
And
also
basically
open
the
lamitri
does
not
make
any
any
kind
of
assumptions
about
the
direction
of
the
link.
It's
open.
The
laminator,
it
just
says:
there's
a
link,
there's
not
a
real
direction
that
open
telemetry
kind
of
puts
on
this
link
and
it's
up
to
the
to
the
back
end.
Do
the
backhands
mostly
what
kind
of
how
they
handle
this
link.
E
A
As
a
small
note,
this
is
part
of
the
a
data
modeling
issue
that
I
don't
quite
know
what
to
do
with
as
we
expand
open
telemetry,
but
the
core
tracing
model
we
rolled
with,
because
we
knew
it
was
an
efficient
model
because
it's
been
used,
you
know
many
times.
A
A
E
So
now
what
I
also
did
in
this
example,
I
basically
made
it
like.
I
started
out
just
with
a
single
message.
I
thought
okay,
it's
simpler,
but
then
I
ended
up
making
it
a
batch,
because
having
here
my
table
message
shows
us
that
yeah
we,
we
cannot
really
use
a
parent
child
relationship
here
to
model
this
kind
of
this
kind
of
connection,
because
we
cannot
have
multiple
kind
of
parents
here.
So
we
actually,
we
are
kind
of.
E
We
need
to
use
links
for
this.
For
this,
for
this
kind
of
modeling.
E
So
in
the
in
the
next,
basically,
the
same,
the
same
kind
of
workflow
and
just
quite
a
bit
more
instrumentation
added,
we'll
start
out
here
so
also
here
we
see
the
deliver
span
with
the
four
links
as
we
had
it
before,
but
we
also
see
much
more
here.
We
have
the
transport
layer
instrumented
and
we
also
have
the
broker
instrumented
and
this
example
with
this
instrumentation.
E
This
uses
this
two
layer
context
approach
that
we
that
we
that
we
were
discussing
before
so
I
have
one
example
here
with
this
two
layer
context
approach
and
then
in
the
last
example,
I
just
try
to
do
it
with
just
one
layer
and
we
see
how
that
how
that
looks.
But
here
we
have
the
two
layer
context
approach.
We
have
this
creation
context
layer
here.
Those
are
the
links.
Basically,
this.
E
What
we
see
here
I
mean
the
the
detail
of
the
the
details
of
the
instrumentation
are
yeah.
Definitely
up
should
not
be
point
of
discussion
here
or
just
quickly
hacked
this
together,
but
just
that
we
see
the
principle
that
the
broker
basically
dequeues
a
message
and
then
the
mqb
pushes
it
to
the
consumer
and
the
consumer.
Just
yeah
adds
this
message
to
a
to
a
prefetch,
prefetched
cache
and
then
in
the
end.
E
Basically,
messages
are
popped
from
this
cache
I
mean
here
we
see
here
there
is
a
that's
just
something
I
created
so
that
I
can
easily
transfer
those
other
traces,
but
here
we
basically
see
the
link
example
that
we
mentioned
before
so
here.
One
message
was
added
in
the
same
trace
that
we
see
here
here.
We
see
like
the
link
from
both
sides.
E
E
Go
to
a
different
trace
here
and
we
see
okay
here
we
have
basically
the
same
thing
here.
The
measure
was
pre
added
to
the
cache,
but
was
not
delivered
because
probably
we
have
some
kind
of
a
threshold
here
that
only
once
a
certain
time
or
certain
number
of
messages
if
they
already
deliver
but
yeah.
What
we
see
here
is
this.
Basically,
we
see
here
we
have
these
two
different
contexts
at
work.
We
see
this
transport
context
here
and
the
creation
context
finally
allows
us.
E
This
is
the
deliberate
span
again
to
just
switch
to
the
producer
trace
where,
where
the
message
was
actually
created
and
also
here,
we
see
a
bit
more
detail.
We
see
this
those
crate
and
sand
spans
we
know
from
before,
but
here
we
have
them
some
mqb
instrumentation
from
the
front
producer
broker
and
daniel
the
broker
here,
basically
cues.
The
message.
A
A
To
do
with
amqp,
I'm
just
curious:
did
you
have
to
do
something
strange
or
is
that
part
of.
E
A
For
the
for
the
first
one
did
you
have
to
modify
the
message?
I
guess
for
either
of
them,
but
did.
E
You
mean
the
first
situation.
We
had
to
modify
one
requirement
that
we
have
for
all
these
cases,
for
all
like
the
three
cases
is
even
for
the
for
the
monday
approaches
that
we
can
somehow
attach
an
immutable
creation
context
to
the
message.
Okay,
so
this
is.
This
is
the
one
requirement
that
is
constant
across
all
cases,
and
that
is
basically
what
we
need
to
to
link
from
the
consumer
to
the
producer.
A
But
I
guess
my
question
was:
did
you
did
you
have
to
modify
the
message
in
such
a
way
that
the
consumer,
on
the
other
end,
would
would
fail
to
process
the
message
if
it
was
not
open,
telemetry
aware?
Does
that
make
sense.
E
How
it
works,
it's
basically
pretty
much
according
to
this
wcc
mqb
draft.
It's
basically
that
the
that
the
the
the
message
has
some
annotations,
which
is
like
a
dictionary,
and
we
just
put
the
trace
parent
in
there.
Great
and
consumer
basically
can
check.
Okay
is
the
trace
parent
there?
If,
yes,
then
I
use
it.
If
it's
not,
there,
then
yeah
so.
A
No
need
no
need
to
modify
the
payload
or
you
know,
change
that
change
the
the
message
payload
you
there's
there's.
E
A
E
So
so
yeah
keeping
in
mind
like
this
example.
Here
basically
I
mean
here.
We
have
one
last
thing
to
mention
here
about
this
two-lane
instrumentation
that
we
have
here
here.
We
basically
we
have
two
different
and
mostly
independent
traces.
E
We
have
like
the
first
trace
where
the
message
is
created
and
which
ends
up
basically
with
the
broker
more
or
less
cueing
the
message
or
just
taking
it
over
from
the
producer,
and
then
we
have
another
independent
part
where
the
broker
then
starts
to
dequeue
the
message
at
some
point
and
passes
it
to
the
consumer
or
maybe
to
multiple
consumers.
So
those
are
two
different
parts
that
are
basically
linked
together
via
this
via
this
creation
context
and
now
jumping
to
the
last
example.
E
Here
again
the
very
same
use
case-
and
here
I
tried
to
get
it
going
with
just
like
one
layer
of
context,
basically
just
having
this
one
context
attached
to
the
message
and
not
not
attaching
any
transport
context,
as
we
did
for
this
example
here,
and
if
we
just
have
this
one
layer,
this
one
context
attached.
Basically,
this
more
or
less
must
be
this
creation
context,
because
that's
what
we
said:
it's
a
must
that
we
need
to
link
the
producer
and
the
consumer
together.
E
E
We
can
either
parent
to
it
or
we
can
link
to
it
and
what
that
here,
what
I
did
here-
I
just
yeah
unconditionally
parented
to
this
context,
and
that
just
to
be
clear
that
that
that
would
work
well
with
this
very
simple
scenario
that
we
had
in
the
beginning
here,
because
here
yeah
we
just
anyway
just
linked
to
this
context.
So
if
we
don't
have
any
transport
layer
or
broker
instrumentation
in
place,
that
works
pretty
pretty
much
the
same
as
here.
E
In
this
simple
example,
with
the
two-layer
approach,
it
only
gets
kind
of
a
bit
more
complicated
and
messy
once
once
this
transport,
like
let's
say
mqb,
instrumentation
and
also
broker
instrumentation,
gets
into
the
picture
because
we
would
we
have
here,
for
example,
this
mqb
delivery
and
here
is
the
corresponding
receive,
and
I
mean
we
would
expect
them
those
two
to
be
parented
but
yeah.
We
cannot
really
bear
in
those,
because
we
cannot
here.
E
This
band
cannot
attach
any
kind
of
context
to
the
mqb
message,
because
this
one
slot
this
one
layer
is
this
one
context.
Layer
slot
is
already
kind
of
occupied
by
the
creation
context.
So
that's
what
they
get
here
and
that's
what
we
parent
to
and
the
same
thing
here
and
the
broker
sends
to
the
consumer.
But
the
broker
cannot
attach
any
context
to
the
message,
because
there's
only
this
one
immutable
slot,
and
so
the
consumer
basically
has
just
to
parent
to
what
it
has
and
that's
this
creation
context.
E
It's
just
a
bit
kind
of
skewed,
but
I
think
it's
it's
definitely,
in
my
opinion,
suboptimal
compared
to
what
we
have
here,
where
we
have
the
nice
kind
of
mqb
kind
of
scent
and
delivery
kind
of
parent-child
relationship
that
model
that
model
all
the
nice
hops,
which
is
also,
I
think,
necessary,
actually
at
some
point,
if
we
wanna,
if
you
would
be
interested
in
any
kind
of
network,
latency
calculations
that
we
cannot
do
here,
because
we
don't
cannot
make
any
relationship
between
those
two
here
that
are
related.
B
Doesn't
the
one
layer
approach
also
imply
that
you
cannot
split
the
producer
and
consumer
side
into
separate
traces,
because
you
can't
create
a
new
context,
really
you're
kind
of
stuck
with
the
one
context
throughout.
E
One
could
create
separate
traces
by
just
using
links
instead
of
parent-child
relationships,
so,
for
example,
to
broke
here.
I
just
I,
I
created
parent
client
relationships
throughout
to
make
it
more
kind
of
transparent
how
the
things
are
kind
of
floating
around,
but,
for
example,
this
broker
here
this
parents
do
this
creation
context
here,
but
it
could
also
just
create
this
receive,
could
create
a
distinct
trace
that
then
links
to
this
to
this
creation
context
here.
B
So
I
think,
I
think,
with
I
think
that
sort
of
means
it's
not
prac
like
I
think
if
you
split
it
and
you
only
have
one
layer
at
any
point,
then
every
downstream
span
is
always
has
to
be
a
brand
new
trace,
because
you
only
have
the
producer
trace
that
you
can
link
to
and
you
can't
you
can't
have
like
without
two
layers.
You
can't
have
both
a
link
and
a
parent.
B
That
it's
really
not
practical
with
one
layer,
it's
not
practical
to
ever
split
this
into
two
traces,
and
I
sort
of
think
that
for
many
use
cases,
that's
really
a
requirement
because
of
the
persistent
nature
of
some
messaging
paradigms.
Right
and.
E
In
delayed
delivery,
yes,
I
think
so
too.
E
I
just
put
it
like
it's
parent-child
relationship
here,
because
it's
easier
to
see
the
big
picture,
but
I
think
you're
right
in
prague
in
like
real
life,
those
will
probably
be
link
traces
and
when
you
just
have
link
traces,
it's
very
kind
of
you
get
a
very
fractured
picture
and
you
don't
really
know
what's
going
on,
because
everything
just
or
all
the
different
phrases
we'll
just
link
to
this
creation
context
and
having
it
as
parent
child
is
not
that
practical
because
yeah,
you
might
have
kind
of
here.
E
It's
it's
a
very
simple
trace,
but
you
might
have
quite
a
big
delay
between
the
creation
and
the
processing
here
and
basically
those
delays
would
would
really
blow
up
your
producer
traces.
Because
then
your
producer
trace
duration
would
suddenly
be
an
hour
because,
an
hour
later,
some
consumer
processes,
the
message
and
his
parents
to
this
trace,
which
is
not
very,
not
very
idiomatic.
So
that's
that's
a
use
case
for
links
actually.
F
I
have
a
question
on
our
not
necessarily
broker
instrumentation.
In
this
example,
johannes,
you,
you
didn't,
have
batching
right.
You
have
just
one
message
on
the
receiver
and
on
the
producer's
side.
E
Is
there
is
batching,
there's
batch
delivery
here,
so
basically,
here
there's
a
prefetch
cache
and
we
can
look
into
it
here.
So
the
consumer
also
here
basically
batches
a
message.
So
here
basically,
you
see
also
message
is
produced,
goes
to
broker
to
the
consumer
and
the
consumer
doesn't
deliver,
but
it
ends
here
after
adding
the
message
to
the
to
the
to
the
prefetch
cache.
E
F
Yeah,
it
makes
sense.
So
my
comment
is
that
if
we
have
batching
consent,
if
we
send
more
than
one
message,
then
we
had
to
have
two
layers,
because
we
can
send
multiple
messages
that
potentially
have
multiple
creation
contexts
and
we
can
send
in
the
background.
We
can
forward
messages
between
brokers,
preserving
their
context,
and
this
is
the
reason
for
for
us
back
then
was
to
have
two
different
players
to
allow
batch.
Send.
E
Yes,
definitely
so
as
soon,
I
think
the
main
point
here
is
as
soon
as
we
dive
into
this
transport
transport,
layer,
instrumentation
and
broken
instrumentation.
E
One
definitely
sees
that
that
this
two-layer
approach
is
necessary
to
produce
like
meaningful
traces
for
this.
When
we
go
about
this
very
simple
use
case
that
we
start
here
and
that
we
plan
to
basically
specify
in
this
first
version
of
the
semantic
conventions
there
there
we
are,
we
are
not.
We
are
not
planning
to
talk
about
any
transport
context.
Instrumentation.
E
If
you
just
have
this
this,
this
application
context
or
creation
context
level,
it's
no
problem,
but
as
soon
as
you
dive
into
the
transport
layer
instrumentation,
then
I
think
one
needs
two
layers
to
really
accurately
model.
What's
going
on.
B
Just
just
one
thought
you'll
honestly,
I
think
the
point
of
your
of
this
example
is
to
show
that
a
single
layer
is
not
a
great
approach
right
like
that's.
That's
what
you
want
to
illustrate
with
this
example.
E
I
think,
with
this
example
I
yes,
I
want
to
show
that
when
we
do
just
have
a
single
layer,
the
traces
that
we
can
create
from
that
are
much
less
how
to
say
a
much
less
kind
of
meaningful
than
traces
we
can
create.
When
we
have
two
layers,
yeah.
B
Okay-
and
I
think
that's
great,
and
if,
if
in
presenting
that
there
are
significant
there,
I
me
I
hope
it
would
just
go
well
and
people
would
agree.
This
is
the
way
to
go.
If
there's
any
pushback
on
that,
I
think
we
can
create
he's
kind
of
my
point
earlier,
and
I
think
ludmila
was
getting
at
the
same
thing
is
that
you
can
create
even
worse
examples
than
what
you
show
there.
Some
scenarios
where,
if
you
only
had
a
context,
it
would
be
even
worse.
B
So
I
I
think
this
is
good
and-
and
if
that
gets
the
point
across
in
in
other
audiences,
where
you're
presenting
it,
then
I
think
that's
totally
sufficient.
But
if,
if
there's
significant
opposition
to
two
layers,
I
think
we
can
do
more
to
show
how
one
layer
causes
problems.
E
That
definitely
makes
sense.
Yeah
I
mean
I
not
for
for
my
for
my
conclusions
to
this
exercise
actually
was
that
in
this
first
version
of
the
semantic
conventions
that
we
want
to
push
out,
basically,
we
we
are
not
talking
at
all
about
broker,
instrumentation
and
also
not
about
transport
layer
instrumentation.
E
So
in
the
first
basically
version
in
v1.0,
we
only
will
not
kind
of
basically
specify
those
higher
application
level
spans
like
this
deliver
span
and
the
creation
and
send
span
here.
E
So
for
this.
For
this
we
w1.0
when
we
just
see
this,
it's
actually
not
a
requirement
to
also
pass
the
transport
context
around.
So
we
do
not
need
to
make
this
a
requirement
for
1.0.
E
I
think
the
only
thing
that
we
need
to
make
sure
of
is
that
what
they
come
up
with
is
extensible
enough,
so
that
at
the
later
point
we
can
also
spec
out
this
transportation
context
propagation
and
cover
it
for
like
the
protocols
that
are
of
interest.
B
For
us,
I
agree
with
that.
I
think,
in
order
for
it
to
be
extensible,
I
think
what
it
means
is
that
the
transport
must
be
allowed
to
modify
the
context,
which
implies
the
two
layers,
and
so,
if
that's
the
conclusion,
then
I'm
happy
yeah.
E
Yeah,
so
I
mean
here,
for
example,
for
I
think
what
we,
what
we
need
to
do
is
that
yeah
we
just
take
like
some
protocols
like
here
in
qb
and
we
and
we
and
we
and
we
test.
Okay,
can
we
work
with
the
two
layers
with
this
protocols?
Can
we
pack
the
two
layers
in
there
and
I
mean
for
mqb?
Basically,
that
exercise
query
shows
yeah
they
can
and
we
can
use
them
as
intended.
E
I
think
what
needs
to
be
done
for
us
is
to
also
test
this
for
other
protocols
that
are
of
interest
for
us.
Can
we
also
manage
this
there
and
basically,
with
those
tests,
we
basically
have
the
potential
extensibility
in
that
direction
covered,
and
I
think
we
then
don't
need
to
require
this
transport
context
in
v.
1.0
of
this
messaging
semantic
conventions.
E
The
only
thing
we
need
to
require
on
context
propagation
site
is
that
we
can
attach
one
immutable
context
and
that
context
ends
up
at
the
at
the
at
the
consumer
side,
but
we
don't
need
to
basically
already
for
1.0,
actually
require
this
transport
context,
because
it
would
also
be
sound
a
bit
weird.
We
require
this
transport
context,
but
nowhere
in
our
spec
then
later
on,
we
actually
use
it.
B
The
only
confusing
part
with
that
statement
is
that
I
mean
just
if
we
look
at
http
as
an
example
where
it
has
defined
a
field
like.
I
forget
the
precise
names
of
trace
context.
This
trace
context
right
that
I,
as
long
as
we
agree
that
that
wouldn't
be
the
place
to
put
this
immutable
message.
Creation
context.
B
E
Definitely
definitely
the
standard,
http,
transparent
field
would
not
work,
because
that
that
that
is,
this
header
is
not
is
by
to
me
that
by
definition
not
immutable
like
across
hops,
okay,
great
perfect,
thank
you
requests,
yeah
and
that's
awesome.
F
Yeah,
thank
you.
So
actually,
when
we
talk
about
the
creation
context,
it's
not
protocol
specific
to
be
precise,
like
you
can
have
a
cloud
event,
you
can
have
your
message
of
any
source,
so
this
is
basically
the
the
library
concern
it
might
correlate
with
something
in
in
the
protocol
like
in
in
case
of
amqp,
but
not
necessarily.
E
Yes,
that's
a
library
concern,
I
think
the
only
the
the
only
place
where
it
then
gets
a
protocol
concern
is
here
that
you
have
to
attach
it
at
the
consumer
side.
You
need
to
know
how
to
produce
or
attached
this
context,
to
the
message-
and
I
think
in
many
cases
this
is
then
via
some
protocol
specific
feature.
G
Right,
but
for
for
for
the
creation
context,
then
I
will
rely
on
on
this
w3c
work.
That
is
in
draft
right,
so
in
this
in
this,
whatever
yeah
key
that
that
is
defined
there,
that
if
they
wanted
this
message
metadata
to
use
right
in
this
in
this
example,.
E
For
for
this
example,
what
is
currently
in
the
w3c
draft
will
be
would
be
sufficient
here
because
there
is
covers
kind
of
just
attaching
the
trace
this
trace
context
and
it
being
immutable
yeah
or
for
mqb,
at
least
for
mqtt.
I
didn't
look
too
deep
into
the
details,
but
I
think
what
we
then
would
need
to
make
sure
for
basically
all
the
protocols
that
we
plan
to
support
mqb
and
qdt
and
http
right.
E
I,
I
think
that
at
least
for
those
three
big
players,
we
make
sure
that
that
it's
possible
to
some
add
to
this
immutable
context
and
that
it's
also
possible
to
kind
of
extend
the
existing
mechanism
with
like
a
transport
context
at
some
point.
But
I
think
this
doesn't
is
not
a
requirement
for
us
shipping
1.0
here.
G
I
was
just
thinking
if
I
didn't
look
yet,
but
it's
on
my
list
to
look
at
the
w3c
draft,
but
do
you
think
it's
it's
it's
feasible
to
use
the
same
yeah
like
because
I
assume
it's
the
same,
similar
key
as
the
trace
trace
parent
key
that
is
present
today.
G
But
do
you
think
it's
possible
to
use
the
same
for
other
protocols
as
well
or
or
each
protocol
will
will
have
its
own,
let's
say,
create
context
key
or
something
because
I'm
just
asking
for,
for
example,
for
http
for
cloud
events
we
also.
We
also
need
to
have
the
same
thing
so
yeah,
I'm
just
wondering
if,
if
it
I
mean
it's,
not
a
good
idea
to
have
one
different
thing
for
each
each
protocol
right
so
yeah.
E
I
think
it's
heavily
dependent
on
the
protocol
for
for
mqb
one
has
like
basically
properties
and
annotations.
Those
are
two
more
or
less
different
dictionaries
attached
to
the
message
and
one
is
immutable
and
the
other
is
not
right
so
and
that's
basically,
you
could
put
the
the
same
trace
parent.
You
could
use
the
same
trace
parent
key
for
both
and
in
the
one
it's
for
the
transport
in
the
other.
It's
for
the
creation
complexion.
E
G
G
E
G
Yeah,
that's
what
is
it's
currently
there,
but
they
had.
They
have
this
other
additional
header
yeah,
but
I
I'm
just
a
bit
yeah
just
thinking,
because
if,
if
we
have
like
messaging
different
protocols
and
each
of
them
has
that
had
their
own
key,
then
I
mean
it
might
be.
Okay,
I
just
I'm
just
thinking
about
it.
A
little
bit.
F
E
E
We
just
put
this
like
in
the
old
tab
under
like
some
future
extensions
connected
with
like
intermediary
and
transport
layer
instrumentation
and
for
mounted
zero.
What
we
could
require
in
contact
propagation
is
just
to
be
able
to
attach
this
this
immutable
context
that
can
then
be
like
extracted
on
the
on
the
consumer
side.
E
It
takes
some
complexity
out.
There
is
still
like
still
like
some
complexity
left,
just
even
with
this
one
immutable
context
to
to
make
clear
how
what
do
we
recommend
or
require
for
the
different
protocols.
G
E
E
But
but
I
think
this
makes
our
stand
like
makes,
I
think
that
makes
our
first
model
much
easier
to
comprehend
for
for
non-messaging
experts
when
we
leave
this
two-layer
model
out
in
the
initial
state.
Also
because
yeah,
as
I
said,
we
don't
really
we
we
don't
really
use
it
for
the
features
we
provide
in
b1.0.
E
G
G
G
G
E
It's
just
just
to
wrap
up
for
for
this
example,
but
what
I
will
do
then,
based
on
this,
I
will
make
some
changes
to
the
existing
old
tap
just
by
taking
out
this
requirement
for
transport
layer
context,
propagation,
and
I
will
move
this
to
another
section.
Just
that
will
be
called
like
future
improvements
and
basically
I
will
put
it
there
and
also
mention
that
this
then
will
be
a
requirement
for
transport
layer
and
intermediary
instrumentation,
but
that
basically
making
clear
that
it's
not
in
the
scope
for
1.0.
G
G
Okay,
if
you're
ready,
I.
A
E
G
Okay,
because
I
don't
have
the
rounding
thing
yeah,
so
I
I
had
this
sample
already
because,
as
I
said,
I
think
some
time
ago,
I
contributed
this
to
the
call
events
go
sdk.
I
contributed
a
while
ago
a
way
for
for
it
using
open
telemetry
for
instrumentation.
They
had
one,
they
had
support
for
open
senses
but
yeah.
G
I
was
working
on
a
project
that
used
cloud
events
and
it
was
go,
and
I
just
noticed-
and
I
just
I
just
implemented
and
the
correct
current
example-
current
code-
that's
there
doesn't
use
links
because
it
was
before
I
joined
the
meetings
before
everything,
but
the
example
is
very
simple:
is
it's
using
http
to
send
the
events
and
it's
it's
just
one
event?
G
So,
basically
there's
a
server
running
and
then
there's
a
client
and
the
client
sends
a
message
to
the
send,
an
event
to
the
server
and
then
just
to
exemplify
the
propagation
etc.
Then
the
server
makes
an
external
call.
G
And
I
modify
now
the
code
to
you
to
to
use
links.
I
also
did
this
before
we
discussed
the
delivery
span,
for
example,
but
the
code
is
modified
now
to
use
link
so
and
because
it's
http
and
both
clients
and
server
also
have
the
auto
instrumentation
on.
So
that's
why
we
see
all
of
the
protocols,
but
basically
it's
similar
to
what
what
johannes
showed
so
there's
the
create
here
event
and
then
it's
passed
on
to
the
to
the
to
the
protocol.
G
So
there's
the
the
post
from
the
auto
instrumentation
and
then
it
reached
the
server
and
the
server
is
also
there's
the
receive
this
receiver
here
is
the
http,
auto
instrumentation
as
well,
and
then
here
I
created
the
I
create
the
process
manually
and
then
here
is
where
the
links
the
link
is
yeah.
So
this
links
to
the
to
the
create
here
not
sure
what
this
other
here
is
actually,
but
the
crate
is
here
and
then
there's
the
the
external
call
that
I
mentioned
to
any
other
service.
G
But
this
is
yeah,
so
this
in
this
specific
case,
the
parent
child
is,
is
simple
because
it
is
just
like
a
natural.
I
guess
http
call,
but
it
also
works.
G
Let's
say
well
with
the
module
that
we
have
defined
and
to
illustrate
if
the,
for
example,
if
the
server
or
the
client
were
not
auto
instrumented,
meaning
that
to
take
the
incoming
the
incoming
span
context
to
be
able
to
continue
the
trace,
then
then
we
would
have
separate
trace,
like
johannes,
showed
and
then
we'll
be
able
to
to
go
back
with
with
the
links.
G
So
it
also
works
well
in
the
case,
for
example,
if
I
was
using
the
sdk
to
instrument
to
send
the
events
via
another
protocol
that
was
not
http
and
that
that
protocol
wasn't
auto
instrumented,
then
I
would
have
the
create
and
would
stop,
maybe
the
crate,
and
then
I
would
have
the
process
and
the
external
call
and
so
on,
but
with
the
links
I
would
be
able
to
go
back
to
the
crate.
G
E
So
I
mean
that's:
that's
basically
also
more
as
a
proof
of
concept
as
with
that
with
http.
It
can
handle
two
layers
enemy
cloud
events
already
basically
specifies
or
spells
this
out
how
this
can
happen.
E
I
think
it's
then
just
yeah
an
open
question
for
later
discussion.
For
us
in
regards
to
many
conventions
is
what
what
will
your
approach?
Do
we
recommend
for
http
or
link
to
to
kind
of
enable
this
immutable?
E
Enable
kind
of
I
think
this
immutable
context,
I'm
not
sure
if
it
just
wanna
link
to
cloud
events,
and
just
generally
say:
okay,
just
use
cloud
events,
because
there's
already
spelled
out.
I
mean
that
seems
kind
of
tempting,
actually
because
there's
always
already
a
specification
where
this
is
in,
but
I'm
not
sure
actually,
if
it's
feasible
to
just
yeah,
say
to
people
when
you
use
hdb,
just
use
cloud
event.
G
Yeah,
it's
it's
yeah,
not
sure
as
well,
especially
because
of
this
the
the
way
the
header
is
propagated,
so
actually
in
in
the
in
the
go
sdk,
I
actually
don't
use
the
the
header
that
is
propagated
because
we
always
because
it's
always
anyway.
We
already
have
the
the
event
deserialized
at
the
point,
and
I
can
just
look
at
the
property-
that's
already
there,
so
I
don't
touch
the
header,
but
in
maybe
some
other
other
cases
with
might
need
and
just
need
to
figure
out
the.
G
How
the
header
name
is
is
is
created
and
also
for
other
trans
transports.
G
But
well,
I
think
it's
a
good
start,
and
it's
it's
in
this
specific
case
for
the
specific
sdk,
it's
really
transparent
for
the
user,
so
the
user
doesn't
have
to
do
anything.
G
I
can
actually
show
so
like
how
the
client,
for
example,
the
client
code
looks
like
it's
really
simple,
so
it
just
just
creates
a
new
http,
client
yeah
and
then
just
you
just
send
it
and
then
because
it's
all
built
in
let's
say
into
the
sdk
it
already.
G
It
will
create
this
create
span,
this
create
context
and
then
attach
to
the
event
and
then
in
the
server
where
it
it
reads
it.
It's
also
transparent.
There's
there's
like
nothing
so
like
you
start
the
server
here
and
then,
when
the
event
event
arrives.
It
arrives
at
this
callback
here,
but
the
receive
span
is
already
created
by
the
sdk.
G
I
just
just
demonstrated
for
the
sake
of
demonstration
that
I
can
inject
or
extract
the
context
from
that
is
the
create
context.
That's
inside
the
event,
but.
G
And
the
nice
thing
with
this
I
mean
it's
not
also
not
possible
for
the
other
and
not
sure
if
it's
possible
for
all
the
other
languages,
but
for
for
this
specific
one
it
this
works.
So
this
trace
here
would
be
at
least
the
crate,
and
the
process
part
would
be,
it
will
be,
will
be
possible
for
any
any
any
any
transport
that
is
used
so
http
and
qpa
whatever
any
anything
that
the
sdk
supports.
E
Yeah,
but
I
mean
at
least
for
go,
I
think
it's
a
nice
very
nice
example
for
open
telemetry's
capabilities,
because
basically
you
have
two
libraries
like
the
cloud
events
sdk
and
you
have
to
go.
Http
library
both
are
natively
instrumented
with
with
open
telemetry
and
basically,
both
work
nicely
together,
as
you
see
in
this
trace.
So
basically
you
just
like
those
two
libraries.
You
don't
need
to
write
any
instrumentation
and
you
just
initialize
your
tracer
and
you
get
a
nice.
G
G
I
just
have
one
last
thing:
if
nobody
has
anything,
but
so
I
have
the
the
pr
open
there.
I
think
I
got
enough
approvals
for
from,
I
think
most
of
you
now,
but
just
there's
just
one
open
question
from
tigran.
I
replied
to
him,
but
maybe
he's
maybe
he's
still
waiting
for
someone
else
to
reply,
but
he
just
he's
a
bit
concerned
because
we
introduced
this
top
new
level
semantic
conventions,
let's
say
namespace.
G
G
What
sorry
I
didn't
get
that,
do
you
mind,
providing
a
link,
oh
yeah
sure
I
can
just
I
can.
I
can
grab
the
link.
Yes.
G
I
think
most
of
you
approved
it.
G
Yeah
now
there's
now
there
is
a
conflict
because
of
the
changelog,
but
I
will
fix
it
and
it
should
be
good
to
go.
This
is
the
link,
yes,.
G
Yeah,
it's
basically
everything
that
we've
been
discussing
right
and
it's
it's
it's
experimental
anyway,
so
it's
still
possible
to
I
mean
I
still
we
still
will
definitely
have
to
update
once
we
progress
more
with
with
this
old
tap
here
anyway,
but
I
think
it's
good
to
have
it
merged
and
some
progress
on
on
it.
E
Thanks
so
we
are
almost
at
time
so
for
basically
for
next
week,
I
will
try
to
find
some
time
to
fix
the
boarding
and
existing
old
tap
to
kind
of
move,
this
transportation
layer
stuff
to
like
future
items.
I
will
also
try
to
come
up
with
another
example
for
this
portal.
E
Instrumentation
on
consumer
site,
like
there
was
some
workload
miller,
did
with
this,
where
we
have
this
receive
span
and
where
we
had
the
problems
with
the
links,
because
I
think
that
is
the
next
basic
or
for
my
side,
from
my
point
of
view,
actually
one
of
the
last
open
problems
on
the
producer
instrumentation
that
we
need
to
tackle
that
we
clarify
okay.
E
How
do
we
properly
create
links
for
this
poor
scenario
when
we
have
to
receive
spend,
because
even
now,
when
we
just
yeah,
throw
this
one
layer
out
for
now
and
put
it
under
to
do?
We
still
have
the
problem
in
this
case
with
like
adding
the
links
after
span
creation,
so
I
will
try
to
like
come
up
with
an
example
there
that
that
shows
how
we
can
do
it
with
the
with
the
current
limitation
of
only
allowing
us
to
to
add
links
at
span
creation,
and
then
maybe
we
can.
E
We
can
look
at
that
example
the
trace
next
week
and
then
maybe
compare
and
see
in
how
far
that
is
feasible
for
us
or
how
strong
we
need
to
push
for
having
adding
for
adding
links.
After
after
span
creation.
A
E
Needed,
oh
sorry,
I
tried
to
say
it
also.
It
helped
me
a
lot
to
kind
of
clarify
some
open
issues
that
also
showed
me
that
this
transport
context
is
not
really
needed
for
now,
but
yeah,
I
think,
is
indispensable
for
for
later
extensions.
A
Yeah
code
prototypes
always
end
up
resolving
the
final
issues
that
we
can't
figure
out
in
english,
so
it's
really
great.
I
know
I
think
it'll
be
helpful
to
be
able
to
present
this
stuff
to
like
the
rest
of
the
the
spec
committee.
I
think
once
we've
gone
through
another
like
round
of
you
know
resolving
the
issues
we
discussed.
A
E
Yes,
I
actually
think
like
that
the
example
for
next
week
will
be
the
more
interesting
one
for
for
this
wide
audience
because
therapy.
Basically,
that
will
be
our
our.
That
will
illustrate
our
need
for
this
ad
links.
Adding
links
after
spam
creation.