►
From YouTube: 2020-08-25 .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).
B
C
Yes,
this
should
be
very
short
one.
We
don't
have
a
lot
of
things
to
the
agenda,
so
we
can
just
go
over
what
I
have
in
my
mind,
so
the
number
one
update
is:
we
have
the
diagnostic
source
preview
8
just
released
to
you
get
a
little
earlier,
which
means
we
are
now
unblocked
from
releasing
our
next
beta.
C
You
should
be
able
to
do
it
today,
but
I
would
like
to
push
it
a
couple
more
days
so
that
we
can
release
by
friday.
The
reason
is,
we
have
some
braking
changes
which
we
should
be
able
to
accommodate
in
the
current
release
itself,
so
that
we
can
avoid
further
braking
change
or
we
can
reduce
the
amount
of
breaking
change
after
the
beta2.
C
It's
very
small,
like
it's
already,
it's
mostly
arising
from
the
spec
itself,
and
also
there
is
a
fairly
big
pr
about
correlation
context.
Again.
Spec
is
now
calling
it
package,
so
I
want
to
make
sure
we
include
these
two
in
the
beta
2.
Even
if
it's
delayed
by
a
day
I
mean
we
should
still
be
able
to
release
it
this
week,
so
that
should
ensure
that
people
who
are
on
boarding
to
be
tattoo
would
have
lesser
and
lesser
things
to
worry
about
when
they
move
2g.
C
C
Okay,
good,
I
don't
have
anything
else
in
the
agenda,
so
if
there
are
no
topics
to
discuss,
let's
just
quickly
go
over
the
open
peers.
I
think
we
don't
have
any
open
issues
to
discuss.
Everything
is
already
discussed,
yeah
fairly
small
thing
here
we
have
like
new
folks
tony.
C
I
don't
see
anyone
if
yeah,
I
cannot
see
anyone
new.
So
if
there
are
anyone
new,
please
use.
C
Okay,
so
we
can
quickly
go
over
the
major
pr's.
I
think
we
only
need
to
probably
go
over
the
baggage
context
fund,
because
everything
else
is
somewhat
reveal.
C
You
also
see
like
michael,
is
already
here
right
here,
so
this
the
spec
was
more.
I
mean
he's
expected
sometime
today,
which
calls
it
baggage
and
not
baggage
context
or
correlation
contracts.
It's
just
called
baggage,
so
I
think
we
probably
think
I
don't
know
what
was
our
decision?
Should
we
call
it
or
should
we
call
it
package
contacts.
C
Yes,
since
suspect,
is
calling
it
baggage,
I
think
yeah.
We
should
just
call
baggage.
That
was
oh
yeah,
so
we
can
just
like
wait
for
this
to
merge
and
then
we
can
go
ahead
and
start
the
release
process,
but
is.
C
In
like,
I
would
request
everyone
to
really
look
at
it,
because
this
is
fairly
big
change
and
it's
the
big
thing
to
call
out
is
it's
not
built
on
top
of
activity.baggage,
even
though
the
names
sound
very
similar,
it
has
nothing
to
do
with
activity.baggage.
We
are
not
even
going
to
build
it
on
top
of
it.
We
are
not
going
to
propagate
or
read
it.
However,
dotnet
will
like,
if
you
use
speed.com
or
http
client,
it
will
do
some
propagation
and
retrieval
with
activity.baggage,
but
that
is
independent
of
this
one.
C
We
shouldn't
be
like
concerned
with
that
at
this
stage,
because
it's
anyway
going
to
use
a
different
header
than
the
one
recommended
by
I
mean
I
don't
see
a
negation,
but
I
thought
anyone
has
any
concerns
or
will
it
help?
If
michael,
can
you
just
give
a
quick
overview
of
what
we
are
achieving
here
with
this
apa.
C
D
Is
I
was
writing
tests
for
it?
So
I
did
this
kind
of
big
stress
test.
I
wanted
to
make
sure
that
the
baggage
wasn't
leaking
to
other
threads.
It
seems
fine,
so
I'm
not
going
to
check
that
in
it
was
just
for
my
own,
like
sanity
checking,
then
I
was
trying
to
get
code
coverage
so
there's
only
a
little
bit
missing
like
the
get
hash
code.
D
Algorithm
isn't
really
working.
It's
calling
just
the
dictionary
hash
code,
which
is
really
just
the
reference
it's
deferring
to
like
the
object
default
one.
So
I'm
going
to
try
to
make
a
more
sensible
hash
code
I'll
do
that
later
today
tonight
and
then
it's
I
just
have
to
do
like
change
logs
unless
we
want
to
rename
it
on
this
first
pr.
D
C
Should
be
pretty
easy,
that's
something
we
need
to
ask
all
of
us,
because
I
mean
I
have
a
feeling
that
the
spectator
is
going
to
merge,
assists
with
the
name
package,
not
baggage
context.
D
C
Yeah
that
makes
sense,
because
then
we
can
avoid
another
rename
or
breaking
change
after
the
beta2,
because
we're
trying
to
get
this
part
of
beta2.
Can
you
also
tell
like
how
this
supersedes
some
of
the
other
things
which
we
earlier
had
so
like?
One
of
the
thing
which
we
tried
to
solve
with
baggage
context,
was
how
to
enrich
an
activity
which
is
not
yet
created.
So
can
you
just
walk
us
through
like
how?
How
can
someone
use
baggage
context
to
achieve
what
was
achievable
with
okay?
D
The
enrichment
scope,
yeah-
this
is
kind
of
half
of
the
solution.
So
right
now
you
can
add
things
to
baggage.
They
will
propagate.
They
will
not
show
up
on
spans.
There's
nothing
in
the
spec
for
that
it
kind
of
indicates.
It
says,
like
baggage,
is
a
mechanism
for
enriching
your
spans,
but
it
doesn't
go
into
detail
about
how
we
do
that.
So
that's
not
on
this
pr.
What
you
could
do
is
you
could
build
just
an
activity,
processor
and
then
take
baggage.current
call
getbaggage.
D
That
will
give
you
basically
a
read-only
dictionary,
and
then
you
could
spin
through
that
and
apply
that
as
attributes
that
doesn't
fully
do
what
the
enrichment
scope
did
that
had
some
features,
for
you
know
scoping
either
the
neck
span
or
all
children.
So
there's
still
some
gaps,
but
this
basically
gets
us
up
to
spec,
and
then
we
can
kind
of
improve
on
that
state.
D
D
Yeah
something
like
that.
I
was
kind
of
thinking.
It
might
be
nice
to
have
kind
of
an
experimental
extensions
assembly
that
we
can
have
like.
You
know
that
processor,
maybe
something
more
like
the
enrichment
scope.
Just
some
stuff.
That's,
like
you
know
it's
filling
gaps
in
the
spec,
but
we
anticipate
the
spec
eventually
will
catch
up
and
then
they'll
be
like
a
primary
thing.
I
kind
of
like
the
idea
of
having
an
extensions
or
an
experimental
library.
So
we
can
have
some
features,
but
it's
pretty
clear,
they're,
not
official
official
I'm
doing
air
quotes.
C
Okay
yeah,
so
one
thing
to
really
clarify
is
like
we
don't
have
an
official
clarification
from
the
spec.
Yet
I
did
create
an
issue
and
it
looks
like
it
was
it's
it's
an
open
issue
story
like
how
the
data
from
communication
context
becomes
bad
part
of
the
span
or
activity.
So
let's
hope
that
spec
boot
clarified,
because
it's
assigned
as
a
required
for
ga
tag.
C
So
hopefully
there
should
be
some
clarification
coming
in
the
next
few
weeks,
but
until
now
we
would
go
ahead
with
baggage
context
and
we
just
document
saying
you
can
write
in
a
processor
to
enhance
your
activity
from
package
context
and
regarding
the
number
of
hopes
or
time
to
leave
thing.
C
E
I
think
initially
people
was
a
little
bit
ambitious.
They
want
to
control
whether
the
contacts
will
flow
across
the
rtc
boundary
or
only
flows
within
the
process,
and
then
you
can
imagine
taking
a
step
forward.
People
will
have
something
like
tpl
and
and
eventually
people
figured
it's
too
big
that
they
cannot
fit
into
something
like
a
w3c
standard.
So,
instead
of
like
creating
open
telemetry
on
standard
like
in
the
in
the
headers,
they
decided
to
take
a
step
back.
E
So
whatever
like
we
want
in
the
headers
like
probably
get
across
services,
we
should
go
for
the
w36
standard
and
anything
else
we
can
do
in
api,
but
we're
not
in
a
place
to
create
yet
another
standard
under
open,
telemetry.
C
E
C
Yeah
and
let's
I
mean
I
think
michael
already
covered
like
what
what
is
left
so
my
next
topic
would
be
like
how
do
we
deal
with
this
experimental
in
general,
because
we
don't
have
like
yeah.
C
Yeah,
do
we
have
proposal
on?
How
do
we
do
it
like?
Should
we
use
the
contrib
repo
to
handle
those
scenarios,
or
should
we
create
a
experimental
package
here
and
release?
I
mean
if
we
put
it
here
and
under
the
folder
experimental,
how
do
we?
How
do
we
tell
in
the
new
because
then
you
get,
consumers
may
not
read
the
actual
source
code,
so
you
should
probably
put
the
same
name
experimental
in
the
nuget
package
itself.
Right.
D
E
E
In
this
way
you
don't
have
a
separate
package,
so
my
my
struggle
would
be,
for
example,
if
you
have
this
open,
telemetry.api
experimental
and
we
have
open
telemetry.isdk
experimental,
and
then
we
have
the
console
exporter,
which
is
depending
on
some
experimental
features.
Then
that
would
be
a
dependency
problem,
so
I
would
probably
just
have
that
separate
namespace
inside
each
package
and
make
sure
like
for
folks
who
include
that
namespace
they're
responsible
for
their
own
future
so
like
we
can
scroll
them
up
at
any
point
of
time.
C
We
just
we
create
a
new
name,
space
called
open,
elementary
dot
experimental.
We
don't
expect
anyone
to
use
it,
but
if
they
use
it,
we
will
be
violating
all
the
same
version.
Rules
like
we
can
break
things
yeah.
C
E
Yeah
that
makes
our
life
easier
and
also
make
name
space
and
exit
places
things
you
can
easily
search
and
replace,
and
so
the
only
concern
is
if
someone
accidentally
include
that
without
knowing.
I
think
it
might
be
a
good
addition
not
required.
It
might
be
good
addition
to
have
something.
Like
a
surprise
warning.
E
I
remember
when
I
used
c
sharp
use
some
like
like
some
function
during
compilation
time,
I
got
some
warnings
say
this
function
is
marked
as
deprecated.
I
wonder
if
there's
similar
mechanism,
we
can
mark
this
function
as
a
like
experimental
speed
and
they
have
to
they
have
to
opt
out
they
have
to
describe
in
their
static
rule.
I
I
know
what
I'm
doing
so
this
way
it
gives
us
a
like
a
more
level
of
safety
here,
but
that's
a
nice
to
have
thing.
Okay,
but
at
least.
C
We
can
start
with
putting
things
into
the
same
package.
Just
the
only
difference
would
be
we'll
be
just
putting
it
under
like
experimental
names.
So
if
you
want
a
concept
of
enrichment
scope
or
if
you
want
to
have
the
notion
of
ttl
into
the
baggage,
we
can
do
that,
but
it
will
be
only
available
for
customers
who
import
their
namespace
yeah.
E
Yeah
and
that's
how
that
will
give
us
some
benefit
like
user
management,
but
it
will
give
us
additional
headache.
For
example,
we
got
to
do
our
due
diligence
to
review
the
code
and
make
sure
anything
outside
that
preview
or,
like
experimental,
namespace,
it's
not
going
to
take
dependency
on
the
experimental
part
which
could
be
hard
yeah.
I
mean
it
has
to
be
like
soundly
reviewed,
like
everything.
C
Let's
see
so
maybe
we
can
write
some
like
ca
validations
which
can
look
at
each
and
every
file.
So
unless
the
namespace
itself
is
in
the
experimental,
it
should
not
be
using
any
experimental.
It
should
be
like
something
which
we
can
try
to
violate
in
the
ca.
E
I'm
not
sure
I
I
just
think
it'll
be
hard,
but
this
is
something
you
can
potentially
achieve,
because
if
you
like
basically
write
extension
library,
you
got
to
like
like
have
extension
methods
and
and
put
additional
functions
in
different
packages.
Just
the
same
thing.
Putting
the
same
package
will
make
the
management
easier,
but
we
have
to
pay
attention.
C
So,
michael,
let's
do
like
merge.
The
baggage
asses
say
like
once
you've
done
with
that:
let's
not
introduce
the
enrichment
scope
initially,
but
we
can
introduce
it
in
the
experimental
name
space
as
we
just
discussed,
and
there
was
this
special
processor
which
can
be
also
under
the
experimental
namespace,
which
can
read
the
which
can
read
the
baggage
and
enrich
the
activity
using
it.
So
these
two
are
like
good
candidates
to
like
kick
off
the
experimental
thing.
C
C
All
right,
I
will
put
that
into
the
meeting
notes
as
well.
Yes,
okay,
eddie
added
something
to
agenda.
So
let's
is
there
anything
else
which
people
want
to
discuss?
Otherwise
I
just
asked
eddie
what
the
last
item
added
in
the
agenda,
so
I
don't
think
we
should
spend
more
time
on
reviewing
the
prc.
It's
like
all
are
relatively
straightforward
non-controversial,
so
it
should
be
reviewed
in
the
pr
itself.
There
is
no
end
of
discussing
here.
C
There
was
one
question
today
like
just
before
the
meeting
in
teachers
channel
about:
why
are
we
using
activity,
source
and
activity
as
opposed
to
the
standard,
tracer
and
span?
So
I
don't
think
the
person
who
asked
the
question
is
in
the
call,
but
it's
something
which
we
want
to
discuss.
We've
been
discussing
this
for
quite
some
time,
but
my
main
point
is
it's:
if
someone
who
is
like
completely
new
to
the
repo
and
this
project
like
really
new,
then
there
is
nothing
in
the
project.
C
It
says
that
nowhere
here
or
nowhere
in
the
getting
started
we
make
it
explicit
that
activity
is
fine.
I
think
yeah
somewhere
here
we
mentioned,
which
represents
an
open
telemetry
span.
So
so,
maybe
rightly,
is
it
something
which
you
have
any
thoughts
on
like
making
it
like
really
obvious
in
the
very
first
side
that
in
opendealmaterate.net
we
use
built-in
primitives
from
the
language
itself
and
then
like
one
description
and
probably
link
to
the
comparison
issue
or
a
talk
when
we
have
the
dog
ready.
C
Think
we'll
need
that
clarity,
uh-huh!
Okay,
so
is
it
something
which
you
would
do
because
you
said
you'd
be
doing
some
dope
changes.
That's
why
I
was
asking.
E
F
On
that,
so
this
is
prashanth
yeah.
I
I
do
get
confused
that
I
try
to
connect
activities
with
span
and
then
refer
to
the
open,
telemetry
spec
to
see
what
properties
are
there
in
activity
which
are
which
are
supposed
to
be
there
according
to
the
spec,
and
I
came
across
that
span
should
have
like
the
start
time
and
end
time,
and
currently
activity
does
not
have
the
end
time.
It
has
duration.
C
Yeah,
so
these
are
like
non-issues,
so
I
have
created
an
issue
which
is
being
updated
with
every
every
dotnet
release.
To
compare
and
contrast,
what
is
the
differences
between
the
activity
api
and
this
thing
which
you
just
specified
is
already
yeah,
but
I
mean
this
is
the
best
we
can
do
for
now
because
activities
there
are
certain
things
in
activity
which
we
cannot
change
like,
for
instance,
like
span,
has
a
method
called
ease.
Recording
I
wish
we
could
just
call
activity.
C
Dot
is
recording
instead
of
ease
or
data
requested,
but
due
to
historical
recent
activity
already
had
a
field
which,
which
has
the
same
name,
is
recording
or
similar
name
as
a
recording,
but
it
means
something
else
it.
It
is
different
from
what's
fancy,
so
it's
not
an
issue
which
we
can
ever
solve
it.
It
will
be
there
forever.
C
I
think
so
that's
why
this
dog
should
be
comparing
it
and,
of
course,
we
still
ship
the
api
stream,
which
still
deals
directly
with
the
terminology,
as
per
the
spec
itself,
so
yeah
there's
no
way
out
of
it,
but
this
is
something
which
we
should
make
it
more
clear
in
the
redmi
yeah.
C
Okay,
yeah
and
there
are
like
other
subtle
differences
as
well,
which
I
have
tried
to
I
mean
this
is
not
an
extensive,
but
it
is
covering
like
key
things
like
one.
One
key
aspect
is
activities
con
source,
which
is
the
dot
net
equivalent
of
tracer.
You
just
create
it
out
of
thin
air.
You
don't
need
anything,
you
just
create
it.
Just
like
that,
but
open
elementary
says,
you
cannot
create
tracers
without
going
through
a
provider.
So
there
will
be
like
these
subtle
differences.
I
don't
think
it
will
ever
change.
C
It's
not
a
point
in
time.
It
will
be
forever
we'll
have
that
different.
So
we
need
to
keep
this
talk,
yeah
and
agree.
We
need
to
call
it
out
somewhere
really
prominent,
that
this
is.
This
is
how
dotnet
is
dealing
with
tracer
and
spamming.
Yes,.
G
One
difference
I
I
didn't
put
much
thought
about
this,
but
just
saying
this
that
occurred
to
me
is
that
we
have
to
add
explicitly
the
activity
sources
and,
in
my
mind,
I
map
activity
source,
a
lot
to
instrumentation
library
and
that's
it's
quite
a
bit
different
for
open
telemetry,
because
if
some
library
is
instrumented,
it's
going
to
show
up
automatically
on
the
case
of
dot
net.
We
had
to
add
explicitly.
So
perhaps
it's
something
to
add
to
the
readme
or
something
like
that.
C
So
yeah
I
mean
it's
a
non-limitation,
but
more
importantly,
is
it
something
which
we
want
to
follow
like
we
somehow,
if
we
take
the
design
decision
that
we
will
subscribe
to
all
the
activity
sources
in
the
system
by
default,
that
may
be
a
little
bit
overkill,
but
it
kind
of
solves
this
issue
where
I
have
to
explicitly
go
and
add
each
and
every
library's
name.
But
if
you
change
the
default
listening
model
to
be
like,
we
listen
to
everything
and
we
have
like
exclusion
list.
C
G
Perhaps
we
should
do
kind
of
automatically
I'm
a
bit
skeptical
of
the
legacy
activity,
because
I
I
had
some
experiments
in
the
past
when
we
just
had
the
first
package-
and
I
I
thought
those
were
kind
of
the
tendency-
was
to
kind
of
have
some
data
that
doesn't
look
like
good
in
the
trace.
You
know
so
when
I
said
like.
C
If
you
change
our
default
listening
model
to
listen
to
all
activity
sources,
you
should
have
also
like
exclude
by
default
those
legacy
activities
because
it
has
a
special
activity
source
name.
So
the
the
listening
model
would
be.
We
subscribe
to
all
activities
created
using
activity
source,
the
new
way
anything
legacy.
You
don't
get
it
if
you
want
to
get
them
use
instrumentation
libraries
to
like
adapt
them
to
the
new
way.
So
that
way,
we'll
avoid
the
issue
of
forgetting
to
enable
a
particular
library.
C
I
mean
I
don't
really
have
strong
opinion
either
way,
but
I
just
want
to
hear
like
what
everyone
is
thinking
and
yeah
you're
right
like
this
is
something
which
I
don't
think
I
created
here
yeah,
because
this
was
mostly
comparing
the
apa
part,
not
the
sdk
part,
but
it's
a
valid
point.
We
should
cover
it.
C
E
I'm
thinking
about
the
usability,
for
example,
if
I'm
a
customer,
I
use
my
application
and
I
subscribe
by
default
to
all
the
activity
sources
which
open
time
trade
like
let's
assume
if
openhandtrade.net
is
going
to
subscribe,
everything
for
the
new
activity
source
by
default
and
all
of
a
sudden.
At
some
day
I
updated
my
new
guide
dependency
and
I
have
external
dependency
to
some
like
redis
library,
and
they
start.
E
I
made
a
lot
of
like
information
which
I
am
not
willing
to
pay
for,
so
I
have
to
look
at
their
library
and
see
which
source
they're,
generating
the
events
and
add
that
into
the
exclude
list.
And
after
that
I
cannot
sleep
because
I
know
I
have
many
dependencies
and
god
knows
the
other
dependencies
they
could.
E
They
could
add
yet
another
dependency
or
they
could
add
additional,
even
source,
and
because
I
have
no
control,
I
have
to
scan
their
code
and
to
see
the
changes
every
day
or
I
have
to
do
the
rendering,
basically
lock
down
all
the
package
dependencies
just
to
feel
safe,
and
I
wonder
like
if
we
don't
have
a
solution
on
that.
That
seems
to
be
a
little
bit
dangerous,
as
I
believe
in
telemetry
space.
We
want
people
to
feel
safe.
C
Yeah,
like
it
got
different
so,
which
means
we
should
be
like
explicitly
opting
in
so
by
default.
If
some
user
has,
let's
say
they
installed
a
new
release
package
and
even
if
that
is
package,
is
fully
instrumented
with
activity
source.
The
application
won't
collect
anything
from
that
and
they'll
have
to
go
and
explicitly
say:
okay,
I'm
interested
in
this
library's
telemetry
so
go
and
enable
it
and
then
they'll
start
seeing
it.
E
Okay,
they're,
not
necessarily
or
or
we
can
make
things
more
complex,
for
example,
giving
people
two
different
options
and
make
the
default
like
everything
in
by
default
and
for
people
who
want
to
have
more
control.
Like
me,
who
cannot
sleep
with
dependency
on
all
the
others?
I
can
switch
that
to
like
default
off,
and
I
know
what
I'm
subscribing
to
okay.
So
we
kind
of
support.
C
It
already
with
the
regex,
like
we
support,
like,
if
you
say,
like
microsoft,
dot
star,
then
we
subscribe
to
everything
from
microsoft,
yeah
exactly
like
system.star.
We
subscribe
everything,
it's
very
similar
to
what
I
logger
is
doing.
So
with
that
in
mind,
I
think
what
we
currently
have
should
sufficiently
cover
the
need.
So
if
there
are
customers
who
don't
want
to
explicitly
go
and
enable
everything
they
can
use
the
star
option,
so
they'll
get
everything
by
default,
but
for
folks
who
don't
want
to
like
have
this
option?
C
They'll
just
do
separately,
enable
or
specifically
enable
what
they
think
they
should
be
enabling,
okay,
and
so
all
we
need,
is
just
document
that
this
is
a
behavior
difference
between
open
elementary
sdk
and
like
dot,
net's
implementation
of
that,
and
we
need
a
similar
doubt
comparing.
This
is
compared
to
the
ap
change,
but
sdk
change
also
should
be
compared
like
similarly.
H
Yeah
is
there
a
way
to
so?
If
you,
if
you
basically
have
on
by
default,
for
certain
let's
say
for
microsoft
or
for
certain
companies,
then
do
you
want
to
inform
the
customer
that
this
may
have
pricing
implications,
so
there
might
be
pricing
subscription
implications
that
could
potentially
happen
like?
Is
there
a
price
point
associated
with
this
or
not?
Oh,.
C
Okay,
no,
when
we
said
on
by
default
b
as
in
the
official
sdk
package,
will
not
enable
any
package
by
default.
User
can
choose
to
enable
themselves.
So
it's
their
conscious
choice.
If
they
use
like
microsoft.,
then
they
like
they're,
essentially
giving
blank
check
any
microsoft
library
which
starts
to
meet
with
the
name:
microsoft,
dot,
they'll
pay
for
the
price.
So
it's
a
it's
their
conscious
decision
that
they're
doing
microsoft
out
as
a
activity
source
very
much
similar
to
I
logger
is
doing
because
in
eye
logger
you
do
similar
thing.
C
You
specify
like
microsoft,
dot
and
verbosity
something.
C
H
C
Cover
that
in
the
like
documentation
of
ad
activity
source,
which
should
say,
we
should
say
like
if
you
do
like
this
based
thing-
that
you
are
essentially
opening
the
window
for
potentially
high
number
of
libraries
emitting
and
sdk
collecting
them
by
default,
I
mean
not
by
default
after
you
made
this
yeah,
that's
something
which
we
can
easily
solve
in
the
like
document
itself.
Here.
I
Hey
see
joe
this,
this
is
a
slightly
different
concern,
but
I
feel
like
it
has
some
kind
of
relationship
to
this
discussion.
We're
having
some
of
you
know
that
I
opened
up
an
issue
in
the
dot-net
runtime
repo
yesterday
regarding
multiple
activity,
listeners
subscribed
to
the
same
activity
source
and
it's
potentially
leading
to
some
unexpected
behavior.
I
think
I
I
honestly
haven't
thought
through
these
concerns
too
much,
but
I'm
just
imagining
a
situation
where.
I
Are
you
trying
to
find
the
issue?
I
can
pull
it
up
or
I
can
send
it
to
you.
I
C
I
C
I
Yeah
by
all
means,
so
the
idea
here
is
that
we
have
an
activity
source
down
there,
that
we
declare
and
we've
added
two
listeners
and
the
get
requested
data
using
context
is
the
one
difference
between
these
two
listeners.
One
says:
no,
don't
create
an
activity.
The
other
says
yeah
absolutely.
I
I
want
this
and
by
the
very
nature
of
adding
these
two
listeners
inside
of
this
process,
it
causes
both
listeners
activity,
started
and
stopped
methods
to
be
fired,
which
I
found
to
be
a
little
unintuitive,
though
you
know,
I
can
kind
of
see
why
maybe
that
night,
runtime
team
made
this
decision,
though
I
do
have
concern
that
this
might
create
some
unexpected
behavior,
as
maybe
there's
some
external
dependency
that
you
know.
Listener
b
has
is
present
in
and
all
of
a
sudden
makes
open.
Telemetry's
instrumentation
behave
differently
because
of
the
presence
of
that
dependency.
C
Okay,
so
I
mean
essentially,
if
I
create
a
separate
activity
listener
and
set
everything
to
all
data
and
all
data,
then
it
can.
It
can
change
whatever
decision
my
sampler
has
made
here.
Let's
say
this
was
the
opener
metric
listener.
We
had
a
sampler
which
decides
whether
it
should
be
none
or
propagation
or
whatever.
But
if
I
add
a
other
listener,
it
can
impact
the
decision
even
for
the
our
own
listeners
right
right,
yeah,
okay,
yeah
I
mean
it's.
I
No,
I
haven't
thought
through
any
security
implications.
I
won't
say
that
there
aren't
any
there,
but.
C
C
There
is
no
way.
I
can
hide
anything
from
someone,
but
in
open
telemetry,
it's
somewhat
possible
because
we
create
two
tracer
providers
and
the
spans
you
create
using
one
tracer
provider.
Is
it's
not
visible
to
the
other
one?
There
is
no.
I
mean
I
can
technically
run
a
secret
pipeline
of
like
spans,
but
in
dotnet
it's
not
achievable.
C
So
my
concern
was
from
the
security
perspective,
but
I
think
riley
was
correcting
me
that,
like
once
someone
has
hijacked
your
process,
because
this
is
only
improv
there's
no
way
you
can
subscribe
it
from
outside
the
process.
So
once
you're
already
in
the
process,
then
it's
kind
of
pointless
to
protect
this
part
because
they
already
hijacked
the
process
anyway.
C
But
from
a
usability
perspective
I
mean
it's
mixer
emotions
for
me.
I
don't
really
know
I
mean
I
don't
have
strong
opinion
that
this
is
a
right
behavior,
but
yeah
I
mean
this
is
something
which
we
should
ask
more
clarification
from
the
team,
but
yeah
okay.
I
just
want
to
ask
like
what
others
think
of
this
behavior,
and
do
we
see
this
as
a
concern
that
we
want
to
actively
pursue
some
change
or
more
clarification
from
doc,
mcd.
E
So
my
personal
take
is
this
is
more
like
a
by
design
from
donet
perspective
and
if
we
believe,
for
example,
the
get
request.
Data
using
parent
id
and
using
contacts
is
something
like
a
subscription
api.
So
basically
we
describe
what
we
want
to
subscribe
for
that
listener.
Then
we
should
change
our
listener
code.
So,
basically,
when
we
receive
the
activity
started
and
stopped,
we
should
also
check
those
subscription
criteria
and
see,
if
that
meets
with
our
criteria,
we
will
call
the
actual
underlying
function.
Otherwise,
not.
C
Probably,
if
you
think
that's
a
concern,
then
yes,
we'll
have
to
like
we'll
have
to
subscribe
to
everything
and
then
or
we
have
to
subscribe
and
then
run
the
sampler
one
more
time,
just
to
confirm
that
no
one
else
has
messed
up
with
the
activity
state.
E
Yeah,
so
if,
for
example,
if
we
describe
some
criteria
in
the
get
request
data
using
like
parent
id
or
contacts
we
can
we
can
see,
it
assured
that
all
the
activities
meeting
that
criteria
will
reach
our
like
onstart
and
unstop
event,
there
might
be
other
activities
which
is
not
meeting
our
criteria,
but
meeting
someone
else's
criteria
got
accidentally
pushed
to
our
listeners.
E
You
know
this.
We
got
to
do
the
actual
check
and
that
extra
check
can
either
be
run.
The
same
logic
again
when
it's
on
the
activity
creation
options,
the
other
one
is
on
the
actual
activity.
I
believe
activity
has
more
data
offered
comparing
to
the
options,
but
we
all
can
double
check
or
we
can
again
leverage
the
evo,
like
like
contacts
api
to
tell
people
like
this
is
something
we
want
to
put
there.
There
are
ways
to
do,
but
I
can
see
there
there
will
be
performance
penalty
on
this
yeah.
Of
course,
yeah.
Oh.
I
Yeah,
I
think
that
might
be
kind
of
expensive,
you're,
basically
suggesting
like
like
if
yeah,
because
somebody
could
create
their
own
sampler
and
say
like
I
have
you
know,
maybe
that
sampler's
logic
would
be
like
I'm
not
interested
in
these
events.
Please
don't
send
them
up,
but
then,
like
somebody
else's
listener,
would
cause.
E
If
you
look
at
this
like
get
requested
data
using
whatever
like
api
as
a
way
how
you
describe
what
you
want
to
subscribe,
then
it
looks
like
about
internet,
but
I
I
think
it's
a
little
bit
tricky
because
they
decided
not
to
call
that
a
subscription
api.
It's
just
some
criteria.
That
means
you
could
get
extra
stuff,
and
that
makes
things
a
little
bit
trickier.
G
Yeah,
it
sounds
more
like
about
the
creation
of
the
activity
than
the
subscription
itself.
A
scenario
that
comes
to
my
mind
is:
if
you
have,
you
want
to
use
a
active
listener
to
kind
of
enhance
this
panel
with
some
information
or
the
activity
with
some
information,
and
then
you
basically
want
to
know
all
the
time.
C
So
do
we
think
that
this
is
something
which
we
should
pursue
with
the
dotnet
team
to
enforce
that
behavior
change,
where
this
listeners
are
like
totally
independent
of
each
other,
so
that,
if
I
say
I
want
to,
if
I
subscribed
using
listener
b,
then
I
all
these
notifications
should
be
purely
based
on.
What
I
tell
my
subscription
criteria
is,
it
should
not
be
impacted
by
anything
else.
Is
it
something
which
we
should
pursue,
or
we
we
can
just
accept
that
that's
the
way
it
is,
and
just.
D
I
mean
my
thoughts
on
it
see
joe
are
there's
only
one
activity
right:
the
source
is
only
going
to
create
one
instance.
So
if
you
have,
let's
say
five
listeners,
if
somebody
wants
that
activity
dotnet
has
to
create
it
right,
so
I
don't
think
they're
doing
anything
wrong.
Air
quotes
they're
just
somebody
has
asked
said.
I
want
all
that
data,
so
they're
choosing
that
state,
so
we
should
probably
as
well
in
our
instrumentation,
enrich
those,
because
somebody
has
indicated
they
want
that
data.
I
don't
think
anything's
necessarily
wrong
there.
D
D
G
C
I
mean
I
could
write
like
in
this
case.
It
says
I
I
my
number
says:
don't
record
it
don't
create
it
at
all,
but
someone
else's
listener
says,
create
everything
all
data
and
record
recorded.
Now,
when
I
get
the
callback
the
activity
will
have
is
recording
is
equal
to
true
activity.
Dot
record
is
equal.
Everything
is
true,
which
makes
the
feeling
that
my
sampler
has
decided
to
sample
it
in,
whereas
in
reality
my
sample
has
not
decided
to
do
that.
C
It's
someone
else's
listener,
but
I
mean
whatever
their
decision
was
it's
kind
of
leaking
into
my
listeners.
C
I
C
Yes,
I
guess
and
like
I
don't
know
from
pure
open
telemetry
perspective,
whether
we
have
the
need
for
multiple
activity,
listeners
subscribing
to
the
same
activities,
but
like
it's
just.net
code,
anyone
can
write
their
own
listener
and
it
can
mess
with
other
listeners.
So
yeah
we
don't
have
any
clean
solution
out
of
it.
D
C
I
think
that's
fair
yeah,
but
it's
like
it's
a
genuine
point
that,
like
anyone,
can
write
their
own
listener
and
add
it
and
they
can
easily
screw
up
the
entire
samplers
or
any
other
thing,
because
they
can
always
set
it
to
the
maximum
and
dotnet
takes
the
higher
of
higher
from
all
the
listeners
so
yeah
and
like
the
upcoming
change
in
the
next
version
of
dotnet,
we
have
asked
for
the
samplers
to
provide
additional
attributes
when
the
sampler
is
done
and
that
will
be
attached
to
the.
C
So,
if
you
have
like
10
listeners
each
adding
like
their
own
attributes,
when
we
listen
when
we
get
the
callback,
we
have
the
activity
which
contains
not
just
our
own
listener,
because
there
is
only
one
activity
and
everyone
is
sharing
it.
So
any
change
I
make
in
one
listener
will
affect
others,
so
I
think
we'll
have
to
leave
with
that
descent
choice
unless
you
think
this
is
like
really
breaking
and
is
worthy
of
perceiving
a
change.
C
So
I
put
some
note
here
I'll
like
add
some
comments
here,
just
to
see
like
what
was
the
thought
process
which
led
to
this
decision,
and
then
we
can
see
if
whether
we
want
to
pursue
any
further
or
we
just
document-
that's
the
way
it
is
and
move
on.
C
Sounds
good
yep
all
right,
so
let
me.
A
C
J
C
Let
me
sing
with
you
offline
and
to
get
it
yeah.
We
were
discussing
how
the
first
release
had
this
verified
tag,
but
subsequent
ones
did
not
so
yeah
I'll
sing
with
you
to
figure
out.
What
is
the
right
way
to
do
that?
Yeah
thanks
all
right,
we
don't
have
any
topics
so
follow.
Is
there
anything
updates
which
you
want
to,
or
we
need
any
asks
for
sdk
from
the
auto
instrumentation
efforts
or
the
robot.
G
We
we
are
basically
starting
with
the
repo
I'm
working
on
the
ci
and
tomorrow
we
have
the
meeting
and
follow
up,
and
also,
if
the
the
let's
say,
the
the
cleanup
of
code
of
conduct
and
notes
is-
and
this
kind
of
thing,
so
basically
the
they're
really
kicking
start.
The
thing
tomorrow
is
an
important
discussion
for
us
to
kind
of
have
a
a
discussion
about
the
road
map
so
to
decide
the
first
real
gold
target
for
us.
So
people,
if
you
want
to
join
tomorrow,
for
this
discussion,
welcome
okay,.
K
So
I've
got
a
quick
question
going
back
to
the
discussion
on
the
differences
between
the
open
telemetry
api
and
the
net
activity
api
before
we
had
talked
about
potentially
creating
an
api
shim
for
that
to
help
help
with
that,
and
is
that
something
I
know
we
put,
I
think
we
put
it
on
the
table
because
it
wasn't
like
a
priority,
but
are
we
planning
on
coming
back
to
that.
C
No,
no,
we
already
did
that.
We
already
have
like
the.
If
you
look
at
the
apa
package
come
on,
this
is
matching
the
spec
and
it's
written
as
a
theme
layer
on
top
of
the
activity.
So
this
would
match
like
this
is
called
tracer.
It
can
do
with
span
stats
plan
everything,
but
internally
this
is
built
on
top
of
activity.
So
we
decided
to
have
that
ship
anyway
and
that
shim
is
already
ready,
and
I
mean
we
have
still
like
some
smaller
issues
which
are
actively
being
fixed.
But,
yes,
we
have
machine.
C
K
B
Hi,
this
is
polo
from
aws.
So
do
you
guys
have
a
sync
with
the
donai
wrong
time
thing
about
the
activity
dress.
C
C
B
Yeah
we
do
try
to
put
the
dress
id
into
the
trace
their
stream,
and
it
seems
like
it's
propagating
correctly.
I'm
just
curious
like
how
you
guys,
sync
with
the
donate
frontend
team,
yeah.
C
No,
we
did
not
like.
I,
I
believe,
like
that's
what
our
intention.
Unless
this
becomes
a
blocking
issue,
we
will
not
be
pursuing
it
with
dotnet.
So
if
you
say
that
this
is
a
blocking
issue
and
you
want
change,
that's
the
only
time
I
think
we
should
follow
with
nighttime,
because
the
comment
which
sergey
left
last
time
was
it
is
like
by
design
and
intentional
that
we
are
making
it
part
of
the
dotnet
itself
so
that
it
becomes
a
standard.
C
So
unless
you
say
you
cannot
achieve
what
you
want
to
achieve
by
using
three
state,
then
we
won't
need
to
pursue
anything
with
knight.
E
E
E
So
if
you
look
at
the
contribution
guideline,
we
have
a
clear
statement
like
if
you
have
some
idea
that
you
think
open
time
should
donate
should
do.
The
first
question
is
to
ask
if
this
is
something
that
the
other
open
temperature
sdks
should
do
as
well,
and
if
they
it
is,
then
we
should
talk
that
in
like
talk
about
it
in
the
open
time.
C
Is
this
like
for
your
other
languages
as
well
right?
Because
the
original
issue
was
opened
for
java?
I
believe
it
was
opened
originally
in
java,
so
this
is
like
australia
mentioned.
This
is
probably
not
probably.
The
disease
is
something
which
concerns
all
the
language
six
and
it
should
come
from
the
spec
itself.
F
Yeah
actually
cj
on
that
so
java
and
javascript
both
as
of
now
provide
interface
for
custom
id
generators.
F
Yeah,
it's
not
from
the
spec.
It
was
like
a
kind
of
like
added
functionality
to
the
sdk.
E
F
Yeah
and-
and
it
was
kind
of
like
easy
or
pretty
like
straightforward
implementation
for
those
sdks,
because
spans
are,
as
in
case
of
net,
not
dependent
on
the
dotnet
runtime
yeah.
I
agree.
C
Yeah
I
mean
if
spec
really
changes
and
spec
allows
for
price
id
generation
to
be
like
controlled
by
the
user.
Then,
yes,
we
can
make
that
happen
by
discussing
with
dot
nineteen,
but
the
first
thing
is
the
spec
has
to
say
so.
First,
we
think
it
I
mean
it's
not
even
create
an
issue,
so
I
think
I
would
start
by
creating
an
issue
in
respect
to
see
what
others
are
thinking,
because
I
guess
that
there
was
no
procurement
like
it's.
C
C
C
So
after
today's
meeting
I'll
try
to
like
add
more
description
here
in
case,
you
want
to
read
it
again.
C
All
right,
I
don't
have
any
other
topics
so
we'll
be
doing
a
release
as
discussed
on
this
friday.
We
should
take
net
preview,
8
dependency
and
we'll
try
to
avoid
more
breaking
changes
afterwards.
So
yeah,
okay,
thanks
everyone.