►
From YouTube: 2021-05-14 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
A
I
think
josh,
like
j
mcd
mentioned
he
might
not
be
able
to
join
because
preparing
for
some
celebration,
like
lifestyle
was
acquired
by
servicenow.
A
A
I
start
to
wonder
like
previously,
we
were
running
this
rotation
like
we
have
the
monday
meeting
and
the
next
week
it
will
be
afternoon
meeting
but
given
like
like.
We
have
a
lot
of
folks
in
europe
who
are
very
familiar
with
the
matrix
domain.
I
wonder
if
it
makes
sense
for
us
to
stick
with
the
the
like
the
morning,
pst
time
meeting,
so
just
switch
back.
A
B
I
mean
it's,
it's
fine
with
me.
I'm
sure
I
prefer
the
afternoon,
but
it
seems
like
our
chats
are
going
to
be
more
about
the
sdk
going
forward
than
the
api.
So
you
know
one
is,
I
probably
don't
even
have
to
be
involved
as
much
and
two
is
you
know.
Certainly
the
the
morning
can
work,
whereas
I
assume
for
the
europe
folks.
Our
afternoon
meetings
are
probably
a
pretty
big
pain
in
the
ass.
B
So
you
know
fine
by
me.
A
Okay,
let's
start
so
so
the
first
one
is
currently.
I
started
working
on
the
isdk
spike
and
the
first
pr
here
I
want
to
put
a
skeleton
and,
and
the
general
thinking
is.
I
want
us
to
start
from
the
essential
pieces.
For
example,
if
you
look
at
that
pr,
if
you
imagine
like
matrix
isdk,
is
a
car,
I'm
basically
saying
the
car
needs
to
have
an
engine,
I'm
not
even
saying
there
should
be
exhaust
pipe,
because
exhaust
wouldn't
make
sense
for
electric
cars.
I'm
just
saying:
they're
basic
building
block
were
two
concepts.
A
One
is
the
measurement
processor
which
handles
the
raw
data
and
then
it
can
do
aggregation
or
it
can
just
drop
the
data
on
the
floor.
Then
there
is
the
the
exhaust
part.
You
take
the
aggregate
data
and
you
can
process
that
and
in
the
processor
you
can
actually
decide
to
export
it
or
drop
it
on
the
floor.
So
I
I
wonder
if
I
can
get
more
review
and
comments
so
so
far,
I
think
the
all
the
outstanding
comments
have
been
addressed.
A
Besides
one
comment,
which
I
I
think
is
related
to
the
data
model
and
this
one.
The
question
here
is:
if
we
allow
multiple
pipelines
in
the
sdk
and
if
they
fork
at
certain
moment
and
eventually
they
start
to
join,
how
do
we
resolve
the
data?
For
example,
we
might
end
up
with
two
streams
that
are
coming
from
the
same
measurement
and
by
mistake
we
could
have
some
aggregation
that
tried
to
item
together
which
wouldn't
make
sense.
A
So
I
I
think
this
is
not
a
blocking
issue
for
the
for
the
skeleton
pr
itself,
but
it's
something
we
should
explore
more
in
the
isdk
implementation
and
also
the
data
model
part.
C
In
the
spec
skeleton
I
don't
know
exactly
how
detailed
it
needs
to
be,
but
it
does
seem
like
a
like
it's
an
important
thing,
for
example,
that
we
don't
can't
support
in
the
java
metrics
implementation
today
and
we're
going
to
have
to
think
about
how
we
do
that.
C
A
A
We
have
a
clear
understanding
that
we
should
support
that
right
and
if
that
two
exporters
they
send
data
through
some
agent
and
ultimately
those
agents
they
pipe.
The
data
to
the
same
collector
that
same
collector
will
see
data
like
two
different
streams
of
data
coming
from
the
same
source,
and
it
has
to
have
some
metadata
or
information
to
consolidate,
or
it
has
to
screw
up
the
data
right
if
they
take
the
same
data
and
fork
it
and
eventually
add
them
together
and
tell
people.
This
is
the
total
count.
A
It
won't
make
sense,
and
I
think
that
problem
is
much
bigger
than
the
isdk
and
and
even
for
tracing.
I
think
we
have
the
same
problem.
You
have
two
exporters
export
the
same
trades
with
the
same
span
id
and
trace
id
to
an
agent,
and
the
agent
is
trying
to
merge
them.
Then
you
will
have
to
handle
those
problems.
A
So
this
is
why
I
tend
to
think
this
is
out
of
the
like,
at
least
I
don't
think
this
is
a
blocking
issue.
This
is,
I
agree.
This
is
a
very
good
question
and
this
implication
detail,
and
we
should.
We
should
have
a
clear
understanding
instead
of
just
ignoring
the
problem,
but
I
my
body
is:
if
you
try
to
get
to
the
bottom
of
this,
it
will
take
very
long
time
and
even
for
tracing
I
I
don't
think
we
have
a
like
ever
reached
the
bottom
of
this
problem.
A
D
D
It
is
about
having
a
like
multiple
pipelines
like
you
will
have
the
stream
of
measurements,
the
measurement
processor
and
so
on.
The
exporter
like
everything
multiple
times,
because
you
want
to
export
them
like
into
multiple
backends
right,
because.
A
A
Is
I'm
just
listening
waiting
for
permissions
to
pull
the
data
and
the
problem
is
they
might
end
up
sending
it
to
the
same
collector
at
some
point
and
start
to
join
the
data,
and
I'm
saying
is:
this
is
a
very
good
problem
and
we
need
to
at
least
give
some
suggestion
and
have
a
like
at
least
cover
some
common
cases,
but
so
my
audience
this
one
is
going
to
take
a
very
long
time
and
I
don't
even
think
we
have
it.
We
have
a
good
solution
for
the
tracing
part,
so
my
question
so.
D
What
I
was,
what
I
would
suggest
is
try
to
come
up
with
an
abstraction
that
represents
this
whole
pipeline,
like
the
processor
and
exporter
together,
and
basically,
you
will
just
send
metrics
to
multiple
of
these
yeah
and.
A
I
believe
we
have
that.
So
if
you
look
at
the
example
here,
I
don't
know
how
how
to
hide
this
comment.
So
you
can
have
one
meter
provider
and
multiple
instruments
and
some
instruments
go
a
one
processor,
the
others
go
to
a
different
processor
and
and
they
can
go
to
the
different
explorers.
A
Model
in
the
isdk,
but
regarding
the
case
like
the
data,
would
eventually
join,
and
how
do
we
resolve
that?
I
think
that's
implementation
detail
and
it's
a
good
thing
we
should
cover,
but
I
I
don't
think
necessarily
it's
a
blocking
issue
for
this
pr.
D
By
the
way
in
micrometer,
this
is
the
this
is
the
composite
meter
registry.
So
you
have
a
composite
registry
which
has
like
multiple
registries
in
it.
So
when
your
instrument
publishes
something
it
publishes
to
the
composite
and
the
composite
will
do
the
2d,
the
like
put
the
data
into
multiple
registries
and
the
registries
do
whatever
they
want
to
do.
D
A
A
One
for
each
process:
that's
because
in
memory
you
can
have
you
can't
have
two
in
memory
state,
but
ultimately
you
can
still
consider
it
with
one.
So
I'm
I'm
trying
to
just
draw
one
state
by
by
giving
that
flexibility.
So
if
you
want
to
do
optimization,
they
might
be
able
to
share
something.
But
it's
not
necessarily
say
you
must
share
something
in
that.
In
that
single
box,
you
can
have
separate
things
that
are
disjoint
and
each
I
mean
the
same.
Like
repeatedly,
you
mean
sharing
data
between
like
two
exporters
yeah.
A
So
let
me
give
you
one
example:
if
you
try
to
export
every
one.
Second,
another
exporter
is
trying
to
export
it.
Every
one
minutes
like
by
default.
You
might
go
with
the
safe
approach,
you
just
duplicate
the
effort
and
they
don't
share
any
anything.
Later
you
might
say,
oh
if
I
already
agree
every
one.
Second,
I
can
probably
do
something:
smart
add
additional
metadata,
so
I
can,
I
can
do
a
further
aggregation.
Then
I
can
save
some
calculation.
A
I
want
like
the
way
I
draw
this
is
I
want
to
make
sure
there
is
a
possibility,
instead
of
I
enforce
that
there
must
be
an
isolation,
each
one
can
have
no
relationship
or
interference
with
the
other
components
that
make
sense,
and
ultimately
you
might
receive
it's
still
like
on
the
address
space
of
that
process.
So
this
is
my
thing,
but
if
it's
confusing,
I
I
can't
add
more
clarification.
Yeah.
B
I
I
think
what
would
what
would
seem
intuitive
to
me?
Is
you
sort
of
draw
the
box
diagram
kind
of
the
way
you
expect
people
to
logically
think
of
it,
which
I
would
think
is
multiple
in
memory
states
and
then,
if
you
want,
you
just
put
a
little
asterisks
and
you
say:
look
it's
an
implementation
detail.
Whether
or
not
multiple
boxes
on
this
diagram
find
clever
ways
of
sharing
some
memory
under
the
hood
and
that
makes
them
more
efficient,
like
and
but
architecturally.
Hopefully,
that
doesn't
matter
like
from
an
architecture.
B
A
B
Okay,
cool,
but
also
for
your
for
your
split
join
thing.
I
I
do
think
you
probably
I
mean
I
think
the
split
is
architecturally
important
because
you
like
you,
definitely
want
to
show
like
look
here's
how
we
could
support
multiple
exporters,
I'm
not
convinced
the
join
is
so
important.
I
mean
yes
in
principle.
It
could
come
back
together
at
some
point,
but
I
don't
know
how
common
that
would
be.
B
B
If
that
means
you
have
a
processor
that
has
like
a
sequence,
number
counter
of
like
everything
that
goes
through
it,
and
so
you're
tagging
every
bit
of
information
with
a
counter
and
then
later
you
can
match
those
counters
back
up
if
they
ever
were
to
meet
like
that's
one
way
of
doing,
split
and
join,
but
in
practice
I'm
guessing
that
people
just
avoid
joining
because
it
turns
into
a
big
mess.
Yeah,
there's
definitely.
C
Cases
there
are
definitely
cases
where
you
cannot
actually
join
yeah,
because
you've
you've
done
dimensional
reduction
in
two
different
ways,
and
then
you
don't
have
a
way
to
de-dimensionally
reduce
in
your
pipeline
in
your
life.
Unless
your
joining
is
only
further
producing
and
even
then,
it
won't
be
possible,
depending
on
how
the
the
dimensions
that
are
being
reduced.
D
Also
from
the
from
the
api
perspective
to
me
as
a
user,
I
I
would
assume
that
one
exporter
has
nothing
to
do
with
the
with
the
other.
To
me
they
are
basically
like
different
entities
working
completely
differently.
They
don't
really
have
any
anything
to
do
with
with
each
other.
So
as
an
api
user,
I
that
would
be
weird
to
me
a
little
bit,
but
I
can.
D
I
can
see
the
the
justification
of
the
optimization
if
it
is
possible
at
all.
A
E
A
B
A
Yeah
yeah,
if
I,
if
I'm
going
to
change
this
in
memory
state
to
multiple
boxes,
I
I
think
each
box
will
be
able
to
have
multiple
metric
processors
here
and
and
and
probably
we
can.
We
can
avoid
this
problem
for
now
by
saying
this
is
a
single
metric
processor
and
the
people
want
the
composite
one
they
can.
They
can
have
one
that
just
broadcast
or
like
college
underlying
process
like
one
by
one.
A
D
This
this
diagram
to
me,
it
makes
like
a
little
bit
more
sense
like.
Basically,
this
is
what
we
we
want
to
do.
This
is
this
is
the
goal
right
that
we
can
have
like
multiple
exporters
and
the
exporters?
Each
of
them
can
have
a
processor.
D
Yeah
but
but
right
now
the
sdk
support
or
the
specification.
Let's
us
do
this
right.
A
Yeah,
so
these
are
the
minimum
thing
I
I
I
could
imagine
to
to
keep
us
moving
to
the
next
step.
I
I
think
once
we're.
Okay
with
the
skeleton
here,
we
can
hammer
out
the
detail.
For
example,
we
can
say:
oh
we
realized
in
the
measurement
processor.
We
have
many
reusable
components.
For
example
the
aggregator
like
we
might
decide,
okay,
the
sum
and
some
like
distribution.
A
Those
components
might
be
reused,
let's
introduce
more
concepts,
but
what
I'm
trying
to
say
here
is
the
like.
Basically,
this
is
a
car
and
we
need
to
have
the
wheel.
We
need
you
have
the
engine
and
later,
if
we
figure
out,
oh
the
engine
needs
to
have
exhaust
pipe
or
it
has
spark
plug
for
gasoline
cars.
A
I
think
we
can
add
that,
but
as
long
as
there's
an
engine,
we
should
be
able
to
move
forward
and-
and
I
just
want
to
draw
the
car
picture
with
the
engine
placeholder
so
later
we
split
the
work
and
people
do
the
prototype.
Individuals
can
come
and
and
tackle
a
particular
part.
So
we
can
divide
and
conquer
the
problem.
A
G
You
you
mentioned
something
very
good
which
is
after
we
do
some
prototypes,
we'll
learn
more
and
stuff.
I
think
that
should
be
a
clear
goal
of
the
document
stated
at
the
top
of
the
document
that
hey
this
is
only
for
prototyping
and
it's
not
the
final
state
of
how
things
will
look
like
oh
yeah.
It's.
A
A
A
Okay,
so
so
please
help
on
this,
and
I
want
to
make
sure
we
can
make
progress
on
getting
the
skeleton,
and
it's
important
is
that
so,
after
that,
we're
able
to
divide
and
conquer
different
people
can
help
on
different
sections,
and
I
want
to
take
a
step
on
the
view.
Api
part.
The
reason
I
think
view
api
will
be
the
next
pr
because,
after
we
have
the
view,
api
we're
going
to
go
back
and
talk
about
the
hint
api
which
will
be
part
of
the
api
spec.
A
This
is
why
I
want
to
prioritize
this
so
for
view
api.
What
I
I
currently
did,
as
I
was
primarily
looking
at
some
of
the
open
telemetry
prototypes,
like
we
have
in
the
sdk,
and
also
what
we
have
in
the
open
sensors,
because
the
view
the
first
time
I
heard
about
the
view
concept
was
when
I
worked
on
open
census
python.
So
these
are
some
questions
I
have,
and
I
want
to
get
the
rough
idea.
A
The
reason
I
don't
have
a
pr
is
because
I
I'm
a
little
bit
blocked
on
the
skeleton,
so
once
this
got
merged
I'll
be
able
to
send
the
pr
for
review.
Otherwise
it
will
be
very
messy.
So
I
I
think
the
vo
api
will
need
to
allow
people
to
define
the
wheel
by
describing
hey,
I'm
define
the
view
based
on
some
existing
instrument,
so
they
will
provide
the
instrument
name
and
they
can
define
for
this
particular
instrument.
A
I
only
need
three
attribute
keys
for
all
the
other
action
fields.
I
can
remove
them
because
I
don't
want
to
pay
for
the
cost
of
calculation
and
storage
and
transformation
and
and
they
they
might
also
need
to
provide
a
view
name
as
an
identifier,
and
I
I
guess
by
default-
probably
it
can
be
the
same
just
in
harris,
but
we
can
discuss
more.
It's
not
not
super
critical
and
they
can't
have
a
real
description
similar
to
probably
becoming
higher,
and
the
most
interesting
part
is
they
have
to
specify
which
attribute
keys.
A
A
So,
for
example,
do
we
allow
unit
to
be
provided
like
if
you
have
a
for
example?
Here
I
have
an
instrument
from
mongodb.
This
is
still
written
and
the
unit
is
milliseconds.
Do
you
imagine
there
will
be
a
common
scenario
where
people
say
hey?
I
have
a
view,
but
I
want
to
change
the
unit.
My
answer
would
be
no.
F
A
G
That's
what
I'm
saying
that
it
should
be
derived
from
the
initial
unit
class
plus
the
aggregation,
because,
for
example,
if
the
aggregation
does
something
like
a
rate,
it's
gonna.
F
G
D
H
A
G
D
Also
is
my
understanding
correct
that
views
are
basically
like
the
view
api
lets.
You
redefine
the
meaning
of
the
instrument,
for
example,
you
can
create
a
gauge
from
a
counter,
or
vice
versa,
or
a
distribution.
Okay,
because.
D
I
A
Okay,
so
take
this
as
a
as
one
example:
you
have
a
mongodb
client
and
you
report
duration,
and
you
have
two
attributes:
the
the
host
and
the
port
and
from
the
customer.
They
only
want
host,
they
don't
care
about
the
port,
so
they
can
define
a
view
and
say
I
want
milliseconds
and-
and
this
is
the
histogram
and
I
want
the
host
as
the
only
dimension-
that's
what
we
want
to
achieve
in
the
deal
and
you
can.
A
Define
the
aggregation
among
they
might
want
to
say,
hey,
you
have
a
counter,
but
for
me
I
don't
need
a
counter.
All
I
need
is
a
distribution
and
and
and
for
distribution
they
want
to
give
you
some
bucket.
They
won't
say
it's
a
it's
a
linear
bucket
or
something.
So
these
are
what
I
call
the
aggregation
they
might
change,
aggregation
and
and
by
certain
type
of
aggregation
they
might
give
you
details
how
they
want
to
aggregate
like
the
histogram
buckets.
G
A
Yeah,
I
I
think
each
attribute
key
probably
will
carry
some
metadata
and
I
agree
with
you
both
then
I
I
think
we
we
need
to
have
that
flexibility
to
specify
where
it
should
be
coming
from,
and
I
also
want
to
make
it
flexible
so
in
in
like
later,
we
might
add
additional
indication
here,
for
example,
we
might
say
hey.
This
is
a
dimension
that
I
can
only
pay
for
like
10
combinations,
if
anything
more
than
10
I'll,
just
drop
like
first
thing.
First
out
or
something
like
that.
Wait
avoid
explosion.
F
A
Yeah,
so
currently
I
I
I
think
if
we
we
allow
the
attribute
key
to
carry
some
additional
information
to
see
whether
it's
coming
from
baggage
or
contacts
and
later
we
can
use
the
same
mechanism
to
add
additional
things.
I
could
imagine
we
can
add
some
additional
view
by
limiting
the
cardinality
or
by
forcing
certain
type
we
can
say
like
if
this
is.
G
F
F
Or
filter
only
for
value
equals
10..
So
so
as
an
example
in
your
case,
in
net
peer
host
and
let
the
airport-
and
you
may
say
only
where
net
tier
4
equals
80.
A
F
So
I
I
can
try
to
remember
all
the
usbs
we
have
for
this,
but
I
know
it
was
common
use,
so.
I
A
A
Okay.
I
have
my
next
question,
which
I
struggle
a
lot
so
so
here
when
I
mention
instrument
name,
I
haven't
heard
a
lot
of
questions,
but
if
you
think
deeper,
you
will
have
a
lot
of
questions.
So
let
me
give
you
a
scenario:
you
have
one
meter
provider
and
you
have
two
different
versions
of
the
the
meter.
They
have
the
same
name
but
different
versions
and
then
even
trying
to
make
it
worse.
A
You
have
a
malicious
library
in
your
application
that
that
is
also
using
the
same
instrument
name
and
according
to
our
current
api
spec.
Each
like
each
meter
should
not
have
the
the
same,
like
name
used
by
multiple
instruments.
It
will
only
have
one,
but
in
this
case
it's
perfectly
fine
because
they
belong
to
different
meters
and
you
have
no
control
so
we'll
end
up
with
three
instruments:
they
have
the
same
name
and
the
the
first
two
are
probably
the
legal
ones.
A
A
You
can
actually
pick
the
the
meter
name
and
version
which
I
I
think
it's
the
wrong
direction,
or
we
tell
people
when
you
define
the
view,
it's
always
going
to
tie
it
to
the
instrument
name
and
if
you
have
multiple
instruments
that
sharing
the
same
name
but
different
version,
the
view
will
be
applied
to
all
of
them
and
we
don't
give
you
a
way
to
select
like
some
of
them
and
in
this
malicious
situation.
A
G
Sense
for
me
for
me,
I
think
it
makes
more
sense
if,
instead
of
meter
name,
we
have
a
instrument
name.
We
have
a
instrument
selector,
which
has
the
capability,
for
example,
to
specify
an
instrument,
a
meter
name
plus
a
version
or
a
regex
for
that
and
so
on
and
so
forth.
So
so
I
think
this
is
how
we
did
it
in
java,
based
on
a
very
good.
I
think
john
actually
did
it,
and
he
did
it
very
nicely
so
having
the
instrument.
A
Yeah,
okay,
that
that
sounds
a
little
bit
complicated,
but
I
can't
imagine
how
that
work
and
and
one
want
to
ask
for
feedback
what
are
the
input
for
the
selector?
I
can
imagine
there
are
many
things,
so
let
me
write
it
down
the.
A
So
we
mentioned
the
instrumentation
library
info.
I
assume
you
mean
the
name
of
the
meter
right.
A
Meter
name,
meter
version
name
type
of
the
instrument
yeah
in
the
type
of
the
instrument,
or
what
we'll
just
say
is
the
instrument
itself.
So
it
is
the
the
instrument
instrument.
C
A
I
see
so
you
won't
be
able
to
do
like
some
of
the
rules
based
on
them
and
so
so
john,
I
think
that's
the.
H
A
G
I
would
not
do
that
for
two
reasons
if
we
want
to
have
a
portable
definition
of
these
views.
So
if
you
want
to
have
a
yamaha
definition
of
this,
you
you
need
to
have
to
to
to
know
if
you
support,
blobs
or
or
regrets,
because
people
will
write
something
and
they
expect,
even
if
that
is
loaded
by
a
python
app
or
buy
a
buy,
a
java
app
to
work.
A
I
see
I
I
think,
that's
still
possible.
If
you
allow
people
to
give
callback
function,
then,
on
top
of
that,
when
you
load
some
configuration,
you
can
convert
that
and
and
do
a
function
check
right.
But
if
you,
if
you
start
from
enforcing
like
everyone,
must
car,
if
people
want
to
have
additional
things,
for
example,
they
won't
have
some
like
dynamic
configuration
and
which
is
not
wild
card.
They
won't
have
some
like
something
that
wild
card
cannot
simply
explain.
G
A
For
example,
I
see
and
and
do
you
think,
loading
regular
expression
or
something
like
you
can,
for
example,
the
version
part
you
can
either
use
the
wild
card
or
you
can
use
semantic
version
and
give
people
the
comparison
like
greater
than
or
equal
to.
I,
I
guess
it
might
be
too
much
so.
G
A
Okay,
so
I
I
can
start
by
making
it
a
little
bit
loose
and
either
to
do
comment.
We
can
hammer
out
the
details
later
sure.
G
C
You
I'm
just
I
mean
so
riley's
definition
of
a
view
here.
Has
the
attribute
keys
being
configuration
and
I'm
curious
about
why.
G
Actually,
in
open
senses
was
a
bit
more
open-ended
and
you
you
had
to
have
that
required
because
there
was
no
such
separation
of
labels
added
to
the
call
versus
labels
from
the
tags,
aka
baggage,
so
we
didn't
want
to
put
all
the
baggages
that
way.
That's.
Why
was
required,
but
I
think
in
this
case,
where
we
have
clear
separation
and
clear.
G
A
I
I
see
the
reason
I
put
it
as
required.
I
was
thinking
if
people
don't
put
anything,
I
give
them
a
convenience
and
by
default
I'll
just
aggregate
everything
all
up,
so
it
will
be
a
single
value
but
like
what
john
described
also
makes
sense
to
me.
A
C
Completely,
but
I
guess
I
guess
the
reason
why
I'm
curious
about
it
being
required
is
that
if
I
don't
specify,
if
I
don't
add
a
view,
I
get
a
default
behavior
right,
I
get
a
behavior
yeah
doing
something.
Something
happens.
If
I
don't
add
a
view
right
and
if
I.
C
G
C
Some
of
the
what
this
this
makes
me
think,
and
I
think
josh
had
brought
this
up
during
when
we
discussed
news
many
months
ago
that
maybe
what
the
maybe
the
design
for
I
don't
know
if
it's
part
of
the
sdk
design
or
what
exactly
exactly
where,
but
that.
Basically,
there
is
a
default
view
associated
with
every
instrument
and
then
that
default
view
just
has
the
defaults
in
it,
and
then
people
can
override
that
yeah
yeah.
So
exactly.
A
C
C
Somebody
yeah
some
way
to
select
an
instrument
for
sure
yeah.
Let's
just
change
it
here
I
mean
I
in
the
in
the
design
that
I
implemented
in
java,
the
prototype
basically
described.
There
was
two:
there
was
separation
of
two
things.
There
was
the
instrument
selector
and
then
there
was
the
how
you
what
you
actually
want
to
do
with
the
measurements,
so
those
were
kind
of
the
two
pieces
of
configuration
that
went
into
a
view
so
one.
C
A
Okay,
cool,
I
I
I
think
I
got
all
the
all
the
top
questions
answer
so
once
the
the
skeleton
pr
got
merged,
I
should
be
able
to
send
a
pr
cover
that
very
quickly
thanks
everyone
and
then
there's
a
question
from
from
josh,
but
he's
not
here.
I
guess
and
I
I
don't
think
I
fully
understand
what
he
he
wants
to
say
here.
So
unless
someone
has
a
good
understanding,
otherwise
I'll
propose
we'll
put
it
in
the
next
meeting
or
I'll,
follow
up
with
josh
and
clarify
you
can
follow
up
on
the
slag.
D
A
C
Zhang
yeah,
so
I
just
wanted
to
ask
a
question
whether
we
could
think
about
the
possibility
of
stabilizing
the
api
specification
before
the
sdk
specification
was
complete,
which
would
enable
language
implementations
to
publish
a
stable
api
that
could
then
be
instrumentation
could
be
written
against
and,
for
example,
the
java
tracing
sdk
wants
to
do,
wants
to
record
metrics
about
the
actual
behavior
of
the
sdk
itself,
and
even
if
we
don't
have
a
stable
sdk
having
a
stable
api
would
allow
people
to
start
writing
instrumentation.
C
A
A
If,
in
general
we
want
to
push
that,
I
have
one
question
and
if
we
can
confirm
that
I
I
can
spend
more
time
just
to
push
the
api
to
be
stable
as
early
as
possible,
and
I
agree
with
you
jump.
I
think
the
api
and
sdk
they
can
have
a
different
rhythm
api
can
go
faster
than
the
ick.
So
my
question
is:
are
we
okay
with
releasing
a
stable
matrix
api
without
the
the
hint
part?
G
That
that
all
the
api
should
support,
adding
additional
parameters
or
whatever
is
the
thing
I
think
we
should
be
fine.
A
Yeah
we
already
have
that
so
we're
fine.
It's
just
like
do
people
think
we
should
just
wait
for
a
couple
weeks
to
have
the
hint
api
hammered
out.
Then
we
do
the
api
release
or
you
just
think
like
releasing
the
api
earlier
with
the
current
state
would
unblock
many
work
streams.
You
have
it's
more
like
the
the
pros
and
cons.
Technically,
it's
all
possible
either
way.
It
isn't
the
same
thing
through
4d
for
the
view
api
as
well
view.
Api
is
not
part
of
the
api,
it's
the
sdk.
D
A
For
the
for,
for
for
for
view,
view
will
be
specced
out
in
the
right
part,
because
this
is
the
application.
Okay,
that's
what
you
want,
but
we
also
want
to
take
the
learning
from
the
view
and
go
back
to
the
api
and
say
the
library
developer.
They
want
to
give
some
hint
to
the
food
application
developers,
so
application
developer
can
say.
I'm
lazy.
I
just
want
to
take
the
default
recommendation
like
I
know
the
library
is
providing
10
dimensions,
but
I'll
just
take
the
default
dimension
that
the
epa
library
developer
would
recommend
me
so
yeah.
G
Personally,
I
think
once
we
once
we
spec
out
the
view
we'll
have
a
much
better
understanding
of
the
hints
that
we
want
or
we
don't
want
from
the
library
developers.
So
that
being
said,
I
think
I
think
if
you
want
to
wait
for
hint,
you
have
to
wait
for
almost
everything
to
happen.
So
so
I
I'm
fine
with
releasing
now
everything
with
the
caveat
and
maybe
a
comment
saying
that
hey
during
the
apa
api,
the
instrumentation
creation
time
user
may
provide
other
optional
options.
So
then,
then,.
H
A
A
Anyone
disagree,
please,
please
jump
out
right
now
and
and
I'll
I'll
bring
this
topic
to
the
tuesday
meeting,
but
the
default
like
recommendation
from
this
stick
is
we
want
to
move
forward
on
the
api
part,
okay,
yeah,
and
thank
you,
john
for
calling
that
out.
I
I
also
thought
about
this,
but
I
I
decided
in
autocad,
and
so
so
thank.
C
G
G
A
If
not,
then,
then
my
ask
please
take
the
six
minutes
to
reveal
the
skeleton
pr
and
either
block
it
and
tell
me
what's
the
blocking
issue
or
give
me
approval,
so
we
can
move
forward
and
thank
you.
Everyone,
thanks,
riley
see
you
next
time.