►
From YouTube: 2021-06-02 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
B
C
C
B
A
I
put
the
summary
of
concerns
that
have
been
expressed
so
far,
just
to
elaborate.
A
Unfortunately,
we
need
construct
star,
because
a
c
plus
plus
17
variant
and
absol
variant
and
most
other
older
before
the
latest
patched
up
standard
variant.
Implementations
would
not
properly
handle
conversion
from
cost
char
star
and
it
would,
by
default,
fall
back
to
bull,
which
is
not
what
we
want.
So
there
is
a
proposal
to
resolve
this
issue
in
latest
standard
c,
plus
plus
20
and
above,
and
there
is
a
reference
implementation.
A
My
point
here
is
that
this
latest
patch
proposal
gonna
take
years
before
it
is
realistically
deployed
in
the
field.
It's
not
even
part
of
any
presently
published
visual
studio
version,
for
example,
and
then
we
are
essentially
losing
ability
to
build
with
standard
library
like
a
standard,
static,
statically,
linked
library.
That
is
why
the
easiest
way
to
solve
this
right
now
would
be
to
add
construction
star,
which
I
did
and
in
the
owned
attribute
value.
A
The
default
conversion
right
now
is
to
actually
progress
that
to
a
std
string
instead,
so
it
doesn't
take
construct,
but
it
immediately
in
that
converter
class,
which
iterates
for
each
it
would
actually
assign
it
internally
to
a
cd
string.
A
That's
the
case
where
I
kind
of
need
to
add
question
star
also
on
own
attribute
value,
and
then,
since
I
added
it
for
the
resource
attribute
value,
I
end
up
adding
three
lines
of
code
for
each
exporter
to
handle
that
case,
because
that
there's
that
big
switch
case,
what's
incoming
on
owned,
attribute
value
and
even
though
in
most
cases
the
incoming
is
going
to
be
a
cd
string
anyways,
since
it
is
invariant
and
for
example,
in
protobuf
exporter
in
otlp,
we
actually
count
how
many
values
we
handle
and
there's
that
big
switch
case.
A
I
made
sure
that
for
all
standard
exporters
I
already
addressed
that
and
all
tests
are
passing.
So.
My
argument
is,
since
I
already
resolved
that
this
these
three
lines
of
code-
that
I
added
is
not
a
very
big
maintenance
hassle
going
forward.
It's
already
there,
so
somebody
who's
going
to
implement
their
own
custom
exporter.
They
can
just
copy
paste
and
follow
about
the
same
pattern.
A
A
Now
I
am
eliminating
that
because
I'm
making
that
a
default-
and
that
means
that
now
we
can
actually
build
the
dll
with
that,
at
least
for
windows
for
15,
17
and
19,
and
it
should
be
compatible
with
all
three.
A
So
that's
what
I'm
planning
to
do.
I
am
planning
to
add
a
build
loop
and
if,
at
some
point
in
the
next
release,
we
have
to
provide
stable,
abi,
pre-built
binary,
I'm
not
saying
part
of
1.0,
I'm
saying
like
in
the
next
follow-up
milestone.
We
can
give
that
recipe
like
a
build.
Look
that
creates
an
sdk
binary
api
compatible
with
everything,
and
that
will
require
my
up
upsell
variant
implementation,
because
otherwise
we
do
not
have
alternative
for
2015
right
now.
A
Okay,
that's
why
I'm
I'm
asking
that
this
thing
needs
to
emerge,
to
unblock
the
proper
support
for
2015
and
to
unblock
the
single
dll
that
is
compatible
with
all
three
compilers
at
once.
B
B
I
mean
arguments
of
pointer
type
in
our
apis,
so
this
is
going
to
be
the
first
instance
any
any
span,
processor
or
exporter,
which
is
written
such
a
way
that
it
assumes
that
this
is
the
the
the
pointer
is
being
owned
by
the
api
or
the
sdk
may
result
in
the
crash
that
that
was
the
only
concern
we
can
documented
that
this
is
this.
Is
this
should
not?
This
should
not
be
only.
This
is
not
on
my
api
or
sdk.
B
This
is
something
which
should
be
copied
by
exporter
as
soon
as
they
get
this
data
I
mean
I
I
know
I
know
the
core
core
exporters
are
fine.
We
have
already
fixed
that.
It's
just
that
somebody
who's
going
to
write
a
new
exporter
for
a
new
processor.
If
they
don't,
they
don't
really
understand
how
to
use
that
pointer
type.
They
can
have
a
scenario
of
that
application.
Getting
crashed
if
that
pointer
is
ready,
so
this.
A
Settings
default
settings.
We
already
include
the
snapshot,
it's
in
a
private
namespace
and
I
tested
that
it
doesn't
clash
with
the
other
absolute
library
which,
for
example,
is
being
used
by
your
tlp
export,
because
initially
I
I
didn't
even
know,
I
didn't
even
think
about
it.
I
built
the
entire
thing
and
it
was
all
working.
Then
I
started
building
with
our
tlp
exporter.
A
That's
where
I
realized
that
oh
gop
itself
brings
its
own
upsell
outside.
I
don't
even
know
like
built,
for
example,
through
vc
package
or
elsewhere.
A
That's
where
I
ended
up
with
that
massive
change
needing
to
isolate
the
private
snapshot
of
upsell,
and
I
also
sent
a
separate
document
which
explains
the
entire
process
like
how
to
take
up
sale
and
how
to
refresh
the
snapshot,
but.
B
I
think,
probably
I
think
you
have
this
is
already
there.
You
can
take
a
quick.
I
think
suggestion
from
him
how
to
handle
that.
B
So
this
is
basically
we
are
discussing
of
having
a
single
variant.
I
mean
so
right
now
we
have
multiple
variants
which
we
using
based
on
the
platform
we
are
using
like
we
have
no
hdd
variant
implementation.
We
have
absol
variant
which
we
use
in
for
visual
studio,
and
then
there
could
be
possible
20.
There
could
be
a
std
variant
coming
with
the
template
class,
so
so
max
was
working
on
having
a
single
variant
implementation
as
part
of
no
std
variant,
and
the
selection
was
using
fcl
variant
for
that.
B
The
problem
with
fcl
variant
and
also
with
c
plus
plus
17
std
variant,
is
they
don't
have
handle
string,
string,
literals,
actually
storing
the
string
literals
properly.
So
basically,
if
any
string
return
is
passed
internally,
it
will
get
converted
to
boot.
So
to
handle
that
scenario
I
mean
max
has
proposed
that
we
should
add
a
constant
cat
star,
as
I
attribute
it
as
one
of
the
attribute
in
attribute
values.
B
So,
as
of
now,
we
have
not
been
exposing
quite
a
time.
We
have
been
using
pointers
as
argument
in
our
apis,
so
just
wanted
to
get
your
view.
It's
a
valid
scenario.
I
mean
just
because
these
libraries
are
not
probably
have
some
bug
and
that
that
bug
would
be
fixed
in
c
plus,
plus
20
for
std
variant.
Before
that
it
is,
I
mean
this.
A
Be
supposed
possible,
they
still
have
that
issue
today
and
visual
studio,
although
they
have
a
proposal
in
the
stl
library.
I
believe
there
hasn't
been
a
published
version,
released
version
with
the
fix
and
my
anticipation
is
that
it's
going
to
be
taking
like
a
year
or
two
or
three
before
everybody
progresses,
because
even
today
we
deal
with
2015
and
it's
been
like
six
years
ago,
so
I'd
say
properly.
Patch
20
is
coming
in
not
earlier,
and
then
another
three
years
for
the
majority
and
maybe
another
five
for
the
minority
of
customers.
A
So
if
we
are
truly
claiming
api
compatibility
within
the
line
of
os
like
windows,
we
cannot
use
them
part
it's
not
going
to
work
for
15,
because
simply
it's
an
api
surface
and
it
doesn't
compile
with
50.
upsell
does
so
that's
why
we
kind
of
end
up
needing
that.
So.
B
B
A
Surprising,
so
let
me
let
me
try
to
proofread
this
with
you
guys.
So,
let's
say
I
cannot
compile
and
park
on
2014
right
and
we
are
producing
a
dll
which
is
supposed
to
work,
a
bi
compact
across
all
supported
compilers
from
15,
17
and
19..
A
It
means
we
cannot
use
them
part
because
the
customer
code,
using
that
api
is
not
going
to
compile
yes,
so
we'll
use
fsn
for
all
the
windows
platforms.
So
we
need
to
use
the
user
for
the
window
I
could
have
kept,
and
but
if
you
are
emotionally
attached
to
that,
even
though
I
am
illustrating
that
all
tests
pass
right
now
with
upsell,
just
fine,
I
deleted
the
empire
and
also
that
makes
us
one
component
less
of
the
boost
license,
even
though
we
depend
on
boost
anyways.
A
I,
for
example,
I
realize
that
jagger,
a
jager
exporter
requires
trips,
which
itself
requires
a
bunch
of
boost
stuff.
I
mean
we
cannot
be
boost
free
anyways
as
as,
as
a
pre-built
binary,
we
still
have
to
declare
that
we
use
boost,
license
components.
A
A
Whereas
when
you
do
stdc
out
you're
not
doing
stdcl
redirect
std
string
all
the
time,
you'd
expect
that
the
old
style
strings
would
work,
and
you
typically
prefer
initializers
to
work
with
the
old
style
strings,
because
not
everybody
in
there
would
explicitly
cast
it
to
string
now
one
option
we
could
have
handled
this
by
explicitly
casting
every
attribute
to
string
or
string
view
which
looks
ugly
from
the
static
initializer
perspective
when
you
deal
with
that,
can
initialize
the
list
in
line
fluent
syntax,
where
you
say
key
value.
A
Key
value
pairs,
json
style,
like
you'd,
naturally
prefer
to
put
a
a
a
c
string
style
assignment
in
there,
and
the
only
way
for
this
to
work
with
the
currency
plus
plus
17
and
with
two
days
unpatched
c,
plus
plus
20
compiler,
is
to
provide
that
very
explicit
first
chart
signature
so
that
there
is
no
mistake
and
conversion
to
both
and
saying.
Oh,
it's
an
errata.
It's
been
it's
it's
being
fixed
in
october
2021.
A
This
is
not
the
right
answer,
because
we
have
to
deal
with
compilers
that
exist
today
that
existed
two
years
ago
that
existed
five
years
ago.
So
that's
my
logical
reasoning.
Let's
solve
this,
the
way
how
we
could
solve
it-
and
I
would
argue
that
again,
adding
three
lines
of
code
per
exporter
standard
exporter,
which
I
already
did,
is
not
a
huge
maintenance.
C
Hassle,
I
think,
can
I
kind
of
add
something
here.
I
think
the
I
think
there
are
two
two
points
here
I
think
max
is
basically
pushing
for
for
supporting
visual
studio
2015
and
only
having
one
variant
maintaining
our
code.
C
I
think
that
is
a
that
is
a
good
aim
and
I
think
clarity
is
pushing
for
like
hinting
at
this
possible,
and
I
think
I
I
I
brought
it
up
sometimes
before
like
it
is
possible,
basically
disposability
kind
of
of
a
memory
problem
when
we
have
a
cons
char
in
our
own,
in
our
own
attribute
variant
of
a
coupler,
exact
name
now.
C
B
A
This
the
way
you
guys
want
to
solve
this,
let
me
know
about
it
if
we
change
the
resource,
attribute
value
implementation
to
not
use
the
owned
attribute
value,
but
I
use
the
original
common
attribute
value
then
provide
its
own
internal
storage.
When
it
gets
initialized,
it
should
have
its
own
copy
of
that,
then
we
can
remove
cost
charge
star
from
the
owned
attribute
value.
A
Okay,
because
the
only
reason
like
I've
been
explaining
when
I
do
that
when
we
do
the
transform
from
common
attribute
value
to
owned,
attribute
value,
we
already
do
the
the
proper
transform
from
cost
charge
start
to
string
anyways
and
that
iterator
function
which
for
each
attribute
copy
it's
already
handled
on
there.
But
there's
that
other
case
where
we
initialize
resource,
attribute
values.
And
if
I
don't
apply
that
fix
on
owned,
attribute
value,
then
we
still
have
that
issue
with
the
blue
conversion
on
resource
attribute
cloud.
A
So
I
may
be
able
to
refactor
that,
like
I
don't
know,
if
we
can
take
a
staged
approach.
For
example,
we
merge
that,
and
I
refactor
the
resource
resource
attribute
value
to
inherit
from
the
common
attribute
value
and
provide
its
own
storage
map.
A
A
It's
the
one
that
forces
me
to
add
the
question
star
unknown,
attribute
value
as
well,
because
otherwise
I
already
handled
the
the
copy
like
in
in
the
normal
flow,
for
example,
api
sdk
in
the
normal
flow,
when
we
transform
from
common
attribute
value,
we
do
we
run
that
transformer
class
which
copies
from
non-owned
to
own
and
when
that
is
done
in
that
transform,
I
already
handle
it
properly.
A
A
That's
the
case
why
I
had
to
add
posture
start
to
own
attribute
value,
because
without
it
the
resource
attribute
is
gonna,
be
broken.
So
I
don't
know
like
I.
I
can
do
extra
work
to
refactor
the
resource
as
well.
C
Because
also
like
just
some
thoughts
to
a
large
proposal,
very
satellite
that
you
that
we
just
have
here
the
upside
variant
for
kind
of
windows,
those
are
those
like
windows,
2015
and
then
park
for
others.
I
think
we
will
still
have
the
same
problem
then
for
those
windows
platforms
where
we,
where
we
use
this
file
variant.
So
it
will
just
kind
of
be
maybe
maybe
limited,
but
I
think
the
same
problem
ever
ever.
C
C
A
I'd
say
for
some
reason,
like
trust
code,
that
I
didn't,
or
we
didn't
try
it
more
because
it's
probably
already
gotten
enough
exposure
elsewhere
in
other
projects,
and
it
has
many
flight.
D
A
That's
why,
when
I
would
choose
a
library,
I'd
prefer
like
upsell
or
gsl
or
standard
library
code,
because
it's
like
100
times
thousand
times
getting
more
exposure
today
as
we
speak,
so
I'm
maintaining
and
part
variant,
I'd,
say
probably
harder
than
just
anchoring
to
specific
version
of
upsell
and
forgetting
about
it
for
another
few
years
because
it
works.
A
It
passes
all
the
tests,
it
is
unlikely
to
change
and
we
should
not
expect
surprises
with
this,
because
most
projects
in
the
world
we
use
it,
including
grpc
and
otlp,
which
uses
a
different
version
of
it
but
anyways
it's
like.
Fundamentally,
we
use
the
same
technology
even
from
the
coverage
perspective.
We
can
anchor
to
stable,
mature
pool,
so
I'd
vouch
for
the
abseil
implementation,
maybe
not
only
for
the
variant
like
I
would
even
you
know,
borrowed
more
from
that.
C
Honestly
speaking,
I
mean
I
would
say,
like
from
the
like
now:
that's
funk's
consideration,
I
think
from
the
like
sdk
or
exporter
point
of
view,
I
think,
what's
important
there.
That
is,
that
everything
that
we
pass
to
the
exporter.
We
should
also
pass
the
ownership
there,
because
we
don't
know
what
exporter
does
it
and
I
mean
the
safest
way
to
do.
This
is
just
like:
enforce
it
in
a
static
way
and
don't
pass
cons,
charge
it
all
or
just
past
strings.
So
I
think
whenever
we
can
achieve
that,
I
think
we
already.
A
Got
it
because,
let's
say
I
got
a
temporary
question
star
and
api
to
sdk
transform
is
already
assigning
it
to
sd
string.
So
I
think
I'll.
Let
you
capture
that
item
about
the
resource
attribute
like
if
you
guys
believe
that
it
would
be
safer
to
avoid
posture
start
on
on
the
attribute
cloud,
I
can
spend
a
bit
more
cycles
to
see
how
to
refactor
the
resource
attribute
value,
and
I
actually
had
the
poor
question
about
resource
attribute
value.
A
Maybe
you
can
clarify
that
so
in
terms
of
bi
stability
going
forward
like?
Are
we
going
to
expose
something
stable?
A
B
A
Said
we
did
not
give
the
abi
stability
guarantee,
so
from
that
perspective
it
seems
that
maybe
we
should
have
made
a
resource
attribute,
use
common
attribute
value
for
which
we
already
give
our
api
stability
guarantee
and
maybe
have
something
like
a
future
refactor
in
the
next
release
of
osd
key
to
I'm.
Just
thinking
like
if
I
plug
in
an
external
pre-built
library-
and
I
still
want
to
set
the
resource,
you
see
what
I'm
saying
right.
A
It
seems
like.
I
have
to
make
sure
that
the
library
I'm
consuming
is
built
with
the
same
settings
and
the
same
compiler
with
the
same
memory
layout
for
the
object
and
that's
where
it
seems
like
it
would
be
actually
better
if
I
don't
use
own
attribute
owned,
attribute
value,
but
rather
use
common
attribute
value
which
provides
all
that
safe,
transform
and
then
to
the
api
contract
or
whatever
sdk
api
contract.
A
The
resource
is
exposed
as
a
collection
of
common
attribute
value
and
internally
within
its
own
implementation
somewhere.
It
has
to
copy
it
into
whatever
map
that
it
handles,
but
not
not
not
like
across
the
like
interface
versus
implementation
being
separate.
So
that's
where
I
think
things
like
copying
monster
star
into
a
cd
string
also
has
to
happen
like
not
inheriting
from
owned,
attribute
value,
but
rather
implementing
its
own
storage.
A
Anyways,
maybe
I
I
I
spent
already
enough
time:
I
can
copy
the
link
to
code
in
the
chat
window.
That
shows
where
I
do,
the
transform
from
construct
start
to
std
string
and
why
to
exporters
it
always
looks
like
a
cd
string
anyways.
C
Yeah
I'll
add
it
to
the
to
the
document,
just
wondering
about
our
point
of
view:
larry
there,
if
you,
if
you
would
say
okay,
we
have
cons
char,
like
on
the
api
level
on
common
attribute
value,
but
we
can
do
without
it
in
like
the
owned
attribute
value.
Would
that
would
that
be
okay
for
you
at
all?
Or
do
you
still
have
concerns.
B
C
C
I
think
we
need
to
have
it
yeah,
so
we
have
to
make
it
possible
for
the
user
to
have
the
nice
kind
of
initialization,
but
I
think
on
the
sdk
level,
in
the
owned
attribute
value,
we
should
not
have
it,
because
that,
basically,
is
what
that's
what
we
post
n
has
passed
on
to
the
exporter
and
there
the
exporter
should
only
get
standard
strings
and
no
cons
chars,
because
when
the
exporter
kind
of
can
take
ownership.
Of
that
I
mean
that,
and
that's
I
mean
that
ownership
model
is
then
enforced
by
the
compiler.
A
I
share
my
screen
like
for
a
second
pretty
much
I'll
copy
that
so
again,
the
only
reason
why
do
do
you
guys
see
my
screen.
D
A
Yeah,
so
there's
that
owned
attribute
value
operator
and
in
there
I
do
have
that
initializer,
which
accepts
construct
star
and
returns
onto
attribute
value
of
type
registering.
So
that
should
be
covering
the
api
surface
and
the
only
problem
that
I
still
needed
that
question
there
was
the
resource
resource
attribute,
because
when
we
do
that
static
initialization
in
the
tests
and
in
fact
what
I
also
do,
is
as
it's
getting
copied
or
installed
in
constructor,
I
invasively
replace
every
element
in
the
map
of
type
c
string
with
s
with
std
string.
A
So
that
way,
when
sdk
operates
in
that
collection,
it
would
only
get
a
steady
string
object
back.
So
that
makes
it
easier
to
deal
with
resources.
You
don't
have
to
assume
whether
it's
a
cons,
charge
star
or
refresher
std
string
from
storage
per
second
perspective.
It's
still
always
the
std
owning
std
string
anyways.
A
So
that
would
mean
less
code
for
exporters
and
less
code
for
the
internal
sdk
surface,
but
a
bit
of
a
refactor
for
the
resource
attribute
value.
Does
it
make
sense
to
you
guys,
like
do
you
feel
like
it's
going
to
be
a
better
solution?
I
can
do
that
if
you
insist.
C
A
Sounds
good,
okay
I'll
handle
that
it's
not
it's,
not
a
big
change.
It's
going
to
make
my
commit
smaller.
Let
me
see
how
to
handle
it.
A
B
B
You
have
another
point
max,
that's
the
only
rate,
and
I
think
you
did
raise
up
your
for
multiprocessor.
I
think
you're
fine
with
that
comment
right
for
for
adding
a.
A
Single
processor-
oh
from
this
one,
my
logical
thinking
is
first
of
all,
it's
not
thread
safe,
so
it
means
that
we
do
that
only
when
we
initially
configure
this
system
kind
of
thing
right.
So
only
when
yes
and
I'm
thinking,
maybe
there's
there's
a
better
way
to
handle
this
semantics.
For
example,
right
now,
I
have
to
always
create
a
collection
populate
that
collection
with
a
single
element
and
pass
that
vector.
A
Even
if
I
want
a
single
processor,
I
still
have
to
do
that
flow.
At
the
same
time,
we
do
already
have
this
base
class,
which
has
all
the
needed
methods.
So
it's
like
we
had
spam
processor
and
the
whole
api
in
the
class
assumes
that,
but
then
suddenly,
under
the
hood,
we
assume.
Oh,
we
actually
have
to
do
this
static
cast.
I
it's
it
it.
It
looks
a
bit
odd
to
me
because
we
are
changing
semantics
of
this
under
the
whole
and
also
I'm
not
sure.
A
If
this
static
cast
is
done
on
a
child
class.
Is
it
really
safe
to
to
make
that
sort
of
conversion?
I
mean
it's
yeah.
B
A
If
you
know
that
you
are
a
single
processor,
well,
what's
the
point
of
adding
a
processor?
If
you
already
know
that
you
set
up
the
system
to
deal
with
the
single
processor,
I
mean
with
a
single
processor.
B
As
soon
as
processor
is
called,
I
mean
it
will
have
two
processors
and
then,
in
that
case,
so
both
the
process
are
going
to
handle
any
file
which
gets
exported
so
yeah.
A
Let
me
see,
I
think
I
think
I
I
was
following
some
other
examples
and
documentation
that
we
had
published
before.
Let
me
search
for
that
and
that's
why,
after
this
change,
I
had
the
issue.
I
think
I
can
refactor
my
own
code
for
the
fluent
and
it's
not
blocking
me
per
se.
A
I
was
thinking
about
any
overhead
that
we
may
incur
because
we
treat
it
as
a
collection
by
default
right
now,
but
in
most
of
our
cases,
what
we're
showing
is
we're
showing
a
single
handler
single
processor
and
then
it
kind
of
doesn't
add
up
that
we
assume
some
extended
functionality,
but
with
really
in
most
cases,
I'm
not
going
to
be
using
that.
B
If
we
can
somehow
change
our
internal
implementation
in
such
a
way
that,
if
only
one
processor
is
there
we'll
just
maintain
that
as
soon
as
the
add
processor
is
called
we'll
convert
internally
the
unique
pointer
to
a
multi-span
pointer,
it
points
contain
somehow,
if
you
can
do
that
internally.
But
I
think
as
long
as
the
sdk
api
remains
same,
I
think
we
should
be
good
internally.
If
you
want
to
change
a
unique
pointer
to
point
to
a
multispec
processor.
B
A
The
processor
doesn't
have
a
container
characteristics,
because
if
a
multi-processor
had
those
characteristics
of
adding
inserting
removing
whatever
custom
other
like
chaining
other
processors,
then
you
wouldn't
have
had
a
need
to
have
add
processor
method
on
the
actual
trace
like
a
quenches
class.
Because
then,
if
you
hold
the
reference
to
multiprocessor
and
a
multiprocessor
itself
has
those
add
delete,
remove,
insert
semantics.
A
You
know
that
you
pass
that
one
to
the
system
while
initializing
it
and
you
could
have
added
and
removed
on
that
kind
of
aggregate
processor,
rather
than
exposing
that
method.
Like
add
processor,
on
in
a
generic
case,
especially
since
it's
not
thread
safe,
you
cannot
really
make
any
changes
to
that
at
runtime
right
now.
You
only
do
that.
Initially,
when
you
set
up
the
system
before
you
start
tracing
so
anyways,
I
don't
have
a
strong
opinion
on
this.
I'd
probably
adjust
the
park
that
pr
for
now.
D
B
A
Again,
I
think
it's
all
passing
it's
just
like
our
sdk
surface
method,
like
class,
makes
assumption
about
processor.
A
Yeah
but
my
point
is
you
would
not
even
do
it,
because
when
you
code-
and
you
know
that
your
approach
there
is
a
single
processor
as
a
developer-
you're
not
gonna-
do
ad
processor
again,
because
you
know
that
you
passed
like
a
single
thing
already
and
it
doesn't
make
logical
sense
to
try
inserting
one.
What
what
I'm
more
can
not
exactly
comfortable
with.
We
are
making
assumption
about
spam
processor
everywhere
in
that
class.
A
But
then
add
processor
method
assumes
that
actually,
no
it's
not
supposed
to
be
the
the
generic
spam
processor.
It
has
to
be
concrete
multi-processor.
Then.
My
question
is:
why
don't
we
use
multiprocessor
everywhere
on
api
surface
and
make
it
very
clear
that
only
that
kind
of
processor
is
now
supported
so
anyways,
I'm
I'm
gonna
park
it.
It's
not
impacting
me.
I
can
change
my
code
to
to
follow
what
you're
suggesting
with
the
collection
of
a
single
element
that
would
work.
A
If
I
pass
a
vector
with
a
single
element
in
that
okay,
I
think
maybe
we
can
change
that
constructor
to
actually
create
that
vector
itself.
So,
even
if
I
pass
a
single
one,
I
can
actually
do
the
more
complete
implementation
of
that
constructor
that
now
it's
in
a
collection
and
puts
that
single
element
in
the
collection
and
that
way
we
can
still
retain
the
signature
which
allows
you
to
initialize
it
with
a
single
one,
and
that
way
the
add
processor
method
would
work.
I
can
change
that.
A
B
So
I
mean
I
just
want
to
talk
about
the
1.4
release
candidate.
Mind
store,
I
mean
at
this
point
I
mean
we
are
at.
We
are
at
the
junction
where
I
think
we
looks
like
that.
We
know
we
know
where
we
stand.
We
know
what
are
the
gaps
for
us
to
go
to
meet
to
these,
to
release
ga,
and
as
of
now
I
mean
the
gas
is
the
specs.
We
have
created
most
of
the
tickets
for
issues
which
should
be
part
of
the
ga
and
as
a
compliance
matrix
validation.
B
I
have
gone
through
all
those
complex
compliance,
matrix,
validation
for
all
the
components
it
just
baggage
and
resources
which
is
left
so
I'll,
probably
just
go
through
this
also,
and
if
whatever
gaps
are
there
I'll
create
a
ticket
for
that,
and
these
are
the
open
issues
as
of
now
for
really
for
us
reaching
release
candidate,
I
mean
that's
something
which
I
have
added
I'll
say
we
should
be
closing
all
of
them,
because
some
of
them
are
documentations
for
quick
start.
I
think
we
don't
have
sdk
quick,
start
guidelines.
B
I
feel
that
I
did
check
it.
I
feel
that
some
of
the
tests
are
failing
for
trace
parent,
even
though
we
support
it
it's
because
of
the
compliance,
the
validation
liability,
which
we
are
using
at
w3c
level.
I
think
it's
somehow
it's
not
adding
the
duplicates
properly
but
I'll
check
again.
B
It
may
not
be
a
problem
from
from
the
suit
which
we
are
using
to
test
it
I'll
see
again,
but
I
don't
see
again
that's
kind
of
blocking
for
release
candidate,
so
the
plan
as
of
now
is
that
probably
this
week
or
next
week,
we
should
be
good
enough
to
have
a
release
candidate
with
all
the
tickets
for
non-compliance
and
whatever,
whatever,
whatever
mandatory
for
ga.
So.
B
As
part
of
the
ga
so
that
we
know
what
are
the
gaps
for
us
to
reach
the
game
again,
that
does
not
mean
that.
B
What
all
areas
we
are
non-compliant
and
what
it
takes
for
us
to
be
compliant
on
those
areas,
and
I
think,
as
long
as
we
have
the
tickets,
we
should
be
fine
for
that.
So
just
wanted
to
see
any
views,
I
mean
if
somebody
really
think
that
we
still
are
far
away
from
rc
or
we
are
good
for
the
rc.
I
mean
that's
my
take
on
where
we
stand
and
I
felt
that
probably
we
are
going
to
have
to
at
least
have
a
release
candidate
in
couple
of
weeks
just
want
to
get
understanding
from
others.
B
Yeah
this
week
and
I'll
see
probably
how
much
I
mean
what
it
takes
to
close
these
issues,
if
not
this
probably
next
week.
So
that's
the
plan
this
week
or
next
week.
D
So
they
we
have
to
make
sure
all
these
are
closed
before
I
say
one
right,
that's
our
goal
in
this
page.
B
Yes,
so
if
they
are
not,
if
either
we'll
close
it
or
we'll
move
it
to
ga,
we
think
that
that's
not
something
blocking
I
don't
see
as
of
now
documenting
common
use
cases
and
recommended
uses
is
to
be
blocking,
but
definitely
something
which
we
should
be
having.
As
part
of
that,
that
just
gave
I
mean,
moving
to
rc
just
gives
more
confidence
for
customers
that
it's
something
which
you
want,
the
the
specs
I
mean
the
api
and
the
sdk
interface
is
not
going
to
change
drastically.
A
I
have
a
bit
of
a
concern
about
the
resource
value.
I
mean
I'm
just
thinking
through
all
that
dll
integration
scenario
and
I
think
we
do
have
a
good
prospective
customer
who's
been
contributing.
All
this
api
only
build
changes
david.
A
I
think
I
was
just
wondering
like
not
for
this
release,
but
in
prep
for
1.1.
Let's
say
when
we
have
dll
and
shared
libraries
for
linux.
A
How
does
that
work
for
an
application
that
only
includes
api
headers
and
that
doesn't
know
what
concrete
implementation
of
the
sdk
it
gas
like
it
could
be
injected
later
on?
A
I
think,
while
we
covered
the
tracer
provider
and
we
covered
the
get
tracer
and
the
basic
tracing
api
resource
is
where
I
see
some
abi
compatibility
issues
right
now,
we
may
need
like.
Can
you
guys
tell
me
if
resource
was
even
a
part
of
vpi
spec
or
was
it
like
something
else?
A
A
That
it
would
be
at
least
maybe
we
should
give
some
abi
stability
guarantee
for
that
part
of
sdk
that
deals
with
the
resource.
That's
minimum
statement
I'm
making
because
for
the
rest
seems
like
we
covered
it
pretty
nicely
with
the
api,
and
all
these
transforms
specifically
the
resource
population
piece.
A
It
would
be
great
to
sort
out
how
that
looks
like
when
the
entire
sdk
is
consumed
from
a
dll
unless
we
say
that
we
use
environment
variables,
but
I
was
kind
of
a
little
bit
against
that
because
in
some
scenarios
on
some
platforms
you
cannot
even
expect
environment
variables
exotic,
maybe
but
windows
store
applications.
You
cannot
rely
on
that.
B
Okay,
I
mean
probably,
I
may
have
to
understand
the
use
case,
because
resource
is
part
of
sdk.
We
never
guaranteed
it.
The
implementation
does
not
really
guarantee.
As
of
now
I
know
we
are
using
hdd
vectors
as
as
part
of
the
api
to
pass
the
list.
We
still
assume
that.
B
C
I
think
the
idea
is
that
resources
are
in
like
initialized,
like
the
same
way,
for
example,
that
you
initialize
your
processor
or
exporter
kind
of
things.
It's
in
the
connection
of
the
sdk
initialization,
but
the
person
who
instruments
the
library
and
to
add
the
start
and
the
end
span
course.
I
think
the
currently.
There
are
no
resources
kind
of
there's
not
even
a
way
kind
of
to
work
with
resources
there,
because
it's
not
part
of
the
api.
A
I'm
just
thinking
like
let's
say
I
have
a
web
application.
I
don't
know
what
vendor
I'm
going
to
be
shipping
with
what
sdk,
and
is
it
possible
that,
in
my
application
code
that
I
manually
instrument
I'd
need
to
populate
resource
values
differently,
depending
on
something
I
don't
know,
node
id
or
service
attributes
of
some
sort
sort,
and
that
means
that
we
don't
really
have
a
contract
for
that,
which
means
that
does
it
mean
like?
I
have
to
build
the
whole
thing
from
source,
but
then
I'm
an
application
developer.
How
is
it
abstracted?
A
The
way
I
mean,
I
need
to
learn
a
bit
more,
but
I
anticipate
an
issue
with
the
api
compatibility
in
this
regard.
I
could
cover
this
for
our
api,
but
resource
attribute
values.
Right
now,
for
example,
is
not
a
stable
release
over
release
or
a
framework
over
framework,
and
that
kind
of
bothers
me.
B
It's
the
instrumentation
name
and
the
version
which
instrumentation
library
has
to
deal
with,
not
the
resource
because
they
are
not
owned
by
instrumentation
library.
But
let's
see
the
use
case
here
and
then
see.
A
I
hope
that
won't
require
a
require
much
refactor
in
the
end,
but
I
anticipate
that
when
we
get
closer
to
building
a
dll
and
shared
library
that
can
be
consumed
at
runtime
rather
than
from
test
apps
and
manual
instrumentation
that
we
have
today,
maybe
in
1.1.
This
may
need
a
bit
of
a
refactor
or
I
don't
know
new
name
space
of
some
sort
that
we
exposed
and
that
may
be
providing
that
abi
stability
guarantee.
A
C
And
I
I
copy
paste
it
like
an
issue
in
the
comments
that
is,
I
mean,
maybe
that's
interesting
in
the
context
of
this
discussion.
There's
actually
some.
I
think
it's
somebody
from
the
travel
side
asking
to
make
the
resource
part
of
the
api
and
that's
still
open.
So
there's
some
discussion
going
on,
maybe
that
I
hope
it's
it's
not
it's
not
making
things
more
confusing,
but
but
it
at
least
it
seems
there
are
discussions
going
on
of
making
or
there
are
people
who
want
to
be
the
resource
part
of
the
api.
C
I
mean
I
don't
see
that
at
any
point
coming
soon,
but
it's
not
just
an
isolated.
A
A
I
need
to
work
through
those
scenarios
to
understand
this
better,
but
I
think
that
maybe,
if
we
had
what
you're
saying
as
a
standard
api
for
resources
in
the
api
spec
for
1.2
1.5,
I
see
that
we
may
be
needing
the
entire
set
of
features
in
api
stable,
since
we
committed
to
at
least
some
of
it
like
full
api.
A
That's
probably
where
we
need
to
work
on
this
dynamic
loading
scenarios,
and
I
think
the
person
who
has
been
contributing
build
over
of
code
for
api
only
is
a
good
candidate.
As
they
said,
they
are
developing
some
instrumentation
and
deal
with
api,
but
they
don't
want
to
implement
esdk.
A
So
they
want
their
service
to
have
that.
Runtime
injectability
of
the
entire
open,
telemetry
stack.
C
But
I
have
to
add
here:
I
think
that
is
that's
a
valid
valid
issue,
but
I
think
it
should
not
really
block
any
1.0
release,
because
I
think
how
harvey
will
probably
do
it
in
the
end.
If
we
really
need
it
in
the
api,
we
will
do
it
similar
to
span
and
just
have
an
api
wrapper
that
has
kind
of
the
sdk
span
in
it
so
and
maybe
for
the
resource.
It's
the
same,
we
will
have
an
api
wrapper
that
has
the
sdk
resource
in
it.
A
How
about
this?
How
about
actually
sending
apr
for
the
resource
attribute
value,
because
I
think
I
need
to
change
that
to
form
an
attribute
value
anyways
to
address
the
the
other
variant
issue,
so
send
a
smaller
pr
which
would
propose
some
refactor
for
the
resource
attribute
value.
Then
we
can
let
everyone
decide
if
we
want
to
expose
something
like
this
through
the
stable
api
circuits,
but
I'll
I'll
think
how
to
make
it
handle
the
incoming
values
the
same
way
as
what
we
do
with
the
api
server.
A
B
A
Yes,
instead
of
owned,
attribute
value
and
then
internally
it's
going
to
store
it
in
its
own
internal
implementation
map.
So
that
way
we
can
decouple
it
from
concrete
std
stream
and
we
still
use
about
the
same
api
style
incoming
attributes,
because
how
are
we
going
to
store
store
them
in
the
country?
What
the
container
will
use,
because
that's
again
the
avi
compliance
right,
it's
an
implementation
detail!
Yes,
I
can.
I
can
handle
it.
A
Okay,
it's
an
internal
implementation
detail
because,
from
the
public
api
perspective,
it's
still
going
to
accept
api
safety.
B
A
I
think
what
do
we
think
I
have
a
quick
one
about
the
gsl
span.
I
kinda
agree
that
it
has
to
be
an
option
and
I
added
some
checks
for
and
undefining
it
if
it's
not
part
of
the
build
and
the
answering
why
gsr
spawn
was
needed
in
my
original
implementation
of
standard
library.
A
A
So,
while
peeking
between
the
two
I
choose
the
one
that
is
striving
to
provide
the
full
conformance.
I
wanted
here.
B
A
A
D,
lib,
what
parts
of
it
I
got
and
it's
like?
Okay,
I
got
actually
variant
because
it's
already
there
right-
and
this
is
the
bigger
size
chunk
so
on
mac,
for
example,
I'd
most
likely
for
fresh
mac
I'd
be
building
with
like
standard
there,
library
variant,
but
I
need
to
borrow
the
spam
somewhere
else
and
from
the
conformance
perspective,
I
was
more
comfortable
to
to
use
what
gsl,
what
what
cpp
core
guidelines
is
recommended.
A
Again,
it's
it's
probably
because
I'm
critical
of
any
custom
code
that
we
borrow
elsewhere
I'd
rather
go
with
the
code
that,
like
you
know,
herb,
is
recommending
in
his
papers
and
that's
the
code
that
the
the
big
guys
are
gonna
be
most
likely
using,
and
it
is
much
easier
to
pass
all
of
these
stringent
security
and
safety
check
with
approved
library
rather
than
with
a
custom.
You
know
hacky
back
port
of
steel,
that
we
maintain.
That's
my
only
reasoning
why
I
would
choose
that.
B
A
Maybe
probably
be
either
up
still
spam
or
even
it's
a
gsl
span
and
we
could
have
that
way,
reduce
the
amount
of
handcrafted
stl
back
port
code.
I
mean
as
much
as
I
appreciate
the
beauty
of
that.
If
we
borrow
more
from
the
upstream
mainline
stl
alike,
libraries,
I
feel
much
more
comfortable
about
that.