►
From YouTube: 2022-06-01 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
B
C
E
E
C
B
D
Okay,
I'm
gonna
get
started.
Let
me
share
my
screen
here.
D
Yeah,
please
add
yourself
to
the
attendees
list.
First
item
is:
we've
talked
about
for
the
last
few
weeks,
just
bringing
it
up
again
the
community
day,
it's
two
weeks
from
monday.
I
think
yeah
that
sounds
great
I'll,
be
there.
So
please
come
and
say:
hi,
I'm
only
going
to
be
there
saturday
to
tuesday.
So
if
you're
there
for
the
rest
of
the
open
source
summit,
I
won't
see
you
the
rest
of
the
week,
but
I'll
be
there
at
the
beginning
of
the
week.
D
All
right
we,
I
guess
this
is
a
little
bit
out
of
order.
Actually,
so
last
week
we
released
the
metrics
release
candidate.
It's
gone
reasonably
well,
but
there
were
a
couple
of
little
issues
that
need
to
be
fixed,
so
that
was
version
29,
and
you
know
there
were
a
couple
little
things.
There
was
a
a
browser
incompatibility
that
fixed
the
or
that
broke
the
ci
and
contrib.
D
Although
it's
the
host
and
os
detector
is
not
working
in
the
browser
is
probably
not
something
that
really
affects
too
many
users,
because
they
shouldn't
be
using
those
in
the
browser
anyways,
but
it
did
break
the
ci
and
contrib
and
they're
a
missing
pre-published.
Only
script
in
the
otlp
transformer
package
means
that
the
esm
and
es
next
versions
of
those
did
not
get
published,
so
those
pr's
are
now
merged
and
there's
a
hotfix
release
for
those.
So
please
give
that
a
review.
D
Once
we
get
a
couple
of
green
checks
on
it,
I'll
probably
just
release
that
today,
while
we're
talking
about
metrics,
I
did
create
a
milestone
to
track
work
needed
for
general
availability.
D
Most
of
these
issues
are
already
assigned
to
people,
but
there
are
a
couple
of
up
for
grabs
issues
here.
So,
if
you're
looking
to
help
out
with
the
the
general
availability
push
for
metrics,
this
is
probably
a
good
place
to
look
not
only
for
up
for
grabs
issues,
but
for
issues
that
are
in
need
of
prs
that
are
in
need
of
reviews
so
that
they
can
be
merged.
D
D
I
wanted
to
talk
about
this
bug
from
last
week
I
had
been
hoping
that
valentine
would
be
here
since
he
worked
more
on
the
context
managers.
Has
anyone
had
a
chance
to
look
into
this
event,
emitter
issue
with
the
asynchronous
contact
manager?
D
It
appears
to
be
breaking
the
the
remove
listener
functionality
for
event
emitters.
I
know
we
talked
about
it
a
little
bit
last
week.
Valentine
wasn't
here
then
either.
So
we
didn't
really
do
much
on
here,
but
I
assume
nobody
has
looked
into
this
or
rono
or
amir.
Have
you
had
time
to
no
okay
last
week
was
pretty
busy
for
me,
so
I
didn't
have
time
to
look
into
it
either.
D
I
will
try
to
look
into
that
at
the
end
of
this
week
and
I'll
also
send
valentine
a
message
on
slack
to
see.
If
he
is
aware
of
this,
the
contrib
ci
is
currently
failing.
I
think
the
the
pr
that
fixes
it
has
already
been
merged
and
will
be
included
with
that
hotfix
release
rano,
you
were
the
one
that
originally
brought
this
to
my
attention.
Is
that
the
only
pr
needed
to
fix
it
or
are
you?
G
F
The
color
and
then
we
have
a
mixture
of
like
currently,
we
have.
D
D
I
think
we
should
be
able
to
use
carrot
everywhere
there
except
the
instrumentation
package.
I
will
probably
have
to
use
patch,
because
if
one
of
the.
D
No,
that
should
probably
be
a
carrot
too,
because
it's
only
api
consumers
like
they
don't
implement
any
like
you
know,
there's
no
sdk
implementations
there.
So
if
something
gets
added
to
the
interface,
that's
not
a
problem,
it
can
trip.
So
we
probably
can
go
carrots
everywhere.
D
I
think
the
original
reason
we
moved
to
pinning
was
because
if
we
have
a
carrot,
dependency
and
one
of
our
users
wants
to
pin
their
dependencies,
they
can
pin
us,
but
then,
if
we
or
you
are
not
pinning
our
versions
as
well,
then
they
can
get
unexpected
upgrades.
It's
kind
of.
C
Yeah,
so
these
are
mostly
dependencies
that
were
currently
pinning
and
suggested
that
we
use
them.
F
F
How
how
would
unpinning
I'm
not
against
the
idea,
but
how
is
unpinning
the
development
dependencies
going
to
help
with
like
help
us
right
now,
I'm
wondering
I'm
just
curious
because,
like
just
a
side
note
on
the
thing
that
dania
said
like
carrot,
using
current
is
fine,
and
but
but
usually
the
version
conflicts
and
like
tons
of
problems.
I
could
actually
happen
because
of
the
fact
that
we
have
to
have
everything
matching
and
some
of
the
packages
in
the
country
repo
depend
on
packages
that
do
implement
something.
F
So
if
there
is
a
one
package
that
is
restricted
by
even
like
a
the
dependency
of
the
dependency
like
on,
that
is
pinned
like
the
whole
country
ripple
like
goes
havoc.
Basically,
it
blows
up.
F
Quite
the
tricky
situation,
it
seems
very
trivial
in
the
on
first
sight,
but
then
you
start
kind
of
figuring
this
out,
and
then
you
understand
that
there's
a
lot
of
things
you
have
to
you
know
change
to
get
them
working
in.
D
I
think
it
would
be
trivial,
except
that
we're
doing
the
the
dependency
hoisting,
which
calls
it
like.
The
packages
should
be
separate
from
each
other,
but
we
hoist
the
dependencies
because
the
ci
is
really
slow.
If
we
don't
and
then
that
causes
the
you
know,
the
versions
have
to
match
between
two
different
packages.
If
we
turned
off
hoisting,
then
we
wouldn't
need
to
worry
about
that.
D
Yeah,
I
know
that
so
the
learner
project
has
been
kind
of
defunct
for
a
while,
and
it
was
actually
picked
up
recently.
Changed
ownership
to
the
company
that
develops
nx,
which
is
significantly
more
performant
and
all
they're
doing,
is
they're
gonna.
D
Keep
all
the
same
learner
commands
but
change
it
so
that
it
calls
nx
functions,
sort
of
under
the
hood
behind
the
scenes,
but
should
be
completely
compatible
and
I've
seen
examples
so
far
where
they've
had
you
know,
10x
20x
speed
increases
just
by
using
nx,
so
we
may
want
to
just
look
into
that,
but
one
thing
that
I
think
might
cause
a
problem
is
that
it
won't
work
with
node
8
and
I
think
it
may
also
not
work
with
node
10
anymore.
D
C
Typescript
is
not
happy
so
at
least
according
to
flour.
Now
we
have
to
like
go
over
all
the
exported
types
and
make
sure
we
don't
export
class
with
private
property,
because
that's
not
supposed
to
work,
so
I
don't
know
if
we
can
do
it
in
a
backward
compatible
way.
Probably
we
can't,
but
at
least
until
this
issue
is
resolved,
we
cannot
mix
different
versions
of
sdk,
at
least
in
country.
I
don't
know,
what's
the
situation
for
end
users,
so
it
might
also
be
related
to
learner
in
some
other
aspects.
D
Okay,
yeah,
I
think
what
I
was
saying
is
just
that
luna
makes
it
more.
It
exacerbates
the
issue.
So,
with
the
issue
you're
talking
about
that's
within
one
package,
you
need
to
make
sure
that
all
your
versions
match,
but
when
we're
using
learn
a
hoisting,
all
the
versions
need
to
match
across
all
of
the
packages
in
the
learn
of
honor
repo,
because
if
it
hoists
one
version
and
then
installs
into
the
package,
node
modules
a
different
version,
then
you
could
have
conflicts
where
you
wouldn't
have
a
conflict.
F
So
you
have
amir's
point.
This
is
actually
valid,
because
I
mean,
if
someone
would
theoretically
build
a
application
that
coincidentally
uses
all
of
the
packages
we
have
in
country,
they
would
be
facing
the
same
problem
right
so
in
that
sense,
like
amir
is
correct
as
well.
It
shouldn't
be
a
problem
even
with
hoisting,
but
it
is.
C
D
C
D
Of
so
the
changing
class
exports
to
be
interface.
Exports
is
something
that
we
have
already
sort
of
started
on
like
when
we,
when
we
see
them
causing
issues,
we
have
been
fixing
those
one
at
a
time,
but
I
don't
think
anyone
has
ever
gone
through
all
of
the
exports
to
see
you
know
how
much
work
it
would
actually
do
to
replace
everything
like
that.
F
I
think
we're
actually
yeah
it's
fine.
We
don't
have
to
kind
of
fix
everything
all
at
once
like
it's
just
there
are
some
in
instrumentation
package
and
we
can
go
go
as
we
are
like
in
like
taking
the
one
by
one
as
they
pop
up.
D
Okay,
can
one
of
you
create
an
issue
for
this,
or,
if
is
there
already
an
issue
for
this,
so
that
we
can
track
this
word.
D
Okay,
the
next
issue:
here
we
we
think
we
fixed
the
flaky
tests
in
the
the
main
repo,
the
flaky
browser
tests.
We
thought
we
had
also
fixed
the
code
coverage
issue
where
it
reports
like
minus
one
percent
code
coverage,
but
actually
it
turns
out
that
we
have
not
fixed
it
based
on
this
run
from
earlier
today.
D
D
All
right,
so
the
the
first
major
discussion
item
that
I
had
here
was
somebody
created
an
issue
asking
for
arm.
64
support
valentine
who's.
Not
here
brought
up
that
you
know
node
supports
arm64
and
since
we're
just
writing
javascript
we
should
be
just
fine
on
rm64.
It
shouldn't
be
anything
that
we
have
to
specifically
do,
but
that's
not
always
necessarily
true.
D
If
we
have
a
dependency
that
has
a
binary
component
or
something
like
that,
so
I
do
think
it
probably
is
worth
testing
on
arm
as
long
as
it
doesn't
drastically
increase
our
test
run
time,
at
least
in
core.
I
don't
know
if
we
need
to
worry
about
it
for
trib
or
maybe
not
yet,
maybe
if
it
goes
well
in
core,
we
can
expand
it
to
contrib,
but
does
anyone
have
any
opinions
on
this?
I
agree
or
disagree
with
that
line
of
thinking.
D
I'm
not
sure
how
we
could
do
that,
because
the
issue
is
like
you
know.
Maybe
the
grpc
is
a
good
example.
I
don't
know
if
grpc
has
a
binary
component,
I
don't
think
it
does,
but
it
might
so
anything
we
know
about
our
packages,
but
not
some
packages.
D
We
have
no
binary
in
our
packages,
but
if
we
pick
up
a
dependency
that
has
one
or
if
one
of
our
dependencies
adds
one
in
the
future
that
might
break
our
m64
support
shouldn't
be
a
problem
in
the
browser,
because
obviously
binary
packages
in
the
browser
are
not
a
thing
already
anyways,
but
for
node
it
might
make
sense
to
just
run
the
tests
on
an
arm
64
system
just
to
make
sure.
D
So
I
I
think
it's
reasonable
just
to
to
add
testing.
This
person
did
add
like
a
quick
prototype
and
they
break.
So
something
is
breaking
these
and
I
haven't
really
looked
into
what
it
is.
It
could
be
just
that
dependencies
need
to
be
updated
or
it
could
be
a
more
fundamental
issue.
I'm
I'm
really
not
sure.
D
So
I
can
look
into
that
a
little
bit,
but
I
I
just
wanted
to
make
sure
before
we
invest
time
in
this,
that
people
think
this
is
a
reasonable
thing
to
to
worry
about,
because
if
we
do,
if
we
do
say
we
support
arm
64,
that
means
you
know
we
have
to
support
it
sort
of
forever.
If
somebody
has
a
bug
in
an
arm
system,
it's
just
one
more
thing
that
we
have
to
support.
D
So
I
guess
you
know
between
us
contributors
and
maintainers.
We
need
to
decide
if
this
is
something
that
we're
willing
to
not
just
invest
time
on
upfront
to
make
sure
it
works,
but
potentially
long
term.
If
we
have
an
issue
in
the
future,
is
this
something
that
we're
willing
to
guarantee
their
works.
D
D
Arm
64,
I
think,
is
a
quickly
growing
segment.
You
know
certainly
like
the
aws
graviton
instances.
I
know
that
honeycomb,
for
example,
has
moved
all
of
their
infrastructure
over
to
arm
as
like
got
cost
savings.
I
I
think
a
lot
of
companies
are
doing
that.
D
I
would
hope
nobody's
running
their
their
production
application
off
of
apple
laptops,
although
maybe
for
local
development.
I
suppose
it
makes
a
big
difference.
E
D
Yeah
so
this
person
that
created
the
issue
actually
mentions
in
here
that
the
tests
fail
in
the
github
actions,
but
they
actually
pass
on
his
local
machine
so
on
his
local
arm.
64
machine,
which
I
assume
is
an
apple
laptop.
Probably
so
I'm
not
entirely
sure
what
it
is.
I
haven't
really
looked
into
this
too
much
yet,
but
I
think
we
probably
should
at
least
look
and
see
how
much
work
this
is
going
to
be.
D
So
I
will
assign
myself
to
this
and
take
a
look
at
this
this
afternoon
and
at
least
see
how
much
work
it'll
be.
D
Okay
aaron,
I
think
I
saw
aaron
during
the
meeting.
I'm
sorry.
D
H
H
It
sounded
like
that's,
not
feasible
for
like
older
versions
of
node,
so
I
I
think
I'm
not
100
sure,
but
it
sounds
like
we
have
a
sort
of
consensus
that
this
is
probably
a
good
way
to
go
forward
with
the
async
resources
stuff,
but
yeah
it's
it's
mostly
like,
like
you
said
the
ladder
I
haven't
had
time
to
get
the
test
passing
yet
I
don't
know.
Does
anybody
have
any
objections?
I
think
the
pr
mostly
you
can
look
at
the
code
and
probably
understand
the
idea
there.
D
Yeah
I
mean
I've
looked
at
the
pr
I
under
I,
I
agree
with
the
general
principle
of
the
pr
and
the
mechanism
that
you're
using
and
all
that
stuff.
I
just
haven't
really
been
looking
too
closely
at
it,
because
it
is
a
draft
and
I
just
wanted
to
make
sure
that
you
weren't
waiting
on
on
us
for
anything.
H
D
G
Yes,
hello,
so
the
first
one
is,
I'm
just
an
ask
for
folks
to
look
at
this
otap
in
the
client
sick.
We
are
proposing
to
add
an
events
api
which
will
allow
creating
you
know,
events
that
they
will
be
over
the
wire
sent
as
logs,
but
the
api
is
a
little
bit
different
than
than
like
a
logging
api
for
blogging
frameworks.
G
G
D
If
it's,
if
you're
prototyping,
something
that
that
is
part
of
spec
work,
then
yeah,
I
think
certainly
we
can.
We
could
merge
it
as
experimental
as
long
as
it's
clearly
marked
that
way.
If
it's
something
that
you
know
the
specification
rejected
or
said
they're
not
going
to
do,
I
think
we
wouldn't
want
to
merge
that
into
this
repo.
That
would
be
more,
you
know,
maybe
something
for
contrib,
but
in
this
case
I
think
you're
just
prototyping,
something
that
will
eventually
be
specified.
D
You
hope
right
so
yeah
yeah,
I
think
the
main
repo
is
is
a
perfectly
reasonable
place
for
it.
As
long
as
it's
in
the
experimental,
folder
and
clearly
marked,
as
you
know,
a
specification
prototype
or
whatever
it
is
you
wanna.
However,
you
wanna
award
that
okay,
great.
D
G
Okay,
great
yeah,
I
think,
there's
a
general
consensus
that
we
want.
We
want
to
have
an
events,
api,
yeah,
okay,.
B
Probably
just
a
follow-up,
what
the
fans
think
so
we're
talking
about
the
experimental
folder
in
the
open,
telemetry
js
repo,
not
the
contrib
repo.
Yes,.
A
B
Entire
api
sdk
again
so
this
is
effectively
taking
what
we
already
have
and
making
it
work
for
the
web.
Only
well
it'll
run
a
node
because
of
random
web,
but
the
intent
is
to
make
a
small
version
of
the
api
and
the
sdk,
and
rather
than
you
know,
this
sort
of
work
doesn't
really
fit
into
the
experimental
bucket
because
it
effectively
I'd
be
creating
an
experimental
api
web
api
and
an
experimental
web
sdk,
and
I
want
it
to
be
tagged
as
experimental,
because
I
do
not
want
this
thing
used
in
production.
B
B
That's
the
intent,
that's
sort
of
why
I
call
it
a
sandbox,
because
it
is
a
case
of
we
need
to
be
able
to
play
with
this,
and
we
actually
do
want
people
to
to
consume
it,
which
means
we
have
to
publish
it,
which
means
that
yeah,
we
don't
want
to
corrupt
the
existing
thing,
so
I
just
want
to
start
start
the
process
of
okay.
B
How
do
we
go
about
setting
this
up?
We
spoke
to
ted
in
the
in
the
rum
sig
and
he
suggested
that
we
need
a
tc
member
to
create
the
new
repo
he.
He
seemed
on
board
with
this
idea.
So
then
it's
a
case
of
well
with
this
community.
What
do
we
want
to
call
it?
B
D
Is
there
a
reason
to
do
that
in
a
separate
repo
and
not
just
create
you
know,
maybe
another
directory
within
the
existing
repo
or
something
like
that?
My
main
worry
is:
is
the
splitting
of
already
limited
resources.
B
B
D
B
D
Okay,
I
mean
I
don't
have
an
objection
as
long
as
you
know,
it's
not
too
confusing
for
users
of
the
of
the
existing
if
we
already
have
stable
and
experimental,
which
and
contrib,
which
has
been
confusing
enough
in
some
instances
to
add
this
whole
like
sandbox
layer
as
long
as
it's
like
named,
and
you
know
documented
clearly
that
that
you
know-
and
I
think,
based
on
what
you
said,
it
sounds
like
you're
on
the
same
page,
there
yeah-
I
don't
have
any
any
objections
to
that
matt
asks,
would
a
separate
repo
under
the
open,
telemetry
or
would
be
worth
considering
matt.
B
D
Should
we
consider
like
a
separate
org
called
like
open,
telemetry
sandbox,
or
would
you
rather
have
under
the
open,
telemetry
org
and
just
put
you
know,
experimental
or
sandbox
in
the
name
or
something
like
that.
B
As
long
as
it's
owned
by
cncf,
I
I'm
I
don't
care
what
the
name
is
if
it's
open,
telemetry
sandbox
or
something
that
I
you
know,
I'm
completely
up.
They're.
D
Think
the
official
owner
is
bogged
in,
but
I'm
not
actually
sure
but
yeah
in
terms
of
getting
like
publishing,
credentials
and
stuff
like
that.
For
for
the
new
repo
that
wouldn't
be
a
problem.
B
And
ted
just
mentioned
that
this
newly
created
issue
so
that
a
tc
member
can
go
off
and
create
it
so
yeah
I'll
raise
the
issue
then
and
yeah
everyone
can
pile
in
terms
of
what
they
want
the
name
to
be,
but
I
I
definitely
want
to
have
the
name
call
out
the
fact
that
this
thing
is
experimental
or
sandbox
or
you
know
just
definitely
do
not
use
in
production.
It
will
not
be
supported
for
production
environments.
B
Yeah,
I
I
we
we
did
talk
internally.
We
could
do
this
on
under
our
at
microsoft,
name
space.
My
I
have
permissions
to
go
off
and
do
that.
But
again
it
comes
back
to
the
the
name
clashing
that
daniel
called
out
it's
okay.
So
if
we
call
it
like
at
microsoft,
slash
open,
telemetry
experimental,
which
it's
like
the
long-term
thing.
Is
we
don't
want
to
own
and
maintain
it?
It's
it's.
It's
a
sandbox.
It's
it's
to
play.
So
we
can
publish,
we
can't
do
it.
F
B
D
Yeah,
I
think
in
terms
of
they
are
going
to
be
published
and
maybe
not
used
in
production,
but
but
used
by
by
end
users
in
at
least
an
experimental
fashion,
yeah
and
the
the
sort
of
implicit
trust
that
that
comes
with
it
being
under
the
open,
telemetry
namespace
is
important
and
not
having
you
know,
I'm
not
saying
that
nev
would
ever
do
this,
but
having
one
one
person
that
owns
the
name
space
that
can
completely
control
it.
D
We've
seen
a
handful
of
times
in
the
recent
you
know
the
last
12
months
or
so
that
that's
not
a
good
idea.
So
I
there
is
precedent
for
having
experimental
things
published
under
the
open,
telemetry,
namespaces
and
other
languages
and
in
the
open,
telemetry
github
art.
That's
that's
not
a
concern
to
me
my
my
question
would
be:
does
it
need
to
be
its
own
repo,
or
should
it
be?
D
D
I,
the
last
time
I
looked
into
this
github,
did
not
support
permissions
for
like
partial
repo
permissions.
If
that
makes
sense,
you
have
to
you,
either
have
right
access
on
the
whole
repo
or
none
of
it,
so
it
would
require
us
to
essentially
add
approvers
to
the
entire
repo
if
they
wanted
to
be
an
improver
for
that
directory.
D
I
definitely
wouldn't
be
adding
arm
64
support
yeah.
My
my
only
my
only
concern
is
is
the
splitting
of
resources.
The
javascript
sig,
like
many
of
the
other
cigs,
is
primarily
comprised
of
people
that
are,
you
know,
either
part-time
or
working
on
multiple
topics,
or
you
know
whatever
it
is.
It's
all
of
the
sigs
in
open
telemetry
have
have
limited
resources
and
I'm
a
little
bit
concerned
about
the
splitting
of
of
resources
that
are
so
related.
D
You
know,
web
js
and
node
are
certainly
different,
but
they're
not
so
different
that
you
know
it
tends
to
be
the
same
people
working
on
them
most
of
the
time
and
I'm
a.
D
About
the
resource
splitting,
but
as
long
as
it's
meant
to
be
temporary,
I'm
not
too
worried
about
that,
but
I
at
least
want
to
make
sure
that
it's
been
considered
before
we
do.
It.
B
Yep
yeah,
because
the
ultimate
goal
is
this
thing
should
be
compatible.
We
should
be
able
to
get
instrumentation
from
the
main
repo
and
run
it
on
top
of
this
thing,
and
if
we
can
achieve
that,
then
we've
hit
the
target
and
that
will
hopefully
provide
some
good
good
feedback
into
the
main
repo
to
make
it
smaller.
So
it
runs
better
in
the
web.
B
Yeah.
Okay,
that's
also
why
I
want
the
name
to
be
called
out
explicitly
because
yeah,
I
don't
want
people
building
instrumentations
in
this,
that
for
the
web.
When
this
thing
the
whole
thing
is
gonna
like
I
want
to
trash
it
at
the
end
of
the
day,
I'm
even
open
to
deleting
the
thing
it's
like.
D
Right,
the
other,
the
other
I
don't
know
of
concern,
is
even
the
right
word.
The
other
thought
that
I
had
you
mentioned,
creating
a
whole
new
api,
the
api
that
we
have
should
be
100
browser
compatible,
and
it
has
at
least
similar
goals
to
what
to
what
you
have
in
terms
of
deployment
size
should
be
really
small
impact.
End
users
should
be
as
small
as
possible.
D
I
don't
think
the
goals
are
all
that
different,
so
I
would
maybe
prefer,
instead
of
rewriting
the
api,
that
you
would
try
to
apply
as
many
of
the
as
much
of
the
work
to
the
existing
api
as
you
can
and
try
to
make
that
work
for
you,
so
that
we
don't
end
up
with
two
parallel
api
implementations,
which
could
be
confusing
for
end
users.
B
It
should
be
the
the
intent
is
to
grab
a
copy
of
it
and
then
see
what
we
can
do
like
in
the
rum
sig.
I
hope
we
got
into
a
good
discussion
about
why
the
breakup
and
one
thing
that
occurred
to
me
is
effectively
the
api
provides
a
knob
implementation
for
the
web.
You
know,
maybe
we
can
drop
that
and
then
to
split
that
out,
so
we
actually
put
the
api
into
two
disabled.
B
This
is
just
the
interfaces
and
this
is
the
default
api
which
effectively
is
saying,
take
the
existing
api
and
say
that's
the
default
ap
the
default
one
and
then
have
a
lower
layer,
which
is
the
api
that
we
could
then
potentially
build
on.
So
a
web
sdk
just
builds
directly
on
the
interfaces.
It
doesn't
need,
I'm
guest
begging,
it's
like
you
know.
These
are
just
random
thoughts
that
I
want
to
play
with
in
the
sandbox
and
see
what
happens.
D
Yeah,
I
mean
the
reason
that
you
have
to
have
the
reason
you
have
to
have
no
op
implementations
in
the
api
is
the
the
stated
goal
of
open
telemetry
as
a
project
is
to
get
like
third-party
libraries
to
build
open,
telemetry,
build.
D
Api
into
their
system,
but
if
there's
no
sdk
installed,
that
api
has
to
do
something,
so
it
has
to
know
up
so
removing
the
no
implementations
like
they
could
certainly
be
made,
maybe
lighter
weight.
But
if
you
remove
the
no
off
implementations,
then
it
is
impossible
for
a
third-party
library
to
call
api
methods
without
breaking.
If
there's
no
sdk
yeah.
B
D
Yeah
I
mean,
as
far
as
your
initial
question
goes,
it
sounds
like
you're
you're
sort
of
asking
for
input
on
whether
or
not
we
think
this
is
a
reasonable
idea,
and
at
least
speaking
for
myself,
it
sounds
like
a
reasonable
idea.
D
D
B
Yeah
I'll
share
a
link
to
app
insight
so
effectively.
I
did
do
an
experiment
at
the
end
of
last
year
of
effectively
taking
effectively
the
the
sample.
That's
already
provided
and
trying
to
build
a
layer
underneath
I've
got
the
right
page
here,
yep
underneath
this,
I
think
I
shared
some
of
the
numbers
with
with
daniel
on
slack
so
effectively.
B
That
is
the
current
app
insights
and
the
nightly
one.
That
will
be
the
the
next
release
that
I'm
publishing
this
week.
Scroll
down
you'll
see
a
nice
big
table
of
numbers.
B
But
using
just
open
telemetry,
so
it
was
like
yeah,
not
usable,
like
even
our
numbers.
Our
numbers
are
bigger
than
I'd
like
one
of
the
next
big
versions.
I'm
going
to
shrink
these
numbers
by
about
10k,
but
that's
an
extra
layer
of
minification
that
isn't
going
out
in
the
next
release.
So
ideally
I
want
to
be
have.
I
want
to
have
open
telemetry
somewhere
closer
to
these
numbers,
ideally
smaller,
and
I
want
that
gzip
size
to
be
like
30k,
that's
internally.
B
What
my
goal
is,
because
if
I
can
get
open
telemetry
and
under
there,
then
I
can
start
effectively
using
it
under
the
covers
and
have
the
api
service
of
app
insights
on
top.
But
it's
using
open
telemetry
to
send
them
to
london.
That's
the
ultimate
goal
for
for
microsoft.
If
you
like,
but
do
you
know.
B
B
If
you
scroll
down
you'll,
see
some
big
jumps
and
numbers.
I
think
in
2.6
is
when
I
started
big
minifications
there,
where
I
dropped
from
you
know,
130
back
down
to
120
that
was
effectively
removing
well
refactoring,
the
way
we
defined
classes
so
that
affected
the
minified
size.
You
know
all
the
references,
the
dot
prototype
and
dot.
This.
D
D
In
the
api,
if
you
look
at,
I
think
our
logging
api
yeah
api
diagram,
yeah
yeah,
so
instead
of
having
let's
see
they
might
be
at
the
bottom
yeah.
So
he
has
all
these
all
of
these
defined
as
types
but
then
they're
actually
implemented
in
the
constructor
like
this,
so
that
they're
referenced
more
tightly.
This
is
what
a
way
smaller
version
of
the
api
than
if
each
of
those
functions
had
just
been
written
or
each
of
those
methods
had
just
been
written.
The
standard
way
you
would
write
a
method.
B
B
Yeah
and
also
means
you
can
hide
all
your
private
properties,
because
your
private
properties
can
be
defined
as
local
variables
in
your
constructor,
so
they're
directly
embedded
in
the
closure
and
if
you
need
them,
you're,
just
referencing
a
local
variable,
not
this
dot,
underscore
private
name,
which
is
then
all
public
as
well.
Sorry,.
D
Don't
think
we
applied
this
to
oh
yeah,
so
we
did
yeah.
No,
we
did
not
apply
it
to
other
places
yeah,
but
we
probably
could.
B
Yeah,
so
that's
some
of
the
changes
the
sandbox
would
do
is
to
explore
those
and
like
private
methods
like
there's,
no
reason
they
they
need
to
be
defined
on
the
on
the
class,
because
you
don't
want
people
calling
them
and
they
end
up
being
class
dot,
prototype
private
name
always
anyway.
So
right,
I
think
in
my
in
the
dynamic
repo
dynamic,
proto
stuff.
I
actually
talk
about
this
a
lot
more.
Let
me
find
that
one.
B
It
takes
things
to
a
whole
new,
a
whole
new
level
and
actually
redefines
it's
called
dynamic
product
because
it
repopulates
the
prototype
from
local
methods.
So
this
is
like
if
you
want
to
go
steroid
approach,
but
still
have
prototype
methods
use
this.
B
Now
the
main
readme
yeah,
this
is
the
helper
function
and
then,
like
that's,
how
you
do
it
so
effectively?
Everything
gets
so
like
in
here
we've
got
everything's
in
infrastructure,
so
it's
on
the
closure,
so
we
can
have
all
local
variables
everything
inside
dynamic,
proto,
so
every
function
defined
there
actually
becomes
a
prototype
level
function
and
if
you're
playing
a
javascript,
you
should
know
the
difference
between
prototype
verbal
functions,
versus
instance,
level
functions,
and
this
does
support
like
the
the
bases,
the
super
class.
B
B
Yeah,
there's
an
extra
function
call
involved
so
effectively.
The
prototype
level
function
is
really
a
proxy
that
looks
up
on
the
object
for
the
real
instance
and
then
calls
that
so.
D
Yeah,
I
think
in
javascript
we
very
frequently
have
this
sort
of
trade-off
between
code,
size
and
or.
B
Yeah
so
yeah
it's
it's,
it's
always
the
trade-off
and
yeah
that
just
be
a
very
aggressive
approach.
I'm
gonna
try
not
to
use
that,
but
I
know
you
know
that
that
that's
a
very
easy
way
to
like
you
can
still
write
classes
mostly
in
the
same
way
you
just
wrap
them
all
in
constructor
and
it's
still
a
class,
and
that
just
gives
you
effectively
the
same
outcome
at
run
time
after
the
class
has
been
created
like
when
you're
unit
testing
it.
B
D
Yeah
and
as
far
as
the
name
goes,
I'm
sure
whatever
you
choose
will
be
fine.
It
sounds
like
we're
on
the
same
page
that
it
should
be
very
clearly
demarcated,
so
yeah,
whatever
you
decide,
I'm
sure
is
okay.
D
D
My
my
primary
motivation
here
is
to
reduce
end
user
confusion
and
too
much
resource
flooding.
If
it's
avoidable.
D
All
right,
anyone
have
any
other
questions
about
this.
D
Okay,
just
like
we
have
every
week,
I
have
a
list
of
old
and
new
prs
that
are
in
need
of
reviews.
D
The
metrics
ones
are
at
least
my
priority
right
now,
so
that
we
can
get
metrics
ga
over
the
finish
line
and
start
working
on
things
like
logging
and
events,
which
I
know,
martin
and
nev
will
probably
be
happy
to
hear
and
beyond
that.
I
hope
you
all
have
a
good
week,
and
I
will
talk
to
you
next
week.