►
From YouTube: 2021-09-21 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).
A
B
B
B
Yeah,
I
think
you
can
write
your
name
if
okay,
so
no
topics
in
the
agenda,
so
that
means
it's
open
for
anyone
to
ask
question.
So
it
looks
like
we
have
eight
people,
I'm
seeing
some
new
names
as
well.
So
let's
do
if
you
are
new
here.
Please
use
this
opportunity
to
say
hello
just
give
a
quick
intro
and
then
we
can
move
to
in
ecosystems.
B
So
I'm
seeing
like
wolfgang
and
galaxy
like
new
folks,
if
you
want
to
say
hello.
C
You're
still
on
mute,
yeah
sure,
oh,
like
maybe
yeah,
we'll
go
first
and
then
I'll,
introduce
myself.
Okay,.
D
C
My
name
is
wolfgang,
I'm
also
from
dine
trades,
I'm
actually
I'm
leading
a
team
that
olegsie
recently
became
part
of-
and
I
actually
joined
this
group
here
about
a
year
ago,
from
time
to
time
or
even
longer
than
a
year.
I
think
so.
We
made
some
initial
contributions
to
estimators
to
open
telemetry.net,
but
then
we
shifted
focus
a
little
bit,
but
now
we
are
looking
into
opentelemetry.net
again
and
yeah.
C
We
spotted
so
that
apr
that
what
axi
is
working
on
at
the
moment
is
about
the
contributing
hotel,
po
http
exporter,
which
is
something
that
we
are
making
use
of
inside
of
dyna
trace,
which
is
why
we
thought
this
would
be
a
valuable
I
guess
for
the
whole
community
and
for
us
contribution,
and
this
is
why
we
are
basically
here
if
there
are
any
questions
regarding
this
request
and
yeah.
B
So
I'll
try
to
open
the
pull
requests
next,
but
before
that
like
are
there
any
pending
questions
or
anything
in
general?
Otherwise
I
can
take
like
the
appears.
I
think
robot
also
has
apr,
so
it
might
be
good
to
discuss
it.
While
we
have
a
good
number
of
people
here.
B
So
any
questions
before
I
open
peers,
okay,
yeah
I'll
go
from
this
one,
and
this
one
from
robert
needs
some
attention,
probably
just
that
yeah
riley
is
not
here,
so
we
may
not
have
enough
contact,
so
we
leave
it
as
pr.
I.
B
I
see
oh
okay,
oh
when,
okay,
this
was
standing
10
hours
ago,
so
I
haven't
even
opened
it
okay
and
finally,
if
time
permits
this
is
a
draft,
but
I
I
will
just
share
some
ideas
so
so
I
think
the
issue
was,
I
mean
not
issue.
The
pr
is
about
like
adding
support
for
http
based
otlp
exporter
right,
that's
the
same
one
right,
yeah,
that's
the
same!
One
look!
What
is
a
specific
thing
which
you
want?
I
think
allen
already
asked
that
question
somewhere.
B
I'm
still
struggling
to
find
the
comments
so
maybe
like
since
allen
is
also
here.
Could
you
just
like
summarize
your
concern?
I'm.
F
Still
trying
to
find
the
comment,
it's
it's
like
somewhere
here,
oh
yeah
I'll.
Just
summarize,
I
full
disclosure.
I
haven't
taken
a
super
close
look
at
this
pr
yet,
but
I
just
engaged
on
the
conversation
about
like
do.
We
want
the
http
exporter
in
the
same
package
as
the
grpc
exporter,
I'm
leaning
towards
the
opinion?
Yes,
but
I
I
I
articulated
some
like
pros
and
cons
of
of
the
two
like
a
con
of
doing.
That
would
be
that
you
know
in
pulling
down
this
package
if
I'm.
F
F
And
then,
of
course,
a
pro
to
keeping
them
in
the
same
is
something
that
we've
experienced
at
new
relic.
We,
we
have
otlpm
just
for
supporting
grpc
and
not
http
right
now,
and
so
we
have
customers
that
have
in
other
languages,
wired
up
using
the
http
exporter
and
then
they've
had
to
effectively
like
swap
out
the
dependencies
in
order
to
get
things
to
work,
which
is
fine.
If
you're
like
the,
if
you're
the
developer-
and
you
can,
you
can
do
that.
B
Okay,
yeah,
I
mean
I
want
to
see
like
whether
there
are
anything
else
yeah
I
mean
I
remember.
Reading
this
part
it
seems
very
reasonable.
Okay,
now
we
have
to
make
a
decision
about.
Do
we
want
to
keep
it
in
the
same
package
or
not
like
I'm
trying
to
see
whether
there
are
any
comments
immediately,
but
is
that
the
only
thing
like
which
is
like
broking
and
after
that?
B
It's
everything
is
like
a
solvable
in
the
pr
itself
or
is
there
any
like
bigger
level
question
which
we
want
to
address
right
away?.
D
Yeah,
I
have
a
question
is,
but
it's
if
we
decide
to
go
with
option
one.
Actually,
I
already
implemented
option
one.
So
I
I
kept
only
one
exporter
which
you.
D
Beginning
of
this
conversation-
and
I
just
had
the
question
I
have
a
question
about-
I
did
default
for
protocol
for
additional
protocol
configuration
which
I
introduced
and
if
we
decided,
I
think
it's
somewhere.
If
you
could
scroll
down,
we
decided
to
use
a
grpc
as
default
and
there
is
a
specification
page
should
it
be
mentioned
there,
because
this
page
is
applicable
for
all
languages
or
for
all
technologies.
But
we
use
it
only
for
c
sharp
at
the
moment,
as
default.
B
B
So
that's
that,
like
should
be
like
very
easy
like
if
it
is
the
same
package,
but
if
it
is
a
different
package,
then
yes
yeah,
I
mean
I
don't
like
having
like
had
the
chance
to
look
at
the
recent
comments.
But
it
looks
to
me
right.
This
approach
seems
very
straightforward,
except
that
sorry,
like
yeah,
except
that
we'll
have
the
extra.
E
Here
because,
like
I'm
implementing
the
environmental
variables,
you
know
support,
and
it
will
be
a
lot
easier
and
simpler
if
it
will
be
in
one
package
if
it
would
be
two
packages,
then
having
support,
for
it
will
be
quite
complex
because,
probably
to
distinguish
the
protocol,
you
will
need
to
basically
probably
reference
two
nougat
packages
and
do
some
magic.
F
B
Yeah
I
mean
like:
does
anyone
else
have
like
opposing
things?
Otherwise
I
think
this
thing
I
mean
I
agree
I
haven't
like
had
the
time
to
like
really
think
through
the
like.
What
is
what
does
it
really
mean
by
like
pulling
these
extra
dependencies,
because
this
may
be
a
concern
for
some
people,
but
that's
the
only
thing
which
is
against
this
proposal.
So
in
the
we
use
the
like
ellen,
can
you
remain
making
like
which
grpc
package
do
we
use
the
google
one
or
the
the
new
one
yeah.
F
F
We
use
the
net
one
yeah
from
quora,
okay,
the
one
which.
F
I
misspoke
the
it's
the
net.
B
Standard
compilation
has
to
use
to
google
okay,
so
the
older
one
is
using
the
original
grpc
one
and
for
the
newer
ones
we
use
the
http
client
based
right,
okay
and
like
yeah,
I
mean.
Basically,
these
are
not
part
of
the
system.
Okay,
so
there
is
it's
it's
an
external
dependency
for
most
customers,
unlike
pure
http,
client,
okay,
that
seemed
to
be
the
only
reasoning
against
it.
B
Yeah,
like
does
anyone
else
want
to
share
opinion,
like
maybe
like
michael
you
are
here
like
you,
you
might
have
some
thoughts
on
it.
B
Okay,
let's
keep
it
this
way
for
now
and
like
one
thing
to
comment
is
like
we,
the
next
stable
release
is
only
planned
by
november,
so
we
have
approximately
two
months.
So
if
you
think
that
anyone
else
has
concern
about
this
approach,
we'll
be
able
to
like
revisit
it,
but
only
until
now,
because
once
we
do
like
the
1.2
stable,
then
there
is
no
going
back.
We
have
to
like
maintain
backward
compatibility
and
everything.
B
So
so,
if
anyone
else
has
concerns
about
like
keeping
the
same
approach,
I
mean
same
same
package:
please
raise
it
in
the
yeah
in
the
pr
for
now
I'll
mark.
The
decision,
like
as
we
are
proceeding
with
the
same
package
based
on
today's
discussion
and.
F
Just
as
a
final
note
about
this,
like
if
they're,
if
anybody
does
come
in
and
expressing
preference
for
not
having
the
grpc
dependencies
like
in
the
http,
you
know
we
could
pursue
a
path
where,
like
we
have
a
a
slimmed
down
package
which
might
be
like
a
different
compilation,
it
would
be
like
the
same
code,
but
just
different
compilation
that
strips
out
all
the
grpc
stuff.
It.
C
Another
reason
to
to
stay
with
one
package,
maybe
is
because
there
is
also
the
the
exporter
version,
which
does
the
json
format
over
hd
over
http
versus
the
protobuf.
We
have
right
now
and
I
think
it
would
be
cumbersome
to
have
then,
if
you
go
a
multiple
package
version,
then
to
have
an
extra
version
just
for
json
over
http
right.
So
this
is
more
like
a
configuration
option
of
the
otrp
exporter,
so
you
say
it's
it's
a
chase
in
a
proto-path
and
which
transport
do
you
use.
B
So
it
looks
to
me
like,
like
the
rest
of
the
questions
in
the
pr
like
I
think
I
mean
those
are
like
purely
like
implementation
details,
so
we
should
be
able
to
like
keep
it
in
the
pr
itself.
B
We
don't
need
to
like
discuss
it
right
in
the
like
segmenting,
okay,
anything
else
for
this
vr.
Otherwise,
let's
go
to
the
next
one.
B
Okay,
so
yeah,
so
I
remember
like
leaving
some
comments.
Let
me
open
it
and
find
what
was
my
comment
about?
Yes,
so
robert,
I
think,
like
I
wanted
michael's
opinion
on
this
one,
so
I
attacked
him,
but
unfortunately
he's
not
in
the
code
anymore.
So
I'll
have
to
ask
him.
B
So
maybe
like
just
a
background
here
like
we
introduced
this
class
like
michael
sorry,
robert
added
this
to
support
the
environment
variable
parsing
option,
but
there
was
a
comment
which
we
left
saying
that
this
is
technically
not
required
to
be
like
public,
because
each
exporter
can
like
make
their
own
copy.
B
So
we
could
like
keep
it
internal.
That
was
the
command
and
of
course
the
other
comment
was
about
keeping
it
sealed
and
I
don't
think
any
objections
we
can
still
keep
it
sealed.
So
my
only
concern
about
keeping
it
internal
using
the
internals,
visible
approaches
we
might
be
like.
We
are
basically
like
exposing
the
sdk
internals,
visible
to
all
the
exporters
which
we
ship
from
this
repository
kind
of
giving
an
unfair
advantage
to
these,
especially
exporters.
B
So
if
I'm
like
doing
an
azure
specific
or
like
new
relic
or
google
exporter,
they
won't
have
the
same
advantage.
So
my
thinking
is.
We
should
not
like
do
this
a
long
time
like
if
it
is
just
to
unblock
something.
We
did
this
in
the
past
just
to
unblock
our
one
auto
release,
but
we
quoted
of
it
eventually
all
the
special
internals
visible.
B
So
I
would
prefer
to
keep
it
internal
if
you're,
keeping
it
internal,
let's
like
either
copy
paste
the
code
or
use
the
other
approach,
which
robert
already
tried
and
didn't
work.
So
I'm
okay
to
like
literally
copy
paste,
the
whole
thing
as
well
or
alternately.
Since
we
are
implementing
something
purely
from
the
spec.
I
don't
think
there
is
much
risk
about
exposing
this
as
public.
B
So
I
let
like
michael
come
in
because
he
he
was
a
person
who
initially
complained
that
this
cannot
be
public
but
I'll
check
with
him
again
to
see
if
this
is
a
strong
objection
or
just
like
a
comment
and
based
on
that,
we
can
like
move
forward
from
this
pr,
so
robot,
like
anything
else,
you
want
to
ask
about
this
pr.
If
not,
we
can
go
to
the
next
one.
E
E
B
Yeah
I
mean
the
other
part.
I
was
not
really
making
it.
I
mean
I
didn't
want
to
sound
as
if
it's
making
it
danger.
It's
just
like
we
are
giving
like
some
sort
of
like
unfair
preference
to
a
set
of
exporters
and
that's
the
same
thing
and
second
is
like.
If
we
make
it
like
the
internal
approach,
we
might
be
like
accidentally
using
some
things
without
even
realizing
that
it's
not
public,
and
so
we
did
this
approach
earlier,
just
to
unblock
program.
B
I
think
the
most
recent
reason
why
we
did
it
is
because,
when
we
were
working
on
the
matrix
we're
not
yet
ready
to
decide
what
is
the
public
ap,
so
we
made
everything
internal
and
gave
the
special
permission
to
otlp,
but
that
requirement
is
already
gone
like
we
don't
have
this
requirement
anymore,
so
there
is
no
need
for
the
sdk
to
be
like
visible
to
the
otlp
exporter
itself.
B
So
if
we
can
get
rid
of
this
thing
and
either
like
copy
paste,
the
whole
thing
or
even
like
make
it
public,
I
would
be
happy
with
any
of
those
options.
Michael
is
back
so
michael.
Can
you
comment
if
you
are
still
here
on
this
one.
B
Uh-Huh,
okay,
welcome
back
yeah,
so,
like
remember,
like
you
had
left
a
comment
like
in
the
previous
pr
about
potentially
marking
this
internal
and
using
the
like
shared
file
approach.
But
since
this
particular
class
is
using
the
event
source
for
the
sdk,
we'll
have
the
issue
like
when
you
refer
it
from
a
different
project.
It
will
configure
two
copies
of
this
thing
so
wanted
to
see.
If
you
are
okay
with
making
this
public
and
field.
A
B
Which,
like
robert,
has
left
here
so
these
helper
classes
they
are
like.
If
the
environment
variable
is
like
not
possible
or
is
invalid,
it
sends
an
error
message
using
the
sdks
event
source.
So,
yes,.
B
A
E
A
B
So
I'm
wondering
now:
how
did
we
get
that
error?
Because
this
is
supposed
to
be
internal?
Okay,
when
you
include
it
from
the
like
jager,
it
needs
access
to.
Okay
got
it
so
maybe
like
an
another
option,
is
to
like
make
the
login
use
a
different
event
source
like
if
it
is
jager
use
the
eager
one,
but
that
would
be
like
even
complexly.
You'll
need
like
another
set
of
like
flags
like
if
it
is.
E
A
Yeah,
I
would
prefer.
I
know
this
is
not
elegant
and
I
wish
we
didn't
need
to
do
these
link
files,
but
I
would
prefer
to
deal
with
the
nest
and
just
make
everything
public.
So
I
think
then
we
get
into
messes
down
the
line.
We
need
to
change
something
that's
that
we
made
public
and
now
we
can
no
longer
do
that.
That
makes
sense.
B
Yeah
I
mean
I,
I
totally
understand
the
reason
why
you
are
standing
about
making
it
public,
but
it
looks
like
we
have
like
other
issues
when
we
try
to
keep
it
internal
and
share
it
this
way,
so
it
seems
like
we
have
to
like
make
a
decision
to
unblock
it's
probably.
A
In
that,
so
I
would
say:
let's
just
kill
those
tests
make
it
private.
The
problem
goes
away
or
if
we
want
to
keep
the
test
instead
of
the
test
accessing
that
internal
via
internals
visible
to
it
could
also
just
link
in
the
private
source.
So
if
we
just
keep
everything,
that's
linked
in
private,
then
we'll
basically
just
scope
it
to
every
assembly,
that's
consuming
it
and
it
will
never
leak
out.
We
won't
have
these
problems
so
that
kind
of
makes
sense.
Yeah.
B
So
robert,
like
do
you
think,
that's
something
which
we
can
try
out
as
opposed
to
using
the
internals
receiver.
E
A
E
E
B
Okay,
all
right
so
make
either
leave
a
comment
explaining
like
what's
the
alternate
option,
to
avoid
the
issue
which
robert
faced
or
you
can
push
a
comment
which
addresses
it
right
away.
So,
let's
move
to
the
next
one.
Thank
you
very
bad
at
keeping
notes
and
look
and
talking
at
the
same
time,
so
I'll
add
a
comment
in
the
meeting
notes
after
the
meeting
is
done
for
the
second
one.
Okay,
what
was
the
issue
here?
B
E
So,
basically,
here's
a
comment
there
was
idea
proposed
by.
I
don't
want
to
say
the
name
wrongly
ray
yank
or
yes,
riley
really.
So
basically,
he
proposed
like
on
the
top
in
the
description,
how
we
could
like
process
or
handle
the
inventory
variables.
So
one
of
the
yeah
so
point
number
two
was
the
thing
that
I
wanted
to
address
in
this
pr.
So
basically,
if
it
was
connected
initialization
of
the
sdk
and
if
everything
something's
wrong,
for
example,
it
cannot
parse
a
port
because
it's
a
string,
it
should
be
a
number.
E
Then
it
could
fire
fast
result
in
exception.
Yes,
so
basically
I
implemented
it
just
to
show
like
what
and
also
try
to
explain
in
the
comments
what
will
be
the
drawbacks
of
such
approach.
So
the
drawback
is
that
basically
right
now,
I
do
not
see.
Maybe
there
is
a
possibility
that
we
do
another
way,
but,
right
now,
this
parsing
logic
is
in
the
constructor.
E
E
E
So,
basically,
if
we
prefer
to
fail
fast,
even
though
sometimes
it
it
can
be
hard
to
make
and
work
around
in
code,
because,
for
example,
you
need
to
basically
clear
the
inventory
available
so
that
it
does
not
throw
an
exception
or
we.
A
B
That's
what
we
do
currently
right,
we
just
log
the
error
and
exactly
the
enrollment
variable
does
not
exist
right.
That's
correct,
like
we
do
the
same
thing
for
like
first
one
and
second
option:
that's
what
we
currently
do,
so
this
pr
was
trying
to
modify
the
code
so
that
we
do
two
like
instead
of
moving
on
yep,
we
are
trying
to
store
exception
and
what
you're
saying
is.
B
B
Okay,
now
I
understood,
what's
the
like
context,
yeah,
I
can
go
ahead
and
do
the
pr
and
leave
my
thoughts
there,
yeah,
okay
yeah.
Anyone
else
wants
to
like
share
comments
on
this
one
yeah,
so
they
didn't
have
a
chance
to
look
at
it
before.
E
Maybe
I
just
have
a
question:
what
happens?
I
haven't
checked
the
code
there
because
there's
this
resources
right
and
what
happens
if
someone
sets
as
an
environment,
available
and
invalid
resource
that
cannot
be
parsed.
E
B
I
see
yeah,
I
mean
this
is
a
good
argument
like
if
we
are
already
doing
it
for
like
some
set
of
enrollment
variables
yeah,
then
we
should
be
like
doing
it
for
the
sake
of
consistency,
yeah,
okay,
yeah,
I
mean
I
totally
forget
that
we
already
have
this
feature
shipped
as
part
of
one
dot
house
stable.
So
it's
already
out,
so
we
cannot
go
and
change
it
anyway.
Okay,
yeah
I'll,
leave
some
comments
in
my
pr.
As
soon
as
I
can
do
it
yeah
thanks
for
bringing
it
up.
If.
B
Yeah,
but
let
me
like
do
the
proper
command
and
close
it
even
if
we
are
like
not
accepting
anything
we
want
to
make
sure
like
it
is
documented,
so
that
it
will
be
clear
for
future
folks
that
it
was
considered
correct.
B
Okay,
so
I
will
go
through
this
vr
yeah
anything
else
to
be
discussed.
I
have
a
very
small
pr
to
be
shown
if
there
are
no
other
questions
I'll
just
go
into
it.
B
Okay
looks
like
no
other
questions
I
want
to
like
get
started
with
views
so
believe
we
were
supposed
to
do
a
release
of
alpha
4,
like
two
days
back
the
last
alpha
or
four
days
back
yeah,
so
we
have
like
a
just.
I
mean
it's
still
being
addressed
like
the
issue
about
like
export.
The
way
we
change
things
now
has
some
other
implications,
so
riley
is
trying
to
address
them
by
fixing
the
flash
implementing
the
shutdown
all
those
things.
It's
basically
like
doing
these
two.
B
We
will
be
like
de-prioritizing
this
thing
for
a
future
date,
because
there
isn't
enough
demand
for
this
right
away.
Based
on
what
I
see
so
I
mean
multiple
exporter
means
at
the
same
time,
so
you
can
export
to
like
prometheus
and
otp
at
the
same
time
would
not
be
supported
as
of
now,
because
we
only
support
a
single
reader,
so
I'll,
create
I'll,
create
an
issue
saying
why
I'm
deprioritizing
this
one
as
opposed
to
something
else
and
then
move
on
and
for
the
next
release.
B
We
intend
to
start
with
views,
so
I
started
playing
with
views.
I
mean
I
think
I
shared
like
two
pr's,
so
it's
relatively
easy
to
do
the
actual
implementation
with
the
current
architecture,
because
the
only
change
we
ever
need
is.
I
mean,
apart
from
the
actual
view,
config
itself.
B
The
only
change
I
found
was
you
just
need
to
like
modify
something
when
an
instrument
is
being
created
for
the
first
thing
to
see
whether
there
is
a
view
config
and
based
on
that
you
decide
it
will
be
dropped
or
it
will
be
mapped
to
a
new
stream
or
you'll
create
like
multiple
streams
from
the
same
instruments.
Opening
implementation
wise,
it
seems
easy,
but
I
wasn't
sure
like
how
do
how
does
the
end
users
experience?
Triplex,
so
I
started
with
the
final
talk
before
I
mean
this
year
does
not
have
the
implementation.
B
So
basically,
I'm
asking
like
folks
to
comment
down
the
approach,
so
this
is
purely
a
programmatic
way
of
configuring
views.
You
you
are,
you
can
add,
like
any
number
of
views,
abuse
get
an
instrument
and
user
decides
what
configuration
that
instrument
should
take,
and
if
it
doesn't
want
to
say
anything
about
that
instrument,
it
can
return
nothing.
You
can
discuss
what's
the
best
way
of
dealing
with
this.
I
have
like
few
examples.
B
So
in
this
example
like
I
basically
this
view
is
saying
all
the
histograms
should
be
aggregated
using
this
approach,
which
is
taking
these
three
bounds
and
for
anything
which
is
not
explicitly
called
out,
it
would
mean
it
will
take
the
default,
so
the
name
of
the
instrument
would
be
whatever
is
the
name
of
the
instrument.
The
description
would
be
whatever.
Is
it
so
that's
this
view
is
doing
and
I'm
adding
like
another
view.
B
It
again
takes
histogram,
so
it
basically
means
I'll
create
for
every
single
histogram
I'll,
be
creating
like
two
metallic
streams
that
by
design
of
the
view
spec.
But
here
I
am
like
naming
it
to
like
something
else,
but
this
would
again
result
in
a
conflict,
because
if
I
create
like
two
histograms,
then
that
means
I'll
have
two
streams
with
the
same
name.
So
that
means
the
second
one
will
be
dropped
so
like,
but
user
can
always
change
the
name
to
be
like
something
else.
B
They
can
like
prefix
the
original
name
followed
by
something
else,
so
that
they
won't
have
the
concrete.
So
this
is
like
one
way
of
like
getting
one
instrument
and
like
kind
of
splitting
that
or
broadcasting
it
into
like
multiple
streams.
Another
example
is,
like
you
have
name
conflict
so
you're,
just
using
the
view.
The
only
use
case
for
this
view
is
just
you're,
just
like
replacing
the
name
with
something
else,
so
you
could
use
this
to
potentially
prefix
the
instrument
name
with
the
meter
name
or
you
can
do
like
any
name.
B
You
choose,
and
the
third
use
case
is
to
suppress.
You
basically
say
that.
Okay,
you
have
an
instrument
with
this
name,
you
don't
want
it
like
exported
at
all,
so
in
the
basic
sense
we
already
have
a
way
to
like
subscribe
to
individual
meters
by
virtue
of
its
team,
but
this
is
like
even
finer
level,
so
we
already
subscribed
to
all
the
instruments
from
this
meter,
but
within
that
I
don't
want
like
a
subset
of
instruments,
so
you
just
basically
say
don't
aggregate
it,
which
means
like
we
just
dropped.
B
B
Based
on
that
we'll
design
the
public
ap,
the
actual
implementation
is
like
purely
internal,
so
it
can
happen
in
a
separate
year.
I
just
want
to
settle
on
the
public
ep
and
different
languages
have
done
it
differently,
primarily
because
the
spec
doesn't
explicitly
say
how
do
you
handle
music?
It
simply
says
it
should
have
the
ability
to
select
instruments
using
so
many
criterias.
B
So
in
our
case,
like
I'm,
just
leaving
the
instrument
itself
in
the
action
callback,
so
you
can
decide
instrument,
name
type
and
it
can
even
fetch
the
meter
from
the
instrument.
So
we
kind
of
cover
this
and
the
configuration
of
the
stream
is
what
the
returned
eyepiece.
So
the
return
type
from
the
action
is
extreme
configuration.
B
So
it's
kind
of
it's
already
matching
the
spec,
but
I
just
want
to
get
a
feel
of
whether
this
is
user
friendly
enough
or
do
we
need
to
like
do
something
else.
That's
right,
yeah
and
hopefully
like
we
should
be
able
to
cover
all
the
view.
B
At
least
the
critical
things
like
people
were
like
asking
for
views
primarily
for
getting
the
custom
instagram,
so
I'll
try
to
focus
on
that,
which
is
why
I
included
the
instagram
case
in
the
example,
and
we
also
have
like
other
users
for
these,
which
is
to
support
like
meter
and
instrument,
but
take
a
subset
of
the
instruments.
So
it's
subset
of
the
tag,
so
you
may
have
like
100
keys.
You
just
care
about
like
two
of
them.
So
that's
another
feature.
B
Then
there
is
another
feature
which
is
to
get
additional
tags
from
the
context
again
not
handling
it
in
this
pr.
So
please
take
a
look
and
share
any
feedbacks
either
in
the
pr
or
we
can
ping
me
and
we
can
discuss
yeah
go
ahead.
D
F
B
So
the
spec
says
the
sdk
can
decide
whether
views
should
be
allowed
to
be
added
after
the
initialized
session.
It
says
it
should
be
allowed,
at
least
at
the
construction
date
after
that,
it's
up
to
us,
so
I
think
somewhere
it
is
mentioned
and
like
where
it
is.
B
Maybe
in
the
meter
provider
there
is
a
language
which
says
what
are
the
things
which
can
be
updated
after
the
provider
is
constructed
yeah.
It
says
this
may
be
done
at
the
time
of
there
was
some
language
initially,
but
then
based
on
some
feedback,
it
was
removed,
yeah
and
for
tracing.
Also.
I
think
we
only
allow
like
processors
to
be
added.
After
the
fact
we
don't
allow,
adding
like
other
source
or
we
don't
allow
adding
the
source
or
anything.
So
I
think
the
key
is
like
pretty
much
flexible
and
based
on
my
implementation.
F
The
reason
why
I
was
curious
about
where
that
conversation
landed
was
that
I
I
recall,
I
know
it
didn't
land
in
the
spec,
but
riley
was
proposing
a
hint
api.
F
And
what
would
have
like
the
default
view
for
a
from
library
and
that
to
me,
if
we
ever
do
get
there
might
require
some
after
the
fact
adding
of
views?
I.
B
See
I
mean
I
don't
feel
like
how
would
like
hints
would
affect,
because
basically,
if
there
is
no
view
configured,
that's
this
is
a
behavior.
There
is
no
view,
so
you
just
take
the
default
and
somewhere
here
there
is
a
to-do
which
says
by
the
defaults
can
be
ordered
and
using
the
hint
and
that
hint
is
part
of
the
api.
It
is
not
an
sdk
configuration,
so
hint
would
be
part
of
like
this
statement
like
when
you
create
the
counter
or
instrument
like
yeah.
B
When
you
create
the
instrument,
there
will
be
taking
additional
parameters
that
will
be
part
of
the
hint.
So
it's
really
part
of
the
instrument
itself
like
in
the
sdk.
We
will
know
the
hint
from
the
instrument,
so
we
don't
need
to
like
support
dynamic.
We
used
to
handle
that
unless
I'm
missing
something
like
no.
F
B
Okay,
yeah
so
like
in
the
like
last
month,
we
did
a
lot
of
refactoring.
So
now
the
entire
structure
is
based
on
two
concepts.
One
is
metric
which
follows
a
spec,
which
is
a
one
metric
class
in
our
sdk
is
really
meaning
metric
stream.
Let
me
just
open
it.
Let's
just
describe
what
I
trying
to
explain.
B
So
we
have
a
thing
called
metric,
which
really
means
a
matrix
stream
which
contains
names
all
the
static
things
which
doesn't
change,
and
then
it
can
have
like
any
number
of
time
series
that
is
captured
by
metric
point.
B
So
with
this
approach,
when
I
try
to
implement
the
view
like
it's
fairly
easy
because
I'm
I'm
only
going
to
touch
like
one
class
quite
likely
or
maybe
like
two
classes,
because
the
view
is
something
which
I
mean
based
on
what
we
just
discussed,
we
know
the
entire
view
configuration
at
the
provider
construction.
So
when
the
provider
is
constructed,
we
know
all
the
views
and
provider
is
the
one
which
has
the
sorry,
which
has
the
callback
which
handles
the
callback
when
a
new
instrument
is
published.
B
So
whenever
there
is
a
new
instrument,
we
see
a
new
instrument,
we
already
know
the
entire
the
conflict,
so
we
already
know
what
do
we
want
to
do
with
this
instrument?
So
there
are
only
three
things:
one
is
the
the
user
says:
don't
listen
to
this
instrument
by
suppressing
the
aggregation
for
that
instrument,
so
it
will
result
in
no
metric
streams
at
all.
So
that's
one
case
and
second
is:
there
is
a
view
which
results
in
the
creation
of
one
metric
stream
per
instrument.
B
So
that's
what
that
would
be
the
case
for
like
I'm
just
using
an
example.
So
if
I
say
for
one
counter,
I'm
just
like
renaming
it
to
my
counter
rename
or
like
some
other
unique
name.
So
it
basically
means
this
instrument
results
in
a
single
output
of
single
metric
and
then
there
is
a
third
scenario
where
a
single
instrument
can
be
resulting
in
like
multiple
streams,
and
one
use
case
is
I'm
like
shown
here.
You
take
the
histogram
and
you
calculate
like
two
aggregates
one,
using
this
bounce
one
using
a
different
bones
or
another
example.
B
Is
you
get
an
instrument
and
you
let's
say
it,
has
like
10
dimensions,
and
each
of
them
is
like
somewhat
high
in
cardinality.
So
instead
of
the
default,
behavior
is
like
you
create
as
many
time
series
as
all
the
combinations,
but
you
can
create
like
two
views,
resulting
in
two
streams.
One
stream
would
take,
maybe
like
one
or
two
dimension
and
the
other
would
take
another
dimension
so
like
overall,
you
keep
your
time
series
and
memory
pressure
down.
B
So
I
believe,
like
all
of
these
things,
are
handled
like
right
in
the
like
instrument
creation
time
itself.
B
So
after
that
like
when
the
actual
recording
comes,
there
is
no
lookup
of
view
or
anything,
because
it's
already
like
I'm
using
the
word
soldering,
because
when
you
create
an
instrument,
you
already
soldered
it
with
all
the
config,
so
that
metric
is
already
created
at
the
instrument
creation.
So
any
anything
else
which
is
the
hot
path
where
the
actual
measurements
are
coming.
You
already
determined
how
we
are
going
to
aggregate
it,
how
we
are
going
to
which,
like
parameters
or
which
bounds,
are
you
going
to
use
for
it?
B
So
all
those
things
are
decided
statically
when
the
instrument
is
created.
So
that's
why
I
kind
of
like
this
design
but
yeah.
If
there
are
any
like
alternate
opinions
like
I'm
happy
to
listen
to
it.
B
Okay,
yeah
and
like
so
my
only
ask
is
just
look
at
the
view
config.
I
think
I
yeah
I'll
just
close
this
one,
because
this
is
where
I
actually
tried
implementing
it,
and
then
I
realized
okay,
it's
fairly
easy
to
do
the
actual
lookup
it's
only
affecting
the
sdk
class
and
maybe
like
slightly
spilling
over
like
in
other
classes,
but
it's
like
fairly
simple,
so
I'll
close
this
one-
and
I
will
mark
this
as
in
on
draft
so
as
to
see
comments.
B
Okay,
yeah
any
other
questions.
B
So
I'll
also
go
and
update
the
timelines,
because
we
we
have
like
missed
the
alpha
4,
because
I'm
still
trying
to
wait
for
riley
to
finish
the
reader
aspects
of
it
and
then
we'll
do
alpha
four,
probably
like
today
or
tomorrow,
but
we
should
still
be
able
to
do
the
beta
one,
because
all
we
need
is
this
feature,
which
should
be
like
very
easy.
B
As
long
as
everyone
agrees
on
the
public
ap,
so
we
should
still
be
able
to
do
it
by
end
of
this
month
by
which
means
next
friday,
all
right
any
questions.
Are
there
like
anyone
looking
to
contribute
and
like
like
looking
for
any
contributions,
and
you
are
like
out
of
ideas,
please
reach
out
to
me.
I
have
created
at
least
six
items
last
week,
but
I
do
have
like
plenty
of
other
things
in
the
metrics.
B
I
didn't
finish,
creating
it
and
like
a
lot
of
them,
I
have
marketers
like
help
one
dirty,
because
primarily
I
think
they
are
like
really
really
easy
for
anyone
to
on
board
as
well,
and
I
think
I
yeah
I
was
planning
to
mark
like
some
of
the
issues
as
good.
First
issue
things
which
require
like
really
like
very
minimal
knowledge
of
metrics.
B
So
if
you
are
like
looking
to
contribute,
please
either
ping
me
in
the
chat
window
in
the
slide
and
we'll
discuss,
even
though,
like
we
have
like
all
contributions,
the
thing
which
we
are
primarily
focusing
for
one
point:
two
is
the
metrics
really.
So
if
you
are
willing
to
offer
helping
metrics
that
would
be
appreciated.
B
Okay,
yeah,
so
that's
pretty
much
end
of
it.
Unless.