►
From YouTube: 2020-08-18 .NET SIG
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
B
B
C
D
C
C
Let
me
use
that
time
to
quickly
give
a
status
update
on
how
things
are
progressing.
So
if
we
look
at
issues
which
are
tagged
for
the
next
milestone,
which
is
releasing
in
approximately
two
weeks,
we
are
pretty
good
shape
there.
So
when
was
yet
august
26,
oh
so
next
week,
I
expect
the
preview
8
of
dot
net
to
be
available
in
nougat,
so
I'll
remove
the
private
feed,
and
then
we
should
be
able
to
release
at
that.
There
is
no
nothing,
no
p1
issues
which
are
blocking
us
from
releasing
the
next
one.
C
Even
though
we
started
with
a
very
small
list
we
achieved
quite
large
number
of
issues
are
addressed.
It's
very
hard
to
find
from
the
github
milestones
along.
The
best
way
to
track
is
to
look
at
the
changelog,
which
should
be
like
fairly
big.
C
E
Yeah
hi,
so
so
we
just
noticed
that
the
address
id
of
an
activity
is
like
kind
of
hardcoded
when
it's
generated
in
the
wrong
time
right
and
yeah
32
digit
render
totally
randomly
and
which
is
converted
from
the
guid.
E
So
we
are
wondering,
if
it's
possible
for
your
site
to
make
like
a
compatible
x-ray
choice
id
the
exercise.
Id
is
like
the
first
eight
digit
number
is
epic
time
in
hexmod
decimal
format
and
the
remaining
24
dj
is
also
randomly
and
using
the
32
bit.
32
digit
render
number
from
x-ray
trace
id
is
also
like
random,
completely
rendered
and
unique,
so
it
will
not
affect
the
current
feature
of
your
site,
but.
C
Is
it
still
like
the
w3c
compatible
one
right,
one
right,
so
one
thing
is
like
we
like:
there
is
no
logic
to
generate
trace
id
as
part
of
open
elementary
repo,
it's
all
coming
directly
from
dotnet
runtime.
C
So,
whatever
change
we
need
we'll
have
to
like,
I
don't
think
there
is
any
anything
exposed
to
support
different
trace
id
than
the
one
which
they
generate.
So
it
could
be
interesting.
How
do
we
achieve
this
thing?
It's
most
likely.
C
Some
support
would
be
rated
from
the
needed
from
the
dot
net
front
time
itself,
yeah,
yeah,
okay,
so
yeah
I
mean
we
don't
have
anyone
from
dotnet
team
joining
us
today.
So
I
think
this
is
something
which
I
need
to
like
get
back,
but
there
are
like
more
folks
if
anyone
else
has
more
insights
on
this.
F
Hi,
this
is
prashant
from
aws
as
well.
I
work
with
volume
so
on
that.
How
do
like
jager
or
zipkin
manage
to
like
convert
the
trace
ids,
because
even
giggers
trace
id
is
not
w3c
compliant.
C
B
If
not
so,
there
are
two
different
issues
between
jaeger
and
aws.
I
format
of
trace
id.
So
in
jaeger
it's
still
16
bytes
of
randomness,
so
it
doesn't
have
any
encoded
value
inside
the
trace
id.
So
I
think
in
this
case
you're
searching
you're
looking
for
some
random,
like
non-random
trace
id.
So
basically
it
still
has
a
random
part,
but
you
want
to
enforce
the
first
part
to
be
a
time,
and
I
I'm
curious.
Why
do
you
need
this
like?
What
is
a
motivation
here.
E
B
Format-
okay:
we
had
this
issue
before
on
specifications.
You
we've
been
wondering.
I
can't
find
it
right
now.
I
will
try
to
find
it.
We've
been
wondering:
why
do
we
need
to
make
sure
that
every
language
supports
this
generation
of
trace
id
or
it's
fine
to
just
leave
it
to
the
language
to
generate
whatever
the
whatever
this
language
you
want?
B
So
if
it
will
be
great
to
have
some
motivation
added
there,
specifically
for
aws
and
this
epoch
time
in
the
beginning
of
trace
id,
what
we've
been
discussing
at
some
point
with
yeah?
I
think
it
was
ansi
and
abhishek
we've
been
discussing
that
we
may
propagate
epoch
time
a
stray
state
and
have
specialized
propagator
registered.
That
will
extract
this
epoch
from
tray
state
and
do
some
magic
to
either
append
it
to
trace
id
or
replace
some
characters
in
trace
id
or
just
send
it
separately
to
your
back
end.
B
E
Oh
yeah
yeah,
we
totally
yeah,
so
you
you
mean
put
the
the
eight
digit
in
the
trace
data
stream
right
and
it's
into
the
propagation
and
then
convert
back
when
we
propagate
to
downstream
services.
B
E
Yeah,
I
think
that's
not
the
feasible
things.
C
So
sergey,
what
was
the
issue
you
said
like
which
you
were
looking
for
some
motivation
to
make
it
part
of
the
spec?
Is
it
like.
C
B
Something
else
yeah,
it
directly
came
from
aws
scenario,
so
in
aws
we
have
this
logic
that
trace
id
is
not
like
totally
unique,
and
there
is
a
logic
like
in
the
back
end
that
rely
on
the
fact
that
race
id
has
a
prefix
that
is
epoch.
B
Time
yeah
I,
and
at
the
point
we've
been
discussing,
like
whether
we
can
infor
like
whether
we
can
allow
this
kind
of
extensibility,
but
it
always
boils
down
to
the
fact
that,
even
if
you
allow
this
extensibility
and
you
can
register
substance
that
put
a
pork
time
in
front
of
trace
id,
there
is
always
a
possibility
that
customer
just
forgot
to
register
this
extensibility
point
or
doesn't
use
this
extensibility
point
at
all,
and
aws
will
start
receiving
trace
ids
that
are
not
conformant
with
your
format,
and
if
we
cannot
prevent
that
non-conformation,
we
need
to
do
something
different
and
the
solution
with
stray
state
may
be
a
good
alternative.
B
You
can
like
expert,
will
expect
this
epoch
time
from
a
trace
state,
and
if
it's
not
there,
it
will
do
something
to
indicate
that
this
trace
id
is
not
conformant.
F
Yeah,
so
so,
currently
the
open
telemetry
java
integration.
So,
if
like
someone
wants
to
send
the
back
use
the
back
end
as
x-ray,
they
would
in
their
tracer
provider,
would
use
the
x-ray
trace
id
generator.
F
F
F
G
G
G
F
That's
yeah
so
in
case
of
exporter,
but
in
case
of
like
a
variable
vendor
situation
where
a
service
is
instrumented
with
open
telemetry
and
it's
talking
to
some
aws
managed
service,
for
example,
sqs
or
lambda.
Then
in
that
case,
even
the
propagator
would
need
to
convert
the
w3c
trace
id
to
the
x-ray
trace
id.
F
We
support
yeah
that
that
can
be
achieved
through
propagator,
but
that
would
propagate
a
word
to
the
this
task
on
every
span
or
activity.
That's
that's
created
for
for
every
context.
F
Yeah
so
propagator
becomes
like
kind
of
the
heavy
lifter
in
the
process.
C
F
My
preference
or
like
the
top
idea,
would
be
if
we
can
get
some
extension
to
the
dot
net
runtime
to
be
able
to
like
have
a
custom
id
generator
to
the
activity
trace
id.
C
C
C
C
So
we
need
to
ask
whether.net
runtime
team
is
willing
to
make
such
a
change,
but
I
would
only
ask
that
like
if
there
is
no
other
workaround
like
if
there
is
a
reasonable
workaround
which
can
be
implemented
using
the
w3c
spec
itself
by
in
terms
of
our
trace
rate,
then
we
we
don't
need
it,
because
it's
generally
a
little
harder
to
make
any
changes
in
dotnet
framework
itself,
then
doing
changes
in
upon
telemetry
just
to
keep
my
backward
compatibility
and
other
things
right.
C
G
I
was
just
looking
at
that
code
today
because
I
was
wondering
if
we
could
turn
off
the
automatic
propagation
of
the
correlation
context.
It
doesn't
look
like
there's
a
way.
No,
there
is
no
way
it'd
be
kind
of
nice
if
there
was
a
way
that
we
could
tell
don
that
like,
we
want
to
own
all
of
that
logic,
so
that
we
could
have
this
flexibility
that
would
be
kind
of
nice.
C
Yeah
I
mean,
based
on
my
knowledge,
there
aren't
any
options.
Even
I
mean
the
only
thing
which
activity
allows
us
to
control
is
the
format
which
is
I
mean
it
only
supports
two
one
is
the
hierarchical
and
then
the
w3c,
but
that
I
said
I
I
don't.
I
don't
see
us,
there
is
no
extensibility
point
for
us
to
take
part
or
even
influence
the
id
generations
or
or
anything
else.
B
Yeah
we
fought
very
hard
hard
on
integrating
it
into
dotnet
and
the
reason
for
that
is
if
it's
integrated,
then
it
will
be
guaranteed
to
be
propagated.
So
we
wanted
this
guarantee
somehow
and
that's
why
we
went
into
like
double
3c
specifications
and
did
all
this
work.
B
And
now,
if
you
try
to
own
it
back
it
will
it
will
a
little
bit
limit
use
of
this
generation
of
id
and
like
propagation
of
correlation,
because
if
it's
not
part
of
net
and
it's
not
controlled
by
net,
then
it
will
be
treated
as
something
that
is
not
a
fast
or
maybe
something.
That's
not
secure
and
like
that
will
generate
some
issues.
C
B
Yeah
we've
been
seeking
for
feedback
on
like
what
exactly
the
scenario
and
how
it
will
be
used,
and
I
still
having
hard
time
to
understand
like
if
x-ray
will
be
used
like
x-ray
expert
will
be
used
and
this
propagator
wasn't
registered,
will
something
fail
or
like?
Wouldn't
it
work
at
all
like
how
does
it?
How
does
it
operate
in
a
situation
when
this,
the
customer
just
thought
what
to
register
this
propagator
or
randomized
generator?
C
Yeah
so
like
the
current
plan,
I
think
we.
C
Both
from
aws
here
so,
if
you
can
like
confirm
after
some
trying
like
see
if
it
is
feasible
to
achieve
the
scenarios
by
using
tri-state
itself,
then
we
don't
need
any
change
in
runtime.
But
if
not,
let's
discuss
it
again
next
week
to
see.
If
we
need
to
push
for
some
changes,
I
think
we
should
probably
start
with
the
spec,
not
just
the
runtime.
C
I
mean
if
it's
a
requirement
which
is
not
specific
to
dotnet,
then
it
should.
I
expect
it
should
come
directly
from
the
spec
itself
so
that
we
have
more
ways
to
push
for
any
changes
in
dotnet
or
any
other
language.
For
that.
F
Yeah
this
week
we
can
explore
the
trade
state
and
how
much
work
or
like
effort.
It
is
and
then
also
prepare
this
step
for
runtime.
C
We
don't
have
anything
else
in
the
agenda,
so
we'll
use
this
time
to
discuss
couple
of
issues
like
open
peers
which
michael
and
eddie
was
working
on,
but
before
we
go
there,
let
me
ask:
is
there
any
questions
which
require
addressing
any
any
questions
at
all?
We
can
take
it
now.
C
Okay,
I
don't
hear
anything.
Okay,
let's
look
at
the
fears
which
I
think
I
merge
yeah.
I
just
merged
this
one.
So
basically
we
had
an
issue
created
last
time
about
the
propagation
which
we
tagged
it
for
the
next
milestone,
not
the
current
one,
because
we
were
not
very
sure
whether
we
have
time
to
address
it.
C
But
last
week
it
was
mentioned
that
michael
would
be
taking
a
stab
at
fixing
the
context,
slash
correlation
context,
slash
distributed
context
apa
to
make
it
complain
with
the
spec
and
this
pr
which
I
just
caught
much
few
minutes
back
is
the
first
attempt.
So
there
are
several
concerns
which
are
raised
here,
but
before
I
go
into
that,
michael
since
you
are
already
here,
can
you
just
walk
us
through
like
what
was
the
biggest
change
here,
and
why
do
we
think
this
is
still
considered
out
of
spec?
G
So
what
this
is
doing
right
now
is
probably
duplicating
everything
we'll
we'll
add,
both
basically
outgoing
and
then,
if
we
receive
it,
then
we'll
probably
create
duplicates
on
the
activity.
So
we
definitely
need
to
fix
that.
The
question
is
baggage
property,
as
it
exists
today
doesn't
give
us
enough
to
satisfy
the
spec.
It's
really.
You
can
only
add
to
it
and
enumerate
to
it.
You
can't
reset
or
remove
or
clear
it,
which
creates
some
problems,
because
the
spec
says.
Basically,
we
need
those
features.
C
G
Is
also
the
other
poll
request,
the
enrichment
scope,
which
is
kind
of
overlapping
with
this,
so
enrichment
scope
was
never
really
intended
for
properties
that
would
be
propagated.
It
was
just
for
local
things
in
the
process,
but
then
we
kind
of
added
this
flag,
for
I
want
to
apply
these
tags
to
all
children,
which
is
kind
of
what
correlation
context
is
doing
so
now.
There's
kind
of
some
overlap,
there's
some
gray
area,
so
we
kind
of
need
to
make
a
decision
on
how
we
want
this
to
work
and
what
we
want
to
support.
C
So
I
think
the
first
question
which
we
need
to
ask
is:
do
we
have
to
build
correlation
context
on
top
of
activity.baggage,
or
should
we
just
like
completely
forget
that
activity.package
exist
and
build
correlation
context
completely
from
scratch,
so
that
we
can
be
like
100
percent
compliant
to
the
spec,
because
we
can
implement
whatever
we
want
in
the
correlation
context
api?
C
If
we
stop
leveraging
activity.package
or
we
can
potentially
work
with
the
dotnet
team
to
improve
or
change
the
baggage
similar
similar
to
what
we
had
done
for
activity
dot
tags
which
was
originally
not
confirming
to
the
open,
telemetry
spec,
it
did
not
allow
removal
or
it
did
not.
It
did
allow
duplicates
to
be
added.
There
was
no
set
operation
and
there
was
restrictions
on
the
type,
but
those
were
addressed.
C
It
will
be
part
of
the
dotnet
fire
release,
but
package
was
never
considered
or
we
never
had
any
proposal
to
fix
baggage.
So
the
question
is:
should
we
still
pursue
this
approach
of
like
making
dot
net
fix
the
baggage
in
the
next
release
and
then
build
our
correlation
context
on
top
of
it?
Or
should
we
completely
ditch
the
baggage?
Completely
and
build
correlation
contact
separately
so
that
we
can
be
compliant
with
the
spec
right
away.
So
apart
from
the
apart
from
the
spec
compliance
perspective,
the
performance
issue
is
also
there,
like
guys.
C
Michael,
was
mentioned,
like
b,
because
dotnet
is
already
taught
to
already
extract
baggage
from
correlation
from
a
header
which
is
called
correlation,
hyphen
context,
and
it
is
also
doing
the
propagation
when
code
is
made
using
http
claim,
whatever
is
on
the
baggage,
it's
injected
into
the
http
header
correlation
context,
with
the
change
which
michael
just
did,
we
will
be
duplicating
the
exact
same
effort
into
a
different
header,
like
called
package,
which
confirms
to
the
w3c
official
recommendation
for
the
header
name.
So
I
think
these
two
are
the
issues
which
we
need
to
address.
H
I
think
we
should
not
use
activity
baggage
to
date.
Well,
as
you
mentioned,
create
all
this
crazy
side
effects
and
going
forward.
I
don't
know
like
usually
it's
a
big
deal
to
do
any
breaking
changes.
If
the
baggage,
like
that,
the
property
on
activity,
the
public
api
will
change
behavior.
This
will
be
probably
no
goal
from
the
net
team
and
it's
up
to
them
how
to
do
this,
but
maybe
I
can
suggest
that
we
follow
what
we've
done
for
w3c,
that
once
this
correlation
context,
spec
matures.net
can
implement
it.
G
C
Mean
to
achieve
that,
we,
the
current
recommendation,
would
be
for
folks
to
put
things
into
activity.baggage
and,
like
we
thought,
even
open
elementary
being
in
the
picture,
it
would
be
propagated
and
extracted
automatically
by
dot
network.
We
will
miss
out
on
that,
like
niceness,
when
we
build
correlation
context
outside
of
package.
C
Yes,
but
I
think
the
only
option
for
us
to
achieve
like
both
these
goals,
like
one
is
to
to
be
able
to
enrich
activity
by
having
a
correlation
context,
apa
and
still
being
compliant
with
the
spec,
is
to
improve
the
activity
itself
to
support
correlation
context,
and
I
think
what
lupitas
was
thinking
like.
We
should
probably
do
a
correlation
context
thing
right
now,
because
there
is
no
scope
for
any
changes
in
dot
net
phi
time
frame.
C
The
earliest
would
be
net
six,
which
is
coming
next
year.
So
by
that
time
we
can
hope
that
the
correlation
context,
spec
itself,
would
be
stable
enough
to
push
the
changes
into
dotnet
baggage
or
baggage
new,
whatever
thing
which
we
call
it
but,
like
my
immediate
concern
is
what
do
we
do
like
in
the
meanwhile
like
right?
Now?
It
should
be
like.
Should
we
just
like
abandon
what
we
are
doing
in
this
pr
by
building
on
top
of
which
builds
on
top
of
baggage
and
like
replace
it
with,
on
correlation.
C
Yeah
I
mean
ludmila:
do
you
have
any
other
thoughts
on
this
one,
because
this
beer,
which
just
got
merged,
is
building
purely
on
top
of
baggage?
So
it's
out
of
complaint
with
the
spec,
but
it
has
the
niceness
of
you
can
add
baggage
without
taking
any
ap
dependency.
H
C
That's
good,
okay,
cool
yeah,
so
just
to
confirm,
I
understand
it
correctly.
We
should
like
revisit
this
pr
makes
changes
so
that
correlation
context
is
built
independently,
following
whatever
is
the
available
spec
and
once
the
specs
stabilize
us,
we
should
pursue
to
make
this
part
of
the
activity
itself
and,
at
that
time
the
correlation
context.
Whatever
we
ship
today
will
be
just
a
around
the
actual
activity,
similar
to
our
other
other
shim
layers,
for
like
the
tracer
and
span.
G
H
C
So
there
is
no,
there
is
no
spec
which
says
how
how
the
correlation
context
should
be
becoming
part
of
the
span.
H
C
C
C
But
so
to
answer
michael,
I
think
we
we
can
probably
check
what
other
languages
are
doing
and
pursue
something
from
the
spec
itself
on
what
should
be
the
actual
thing
which
we
should
do
with
the
correlation
context
thing
yeah.
I
didn't
realize
that
it
was
not
specced
out.
C
That
sounds
good
to
me.
Yeah,
okay,
I'll,
write,
notes
after
we
are
done
so
so
there
are
no
pending.
I
mean
we
already
discussed
what
we
are
going
to
do
with
correlation
context,
but
that
aside,
it
had
several
other
changes.
Okay,
I
mean
if
there
are
like
photos,
just
create
issues
or
think
one
of
us
in
jitter
we
can
discuss,
but
the
main
thing
is
so
we
can
move
on
to
the
next
one,
which
is
closely
related
to
this.
C
It's
not
yet
much.
So
it's
still
an
open
pr.
So
again,
michael,
can
you
walk
us
through
the
reasoning
behind?
We
are
introducing
something
called
enrichment
activity,
processor
and
enrichment
scope.
G
Sure
so
the
main
use
case
or
story
that
that
I
wanted
to
enable
is
people
adding
what
I'm
calling
contextual
information
on
their
spans.
So,
like
I'm,
making
an
http
call
to
some
web
service.
I
know
in
my
library
this
particular
call
might
be
for
a
certain
customer
or
a
certain
user.
It's
information.
G
So
the
enrichment
scope
is
really
just
a
closure
so
that
I
can
put
some
stuff.
You
know
in
a
callback
that
once
that
activity
has
been
created
and
sampled,
I
can
then
push
some
data
onto
that
spam.
It's
not
meant
to
propagate.
It
was
really
just
for
that.
Next,
guy
that's
created,
so
you
would
wrap
like
a
call
to
sql
or
an
http
call,
or
I
don't
know
a
socket
something
immediate
you're
about
to
make
a
call-
and
you
just
want
to
basically
cue
up
some
data
that
you're
going
to
put
on
that
spin.
G
That
was
sort
of
the
initial
thinking
and
then
alan
had
an
idea
to
expand
it,
which
was
pretty
easy
to
do
so
that
you
could
create
a
longer
live
scope.
You
might
do
it.
I
don't
know
in
a
thread
or
in
the
whole
library
that
would
just
have
contextual
information
that
would
be
applied
to
every
span.
That's
emitted,
that's
sort
of
like
correlation,
but
it's
not
propagated.
It's
just
for
that
process,
which
is
a
significant
feature.
G
G
So
that's
basically
what
is
built
the
reason
there's
a
processor
for
it
is
riley
brought
up
that
originally
I
had
it
in
the
activity
listener,
but
then
customers
that
aren't
using
this
still
have
to
pay
a
perf
cost.
So
I
pushed
it
into
a
processor
so
that
people
can
basically
opt
in
to
the
feature
and
anyone
that
doesn't
they
won't
have
any
kind
of
perf
at
all.
It'll
just
basically
be
transparent
that
it
exists.
C
I
see
so
this
is
I
mean.
Can
you
help
me
with
differentiating
this
from
correlation
context?
So
if
I
were
to
replace
this
with
using
correlation
context,
dot
add
these
tags?
How
would
it
be
different?
Is
it
only
about
the
propagation
further
downstream.
G
C
G
C
G
G
So
if
you
say
first
child,
it's
just
going
to
apply
to
the
next
span
created.
So
in
this
case
it's
wrapping
an
http
client
call.
So
this
user
just
wants
to
add
some
data
to
that
http
client
call
if
you
were
calling
like
grpc
or
something
that
you
know
we're
instrumenting
one
library
that
itself
makes
another
call
that's
where
that
becomes
really
important.
So
the
whole
idea
here
was:
I
just
want
to
write
it
on
the
next
thing
and
not
anything
else
downstream
or
anything
else.
That
happens
later.
G
C
Yeah,
so
I'm
still
thinking
is
there
any
other
alternate
way
to
achieve
this
without
introducing
an
api,
I
mean
I
am
fine
with
the
api,
but
my
only
concern
is
this
is
very
specific
to
dotnet.
There
is
no
spec
or
anything.
It
would
be
like
something
which
is
specific
to
dotnet.
C
I
mean
which
by
itself
is
not
a
harmful
thing,
but
I'm
just
saying
like
this
would
be
like
very
specific
to
dotnet
and
very
similar
to
the
correlation
context.
So
there
could
be
like
potential
confusion,
or
when
should
I
use
one
versus
other
and
what
what
benefits
do
we
have
when
I
use
one
approach
versus
the
other
approach.
C
H
Yeah,
I
remember
there
was
some
conversation
about
correlation
contacts
that
it
should
have
time
to
leave
for,
like
number
of
hopes
sergey
do
you
know
if
it's
something
that
is
still
being
discussed.
H
A
F
H
C
Yep
you
mean
the
I
logger
begin
scope
cooperate.
H
Exactly
yeah,
and
probably
we
we
had
this
discussion
for
years
like
how
to
make
activity
versus
correlation
context
versus
slugger
scopes
work,
so
I
I
don't
think
we
will
ever
be
able
to
solve
it.
C
Yeah,
I
think
one
thing
which
we
are
missing.
There
are
like
two
parts
which
michael
has
shown
in
this
example.
So
one
is
to
put
regular
things
which
are
like
not
really
coming
from
the
library
itself,
but
then
there
are
certain
things
which
are
like
the
strong
object,
like
http
request
or
sql
command
instance.
C
We
are
trying
to
extract
more
things
which
are
part
of
those
strong
object.
So
so
michael,
can
you
describe
like
what?
What
is
the
like
real
difference
between
these
two
apart
from
fact.
G
The
second
part
there
is
is
another
common
request,
which
is
so
I'm
sending
http
spans,
and
I
want
to
capture
more
data.
So
in
this
example,
I
have
user
agent
on
the
request
and
have
content
type
on
the
response,
so
this
would
be
easier
to
solve
with.
We
could
just
add.
You
know
an
action
delegate
in
the
options
in
the
instrumentation,
because
we
have
you
know
these
objects
available
inside
the
instrumentation.
We
have
requests,
we
have
response,
we
might
have
an
exception,
so
we
could
do
it
in
the
options
for
this
case.
G
G
The
other
alternative
is,
we
have
to
add
it
on
all
the
instrumentation
options,
which
is
fine.
I
feel
like
we
should
as
well,
because,
like
filters
are
pretty
common
enrichment's,
pretty
common
but
yeah
I
mean
I
have
a
demo
because
I
felt
like
if
you
had
enrichment
scope
and
you
were
enriching,
you
could
also
do
it
there.
It's
just
it's
just
kind
of
a
convenience
thing.
C
My
only
question
is
like
this
is
something
which
we
can
achieve
without
changing
anything
by
writing
a
simple
activity:
processor
right,
because
if
you
write
an
activity
processor,
you
get
callback
on
start
and
end,
and
if
you
like,
just
like,
we
were
recommending
here
like
we
need
to
add
an
enriching
processor.
So
inside
this
processor,
you'll
get
activity
start
and
stop,
and
inside
activity
you'll
have
an
opportunity
to
retrieve
the
like,
actual
sql
or
http
object
and
use
that
to
enrich
the
activity
itself.
C
So
whatever
is
shown
in
this
line,
it's
something
which
we
can
achieve
even
today
without
any
change
right.
G
Correct
you
could
write
a
a
custom
processor.
I.
G
C
C
Interesting
yeah,
so
the
activity
processor
is
somewhat
superior
in
that
case,
because
you
write
it
once
and
add
it
at
the
time
of
building
your
tracer
provider
and
don't
worry
about
anything
else
that
that's
the
reason
why
I
said
like
it
should
be
possible
for
us
to
achieve
this
thing
without
using
enrichment
scope,
it's
like
something
which
we
should
have
yeah.
It's
not.
C
C
G
Closure,
that's
the
main
thing,
because
if
you
had
an
activity
processor,
how
do
you
get
it?
How
do
you
inject
that
context
for
this
particular
request
into
that
global
thing,
or
vice
versa?
If,
if
you
have
a
single
delegate
in
options,
it's
fine
to
grab
the
things
off
the
message:
http
requests,
http
response,
but
getting
these
variables
or
something
that's
you
know,
contextual
becomes
very
difficult.
If
you
only
have
one
global
thing,
if
that
makes
sense,
that's
why
I
kind
of
went
with
this
logger
scope
type
of
design
here.
H
I
guess
the
the
only
concern
here
says:
you're,
correct
me:
if
I'm
wrong
that
and
the
this
is
the
some
kind
of
public
api
and
generally
they
are,
they
hurt
and
sometimes
hurt
more
than
provide
value,
I'm
not
sure
like
where
we
are
with
this
one,
and
I
think
it's
quite
useful,
but
the
concern
is
that.
C
A
G
G
C
H
C
Okay,
so
we
are
essentially
saying
the
same
like
it's
not
part
of
the
main
sdk
package.
It
should
be
like
a
separate
package
so
like
the
scope
and
the
processor
can
be
like
completely
separate
from
the
main
sdk.
C
You
see
yeah.
That
makes
sense,
so
I
mean,
if
I
were,
to
like
split
this
into
two
separate
problems
like
one
is
these
two
lines
which
I'm
highlighting,
which
we
should
be
able
to
solve
with
a
proper
correlation
context,
api
which
supports
the
notion
of
like
first
child
or
number
of
hopes,
equivalent
thing
and
the
second
part
we
can
support,
even
without
correlation
context,
by
writing
a
like
regular
activity
processor.
So
these
two
are
independently
achievable.
G
The
first
part
we
could
build
into
correlation
context.
I
mean
we
just
need
a
little
bit
of
expansion
in
that
api.
It'd
be
nice.
If
you
could
add
stuff
to
it
and
say
you
know
the
number
of
hops
or
yeah,
it's
not
part
of
the.
D
So
forgive
me
for
my
that
might
be
well.
I
am
somewhat
familiar
unfamiliar
with
the
correlation
context
specification,
but
one
of
the
things
that
intrigued
me
about
this
pr
was
mainly
the
declaration
of
attributes
on
spans
that
are
that
are
generated
by
you
know
built-in
instrumentation
in
libraries
and
so
question
like
imagine.
If
this
scope
were
around
a
database,
call
where
you
know
it's,
not
an
external
call,
it's
not
something.
That's
going
to
be
like
propagated
downstairs
stream
to
another
service
would
correlation
context,
be
a
solution
in
that
use
case
as
well.
C
D
C
Yeah,
so
the
that's
the
question
which
we
were
trying
to
address
earlier,
like
how
do
we
propagate
it,
because
the
pr
which
we
merged
earlier
by
michael
this
one
uses
a
w3c
baggage
to
propagate
it?
But
this
would
mean
user
has
to
add
the
baggage
formatter
to
the
list
of
composite
formatter
and
we
modified
the
http
in
and
out
to
include
it
by
default.
So
it
has
a
composite
propagator
which
does
trace
context
and
the
baggage.
C
D
C
The
part
which
we
were
I
mean
I'm
not
even
sure
like.
Where
would
the
correlation
context?
When
would
the
things
from
correlation
context
become
part
of
the
span?
So
that
part?
I
am
not
yet
sure
I
need
to
reread
the
spec,
but
based
on
what
ludmilla
was
saying,
it's
not
really
specked
out,
like
what
part
of
the
correlation
context
becomes
part
of
the
span,
attributes
yeah,
okay,
yeah.
D
C
It's
unclear
to
me
as
well.
I
I
need
to
do
some
more
background
trade
there
and
see
even
today,
if
you
do
anything
to
baggage,
it's
not
going
to
be
visible
anywhere,
because
none
of
the
exporter
deals
with
baggage.
Yet.
C
Okay,
but
yeah
I
mean
this
is
something
which
we
still
need
to
discuss
and
what
should
be
the
right
way
to
handle
it
yeah.
So
michael,
do
you
can
you
just
summarize
in
the
notes
here
I
probably
didn't
write
it
down.
Can
you
just
summarize
the
action
item
which
we
are
trying
to
like
one
of
the
option
is
to
extract
this
out
into
a
separate
package
so
that
the
we
have
less
public
apa
burden
in
the
main
package
or
alternately.
C
Let's
work,
let's
work
on
the
correlation
context,
part
first
and
see
if
it
can
address
this
part
and
the
the
depth
or
number
of
hope,
part
first
and
then
come
back
to
this.
Does
it
make
sense.
G
A
solve
and
then
we
can
pursue
so
we'll.
Do
the
other
thing
we'll
we'll
the
first
item
we
talked
about
with
correlation
context.
Well,
we
won't
tie
it
to
baggage,
we'll
get
that
done,
and
then
we
can
try
to
see.
I
don't
know
if
we
can
get
the
spec
clarified
or
expanded
so
that
we
can
then
eliminate
enrichment
scope
and
just
pull
it
into
correlation
context.
Correct
yeah
that.
C
Yeah,
so
are
there
any
more
costumes
on
this
area?
I
mean
it's
little
bit
unclear
for
many
folks,
including
myself,
but
we'll
come
back
to
it
next
week
as
well.
C
Okay,
yeah,
but
even
if
you
don't
do
anything,
we
should
still
sorry,
even
if
you
don't
do
anything,
we
should
still
take
care
of
populating
the
activity.
Dot.
Custom
object
from
all
our
instrumentation
right.
I
think
you
did
this
as
part
of
this
pr,
but
it
should
be
done
until
slightly
so
that,
like
if
some
customers
want
to
write
processors,
they
should
be
able
to
access
it
themselves.
F
G
Is
in
or
out,
I
think
so.
I
think
that
should
be
kind
of
standard
practice
for
instrumentation.
As
we
add
the
display
name,
this,
the
the
kind
and
the
raw
object
as
a
custom
property
yeah,
and
if
someone
wants
to
use
it,
they
can
use
it
otherwise,
they'll
just
sit
there
with
you
know
you
you
have
to
all
okay,
whatever
it
is,
underneath
a
dictionary
or
a
collection
or
a
list
or
something
which
kind
of
sucks.
But
I
think
the
value
is.
It
gives
everyone
an
extension
point
if
they
want
to
do
anything.
C
G
C
Similar
for
correlation
bonus,
we
can
merge
it
and
then
like
work
subsequent
prs
to
clean
up,
because
otherwise
we'll
keep
this
like
pending
forever
and
then
it
will
be
a
bigger
issue
to
deal
with
all
the
conflicts
and
yeah.
I
think
I'll
take
another
look
and
we
can
merge
and
then
discuss
or
address
the
concerns
in
a
separate
folder
up
here.
A
C
Flexibility
of
like
adding
like
public
ap
and
changing
it,
so
we
should
be
leveraging
that
to
the
max
and
we
shouldn't
be
doing
that
after
we
go
ga.
But
right
now
is
the
time
to
do
this.
Experiment.
C
Okay,
yeah
is
there
any
other
question
on
this
topic
or
any
other
topic,
because
this
was
like
asked
like
several
times?
Have
issues
open
asking?
How
do
I
enrich
my
http
span
with
something
from
http
contact?
So
this
is
something
which
we
really
need
and
we
need
to
address
it.
If
not
for
the
next
immediate
release
we
should
try
to.
I
mean
we
probably
have
it
by
an
extremist,
but
if
not,
it
should
be
part
of
that
release.
After
next.
C
Okay,
are
there
any
questions
on
this
topic
or
any
other
questions?
Otherwise
we
can
yeah
I'll.
Do
some
like
right
up
here
with
help
from
michael,
we
discuss
a
lot
of
stuff,
so
it's
kind
of
hard
to
keep
up
with
that
and
write
at
the
same
time
so
I'll
do
it
after
the
call.
C
I
Ahead
hi,
my
name
is
lanice
spangler.
I
work
for
new
relic
and
I
am
here
basically
as
an
observer
just
to
start
getting
the
lay
of
the
land
and
understand
the
issues
that
are
under
discussion.
I
I
don't
I
I'm
committed
to
another
project
right
now,
but
I
had
some
free
time
today
and
I
wanted
to
check
in
and
and
see
what
you
all
were
talking
about.
So
yeah,
okay,.
C
Yeah
and
yeah,
we
don't
have
any
new
members,
yeah
got
it
okay,
so
let's
meet
again
next
week
and
just
a
reminder,
there
is
a
separate
segmenting
for
auto
instrumentation,
which
was
part
of
this
meeting
earlier,
but
now
it
is
spin
off
into
it,
something
I
think
it's
tomorrow
I
forget
the
day,
but
it's
in
the
community
currently
anyway
yeah.
So
no
more
updates
from
me.
Thank
you.
Everyone.