►
From YouTube: 2022-06-23 meeting
Description
Instrumentation: Messaging
A
A
A
A
A
Yeah,
I
have
a
another
meeting
afterwards.
I
personally
think
so,
I'm
actually
at
a
bar,
because
it's
more
convenient
to
be
on
my
phone.
That's
why
my
webcam
is
activated.
B
Yeah
gotcha
yeah,
whatever
works
right.
A
A
C
Yeah,
it's
open
source
conference
or
the
open
source
summit.
The
open
telemetry
days
was
on
monday
and
I'm
staying
for
the
rest
of
it.
Since
you
know,
I
live
like
five
miles.
B
I
used
to
monitor
rama's
coming
up
and
I
sort
of
like
walking
distance
from
that.
So
I
used
to
have
no
excuses
to
miss
that
one.
C
My
understanding
is,
he
was
sick
and
couldn't
make
a
self.
D
C
I
did
get
to
meet
a
bunch
of
other
people
who
who
are
contributors
too,
so,
oh
yeah,
that
was
nice
yeah.
It's
really.
D
C
Mostly
from
like
the
community,
sick
and
the
governance
council,
I
know
elita
was
there:
austin
was
there
which
would
call
it
jeff
from
java.
Was
there.
C
E
B
Yeah
yeah
nice,
it's
been
a
while,
since
the
shark
morgan,
morgan
mclean,
I
think,
was
supposed
to
be
there.
Oh
no
he's
virtual,
oh
no,
never
mind
yeah
yeah,.
B
B
Cool
well
looks
like
everyone's
signed
in
this
looks
pretty
similar
to
last
week,
so
hopefully
it's
not
gonna
take
the
whole
time
and
we
can
get
back
to
conferences
or
working
yeah
thanks
everyone
for
joining.
If
you
have
anything
else,
you
wanted
to
add
to
the
agenda,
please
be
sure
to
add
it
here
or
we
can
pause
and
just
talk
about
at
the
end,
to
start
off.
Think
taking
a
look
at
the
progress
of
the
metrics
sdk
alpha.
B
I
think
this
is
week
by
week
getting
more
accurate
of
a
representation
of
where
we're
at
let
alone
our
progress.
So
I
added
a
few
more
issues
this
week
to
address
implementation
of
the
aggregators
themselves,
based
on
a
pr
that's
already
opened.
I
don't
think
that,
while
maybe
the
structure
may
change
a
little
in
the
pr,
I
think
we're
still
going
to
need
them
so
they're
accurate
issues,
and
I
think
that
that's
getting
a
little
more
accurate.
B
I
think
the
only
thing
that
isn't
really
documented
here
just
for
like
heads
up
is
the
connection
between
a
meter
and
the
instruments
and
implementing
the
instruments.
I
know
we
have
some
implement
like
the
instruments
that
kind
of
thing
and
that
might
encapsulate
some
of
this
work,
but
I
also
wonder
about
like
the
registration
of
those
and
how
that's
going
to
get
broken
apart.
B
So
just
a
heads
up
this
may
be
a
little
bit
high,
but
otherwise,
I
think
we're
doing
pretty
good
with
that
said,
we
kind
of
jump
into
the
project
view
of
the
metrics
work
here.
I
think
this
is
a
pretty
accurate
representation
of
the
things
that
are
currently
no.
This
isn't
accurate
because
I'm
seeing
a
couple.
B
Looks
like
yeah
your
your
pr
about
the
exporter,
though,
is
not
here
is
the
thing
that
I'm
missing.
B
Yeah-
let's
just
I
think
we
can
just
probably
jump
into
this
and
then
maybe
go
back
to
the
project
board.
I
don't
know
if
you
can
talk
too
much
aaron,
but
this
looks
it
looked
pretty
straightforward,
there's
still
some
pending
questions
from
david
here
that
needed
to
get
resolved,
but
I
think
that
we
could
probably
handle
this
asynchronously.
Is
there
anything
else
you
wanted
to
talk
about
about
this
pr.
C
No,
I
would
love
more
feedback
on
it
if
there
is
any
the
reason
why
I
wanted
to
get
this
is.
I
think
this
is
the
one
thing
blocking
implementation
of
exporters
and
or
readers
like
prometheus,
so
I
will
make
the
changes
when
I
get
a
chance,
it's
a
little
bit
iffy
right
now,
because
I'm
at
the
conference,
but
okay
usually
have
a
little
time
in
the
mornings
to
do
that
sort
of
work.
B
B
B
Issues
a
little
while
ago-
and
I
think
I've
updated
all
of
these,
so
this
should
be
pretty
accurate.
I
think,
to
the
current
status
of
the
project,
which
is
pretty
good
40
issues
done
where
our
pr
is
done,
so
we're
doing
we're,
making
progress,
slow
and
steady
as
they
say
right,
what's
open,
this
is
still
open.
B
I
think
we
had
talked
about
this
this
one
here
as
well.
I
wanted
to
ask
aaron
your
opinion
on
these
was
the
goal
to
close
this,
the
view
state
stuff
or
no,
this
one
was
to
rename
essentially
right.
C
God
I
can't
remember,
I
think
this
was
assumed
by
the
aggregator
discussion,
because
that
that's
where
the
logic
now
lives
right.
B
Well,
I
think
this
has
got
to
do
with
the
pipelining
is
what
like
in
josh's
example,
so
how
a
reader,
I
think
signals
into
some
sort
of
like
pipeline
that
it
needs
updates
from
a
particular
yeah.
Here
we
go.
Here's
some
pipeline
action
going
on
here
yeah.
I
think
this
is
the
last
one,
and
so
I
think
we
had
we
kind
of
like
said,
like
maybe
we're
gonna
rename
this
into
something
like
more
like
pipeline
or
add
some
sort
of
like
pipeline
yeah.
Why
don't
we
just
do
that.
B
I'm
gonna
do
that.
Okay,
I
think
that
answers
my
question
and
then
there
was
just
like.
I
think
you
are
at
a
good
point
on
well
is
may
18th,
so
a
little
while
ago
probably
need
some
refresher
on
this,
but
I
think
this
was
kind
of
the
the
concluding
direction
and
I
think
that
we
were
on
the
right
track.
We
obviously
needed
some
aggregations,
we
needed
the
export
metric
stuff
and
then
I
think
from
there
we
could
start
building
out
the
pipeline.
B
So
I
think
this
is
in
line,
and
I
think
that
rename
is
what
I
wanted
to
get
at.
I
kind
of
wonder
if
this
implementing
the
view
state,
which
would
then
translate
into
an
implement
the
pipeline,
isn't
really
needed
because
I'm
not
well,
I
don't
know
we
have.
We
do
have
a
pipeline
type
here.
Maybe
we
could
I'll
leave
this
for
for
what
it
is
as
the
implementation
here,
but
we
may
just
not
need
to
do
some
sort
of
like
structure
and
decide
on
that.
B
I
think
that
we've
got
a
pretty
clear
view
and
we
can
think
these
are
both
the
same
one.
But
I
I'll
I'll
read
it.
D
C
Yeah
I
I
find
the
structure
package
is
great
when
we
are
talking
about
something
like
the
aggregators,
where
there
is
a
need
for
a
common
interface
amongst
a
number
of
different
things.
But
it's
less
useful
when
we
have
the
build
a
thing
like.
B
B
Cool
okay.
That
looks
good,
I
think
otherwise,
I've
looked
over
these
issues.
I
didn't
really
have
any
other
questions.
I
don't
know
if
anybody
else
has
something
else
they
want
to
discuss
on
the
project
board
here.
B
Well,
I
guess
we
didn't
jump
into
this
pr.
This
is
going.
Maybe
we
could
talk
a
little
bit
about
there's
a
little
bit
of
a.
I
think
a
bike
shed
going
on,
but
I'm
not
opposed
to
that
at
you
know
at
this
level,
but
I
also
wanted
to
touch
base
on
some
sort
of
like
conceptual
ideas,
maybe
so
aaron,
maybe
I'll.
Let
you
ask
ask
your
question
here
so.
C
My
feeling
is
that
when
you
go
with
or
when
you
use
the
the
verbs
that
you've
chosen
is
it's
forcing
it
into
a
particular
way,
which
may
not
always
be
appropriate
for
how
we
implement
things.
I
also
don't
think
that
that,
in
particular
that
there's
a
value
for
having.
C
A
common
what
you
called
cycler
across
different
implementations
that
needs
to
first
take
the
implementation
and
then
already
break
it
out
into
it,
where
essentially
like.
C
Why
not
just
build
something
that
is
a
cumulative
sum
and
something
that
is
a
cumulative
histogram
and
not
have
to
try
and
share
the
common
layer?
Is?
Is
my
takeaway
to
this
right?
So
you
would
have
like
a
delta
sum
and
a
cumulative
sum,
and
there
are
some
similarities
to
them,
but
that's
just
because
they
do
something
similar
in
summing
stuff
right
and
that
breaks
away
the
need
of
having
this
common
cycler
package.
That
does
this.
The
fur
stuff,
which
is
actually
a
pretty
costly
logic
generally
like
having
to
do
the
type.
C
Switching
and
whatnot,
is
something
that
I
would
prefer
not
to
have.
If
we
can
avoid
it,
except
one
set
like
the
very
output,
but.
B
Yeah
well
type
swiping
is
a
pretty
unless
it's
changed
dramatically.
It's
a
pretty
lightweight
thing
for
the
runtime
to
actually
compute
like.
I
don't.
I
think
it's
a
cpu
cycle,
it's
pretty
quick,
but
I'm
also.
I
I
liked
the
idea
of
splitting
these
two
cumulative
cycler
versus
the
you
know,
building
it
into
the
implementation
because
it
separates
duties.
I
guess
is
my
understanding
or
my
goal
here.
The
problem
is
like
when
you
get
something
that
tries
to
do
too
much,
it's
it.
B
It's
going
to
compound
the
code
and
the
way
I
see
it
is
like
you're
going
to
have
two
different
implementations
that
are
going
to
be
very
intertwined
and
one's
going
to
need
to
maintain
its
own
state
and
the
other
is
going
to
need
to
maintain
it
only
for
a
cycle
and
so
how
how
that
state
is
maintained
is
then
baked
into
the
logic
versus.
B
If
you
split
it
out,
you
can
have
something
maintain
its
state
and
we
can
change
the
api
in
the
future
to
to
pass
state
across
those
boundaries,
and
I
think
that
if
that
structure
allows
for
greater
composability
was
my
intention
there.
I
I
don't
know
about
the
heaviness
of
it.
B
I
I
worked
out
an
implementation
of
this,
so
I
haven't
proof
or
done
any
benchmarking,
and
I
obviously
think
there's
a
second
and
there
probably
a
third
round
of
the
sdk
for
just
improving
benchmarks,
but
I
do
wanna,
like
you
know,
get
in
in
the
right
vicinity.
So
I
I
appreciate
those
kinds
of
concerns
at
this
point.
B
I
I
just
was
like
I
was
looking
at
it
and
you
know
you
are
right
that,
like
there
is
a.
B
I
guess
an
added
I
don't
know
so
I
look
at
it
like
how
do
you?
How
do
you
fold
in
aggregations
from
one
cycle
to
the
next
is
a
concern
of
the
cumulative
cycler
in
this
parliament's,
and
so
that's
also
not
something
for
the
delta
cycler,
and
so
I
guess,
like
the
thing,
is
it's
like
you're
going
to
have
to
signal?
If
you
do
it
in
the
other
way
or
some
sort
of
aggregator,
you
have
a
a
delta
sum
versus
a
cumulative
sum
right.
B
You
signal
the
delta
sum
and
it
just
resets
right,
and
you
signal
the
cumulative
sum
and
it
doesn't
reset.
I
guess,
is
the
only
other
option
so
you're
incurring.
I
guess
that
overhead
for
this
implementation,
where
the
the
sum
would
have
to
reset
for
the
cumulative
when
it
wouldn't
in
the
other
direction.
B
I
guess
that's
true,
but
the
other
way
is
also.
I
I
wonder
about
the
efficiency
of
how
how
that
structure
is
going
to
work
out.
I
haven't
worked
through
it,
though
I
have
to
think
I'll.
Think
a
little
more
about
that.
C
Just
also
remember
like
when
we're
when
we
first
create
these
aggregations,
we
have
all
of
the
information
that
we
need
and
it's
not
like
they're
going
to
be
dynamically
changed
from
delta
to
cumulative.
It's
either
going
to
be
a
delta
aggregation
versus
life
or
it's
a
cumulative
aggregation.
C
So
that's
one
of
the
reasons
why
I
just
think
it's
probably
simpler
for
us
to
have
the
the
code.
Like
you
know
when
you,
when
you
do
a
new
sum,
you
either
say
it's
a
delta,
temporality
or
a
cumulative
temporality
that
you
need
and
you
get
an
appropriate
thing
back
from
it
like.
C
I
guess
my
my
concern
is
that
you
know
the
aggregation
needs
to
know
both
of
those
together
more
so
than
just
how
it
manages
to
update
or
to
handle
updates.
C
E
C
As
long
as
we
have
like
my
main
concern
here
is
that
we
have
two
separate
interfaces
for
writing
and
reading,
because
those
are
going
to
be
used
completely
separately
by
your
right
path,
which
is
your
instruments
and
your
read
path,
which
is
your
readers,
because
they
don't
have
a
very
common
view
of
how
they're
grouped
just
that.
The
underlying
the
underlying
aggregation
layer
is
pointed
to
in
different
ways.
Right.
B
Okay,
yeah,
I
I
got
you
yeah
and
I
I
agree.
I
think
that
that's
that's
it.
It
also
is
like
how
you
want
to
store
them.
I
know
I'm
looking
at
a
lot
of
examples.
We
want
to
store
like
that
that
read
interface
with
the
meter
and
you
want
to
store
the
right
portion
of
it
with
the
or
the
instrument
so
having
a
separate,
you
know
you
can
obviously
split
them
out
after
the
fact,
but
I
think
that
if
we
structure
it
this
way
it'll
help
helping
that
pay.
B
That
way
I'll
go
back
and
take
a
look
at
the
the
combination.
Here,
though
aaron
I,
I
wanna
wanna
spend
some
time
thinking
about
that.
B
Yeah,
okay,
cool,
then
I
think
that
and.
C
I
also
want
to
point
out
that
this
is
all
internal,
so
it's
subject
to
change
and
I'm
I'm
not
too
tightly
wed
that
it
needs
to
be
one
particular
way
or
another.
So
if
this.
B
Yeah
I
and
I
I'm
very
strongly
opinionated
that
performance
issues
like
should
just
be
put
into
an
issue
and
having
a
working
implementation
and
alpha
releases
are
important,
but
I
I
see
your
point
aaron
and
I
kind
of
want
to
spend
some
time
thinking
about
that,
and
so
hopefully,
by
the
end
of
today
I'll
have
a
response,
whether
that's
we
should
put
it
in
an
issue
or
if
it's
I'm
going
to
make
a
change,
really
quick.
I
think
it's
my
goal.
G
I
can't
see
anything
I
haven't
seen
you
guys
for
a
while.
I
just
noticed
that
josh
isn't
here,
and
I
know
that
I
was
reacting
to
tyler
what
you
said
about
the
performance
stuff.
I
know
josh
was
made
in
several
times,
but
he
felt
there
were
important
design
considerations,
in
other
words,
like
we
couldn't
defer
the
performance
consideration
because
fixing
it
won't
require
a
different
design.
G
So,
just
thinking
about
that,
I
know
I've
seen
that
a
lot
in
the
metric
stuff
part
of
that
is
what's
kept
me
from
studying
it
much
because
I
know
it's
been,
it's
caused
it
to
churn
a
lot
of
the
time
if,
in
this
case,
you
think
that
it's
just
a
thing
we
can
fix
later.
I
can
see
referring.
B
Yeah-
and
it
is
specifically,
this
is
on
an
internal
package,
and
so
these
implementation
details
are
not
leaked
to
an
external
api.
In
fact,
I
think
that's
one
of
the
biggest
concerns
that
I'm
having
right
now
is
to
minimize
that
publicly
leaked
api
and
we're
doing
a
really
good
job
in
my
opinion
and
so
yeah.
I
think
that
performances
is
important
ultimately,
but
at
this
point
it's
about
you
know
getting
the
right
apis
and
then
the
internal
structure.
B
I
think
we
want
to
try
to
get
it
working
and
accurate
and
then
from
there
builds
or
refactor
based
on.
That
is
what
I
was
trying
to
say.
There.
B
Depend
on
them
right
exactly
and
that's
that's
the
goal,
and
so
honestly
I
mean
I
could
see
also
getting
the
alpha
release.
People
just
going
like
this
is
garbage
because
it
is,
you
know,
allocating
every
single
cycle,
but
I'm
okay
with
that
feedback.
As
long
as
my
response
is
well,
then
wait
for
the
beta
release.
You
know
so,
yes,
okay,
okay,
let's
see,
I
think
that
was
it
for
project
boards.
B
The
only
other
thing
on
the
agenda
is
aaron's,
calling
out
some
review
of
the
getting
started.
Doc
refactor,
which
has
I
don't
know.
I
can't
see.
C
Anybody
anymore:
it's
it's
a
little
bit
old,
it's
about
two
months
old
now
or
a
little
over
a
month
old,
but
they've
finished
churning
on
it.
I
walked
through
it
at
one
point
and
I
had
some
very
minor
feedback,
we're
looking
for
I'm
just
looking
for
a
second
approver
to
go
and
sign
off
on
it.
B
Yeah,
I
I'll
be
honest.
I
was
a
little
bit
worried.
It
doesn't,
I
think,
come
to
parity
with
what
we
currently
have.
One
of
the
main
things
that
stood
out
to
me
is
that
the
example
that's
built
here
is
not
included
in
the
code
base,
so
users
don't
have
a
working
example
to
go
from
I'd.
Ask
for
that.
There's
some
minor,
I
think,
go
isms.
B
I
I
change
in
the
example
as
well,
but
the
only
other
thing
on
top
of
that
would
be
linking,
and
I
do
want
to
know
what
we
think
about
with
the
existing
fibonacci
example.
If
those
dots
should
be
moved,
it
seems
like
they
overlap
so
heavily
and
if
we
just
want
to
leave
the
example
just
sitting
in
the
directory,
but
I
think
as
a
starting,
I
wanted
to
see
at
least
some
workable
code
example
to
match
the
parity
here.
C
I'd
be
okay
with
either.
I
would
love
to
put
that
feedback
into
the
actual
pr
so
that
we
can
actually
get
people
working
on
it
yeah.
C
I
agree
that
having
workable
code
like
actual
go
file
with
that
code
in
it
would
probably
be
the
best
scenario.
The
challenges
is
this:
is
you
know
this
targets,
something
that
isn't
done
through
the
godox
and
whatnot
right?
This
is
targeting
the
the
main
website.
B
Yeah,
okay-
and
I
did
add
this
as
a
comment
less
than
an
hour
ago-
so
hopefully
do
you
know
the
carter
mp,
oh
honeycomb,
okay,
I
don't
yeah,
okay,
it.
B
Okay,
yeah,
okay,
but
yeah.
This
is
the.
G
G
So
you
could
argue
okay
well,
when
would
it
you
know,
but
it's
because
it's
not
handling
clean
shutdown
of
the
server,
but
it
kind
of
sets
people
up
to
for
this
fire
and
forget
treatment
of
managing
the
exporter
when
it's
using
a
batch
fan
processor.
So
it's
going
to
be
publishing
asynchronously
and
not
waiting
for
it
to
finish
that
job.
B
And
I
I
think
I
noticed
that
in
a
few
other
systematic
issues
with
some
of
the
setup,
but
it's
really
hard,
I
think,
to
comment
in
the
code:
that's
in
the
dock,
so
I
was.
I
think,
that
at
the
core
I
wanted
a
compilable
example
to
then
like
work
on,
and
then
we
can
refactor
the
docs
to
match
that.
G
C
So
I
agree,
but
I
feel
like
something
is
better
than
is
something.
B
We
definitely
keep
finding
bugs,
but
I
I
also
think
that,
like
you
know,
the
goal
here
for
the
project
is
to
have
this
uniform
example
from
which
all
getting
starteds
are
going
to
be
built
from,
and
so
I
I
think
that,
like
that's
an
admirable
goal,
and
I
think
that
we
should
continue
to
try
to
pursue
that,
but
I
want
to
make
sure
that
we
get
it
right
and
I
don't
want
to
change
it
to
be
something
less
in
the
process.
B
G
G
Are
there
any
easy
ways
to
make
trace
publishing
optional,
like
they
were
looking
to
be
able
to
pass
in
some
parameters,
or
you
know,
passing
an
argument.
Rather
that
would
defeat
tracing,
and
I
started
talking
about
noaa,
tracers
and
asking
why
and
and
their
concern
was
like
they
saw
the
tracing
as
a
luxury
that
they
couldn't
perform.
It
was
slowing
their
programs
down
too
much.
G
Oh,
that's
weird,
so
I
started
pushing
and
it
turns
out
that
they
were
not
using
the
batch
span
processor,
so
I'm
pretty
sure
that
they're
paying
a
synchronous
cost,
and
so
you
know
I
started
pushing
for.
Oh,
you
should
use
that
and
it
makes
the
publishing
asynchronous.
But
then
now
you've
got
to
clean
up
thing
to
consider.
You
know
how
are
you
cleaning
up?
They
had
no
cleanup
in
their
program
and
probably
also
need,
since
it
just
runs
still
until
it
dies.
G
It's
never
really
supposed
to
end,
but
still
it's
something
to
think
about.
So
it
was
nice
to
see
that
just
today
that
this
example
shows
using
the
batch
span
processor
because,
apparently,
if
you
don't,
you
may
not
be
able
to
afford
it,
and
I
had
never,
I
think,
from
day
one
using
this
library.
I
I
have
the
battery
processor
and
so
I've
never
tried
to
use
it
synchronously.
B
Yeah
I
mean
it's,
it's
bad.
In
fact,
I
think
I'm
trying
to
like
find
the
code
right
now,
but
I'm
pretty
sure
we
updated
the
docs
to
say,
like
you,
don't
want
to
be
using
the
the
simple
spam
processor
in
production.
That's
a
bad
idea.
I
have.
H
All
of
the
examples
I
think
too,
we
updated
at
one
point:
they
used
to
use
the
simple
spam
processor,
but
we
were
getting
that
exact
same
feedback.
The
people
were
using
the
the
getting
started,
examples
to
get
going
and
continuing
to
use
the
simple
spam
processor,
which
was
then
causing
them
a
significant
performance
penalty.
So
we
updated
them
all
to
use
the
batchman
processor
to
try
to
nudge
people
in
the
right
direction.
B
B
This
way,
because
it's
easier,
there's
no
need
to
flush
and
then
you
just
ensure
to
like
you
know,
visualize
the
traces
that
are
coming
out
but
yeah
as
you
were
saying,
and
is
there
anything
you
pointed
out
like
we
rewrote
it
because,
like
we
saw
exactly
that,
like
people
just
start
copying
it
and
that's
not
what
you
want
and
I
have
found
it
in
the
docs
like
we
have
definitely
updated
doc.
Saying
like
this
is
not
recommended
for
production
use.
B
Okay,
yeah.
That's
that's
really
good
feedback,
though
thanks
also
for
digging
deeper
into
that,
because
if
you
just
took
their
initial
response,
I
yeah,
I
don't
think
we
would
have
got
to
the
underlying.
G
G
People
who
grab
grab
this
stuff.
From
the
perspective
of
how
can
I
copy
and
paste
the
smallest
amount
of
code
and
get
going
as
opposed
to
in
like
us,
like
we're,
eager
participants,
we're
going
and
looking
for
all
the
options
and
want
to
feel
out
what
they
do
and
try
to
tweak
it
to
the
best?
And
I
think
there
are
some
people
who
assume
somebody
else
already
figured
all
that
out
and
that
they're
not
gonna
have
to
do
much
to
get
that
the
better
behavior
out
of
them.
C
I
would
keep
an
eye
out
for
some
communication
from
I
believe,
honeycomb
driving
this
and
getting
a
common
launcher
across
vendors
to
kind
of
ease,
a
proper
setup
of
tracing
and
eventually
metrics
and
such
I'm
not
sure
the
details
of
it
per
se,
not
100
sure
at
least,
but
I
know,
there's
been
talks
between
people
at
honeycomb,
people
at
white
stuff
and
maybe
even
new
relic.
I
believe,
has
been
in
there
to
help
ease
that
burden.
C
B
Yeah
yeah
one
of
the
reminding
them
also
yeah.
I
maybe
we're
gonna,
say
the
same
thing.
Who
knows
so
one
of
the
things
that
I've
also
like
tried
to
work
on
in
the
past
and
I've
gotten
like
a
little
bit
into
is
this
could
be
really
beneficial
to
have
a
standardized
configuration
language
so
having
some
sort
of
like
markdown
syntax
to
provide
configuration.
So
therefore
you
know
that
configuration
works
across
the
board
and
then
you
can
say
like
well.
B
Here's
a
you
know:
a
testing
configuration
standardized
that
you
can
use
in
java.
Python,
go
ruby
all
these
other
languages
and
here's
the
production
version,
which
you
know.
Maybe
the
testing
has
a
synchronous.
You
know
thing,
but
then
the
production
obviously
is
going
to
configure
a
batchman
processor.
B
I
think,
if
that's
also
another
option
that
we've
been
looking
at
trying
to
do
for
a
while
now
is
a
standardized
configuration
effect,
I'm
on
the
hook,
but
I'm
spending
time
trying
to
build
metrics
just
to
get
here
and
go
yeah.
G
Yeah,
it
reminds
me
just
by
way
of
analogy
of
things
you
see
in
photography
with
cypher
suites,
where
it's
a
recipe
of
like
15
choices,
all
of
which
seem
independent
at
first,
but
then
you
wrap
them
up,
and
you
say
these
work
well
together
and
here's
a
shorthand
name
for
it.
So
you
know
you
think
about
you
can
figure
this
stuff
like.
Oh,
I
got
a
batch
fan.
Processor,
maybe
there's
a
certain
buffer,
and
I
want
otlp
and
I
want
grpc
and
there's
so
many
choices
that
you
know.
G
Like
I
know
in
my
code,
I
tend
to
use
the
same
ones
again
and
again,
but
somebody
else
can
come
along
and
not
make
those
choices,
and
I've
heard
the
word
profiles
thrown
around.
I
really
don't
know
what
it
means
in
this
context,
but
I
can
imagine
that,
being
like
you've
got
a
little
slug.
You
know
a
15
character,
slug
or
something
that
basically
identifies.
This
is
a
common
configuration
choice.
G
This
is
a
problem
to
do
and
which
put
that
whole
recipe
together,
but
also
a
config
file,
yeah,
something
that
we've
discussed
before
in
the
kubernetes
project.
They
have.
This
idea,
called
component
config,
never
really
took
off.
The
idea
was
to
try
to
get
away
from
command
line
flags
and
put
the
put
the
configuration
into
conversion
schema,
schema,
controlled,
config
files
so
that
you
can
evolve
them
over
time,
but
try
to
get
away
from
the
limitations
of
what's
easy
to
express
with
command-line
flags
only
only
took
on
a
few
components.
B
Yeah
david
jiminy
thoughts
on
this.
F
Component
config
is
great.
I
like
the
idea
of
having
versioned
version
it.
I
will
say
the
file
format
looks
like
a
kubernetes
object,
but
that
just
means
that
it
uses
the
kubernetes.
I
don't
even
know
what
they're
called
like
parsers
like
to
parse.
F
Stick
them
in
an
api
server
yeah
for
it
to
be
useful.
So
I'm
not
sure
if
there
are
other
ties
to
kubernetes,
but
it
is
very
nice
to
have
a
version
config
where
you
can
say
actually
we're
releasing
a
v2
of
this
particular
file
and
there's
some
sort
of
internal
representation
that
everything
converts
into
and
you
can
manage
that
and
that
sort
of
machinery
is,
is
very
nice.
B
Yeah
all
good
things
to
think
about.
I
also
like
aaron's
universal
launcher
thing,
because
every
company
now
has
their
own
launcher
or
even
users,
building
their
own
launchers,
but
yeah.
These
are
all
good
user
feedback
pain
points.
I
wish
we
had
more
developer
focus
to
progress
these
things
faster,
but
we're
working
on
them
they're
on
the
pro
or
on
the
roadmap.
By
the
way,
stephen,
I
don't
know
if
you're
aware,
but
yes.
B
B
Awesome,
I
think,
then
we
can
probably
end
it
here
thanks
everyone
for
joining.
I
definitely
appreciate
your
time
and
effort
in
the
project.
Overall,
we'll
see
you
all
next
week
same
place
same
time
or
asynchronously
bye.
Everyone.
Thank
you.
Thank
you.