►
From YouTube: 2022-02-08 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
C
D
It's
been
reviewed
a
couple
of
times
and
I
think
it's
it's
getting
to
a
good
point.
I'd
love
to
get
some
actual
additional
review
and
any
many
points
of
view
on
this.
E
E
D
Thank
you,
yeah
no
worries
and
it's
not
waiting
on
tigran,
yes,
tigran
is
has
been
very
kind
and
you
know
provided
some
feedback,
as
the
others
also
did,
and
thank
you
for
all
that.
That's
really
helpful,
but
yeah
everybody
please
review.
Please
give
it
a
give
it
a
go.
It's
in
a
very
early
experimental
state
which
is
good.
This
is
the
time
for
you
to
bring
in
everything.
You
have
every
piece
of
review
anything
any
thought
before
it
gets
crystallized
way
too
way
too
early,
and
then
you
regret
the
decisions
we
make.
D
So
this
is
why
I
bring
it
up
and
please
by
all
means
review.
C
C
Okay,
the
next
item.
Yes,
you
want
to
add
something.
No
just
assume.
Thank
you!
Perfect.
Okay,
moving
forward,
tigran
review,
tracer
meter,
library,
name,
scope,
name,
proposal.
E
Yes,
there
I
made
some
amendments
to
the
pr
this
one
has
been
open.
I
guess
most
of
the
people
here
in
the
school
already
heard
it
once
I
just
wanted
to
bring
attention
to
the
fact
that
there
were
changes
to
the
to
the
pr.
E
If
you,
if
you
reviewed
it,
if
you
approved
it,
please
have
another
look.
I
linked
specifically
to
the
commit
which,
which
is
the
delta
between
what
it
was
and
what
it
is
now.
E
C
F
C
It's
looking
better,
so
I
would
suggest
we
try
to
merge
it
tomorrow
unless
there's
some
specific
complaint
you
know
or
some
issue
to
be
addressed,
but
unless
there's
something
very
specific,
after
all
the
review
and
all
this
effort
that
has
taken,
I
suggest
we
emerge
it.
So
please
anybody
there's
something
against
that.
Please
raise
it
today,
otherwise,
tomorrow,
let's
use
merchants.
There
are
enough
reveals
that
stickers
mentioned.
So
we
should
go
back.
E
I'd
like
to
make
sure
that
maintainers
also
take
a
look
at
this.
This
is
not
just
a
spec
issue.
It
will
have
consequences
in
changing
some
of
the
existing
code.
The
way
that
it
is
written
supposedly
should
not
be
a
breaking
change.
I
would
like
the
maintainers
to
confirm
that
it
is
not,
and
if
they
see
any
chance
for
this
to
be
a
breaking
change
in
the
api,
then
we
need
to.
We
need
to
rework
that
that
part.
C
Okay,
thank
you
so
much
for
that,
thanks
so
much
for
the
patience.
Okay,
the
next
point:
tigran
proposal
to
remove
experimental
metric
service
configuration
from
protos.
E
Yeah
this
one
has
been
living
in
the
proto
repository
for
quite
some
time
now.
It
was
added,
I
think,
more
than
a
year
ago,
and
I'm
not
aware
of
any
implementations
that
actually
use
it.
It
was
never
refined
kind
of
it.
It
was
added
and
stayed
there
now
it's
something
that
we
need
to
maintain
because
it
it
broke
one
of
the
changes.
Actually
I'm
unrelated,
but
changing
the
in
the
build
tools.
E
So
armin,
I
believe,
raised
the
the
question
whether
we
actually
need
it
or
no,
and
I
think
I
agree
with
him-
it's
probably
not
necessary.
So
the
proposal
is
to
remove
this.
E
I
I
wanted
to
give
a
chance
to
object
to
anybody
who
actually
uses
it.
I
am
not
aware
of
any
usage,
but
maybe
there
is
some,
and
if
there
is
then
we
probably
shouldn't
be
doing
this
so
lightly,
so
I'll
keep
it
open
for
a
while
and
if
anybody
has
any
thoughts
on
this.
Please
comment
on
the
pull
request.
There.
C
Perfect,
thank
you
so
much
for
that.
So
the
metrics
group,
if
you
could
confirm,
I
see
a
pair
of
reviews
already
so
looking
good
but
yeah
just
in
case.
Let's
wait
a
little
bit
more.
Thank
you.
Okay.
Next
item
johannes
state
of
the
pr
for
adding
links
after
spam
creation
you're
around
johannes.
Yes,
yes,.
G
I'm
around
I
brought
this
issue
up
in
this
meeting.
I
think
three
weeks
ago
about
the
allowing
to
add
links
after
spank
creation.
There
were
there
was
not
much
pushback
or
concerns
or
put
up
the
pr.
G
I
think
those
concerns
were
addressed
also
by
joshua,
so
it
would
be
yeah
great
if,
if
some
other
people
could
have
could
have
an
eye
on
this
pr
and
see
if
there
are
any
any
concerns
left
or
if
you
think
that
yeah
by
the
discussion
that
is
present
there,
those
concerns
have
been
addressed
and
and
if
there
is
any
concerns
left,
maybe
it
would
be
great
to
kind
of
get
an
idea
about
the
path
forward
with
this,
because
we
are
a
bit
blocked
by
this
being
an
open
question
in
the
in
the
messaging
work
group,
whether
we
can
work
with
edikings
after
span
creation
or
not.
C
Before
bogdan
jumps
in
in
case
he's
around
in
the
call,
I
wanted
to
mention
that
my
my
impression
is
that
you
would
be
presenting,
like
the
instrumentation
group,
some
more
comprehensive
document
or
summary,
because
tev
ted
young
mentioned
in
a
comment
that
it
could
be
helpful
for
the
messaging
seek
to
produce
a
clear
presentation
of
these
new
proposed
models.
So
probably
that's
what
we
were
waiting
for,
but
anyway,
in
any
case,
I
see
also
a
follow-up
from
ajon
who
basically
provides
a
rather
complete
explanation
of
a
specific
point.
G
C
If
we
have
to
present
it,
yes,
I
mean
it
could
be.
I
don't
know
whether
we
will
have
time,
but
if
we
have
time
today
it
would
be
nice
that
you
could
present
it
today,
if
not
next
week,
but
in
general
I
would
say
that
we
should
be
able
to
present
something
like
a
summary
or
document
or
something
that
works
as
a
reference
in
case
you
know,
let's
say
that
book
that
is
not
hearing
the
call
or
or
let's
say
that
armin
has
some
complaint
so
yeah.
We
have
to
do
a
lot.
C
C
C
Okay,
perfect,
thank
you
so
much
for
the
sorry
for
the
delay.
Yeah,
the
next
point.
Okay,
now
it's
metrics
time
yeah!
I'm
glad
that
we
will
have
enough
time
to
discuss
a
lot
of
items.
Riley
do
you
want
to
drive
this
part.
H
So
the
first
ask
is:
please
review
the
pr
which
is
marking
the
sdks
mixed
and
stable.
If
you
see
any
blocking
issue,
please
call
I'm
using
this
api
to
collect
the
idea
like
how
many
items
we
need
to
prioritize
before
we
can
mark
the
isdk
as
stable.
So
if
you
think
there's
a
blocker,
you
should
call.
H
H
I
I
think
we're
not
ready
to
make
that
a
stable
part
of
the
api.
So
my
suggestion
is:
we
should
leave
that
as
experimental
and
and
give
the
language
six
some
time
to
experiment
with
it,
and
I
also
cut
out
some
of
the
concerns.
One
thing
is:
we
probably
need
to
look
forward.
We
have
a
goal.
Eventually,
the
matrix
api
will
need
to
add
a
hint
and
it's
hard
to
imagine
how
we're
going
to
do
that
if
we
allow
this
vr
to
get
merged.
I
You
have
any
I'm
curious
more
about
this
hint
idea
of
yours,
because
I
want
to
present
to
the
group
that
the
reason
why
this
pr
seems
so
big
and
so
late
in
the
game
is
that
we're
not
comfortable
implementing
the
api.
That's
there
today
in
some
of
these
depositories
and
so
we're
we're
stuck
in
a
place
where
I'd
rather
change
the
api
than
implement
it
actually.
And
if
we
get
to
this
discussion
about
oh
well,
yeah
this,
you
know
multiple
observations
from
one
callback.
That's
honest!
I
If
I
have
to
work
around
that
in
my
own
code
to
make
five
observations
from
five
separate
callbacks
and
to
do
that
efficiently,
I've
got
to
invent
some
stuff,
there's
going
to
be
some
concurrency
questions
and
then,
at
the
end
of
the
day,
we
won't
even
know
if
my
observations
make
it
to
the
same
metrics
reader.
At
the
same
time,.
H
H
I
And
if
it,
if
you
ask
me
what
we
want,
what
we
should
do,
I
think
it's
the
views,
spec
entirely,
that's
causing
this
trouble
and
I
would
have
been
much
happier
if
we
could
have
gotten
to
a
kind
of
1.0
without
views.
That's
that's
always
been
the
case,
so
here
we
are
and
we're
sort
of
stuck
with
views.
I
We
haven't
implemented
views
and
we
can't
implement
views
because
we
don't
like
the
api
that
we're
facing
there's
like
all
kinds
of
problems.
That's
played
still,
so
I
think
calling
the
whole
sdk
stable
is
perhaps
a
mistake.
Now
if
we
can
solve
these
problems
and
everyone
there
would
stop
being
so
much
dissent.
I
think
that
we
could
begin
to
think
about
stable.
H
K
I
mean
riley,
you
have
to
understand.
Also
like
I
get
you
like.
That's
not
a
really
good
idea,
and
maybe
we
should
go
through
some
sort
of
like
vetting
period,
but
the
opposite
is
also
true
so
like
what
josh
is
describing
is
in
the
go
language.
The
api
that
was
rushed
to
be
stable
does
not
work
so,
like
you
know,
we
have
a
problem
there.
K
So
if
we
want
to
actually
get
something
out
in
the
go
language
for
the
api,
that
is
somewhat
idiomatic
like
somewhat
idiomatic,
that
users
won't
just
throw
their
hands
up
and
say
I'm
not
using
this
like.
We
need
these
changes
so
like
how
that
how
that
time
period
looks
is,
is
something
I
think
we
can
discuss,
but
if
you
also
take
into
account
that,
like
we're
going
to
block
this,
because
we
have
another
theoretical
thing
called
the
hint
api
that
we
want
to
add
eventually
into
the
future,
that
doesn't
seem
reasonable
to
me.
L
H
J
What
does
it
mean
for
a
language
to
to
implement
it
because
I've
prototyped
it
in
java?
But
we
can't
merge
it
and
release
it
as
part
of
our
api,
because
our
api
artifact
is
stable,
and
so
we
can't
publish
an
experimental
portion
of
that.
Yes,
you
release.
J
I
think
the
java
sig
might
be
open
to
having
a
release
candidate
for
this
behavior.
That
would
allow
us
to
vote
the
behavior
yeah.
L
That
sounds
reasonable
would
would
doing
that
block
further
releases
of
the
stable
api,
though,
like
my
question
is,
is
this
something
that
we're
going
to
have
to
commit
to
stabilizing
quickly
or
backing
away
from.
A
I
mean
java
doesn't
have
any
concept
of
releasing
an
api
artifact,
that's
partially
stable,
like
what
we
release
is
stable
and
we
provide
guarantees,
as
are
defined
in
the
specification
around
what
that
stability
means
and
if
we
had
to
release
a
release
candidate
and
then
sit
on
it
for
some
indeterminate
amount
of
time
and
not
release
anything
else
period
until
that
was
stabilized.
I
don't
think
that
would
be
acceptable.
J
I
So
there
has
been
some
debate
in
my
pr
and
I
I
think
it's
worth
visiting
you
know
we
we
don't
seem
to
have
any
solution.
That's
perfect
for
the
case
when
there's
multiple
instruments
registered
and
different
vendors
are
going
to
see
this
different
ways.
So
it's
worth
reading
through
the
feedback.
The
one
of
the
big
ideas
that
comes
out
of
it
is
that
views
can
help
us.
I
It's
actually
the
first
application
for
reviews
that
I
particularly
see
as
potentially
viable
like
I,
I
would
be
much
happier
if
we
had
released
sdks
and
my
users
could
just
take
them
and
start
reporting
metrics.
I
don't
need
views.
I
just
need
metrics
to
start
flowing,
but
here
we
are
talking
about
a
good
use
for
views
which
is
to
correct
all
these
conflicts,
and
it's
worth
thinking
about
that.
But
that
is
something
I
don't
want
to
rush.
I
H
Yeah,
so
it
it
seems
to
me
this
topic
is
important
enough
and
we
want
to
make
like
big
investment
on
it.
So
so
josh,
I'm
happy
to
work
with
you
offline
to
go
through
the
swag
pr
and
and
maybe
address
some
of
the
questions.
H
Meanwhile,
I
I
think
we
we
do
need
to
have
a
more
frequent
conversation,
so
maybe
we
can
use
the
metrics
say.
I
would
ask
the
question
which
language
state
is
committed
to
prove
this
working
like.
We
will
probably
need
a
daily
sync
up
once
the
the
spec
is
there.
Maybe
we
need
the
language
owners
like
maintainers
to
come
back
and
say
this
is
confirmed
in
my
language.
I'm
I'm
happy
to
ship
the
stable
version.
I
Pr
so
this
something
says
this
is
okay
to
do,
because
everyone
says
where's.
The
spec.
I
Say
they
have
good
confidence?
I
mean
my
my
opinion
is
that
you
can
kind
of
prove
on
first
principles
that
something
here
has
to
work,
because
there's
an
equivalency
that
you
can
draw
between.
Okay,
I
had
two
regis.
I
had
two
registrations
with
two
callbacks
that
must
behave
the
same
as
one
registration
with
a
wrapper
around
two
callbacks,
which
must
behave
the
same
as
if
I'd
define
two
callbacks
on
that
instrument
and
use
the
same
function
twice
like
none
of
those
should
be
any
different,
and
I
think
we
can
write
better
specs
here.
I
I
definitely
have
read
the
feedback
from
the
last
24
hours
and
I
could
improve
on
the
language
you
know
like.
For
example,
you
asked
a
question
about
functions
and
and
if
you
try
to
unregister
a
closure-
and
I
actually
don't
did
not
want
to
say
anything
about
closures-
I
want
to
say
there's
a
type
called
a
callback
with
a
method
called
unregister
and
you
you
call
register,
call
yeah.
H
H
J
Yeah,
I
can
work
on
behalf
of
java.
You
know
I
can't
guarantee
that
we'll
be
open
to
like
having
a
release
candidate
for
this,
but
I
think
we
can
come
together
and
in
some
way
form
a
consensus
on
whether
we're
comfortable
with
this
new
api,
whether
that's
just
like
you
know,
we've
evaluated
the
pr
sufficiently.
J
L
H
Okay,
we
think
these
are
good
enough.
I
I
heard
javascript
because
I
think
javascript
they
have
the
typical,
like
paradigm
of
using
either
item
to
delete
a
callback
or
they
just
have
to
add
event
lists
and
remove
event
listener
style.
So
maybe
we
should
have
a
third
language.
F
Well
us
in
python
or
canadian
immigrant
use
prs.
I
don't
know
if
it
will
be
a
good
one
for
us
to
participate
in,
but
it's
okay,
so.
F
Here
well
at
least
I
can
over
my
head
with,
if
there's
something
that
that
is
needed,
something
specific
that
you
you
want
us
to
test,
but.
F
All
right,
yeah,
that's
okay,.
J
Yeah,
I
think
what
we
need
is
for
some
maintainer
from
from
a
language
to
be
able
to
say,
take
like
a
hard
look
at
this
spec
pr
and
be
able
to
say
yes
or
no.
Our
language
is
comfortable
having
this
api
implemented,
and
you
know,
however,
they
come
to
that
consensus
of
whether
they're
comfortable
is
up
to
the
language
but,
like
I
think,
that's
the
answer.
We
need.
B
I
can
try
to
find
some
time
for
js
art.
One
of
the
other
maintainers
is,
is
been
doing
most
of
our
metrics
work,
so
I
can
see
if
he
has
time
to
do
it
and
if
not,
then
maybe
I
can
take
a
crack
at
it,
but
I
think
he
would
be
a
better
person
to
do
it,
unfortunately,
he's
in
a
super
inconvenient
time
zone
for
this
meeting.
So
he's
never
really
here.
H
Okay,
so
I
want
to
put
some
timeline
on
this:
can
we
target
like
within
a
week
we
can
solve
this.
H
J
Yeah
a
week
is
fine
for
java.
I
think
we
just
need
to
sync
up
as
a
group
one
more
time-
and
you
know
confirmed
a
few
things
but
we're
pretty
close.
Okay,
cool.
I
I
feel
like
everyone's
going
to
come
back
and
say:
yeah,
the
api
is
fine,
but
I
still
don't
quite
know
exactly
whether
what
the
correct
and
whether
the
recommendation,
what
the
recommendation
is
for,
let's
say,
calculation
of
a
view
over
asynchronous
instruments
when
I'm
removing
attributes
and
we've
talked
about
that
a
little
bit.
But
it
seems
to
be
like
so
far
down
the
road
for
most
of
us
that,
like
okay,
let's
just
get
to
the
point
where
we
can
use
a
view
to
rename
a
metric
and
forget
about
that
particular
removal
of
attributes.
I
Question
because
when
you
have
duplicate
observations
that
may
change
your
result
like
it
gets
very
complicated
right
now
we
have
a
lot
of
like
it's
not
defined
language
in
the
right
places
to
for
me
to
be
comfortable
moving
forward,
but
I
think
there
will
be
questions.
H
Yeah
so
quick
question
for
carlos,
like
if
we're
going
to
merge
this
pr
within
a
week,
would
you
see
like
the
next
spike
release
catching
this
or
it
would
be
taken
by
the.
C
Next
one,
so
we
haven't
released
this
month,
we
have,
we
were
actually
waiting
for
the
metrics
part.
So
I
think
that
this
is
important
enough
just
to
hold
it.
I
don't
know
if
anybody
else
has
an
opinion.
We
were
doing
a
monthly
release,
but
you
know,
like
december,
was
not
very
not
a
very
you
know
like
it
was
a
very
lazy
month.
So
generally
it
has
been
slow
as
well,
so
we
can
hold
it.
I
think.
K
C
That
that
could
also
work.
I
don't
know
what
riley
and
jamaica
think
about
that.
We
could
just
also
go
that
path
like
we
just
released
the
monte
release
like
today
or
tomorrow,
and
wait
for
for
for
the
monthly
release
in
march.
H
Yeah
I'll
work
with
clutch
on
that,
although
on
the
overall
like
the
sdk
spec,
makes
the
stable
release
currently,
I
I
cannot
do
it
because
we
don't
have
enough
visibility
on
how
many
issues
people
think
we
should
solve
like.
We
need
to
first
understand
the
ask,
and
then
we
need
to
triage
to
ask
to
decide
which
one
should
be
part
of
that
which
one
can
be
deferred,
and
currently
the
leichhoff
asks
is
already
saying
it's
a
problem.
Maybe
folks
are
more
focusing
on
the
api
at
this
moment.
F
Yes,
so
we
have
a
kind
of
small
question
on
the
meaning
of
wild
card.
It
is
defined
for
you
that
there
can
be
support
optional
support
for
wildcards
in
the
name
of
the
instrument
we
are
considering
about
just
using
regular
expressions
so
that
the
name
of
the
instrument
that
can
be
passed
to
our
implementation
can
be
just
it
as
a
regular
expression,
but
that's
some
pushback
from
aaron
from
google,
and
we
will
like
to
know
if
there
can
be
a
clarification
with.
F
H
Whatever
I
I
see
so
I,
if
I
remember
correctly,
we
discussed
about
this
and
in
the
current
spike
it
just
mentioned
wild
card
without
defining
what
type
of
wildcard
you
should
be
using.
I
I
think
individual
language.
Currently
they
have
the
freedom,
because
respect
doesn't
require
anything
right.
So
if
you
think
we
we
should
unify
that,
my
my
question
would
be:
do
you
think
each
language
have
their
own
style
of
how
people
should
define
a
string
pattern?
My
answer
is
yes,
it
seems
like
javascript.
H
F
I
don't
think
we
should
try
to
make
this
uniform
just
hard
right.
I.
F
Yeah,
I
am,
I
was
more,
I
was
asking
and
the
the
answer
that
you
gave
clarify
that
this
is
the
the
way
to
implement.
This
is
idiomatic.
It's
it's
sex
or.
H
But
maybe
like
what
I
can
do
is
I
I
can
clarify
that
in
the
spec
saying
language
can
choose
their
ideological
way.
This
would
help
you
right
yep.
That
would
be
great.
Thank
you
yeah.
I
want
to
see
like
if
others
would
agree.
F
H
L
I'm
not
sure
how
I
feel
about
leaving
that
unspecified
or
to
the
sig.
This
seems
like
something
where
we
might
want
consistency
across
languages
right.
We
want
users
who
are
defining
views
to
be
able
to
define
a
view
regardless
where
they
are
and
to
be
able
to
share
views
among
languages.
I
could
certainly
imagine
right.
Imagine
you've
got
a
multi-language
application
framework
and
you
want
to
have
consistent
metrics
coming
out
of
them.
L
You
should
be
able
to
say
this
is
the
view
that
you're
going
to
define
and
here's
the
definition
of
it
if
we
say
that
each
language
can
define
their
own
meaning
for
wild
card.
That
becomes
much
more
difficult
from
the
examples
in
the
spec.
It
looks
like
the
wild
card.
Envisioned
is
much
more
like
shell
globbing,
where
star
is
dot
star
and
a
reg
x
and
question
mark
is
dot
in
a
regex.
L
I
think
that's
simple,
to
define
and
simple
to
implement
and
can
be
implemented
anywhere.
There
are
regexes.
If
we
allow
languages
to
start
using
regexes,
then
you've
got
to
account
for
the
wide
variation
of
support
for
regex
features
in
languages.
Are
they
pcre?
Are
they
re2?
Are
they
whatever
the
heck
javascript
is.
H
Yes,
my
answer
is
no.
I
I
think
if
we
allow
something
like
a
tcp
port
or
something
to
be
specified,
I
can
imagine
that
will
be
used
as
environment
variable
and
maybe
environment
variables
shouldn't
be
language
specific.
But
for
this
one
I
don't
imagine
that
someone
would
specify
that
in
like
a
language
neutral
configuration
file,
because
if
you
think
about
the
instrument
name,
they
they
might
be
like
language
specific.
H
J
I've
been
thinking
about
building
a
file
based
configuration
mechanism
to
configure
views,
so
interpret
some
sort
of
structured
text
like
gamma
or
json,
and
interpret
that
and
convert
it
to
a
view
configuration
and
what
anthony's
saying
matches.
Well
with
that.
If
we
wanted
to
have
a
language
agnostic
file
based
configuration
mechanism
for
views.
J
L
J
Is
it
something
that
needs
to
be
specified?
Now,
though,
could
we
later,
like
you
know,
could
we
have
language
idiomatic
ways
to
specify
wild
cards
and
then
later
specify
that
you
know
regular
expressions
are
required,
some
form
of
them?
I,
I
think
I'll.
L
Be
breaking
behavior,
though
right,
and
so
if
we
were
to
restrict
the
specification
of
any
of
the
languages
that
have
implemented
some
language
specific
capability,
then
we
would
be
potentially
breaking
the
existing
view.
Implementations.
H
So
one
thing:
I'm
thinking
about
javascript
in
javascript,
there
are
well
like
you
can
represent
the
wildcard
in
a
string,
but
the
native
way
is
to
just
put
a
regular
expression,
the
native
red
expression
type
directly,
and
I
think
in
javascript.
You
have
one
function
that
you
allow
people
to
either
put
regular
expression
or
a
string,
and
if
this
drug
expression,
then
you
do
whatever
you
should
do.
If
it's
string,
then
you
treat
it
as
wild
card.
B
J
H
Yeah,
so
so,
do
you
guys
think
it
will
be
helpful
if
we
we,
like
rephrase
the
spikes
saying
languages,
have
freedom
to
either
idiomatic
way,
give
some
flexibility
to
python
and
later
we
can.
We
can
add
additional
requirements,
saying,
for
example,
all
the
languages
should
at
least
support
like
a
glove
style,
wild
card
for
configuration
that
can
be
an
additive
change.
Much
later.
J
F
H
Glob
I
understand,
but
you
can't
have
different
parameters
right
in
python.
I
can
imagine
you
have
the
name
equals
to
asterisk
and
later
you
want
to
support
regular
expression.
You
can
do
something
else
like
by
putting
another
parameter
like
if
that
parameter
is
already
used.
You
can,
you
can
add
another
thing.
J
Yeah,
I'm
with
riley
on
that,
as
long
as
the
the
languages
leave
the
door
open
for
you
know
some
sort
of
common
convention
to
be
added
later.
N
Okay,
so
just
to
clarify
if
the
idiomatic
way
is
like
what
daniel
said
for
javascript,
you
accept
either
like
a
javascript
object,
a
regex
object
or
a
string
and
then
interpret
it
differently.
Based
on
that
that
doesn't
fill
well
with
converting
it
to
yaml
later
right.
H
B
L
Yeah,
of
course,
which
is
why
I
think
the
it's
important
to
specify
now,
if
you
want
to
provide
a
regular
expression,
here's
the
method
for
doing
that.
If
you
want
to
provide
a
straight
string,
match
here's
the
method
for
doing
that.
If
you
want
to
provide
a
show
globe,
here's
the
method
for
doing
that
or
we
we
pick
one
of
those
and
support
them.
B
J
So
in
java
we
provide
an
option
to
select
names
with
with
a
predicate,
so
just
like
a
function
that
accepts
the
name
of
the
instrument
and
returns
true
or
false.
J
That
seems
like
the
most
general
way
to
still
have
you
know,
control
over
this
type
of
thing,
so
you
know
you
could
start
with
requiring
that
languages.
Support
like
a
predicate
to
select
names
and
then
later
a
reg
x
is
just
like
a
type
of
predicate
and
whatever's
idiomatic
in
your
language
is
just
like
another
type
of
predicate.
N
L
L
Right
for
file
based
configuration
to
work,
then
we
would
need
to
have
a
common
set
of
predicates
implemented
with
identifiers
for
them
that
could
be
specified
in
the
file
and
configuration
options
that
they
need
in
the
file.
We
can
certainly
make
it
work.
I
I
don't
think
that
that
forecloses
that
option
the
same
way
that
simply
saying
languages
can
do
whatever
seems
idiomatic
to
them
for
wild
cards
feels
like
it
would
foreclose
to
me
that
option.
H
Yeah,
so
my
suggestion
is
that
file
based
listing
seems
to
be
interesting,
but
we
can
make
that
much
later
and
it
doesn't
have
to
have
the
full
functionality
with
what
you
can
do
with
the
callback
or
what
jack
mentioned.
So
it
must
be
a
subset
unless
you
like,
introduce
your
domain
specific
language
in
the
configuration
which
I
I
think
is
too
crazy.
H
H
F
We
we
considered
that
maybe
there
will
be
other
issues
regarding
file
based
configuration
compatibility
among
languages
we're
facing
one
now,
but
we
haven't
even
considered
if
some
other
instrument
selection
criteria,
for
example,
may
also
be
completely
hard
to
implement
there.
So
maybe
we're
restricting
ourselves
based
on
a
feature
that
may
even
never
get
implemented
because
of
the
difficulties
that
we
may
face
facing
forward
right.
H
H
F
Right,
what
I'm
trying
to
say
is
that
we're
having
difficulties
right
now
to
keep
this
wild
card,
slash,
regex,
support
open
for
all
languages
and,
at
the
same
time
guaranteeing
that
this
will
be
possible
to
represent
in
a
uniform
way
in
a
file
for
a
views
configuration
file.
Let
me
share
them
in
languages.
F
H
L
Yeah,
I
wouldn't
have
that
expectation
either.
My
concern
here
is
that
for
the
subset
of
selectors
selectors
that
we're
describing
in
the
spec
some
of
them,
particularly
the
wild
card-
support
for
name,
have
ambiguity
and
they
should
have
consistency
instead,
I
I
don't
feel
comfortable,
saying
every
language
can
do
whatever
they
want,
and
it
will
be
interpreted,
however,
that
language
chooses
to
interpret
it
if
we're
going
to
ever
at
some
point
have
some
cross
language
configuration
for
that.
J
J
Well,
then,
when
we
code
to
translate
that
to
a
specific
language's
view
api,
it's
it's
limited
by
what
that
language
sdk
provides
and
if
the
the
language
provides
a
way
to
like
accept
a
posix,
regular
expression
and
and
select
names
based
on
it
great.
If
they
don't
provide
that
capability,
then
that
language
can't
support
that
feature
of
the
file
based
configuration.
J
H
L
I
I
mean
I
I
seem
to
be
outnumbered
here,
but
I
I
do
find
it
inconsistent
that
we
would
be
saying
here's
a
feature
we
want
all.
We
want
to
have
consistency
across
languages
with,
but
we're
not
going
to
be
consistent
about
the
format
of
the
thing
that
goes
in
here.
I
think,
if
we're
going
to
say,
wild
card
support
is
optional.
We
should
define
what
wild
card
support
means
and
if
we
want
to
enable
regular
expressions,
we
should
say
regular
expression.
L
Support
is
optional
and
we
should
define
what
regular
expressions
means
is
that
posix
is
a
pcre
whatever
right,
but
simply
saying,
while
wild
card
support
should
exist
or
is
optional,
without
providing
any
further
definition
of
what
we
mean
by.
That
seems
dangerous
to
me
and
wrong.
J
H
L
I
think,
if
you
say
wild
card
to
many
developers,
they're
going
to
think
of
shell
glob
style,
wild
cards,
which
would
be
star
for
any
sequence
of
characters
and
question
mark
for
any
single
character.
I
don't
think
most
developers
at
least
I
certainly
wouldn't
think
regex
if
you
say
wild
card.
Those
are
distinct
things
to
me.
B
J
F
F
L
Well,
I
think
the
spec
is
because
the
spec
is
a
floor.
It's
not
a
ceiling
right,
it
does
say
you
can
implement
other
matchers
other
selection
criteria.
But
if
we're
going
to
specify
in
if
we're,
if
we're
going
to
include
something
in
the
spec,
we
should
probably
specify
it
and
not
leave
it
to
interpretation.
H
F
L
L
Does
that
mean
the
explicitly
listed
optional
criteria
from
the
spec
or
is
it
does
that
also
include
any
of
the
sdk
specific
additional
optional
criteria
like
if
an
sdk
included,
regex,
and
that
was
included?
Is
that
sufficient
to
not
be
an
error?
It
seems
that
it
should
be,
but
it
might
be
somewhat
ambiguous.
J
Yeah
yeah,
I
think
that
if
you,
if
you
specify
selection
criteria
in
a
way
that
is
language
idiomatic,
that
that
meets
the
the
criteria
to
not
throw
an
error-
I
I
I
don't
know
whether
that's
ambiguous
or
not.
I
don't
think
it
is
on
my
read,
but
you
know
I
think
the
the
point
of
that
phrasing
is
that
we
need
some
way
to
select
an
instrument.
If
that's
not
provided,
then
we
have
no
choice
but
to
throw
an
error.
I
Can
I
say
something
just
it
stuck
in
my
head,
while
listening
to
this
conversation
about
regex's,
that
there
was
an
analogy
made
to
the
sampling
interface
and
the
sampling
interface
is
quite
a
lot
more
specified
in
sdk
spec
to
my
mind,
and
maybe
that
would
be
a
good
direction
for
us
just
a
feeling
I
had,
as
you
were
discussing
it.
So
there
there's
a
spec
that
says:
sampling
parameters
includes
this
all
these
fields
that
are
pretty
clearly
specified
and
it
acts.
I
The
point
is
that
it
will
act
as
a
predicate
that
the
sampler
acts
as
a
predicate
and
the
sampling
parameters
are
exactly
the
inputs
that
you're
specified
to
receive,
and
then
the
sampling
result
is
also
clearly
specified.
So
it
might
be
I'll,
add
some
structure
to
this
spec.
If
we
had
we'll
call
it
a
view,
a
view
parameter
list
view
parameter
which
includes
the
instrument
name,
its
instrument
type,
its
number
type,
like
everything
that
you
know
to
make
this
predicate
decision
and
then
the
result
is
the
aggregation.
I
You
want
to
use
the
output
name.
You
want
to
use
the
output
description.
The
output,
like
maybe
the
output
unit,
one
day,
etc,
etc.
I
had
to
create
that
structure
myself
in
the
prototype
and
it
felt
like
I
was
kind
of
free
freestyling.
J
Yeah,
so
you
have
like
an
instrument,
selection
criteria
and
the
the
view
you
decide
whether
the
view
applies
or
not
by
just
you
know,
for
the
given
instrument
applying
a
predicate
that
accepts
this
criteria
and
decides
true
or
false
whether
that
instrument
satisfies
it
and
it
had
like.
You
said
it
has
all
the
parameters
that
you
might
need
to
make.
That
decision.