►
From YouTube: Open Telemetry's Personal Meeting Room
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
C
Is
that
a
pretty
common
experience
for
being
on
a
on
a
Linux
system?.
A
Oh
yeah
Zoom,
it's
not
happy
I,
don't
think
and
they
dropped
they
technically
dropped.
Support
for
Fedora,
now
I
believe
they're,
like
only
support
Ubuntu.
Yes,.
C
I've
never
used
Linux,
except
for
you
know,
through,
like
a
shell
I've,
never
had
like
a
a
Windows
version
of
Linux.
Where
it's
been
my
my
you
know,
workstation
mission.
D
C
Right
so
we
have
a.
We
have
a
document
now
for
the
working
group.
D
C
Yeah
so
hello,
everyone,
so
I'm,
familiar
with
I,
think
most
of
the
people
on
this
call,
Tristan
and
Alex
and
I
have
met
for
a
couple
of
weeks
in
just
one
a
couple
of
times
before
this
and
Tyler
yawn
has
has
also
been
involved.
In
you
know,
we've
been
working
on
a
variety
of
things
related
to
getting
a
a
file
based
configuration
schema
put
together.
C
Mostly
the
work
has
been
in
the
form
of
you
know,
doing
prototypes
and
different
technologies
that
might
be
involved.
So
you
know
different
encoding,
Technologies
like
yaml
or
Json,
and
then
different
ways
to
specify
the
schema.
So
some
of
the
ones
we've
been
looking
at
are
things
like
Json
schema
and
protocol
buffers
and
Q,
and
we've
we've
kind
of
eliminated,
a
variety
of
others,
just
that
are
kind
of
more
esoteric
and
probably
not
worth
time,
but
so
yeah
so
to
the
folks
that
are
here
for
the
first
time.
C
So
maybe
we
should
start
with
just
like
introductions
and
maybe
while
you're
interested
in
this
in
this
working
group
and
and
what
you
hope
to
have
accomplished
from
this
group.
So
we
can
make
sure
we're
all
on
the
same
page.
C
C
So,
like
the
the
outcome
that
I
see
of
This
Is
Us,
putting
together
an
Otep
with
a
proposal
for
how
we
see
what
we,
what
we
see
a
file
based
configuration
schema
being
composed
of,
and
so
you
know
that,
maybe
that
would
be
like
hey
specify
the
file
based
config
schema
in
yaml,
and
you
know,
use
protocol
buffers
or
something
to
or
some
other
technology
that
we
arrive
on
as
a
group
to
to
specify
like
how
the
data
is
structured.
C
And
then
you
know,
after
that's,
approved
and
merged
I
would
imagine
going
and
implementing
prototypes
or
implementing
that
in
in
the
Java
language,
so
that
we
could
in
in
the
Java
SDK
we
could
parse
one
of
these
files
and
use
it
to
configure
an
open,
Telemetry,
SDK,
the
Tracer
provider,
the
media
provider
and
the
logger
provider.
So
that's
kind
of
my
vision
for
how
this,
for
what
that
the
outcome
is
of
this
working
group.
D
Well,
I'll
go
next
I'm
Alex
I'm,
a
maintainer
in
The,
Collector
and
contributor
to
various
other
repository
and
open
Telemetry
I'm.
An
engineer
at
lightstop
and
I'm
really
excited
about
this
user
group,
because
I've
spent
a
bunch
of
time
configuring
open,
Telemetry
in
various
languages
and
it's
always
a
pain
because
they're
each
language
seemed
to
use
slightly
different
configuration
options
or
a
different
SDK
I.
Think,
from
the
point
of
view
of
lights,
up,
we've
provided
our
users.
With
these
things
called
the
distro.
We
call
it
launchers
to
kind
of
simplify
the
configuration
experience.
D
I
think
we've
we've
heard
from
various
users
that
it's
great
to
have
this
kind
of
simplified
configuration
experience,
but
they
really
want
to
have
it
as
part
of
the
vanilla,
open,
Telemetry
experience
rather
than
you
know,
feeling
like
it's
a
it's
a
vendor-specific
thing.
So
I
think
my
interest
is
trying
to
get
open
Telemetry
as
easy
to
use
as
possible
for
as
many
users
and
yeah.
That's.
That's
me.
A
And
go
next
I'm
Tristan
I
work
at
Splunk
and
I'm,
a
maintainer
of
the
early
implementation
of
the
API
SDK.
The
the
only
thing
I
have
pretty
much
the
same
goals
and
see
the
plan
the
same
as
Jack
and
Alex,
but
would
say
I
think
we'll
probably
have
some
prototypes
before
we
even
publish
an
Otep.
E
B
Hi
everyone
I
can
go
next:
I'm
Dmitry,
I,
I'm
maintainer
of
the
collectors
and
usually
I
use
sdks
as
a
user
to
try
things
out
so
I'm,
not
probably
not
gonna,
participate
in
this
working
group
actively
going
forward
just
curious
how
the
things
going
to
be
solved
like
all
this
user
facing
issues
and
how
it
can
how
we
can
relate
to
the
collector
configuration
potential
as
well.
F
So
we,
the
auto
instrumentation,
is
not
very
helpful
with
the
Matrix
currently
today,
because
there
is
no
way
to
configure
the
views
and
there
are
other
things
that
are.
We
cannot
currently
support
with
the
envs.
F
We
were
thinking
of
providing
some
sort
of
file
based
configuration,
but
then
we
realized,
like
there's,
also
a
working
group.
This
has
started
so
I
was
interested
in
you
know
following
along,
and
you
know,
give
some
inputs
and
try
to
you
know:
Implement
is
implement
it
for
the
python
SDK
and
see
how
it
goes.
I'm
really
excited
about
this
group.
C
Actually
so
you
mentioned,
Street
counts
that
the
view
base
configuration
is
one
of
the
driving
factors,
and
so
we
have
a
similar
concern
in
in
Java
and
we
have
some
prototype
module.
That
specifically
allows
you
to
configure
views
with
the
CML
configuration
scheme
to
to
bridge
that
Gap,
but
yeah.
It
would
be
great
if
it
was
specified
in
part
of
a
you
know:
symmetric
across
the
languages.
F
Yeah,
that's
true
that
that
was
the
one
like
we
were.
That
was
the
point
where
we
we
wanted
to
make
some
decision
like
so
far.
It's
working
well
for
other
components,
but
we
use
there
is
no
way
to
configure
it,
which
is
important
part
of
the
Matrix
SDK
yeah.
That's
why
we
are
interested
in
this
group.
G
I
can
go
next,
real,
quick.
My
name
is
Jeremy.
He
has
some
pronouns
I've,
been
working
on
a
poetry
python
for
like
seven
months
or
something
I,
mostly
work
on
auto
instrumentation
for
Microsoft,
because
I
I'm
working
on
basically
providing
Azure
systems
where
you,
where
users
can
just
click
the
Switch
and
turn
on
instrumentation
yeah,
and
so
we're
similarly
interested
in
having
a
file
configuration.
So
people
can
very
easily
change
and
migrate
their
settings
from
one
app
to
another.
H
Yeah,
probably
can
just
mention
myself
briefly:
I
am
the
DC
sponsor
of
this
one,
this
effort
yeah.
Basically,
there
was
also
some
concern
about
explosion
of
environment
variables
because
everybody
needs
some
fear
this
and
that
so
hopefully
this
will
solve.
Also
that
part,
you
know
yeah
so
I'm
pretty
curious
about
that.
Yeah
mostly
will
be
in
the
loop,
mostly
reviewing
stop
yeah.
I
Hey
guys
I'll
go,
my
name
is
Mike
Blanchard
people
call
me
Blanche
I'm,
one
of
the
maintainers
on
the
dot
net,
say
language
I
work
at
Microsoft,
I
kind
of
got
involved
in
this
through
environment
variables,
I've
been
trying
to
make
sure
that
what
the
spec
prescribes
for
environment
variables
fits
in
nicely
with
what.net
does
with
its
configuration,
which
is
a
little
bit
different.
I
So
this
working
group
came
up
and
it
seemed
like
it
would
be
good
just
to
be
involved
and
help
from
the.net
side
and
hopefully
build
something
that
works
really
nice
with
the.net,
auto
instrumentation
group
as
well,
because
they
have
a
lot
of
similar
needs.
So
I'm
excited
about
it.
Looking
forward
to
making
something
great
with
you
guys.
C
Right
have
the
folks
that
are
new,
or
is
everyone
familiar
with
some
of
the
some
of
the
resources
and
artifacts
that
we've
been
working
on
so
far,
I'll
assume
no
and
I'll?
Maybe
just
do
a
quick
walkthrough
of
some
of
those
I
think
err
on
the
side
of
caution,
so
I'll
I'll
share
my
screen
and
drive
a
bit.
C
All
right
so
in
the
meeting
notice
we,
let's
see
we
got
our
meeting
notes
here
and
at
least
one
of
the
resources
that's
relevant
is
linked
directly
in
here.
So
there's
this
GitHub
repository.
This
is
a
repository
under
Tyler
yawn.
That's
Mr,
Alias
and
we've
been
putting
together
some
prototypes
in
here,
and
so
the
way
that
this
has
been
organized
is
there's
prototypes
and
different
directories
for
each
of
the
different
configurations,
schema
options
that
we've
been
considering
so
there's
one
for
protobuf
and
then
within
protobuf.
There's
an
example.
C
Java
implementation
that
generates
you
know,
classes
from
those
protobufs
and
parse
is
an
example,
file,
config
and
then
there's
a
you
know,
a
similar
exercise
for
Json
schema,
and
so
you
know,
there's
another
Java,
implementation
and
Tristan
has
been
putting
together
a
proof
of
concept
or
a
demonstration
with
Q,
which
is
another
option
for
specifying
the
schema
and
that
hasn't
been
merged.
C
Yet
we
don't
really
have
criteria
for
merging
we're,
still
kind
of
figuring
a
lot
of
the
basics
out,
as
in
terms
of
how
we
want
to
work,
but
so
effectively,
we've
put
together
some
sort
of
prototype
in
Q,
Json,
schema
and
in
protocol
buffers
and
those
prototypes
live
in.
This
hotel
schema
repository
that
is
linked
to
in
the
meeting
notes.
C
Another
resource
that
we've
been
working
on
is
this
this
this
Google
doc
open
Telemetry
configuration
file
and
I'm
gonna
I'm
going
to
link
to
this
into
meeting
notes.
C
And
let's
get
rid
of
this
extra
stuff.
C
Oops
make
sure
this
works,
so
this
is.
This
was
a
draft
that
Tyler
put
together
a
long
time
ago,
and
you
know
he
was
just
trying
to
outline
the
motivation
for
a
configuration
file
schema
and
you
know
the
what
the
requirements
are
and
then
you
know
this
was
kind
of
a
Dumping
Ground
for
some
of
the
some
of
the
notes
that
came
out
of
the
exploration,
so
you
know
of
the
different
solutions
that
were
considered.
Why?
What
makes
them
good
or
bad
what
are
open
questions
and
so
on.
C
So
this
has
just
kind
of
been
like
a
working
document
that
may
eventually
Inspire
an
otat.
Maybe
language
from
it
is
eventually
lifted
into
an
Otep.
But
for
now
it's
just
it's
just
a
working
document
and
nothing
more.
So
there's
nothing
like
binding
about
anything
in
here.
H
C
True
yeah,
so
in
cncs,
lock,
there's
Hotel
config
file.
Yeah
we've
been
having
some
discussions
in
there
as
well.
C
Okay,
so
if
anyone
has
any
questions,
I'm
happy
to
answer
them
about
those
resources,
but
if
not,
why
don't
we
try
to
move
on
to
this
agenda
item
what's
next?
C
D
E
A
D
A
C
And
maybe
maybe
this
isn't
as
important,
but
just
like
so
there's
the
scheme
of
representation.
So
what
technology
we
use
and
somewhat
related,
but
also
somewhat
like
independent,
is
what
is
what
is
actually
configurable
in
this
in
this
representation?
So
what
types
of
things
do
we
want
to
include
in
the
initial
scope
versus
what
things
are
we
punting
on.
F
F
Is
there
something
that
I
that
already
you
know
discussed
like
agreed
upon,
but
okay,
so
the
protocol,
something
this
is
how
the
schema
is
going
to
be.
Is
it?
Is
it
still
something
that's
being
experimented.
C
It's
it's
very
malleable
right
now,
so
it's
it's
very
much
up
in
the
air.
So
if
you
look
at
the
actual
Source,
that's
committed,
I
took
a
stab
at
coming
up
with
at
one
point,
what
I
thought
like
an
example,
configuration
scheme
might
look
like
and
so,
like
you
know,
if
you
go
to
the
Json
schema
directory
and
then
this
kitchen
sink
yeah,
this
is
basically
some
yaml
that
I
thought
hey.
C
What
is
all
the
configurable
surface
area
that
we
care
about
in
the
SDK
and
I
tried
to
you
know
represent
that
in
a
structured
way
and
annotate
it
with
docs
or
with
comments,
so
you
could
actually
like
understand
what
I'm,
what
I'm
trying
to
say
and
then
I
tried
to
represent
this
schema
using
Json
schema,
so
that
was
kind
of
the
exercise,
but
you
know
this
was
just
this
was
just
the
first
draft
right.
C
It
was
just
something
I
pulled
out
of
my
head
and
you
know
what
we
actually
proposed
could
be
similar
to
those
who
are
very
different.
I
think
we
need
to
decide
that
as
a
group.
C
You
know
in
another
thing
to
note
with
that.
With
respect
to
that
is
so
in
in
the
protocol
buffer
and
the
protobuf
directory,
there's
another
kitchen
sink
yaml
and
it
looks
really
similar
to
the
one.
That's
in
the
Json
schema
directory.
But
there's
some
key
differences
and
the
reason
is,
is
because
protocol
buffers
are,
you
have
limitations
in
terms
of
how
what
you
can
represent,
and
so
I
had
to
like.
C
Take
this
initial
sketch
of
what
I
thought
configuration
would
look
like
and
then
modify
it
so
that
you
could
actually
express
it
in
protocol
buffers
so
that
that's
that's
just
something
to
be
aware
of,
and.
C
C
Yeah,
if
that
is
interesting
to
folks
so
like,
let
me.
A
A
A
Alex,
for
example,
configuration.
C
Exactly
so,
Alex
has
taken
another
and
let's
just
go
off
on
that
tangent,
real,
big,
but
quickly
and
then
come
back
to
your
question.
Tristan
so
Alex
has
this
example
configuration
that
we've
been
commenting
on
and
it
hasn't
been
merged
yet,
but
it
kind
of
takes
some
of
those,
the
the
concepts
that
I
sketched
out
initially
and
then
you
know
applies
Alex's
own
interpretation
on
them
and
I
think
there's
a
lot
of
good
things
in
there
and
you
know
if
we
can
all
agree
on
on
something
like
this
and
get
that
merge.
C
D
And
I
think
just
one
thing
to
point
out
in
this
PR
is
that
I,
so
what
the
other
kitchen
sink?
Yaml
configuration
files
focus
on
how
to
represent
the
data
for
the
different
schema
tools
that
were
being
tested.
This
PR
is
really
focusing
on
the
user
ergonomics
first
and
then
trying
to
see
can
we
work
backwards
from
that
point
rather
than
trying
to
force
the
schema
onto
users,
if
that
makes
sense.
C
Okay,
so
we
went
down
we're
going
back
to
this
tangent
about
the
differences
between
protocol
buffers
and
Json
schema,
because
I
I
claimed
that
there's
some
limitations
and
protocol
buffers
and
how
you
express
stuff
and
that
manifests
in
the
ergonomics
of
these
files.
C
So
let's
look
at
one.
Let's
look
at
one
particular
example
of
how
you
express
like
an
exporter.
C
C
Oh
man,
that's
that's
a
bad
example
for
a
reason:
I'm
not
going
to
get
into
okay.
Let's
look.
Let's
look
at
configuring.
A
simple
span,
processor,
so
simple
span.
Processor
is
a
type
of
span
processor.
That
is,
you
know
one
of
the
built-in
ones.
According
to
the
specification
and
in
this
here
I'm
saying:
hey,
configure
the
Tracer
provider
with
a
list
of
span
processors
and
then
I
go
on
to
list.
C
You
know
each
span
processor
and
you
know
I
do
the
same
thing
in
both
places.
So
you.
C
Provider
span,
processors
and
then
a
list
of
span
processors
and
one
thing
that
fell
out
of
protocol
buffers
versus
Json
schema.
We
have
Json
schema
here
on
the
right
we
have
protocol
buffers
here
on
the
left
is
Json
schema
allows
you
to
say
something
like
this,
so
it
says
when
a
key
named
name
has
a
value
called
Simple
then
enforce
a
particular
schema
on
the
remaining
arguments,
so
you
can
express
that
in
Json
schema.
So
you
know
when
this
is
present
and
force
this
other
bit
of
schema.
C
You
can't
do
that
with
J
with
protocol
buffers,
so
you
know
I
had
to.
Instead
in
in
the
schema
say:
hey
there
is
a
field
called
processor,
it's
an
enumeration
of
different
names
of
processors,
so
simple
batch
and
then
maybe
some
like
custom
extension,
processor
and
then
separately,
I
had
to
have
a
different
field,
which
are
the
arguments
that
configure
your
processor.
That
is
named
simple
and
so
like
simple
processor,
args
is
a
type
in
protocol
buffers,
and
so
it
has
a
schema
associated
with
those
arguments.
C
C
There
is,
you
know
in
terms
of
their
ergonomics,
so
you
have
to
say
hey
this
is
the
processor
called
simple
and
here
are
the
arguments
for
it
in
Json
schema,
you
just
say:
hey,
we
have
a
processor
called
simple
and
you
know
you
can
enforce
the
schema
of
the
simple
processor
automatically
just
by
recognizing
that
there's
a
key
called
name
with
a
value
called
Simple,
so
that
that
type
of
pattern
actually
happens
a
lot
throughout
this,
and
so
you
know,
without
getting
into
you
know
more
examples.
A
C
E
A
Schema
because
most
people
have
Jason
schema
implementations
in
their
language.
C
Yeah,
actually
so
that's
a
that
might
be
a
good
option.
Segue
into
talking
about
Json
schema
some
of
the
sharp
edges
there
because
it
does
have
sharp
edges.
C
Oh
here
we
go,
they
have
these
drafts,
so
the
current
draft
is
20
2012.
and
they
had
these
other
drafts
that
were
available
at
different
points,
and
so
when
you
say
that
a
particular
language
has
support
for
Json
schema,
you
can't
just
say
it
has
support
for
Json
schema.
You
have
to
say,
like
which
version
of
the
draft
it
has
support
for
and
just
to
give
you
an
idea
of
how
those
differ.
Do.
C
Yeah
yeah
so
I
think
it
it's
considered
and
I'm,
not
an
expert
on
Json
schema
or
how
they've
gone
about
in,
like
you
know,
versioning
their
drafts.
But
what
I've
gathered
from
this
is
that,
like
so
you
know,
here's
an
implementation
of
Json
schema
in
Java.
C
It
claims
to
have
support
for
a
couple
of
different
versions
of
the
draft
and
when
you
configure
this
Library,
what
you're
essentially
doing
is
saying
hey
interpret
this
Json
schema
as
if
it
was
this
version
of
the
draft,
and
so
you
know
when,
when
we
say
that
Q
can
compile
to
Json
schema
like
what
we'd
effectively
have
to
say
is
like
okay,
which
version
of
the
Json
schema
draft.
And
then
what
is
the?
What
is
the
support
for
different
versions
of
that
draft
across
different
languages?.
G
A
C
And
I,
and
that
wasn't
just
erling
by
the
way
so
I
did
I
was
I.
Haven't
looked
at
this
in
a
couple
of
weeks
now
but
like
when
I
was
doing
some
initial
analysis.
C
You
know
while
it
at
first
glance,
it
looks
like
there's
good
Json
support
across
all
languages.
What
I
was
kind
of
gathering
was
that,
like
you
know,
when
you
incorporate
the
version
of
the
draft
into
here,
the
coverage
actually
gets
a
bit
more
spotty,
because
what
you
actually
want
to
say
is
like
what
is
the
good
support
for
20
2012
across
all
languages,
and
that's
doesn't
have
quite
as
optimistic
of
a
story.
A
C
Okay,
so
we're
kind
of
down
in
the
solution
space
weeds.
Do
we
want
to
like
do
you
want
to?
You
know
pop
back
up
the
stack
and
I
I?
Don't
know
it's
useful
to
talk
about
that
that
stuff
as
well,
but
you
know.
D
The
next
meeting,
so
that
we
can
at
least
have
like
an
apples
of
apples,
comparison
and
then
just
come
up
with
a
a
decision.
D
Yeah
I
can
do
that
and
you
know
I
mean
even
if
we
come
up
with
a
a
decision,
it
doesn't
mean
that
we're
not
going
to
face
a
bunch
of
criticism
during
the
Otep
stop
anyway.
So
you
know
we
don't
have
to
think
that
this
is
ultimately
the
the
final
decision
we
make
on
this
topic.
D
And
then
I
guess
some
ideas
of
the
scope.
D
D
C
I
mean
I
think
so.
I
think
what
you're
essentially
saying
is
like
is:
can
we
come
up
with
some
sort
of
initial
scope
in
one
of
these
kitchen
sink
example,
yamls
and,
like
you
know,
decide
maybe
tentatively
what's
in
what's
out
for
some
initial
version
so
that
we
can
well
for
the
purposes
of
what
So,
like
you
know,
so
we
can
prove
that
this
is
you
know,
there's
enough
things
that
you
can
do
with
it
for
it
to
be
useful.
C
That's
like
one
one
good
outcome
of
that
exercise
and
another
outcome
is
the
you
know
you
can
prove
that
you
can
express
certain
types
of
complex
configuration
that
isn't
available
with
environment
variables.
So
you
know
you
prove
it's
flexible
enough
to
accommodate
certain
key
use
cases.
D
Yeah
I
guess
just
even
from
this
call
some
of
the
cases
that
we
need
to
cover
for
sure
are
environment,
variable
replacement
and
the
ability
to
configure
views
and
metrics.
Is
there
other
things
that
we
think
are
like
a
bare
minimum
requirement.
C
I
mean
we,
we've
talked
about
a
few
of
these
things,
let's
rehash
them
just
because
the
group
has
changed
so
one
of
the
use
cases
that
one
of
the
things
that's
limited
by
environment
variables.
Is
you
can't
configure
more
than
one
processor?
So
you
can't,
you
just
have
to
configure
exactly
one
processor
which
is
like
you
know
your
batch
processor,
and
you
know
if
you
want
to
have
more
than
one
batch
processor
linked
to
more
than
one
exporter,
then
you
can't
have
different
configuration
options
for
those
batch
processors.
C
C
What's
you
know,
built
into
the
spec,
so
I
think
that
you
know
it's
it's
useful
to
say
that
you
know
in
this
this
initial
draft
that
we're
going
to
Target
being
able
to
reference,
like
extension
components,
but
that's
like
that's
something
we
we
could
and
should
discuss
like.
It
increases
the
utility
to
say
that
that
is
in
scope.
D
Yeah
I
I
added
the
instrumentation
configuration
as
well,
because
I
think
that's
something.
That's
not
currently
very
well
specified
in
every
language
kind
of
has
various
ways
of
dealing
with
it
and
I
guess:
I
guess:
there's
also
like
more
complex
data
types
right
for
like
resource
attributes,
for
example,
which
was
one
of
the
one
of
the
sticky
points
for
environment
variables.
If
I
remember
correctly
like
if
you
wanted
to
specify
like
arrays
within
resource
attributes
or
something
like
that,.
C
Yeah
right,
so
that's
that,
hopefully
that's
going
to
be
like
a
deal.
Breaker
I
don't
like.
If
we
can
do
some
of
this
other
stuff
that
should
fall
out
but
yeah.
Let's
mention
that.
That's
a
motivating
use
case.
C
And
I
I
added
a
a
sub
bullet
under
your
instrumentation
configuration
so
like
I
assume
that
what's
going
to
happen
is
each
language
is
going
to
have
its
own
types
of
things
you
want
to
configure
for
instrumentation,
and
for
and
and
also
you
know,
for
that
specific
language
ecosystem
that
maybe
is
related
to
the
SDK
and
not
instrumentation,
but
I
think
it
would
be
good
to
identify
some
cross-cutting
concerns
for
instrumentation
configuration.
We've
we've
enumerated
some
of
those
Alex
in
that
that
issue
that's
opened,
like
you
know
which
HTTP
headers
to
capture.
C
C
So
my
I
guess
what
I'm
trying
to
say
is.
It
might
be
good
to
focus
on
the
like
the
cross-cutting
concerns
for
instrumentation
configuration
and
and
and
maybe
punt
on,
the
language
specifics
for
now,
and
maybe
at
least
be
able
to
accommodate
those
in
some
future
version,
but
maybe
not
try
to
solve
that
problem.
Initially
right.
D
C
C
So
another
thing
that
we
can
I
guess
to
do
before
the
next
meeting
is
we
can
we
can
try
to
get
the
like
the
the
kitchen
sink
example
merged.
So
you
know,
essentially
what
we'd
be
doing
and
saying
that
is
like
hey.
We
have
some
idea
of
the
initial
scope
and
you
know,
while
it's
still
like
a
like
a
working
document,
we've
at
least
in
some
form
agreed
we've
drawn
A
Line
in
the
Sand
and
that
line
can
be
adjusted,
but
it's
somewhere
to
start.
C
I'm
trying
to
think
forward
a
bit
like
you
know:
how
much
do
we
want
to?
Actually
how
important
is
it
to
actually
enumerate
the
next
steps
after
this?
But
you
know
I'm
thinking.
Let's
say
we
arrive
on
some
conclusion
for
some
schema
definition,
language
we
say,
let's
just
say,
Q
for
argument's
sake.
C
You
know
we
need
to
build
those
prototypes
in
queue
and
then,
if
that
continues
to
pass
our
gut
checks,
then
when
we
say
hey,
Q
is
still
good.
We
we
think
some
of
the
prototypes
are
like
viable
and
we
haven't
run
into
any
brick
walls.
C
D
A
C
E
A
If
we,
if
we
can
have
what
we
agree,
is
the
ideal
configuration
and
then
we
can
kind
of
work
aside
from
that.
If
how
much
has
to
change,
to
use
a
particular
to
use
protobot
to
use
Json
schema
to
use
Q,
and
are
we
okay
with
that
change?
I
guess
might.
D
D
C
Seems
a
little
bit
aggressive
because
I
think
like
what's
going
to
inform
that
is
like
and
I
just
reordered.
Some
of
these
bullets
in
this
list
is
like
okay,
so
you
have
this
idea
of
your
initial
scope
and
that's
going
to
influence
your
the
the
prototypes
that
we
build
in
a
variety
of
languages
for
the
different
schema
representations
and
you
can't
really
evaluate
which
one
is
the
schema
representation.
C
E
C
Kind
of
reflects
the
ordering
that
these
bullet
points
are
in
here,
so
settle
on.
The
initial
scope
build
a
couple
of
prototypes
for
each
of
the
different
schema
representations
and
different
languages
and
from
those
prototypes
evaluate
the
pros
and
cons
of
each
and
then
we
can
have
a
sensible
discussion
about
like
which
one's
the
best.
C
C
D
I
mean
we
could
definitely
do
it
incrementally,
maybe
maybe
the
best
place
to
start
is,
is
just
to
take
one
each
one
of
these
bullet
points
in
here
and
try
and
get
a
separate
PR
for
each
one,
and
then
you
know
get
the
environment
variables
as
they
stand
today
into
a
configuration
schema
and
then
get
that
merge,
and
once
we
have
that,
then
you
know
we
could
potentially
start
on
the
prototyping.
From
that
point
on
right,
like
you,
wouldn't
necessarily
need
to
do
all
all
at
once.
Yes,.
C
Yeah
some
of
these
things
kind
of
depend
on
each
other
right.
So
you
know
the
environment
variables
and
multiple
processors
like
those
are
kind
of
interwoven
because,
like
the
environment
variables
today
you
can
configure
multiple
exporters
and
so
what's
implied
in
there.
When
you
configure,
multiple
exporters
is
like
each
one
is
associated
with
a
different
processor.
C
D
B
C
Some
boundaries
around
the
conversation
so,
like
a
conversation
around
some,
you
know
very
specific
thing,
doesn't
impact
the
the
pace
of
the
overall
structure.
Yeah.
C
So
then
the
to
do
would
then
change
from
you
know,
get
the
initial
scope
configuration
merge
to
like
iterate
on
initial
scope,
configuration
starting,
simple
and
increasing
in
complexity.
F
Alex,
just
to
make
sure
that
I
understand
this
step.
The
environment
variables
with
the
first
item
that
we
are
talking
about
is
providing
a
file
which
has
list
of
environment
variables
and
the
values
that
it
you
would
ideally
set.
Another
SDK
configures.
Let's
say
if
you
take
Hotel
traces
exporter
and
use
data
values,
so
is
it?
Is
it
that
file
that
it
reads
and
configures
the
SDK.
C
So
so
I
can
comment
on
this,
so
I
think
what
we
mean
by
this
is.
You
know
we
have
this
list
of
environment
variables
that
the
specification
describes
today
on
how
you
you
know
you
use
these
environment
variables
to
configure
your
SDK
we
want
to
minimally
represent.
We
want
to
minimally
make
sure
that
all
of
the
configuration
described
in
those
environment
variables
can
be
similarly
represented
in
a
file
based
configuration.
F
C
And
I
guess
like
so
you
know
the
prototypes
kind
of
depend
on
this
initial
scope
right,
but
it's
we
can
still
make
progress
on.
You
know
getting
this
Q
prototype
merged
just
to
you
know,
essentially
we're
building
out
some
of
the
tooling
and
then
as
the
as
the
target
changes,
because
the
initials
like
the
kitchen
sink
example,
the
initial
scope
changes.
We
can.
You
know,
update
that
prototype
to
reflect
to
reflect
what's
new
it.
So.
E
C
Yeah,
why
don't
we
do
that
and
so
I
guess
for
the
other
folks
on
the
call,
just
if
you're
interested
in
contributing
please
follow
along
in
this.
You
know
this
repository
and
you
know
I
will
be
posting
to
issues
and
pull
requests
there
and
feel
free
to
contribute
and
jump
in
and
Alex
and
Tristan
I
know.
The
last
couple
weeks
were
have
been
like
a
little
bit
stagnant.
In
my
opinion,
we've
been
in
a
bit
of
a
holding
pattern
because
you
know
it's.
C
You
can't
really
proceed
that
much
when
there's
about
to
be
this
working
group
that
that
starts
because
you
know,
then
you
just
have
more
things
to
catch
everybody
up
on
and
synchronize
on.
So
now
that
we've
established
this
we've
had
the
first
meeting
with
the
working
group.
Everyone
I
think
is
on
roughly
the
same
page
I
think
we
should
be
able
to
proceed.
C
All
right,
y'all,
well
I'll,
see
you
in
a
couple
of
weeks
and
until
then
I'll
see
you
on
slack
and
and
GitHub
so
have
a
great
Friday
yep.