►
From YouTube: 2021-06-22 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
B
B
C
My
understanding
is,
this
was
filed
from
the
go
sig
because
there
was
a
remnant
from
open
tracing
and
our
open
census,
and
the
question
was:
do
we
delete
it
or
try
to
splick
it
out.
D
Well,
it's
a
little
bit
more
than
that.
It's
also
there's
a
functional
element
that
was
missing,
that
this
is
adding.
There's
this
concept,
that
if
you
have
multiple
trades
providers
or
more
trace
routes,
that
you
need
to
be
able
to
correctly
get
a
span
if
you're
past
explicit
context
and
the
right
trace
path,
trace
provider
and
that's
what
this
was
trying
to
emulate.
So
yeah,
it's
a
holdover
from
open
tracing,
but
it's
also
is
is
functionality
that
was
missing
that
we
found
when
we
were
releasing.
This
users
were
needing.
A
E
Yeah
sure
so
there's
a
comment
later
on,
where
I
described
the
http
instrumentation,
where,
if
an
instrumentation
author
wants
to
use
our
general
http,
git
post,
put
helpers
that
uses
a
default
transport
that
uses
the
global
tracer
provider,
that's
not
usable
in
a
situation
where
there
are
multiple
tracer
providers
in
play
and
an
instrumentation
author
can't
know
whether
there
are
multiple
tracer
providers
in
player
or
not
because
they
have
no
control
over
the
sdk.
E
That's
installed
in
the
application,
so
that's
totally
unusable
to
them
and
even
using
an
explicitly
constructed
hotel
transport
with
a
tracer
provider,
that's
provided
to
them
is
somewhat
risky
because
they
then
need
some
way
to
know
which
tracer
provider
do
they
use
for
any
given
request.
This
solves
that
by
enabling
them
to
take
the
request.
The
the
span
from
the
request
context,
if
one
is
active,
then
use
the
tracer
provider,
that's
associated
with
that
span,
to
construct
a
new
tracer
and
starting
to
span
so.
F
F
E
The
tracer
provider,
which
is
the
the
export
pipeline
and
it
is
span
related
because,
while
we
could
attach
a
tracer
provider
to
a
context,
alongside
of
a
span
doing
so
runs
the
risk
of
the
tracer
provider
and
the
span
becoming
dissociated,
whereas
the
span,
at
least
in
any
implementation
I
can
think
of,
is
going
to
carry
a
connection
to
its
tracer
and
thus
its
tracer
provider,
so
that
when
it
and
when
it
ends
it
can
provide
all
of
its
span
data
to
the
tracer
provider
to
process
through
the
processing
pipeline.
F
G
Okay,
can
I
make
a
have
a
clarifying
question?
Is
this
the
case
where
you're
talking
about
the
default
http
so
for
people
who
don't
know
go
there's
like
a
default,
http
client,
that's
essentially
implemented
as
a
global
itself,
where
you
just
say
get
post
without
first
creating
a
client.
E
E
That's
illustrative
of
the
problem:
it
is
a
more
general
problem.
We
had
a
conversation
with
the
one
of
the
authors
of
buildkit
who
was
updating
their
instrumentation
from
open
tracing
to
open
telemetry
and
because
of
the
very
deeply
nested
component
structure
that
they
have
and
their
their
requirement
that
they
not
depend
on
globals.
G
But
but
again,
is
it
the
case
so
normal?
I
guess
here's.
What
I
want
to
tease
out
is
is
this.
Turning
into
the
new
guidelines
yeah,
we
don't
want
to
steer
slack
the
new
guidelines
being
that
you
should
never
hand
instrumentation
a
tracer
provider,
and
you
should
always
be
dynamically.
G
D
No,
I
don't
think
that's
the
intent
of
this
pr.
I
think,
there's
there's
a
comment
to
hire.
That
yuri
has
a
very
similar
situation,
and
if
this
is,
if
this
is
designed
as
like
a
new
way
to
start
spans,
essentially
and
like
it's
going
to
be
a
replacement
for
the
old
one,
but
it
is
is
intended
to
be,
I
think,
a
supplement,
rather
than
a
replacement,
if
you're
expecting
to
start
a
span
in
any
way
that
you
know
you
don't
actually
understand.
D
If
there's
a
parent
or
you
don't
know,
you
know
like
you're,
propagating
something
and
you're
getting
it
from
the
propagation.
You
need
to
be
using
the
a
tracer
provider
from
the
global,
a
tracer
provider.
That's
past
the
instrumentation,
or
something
like
that.
I
think
this
is
something
where
you're
you're,
looking
where
you're
receiving
a
context
and
like
in
the
case
of
build
kit,
you
see
like
well.
D
If
there
is
already
some
spans
started
here,
I
want
to
make
sure
that
the
spans
that
I
create
are
going
to
be
in
the
tracing
pipeline
of
whatever
that
span
was
so
in
because
it's
think
about
it.
From
like
a
multi-tenant
perspective,
if
you
have,
you
know
a
lot
of
different
endpoints
that
you
want
to
send
your
traces
dependent
on
some
sort
of
sampling
parameters,
maybe
just
holistically
different
like
customers,
or
something
like
that
right,
then
you
want
to
be
able
to
like
partition
where
those
traces
are
going
to
be
going.
D
And
how
do
you
do
that
from
the
build
kit
perspective
like
if
you're,
just
a
generic
library
where
things
are
coming
in
and
out,
and
you
don't
have
the
context
as
to
like
where
this
should
be
going,
where
this
should
be
going,
it's
really
hard
to
actually
like
provide
functionality
from
the
tracing
library
or
from
any
library's
perspective.
D
G
That
so
that
makes
that
makes
sense
to
me,
but
I
guess
and
to
be
clear:
I'm
not
I'm
not
being
accusatory.
I'm
trying
to
suss
out
whether
we've
got
reality
is
not
matching
our
model
in
some
significant
way,
because
it
seems
to
me
like
what
you're
saying
is.
G
You
may
be
in
a
some
kind
of
multi-tenant
situation
where
there
are
multiple
tracer
providers
flying
around
and
the
provider
you
want
to
have
needs
to
be
in
some
specific
pipeline.
Okay,
fair
enough,
but
it
seems
to
me
like
if
I'm
instrumenting,
like
an
http
client,
a
db
client
like
almost
any
kind
of
shared
library.
Wouldn't
I
be
in
that
situation
where
I
would
need
to
accommodate
people.
G
G
If
I
don't
support
this
dynamic,
tracer
provider
approach,
it
seems
like
that
would
mean
my
instrumentation
wouldn't
work
with
anyone
who
needed
to
do
that.
E
G
C
Yeah
go
ahead,
two
points.
I
do
remember
ancient
conversations
in
this
group
earlier
on
about
possible
solutions
that
are
different
here.
One
is
that
you
know
if
I
want
to
get
my
meter
provider,
I
would
like
to
know
the
current
sdk
not
in
from
the
contacts,
not
the
tracer
provider,
but
like
the
package
of
all
my
providers
and
the
one
of
the
ideas
that's
come
up
is
to
put
it
in
the
context
like
instead
of
saying
context
get
my
current
span
get
my
trace
provider.
C
It
says
something
more
like
context
get
my
current
instrumentation
package
get
my
current
instrumentation
provider.
I
don't
know
a
telemetry
provider
is
probably
the
right
word.
Actually
that's
those
are
both
of
my
topics.
I
wanted
to
say
that
we've
talked
about
this
in
the
past
and
possibly
someone's
gonna
wanna
in
a
multi-tenant
environment
get
to
their
metrics
provider
as
well
from
the
context
yeah.
G
G
My
point
real
quick.
I
guess
I
want
to
emphasize
that
if
it
turns
out
this
is
like
a
real
thing
that
we
have
to
support.
It
seems
to
me
that
it
does
fundamentally
change
the
the
advice
and
best
practices
that
we
would
be
giving
out
to
instrumentation
authors,
at
least
at
least
in
go.
A
F
Because,
usually
when
you
do
multi-tenancy,
you
construct
objects
for
every
tenant
or
or
things
for
every
tenant.
So
so,
essentially,
why
is
not
a
tracer
provider
passed
as
part
of
initialization
of
the
build
goal
build
and
it's
it's?
That
is
a
singleton,
because
that's
that's
how
I
feel
that
that
that
the
build
kit
is
a
global
and
we
are
trying
to
work
with
the
global.
D
Yeah,
I
think
I
see
what
you're
saying
and
I
think
they
in
conversation
with
them
were
very
hesitant
to
provide
this
functionality.
I
I
think
it's
not
necessarily
correct
to
say
that
they're
they
only
have
a
single
instance
running
they.
D
They
showed
these
really
interesting,
complex
examples
where
they
were
tracing
across
these
dynamic,
build
environments
where
things
would
be
doing
call
outs
to
cloud
environments
and
that
kind
of
thing-
and
I
could
totally
see
the
situation
where
you
have
all
these
like
really
complex
processes,
and
maybe
in
some
situations
you
want
to
have
a
higher
sampling
rate.
That's
going
to
you
know
a
really
short
lived
environment
that
you
can
see,
really
high
fidelity,
traces
and
maybe
a
longer
term
one.
That
is
not
doing
something
like
that.
D
Maybe
something
these
are
one
of
the
situations
that
I
kind
of
came
up
with.
Another
maybe
span
limits.
If
you
have,
you
know
some
sort
of
paid
back-end,
you
want
to
like
really
restrict
your
spam
limits
or
something
like
this,
and
so
they
I
don't
know
they
did
show
that
there
was
like
a
lot
of
reason.
I
think
behind
it
and
then
the
other
side
of
things
is
they
were
hesitant
to
require
that
to
have
build
kit
actually
trace
things
correctly.
D
You
need
to
update
their
configuration
and
that
configuration
now
needs
to
be
passed,
the
tracer
provider,
or
they
have
to
get
this
single
global.
Then
the
single
global
obviously
can't
handle
this
multi-tenant
and
in
fact,
like
the
single
tracer,
provided
you
pass
to
the
initialization.
It
could
work
really
well
if
you
want
to
start
their
own
spans,
but
it's
not
necessarily
guaranteed
that
if
it's
going
to
come
back
and
and
be
the
exact
tracer
provider
that
you
apprehended
for
the
span
that
you
you're
trying
to
annotate
or
create
a
child
under
yeah.
F
And
what
about
how
did
open
tracing
solve
this
problem?
Did
you
have
a
get
tracer
on
the
span,
get
tracer
or
just
a
tracer
method.
D
Yeah
on
the
span,
yeah
yeah-
and
this
that's
exactly
where
this
conversation
started.
They
came
to
us
and
said,
like
you,
just
removed
this,
we
need
this
and
I
and
we,
I
think,
correctly
removed
it
because,
like
there's,
no
guarantee
that
the
tracer
that
the
span
is
associated
with
is
the
same
instrumentation.
So
you
don't
really
want
to
be
reusing.
A
D
Well,
but
as
anthony
kind
of
pointed
out,
like
there
there's
a
chance
there,
that
your
provider
doesn't
actually
match
your
spam
at
that
point
like
you,
can
have
a
span,
get
updated
in
the
context,
and
then
the
provider
is
inaccurate
for
that,
and
I'm
not
opposed
to
this
idea
that,
like
we
could
totally
provide
this
convenience
function
as
well,
where,
if
you're
given
a
context,
if
the
span
is
embedded
in
the
context,
we
could
add
another
wrapper
method
or
function
around
that.
D
That
says,
like
just
give
me
the
tracer
provider
from
this
context,
and
it
can
do
like
all
of
the
disentangling
of
like
well,
I'm
going
to
look
for
the
span.
If
the
span
has
a
tracer
provider,
I'm
going
to
give
you
back
the
right
tracer
provider
and
it's
just
like
a
convenience
function
in
some
ways.
I
think,
if
that's
totally
viable,
but
there
has
to
be
some.
Some
association
with
the
spam
is
the
problem.
G
Does
I
mean,
does
there
I
mean
you
should
be
the
sdk?
Well,
I
guess
you're
right
you're
saying
you
have
to
do
this
at
the
api
level
because
you
don't
know
which
right
exactly.
D
Yeah
yeah
you're
all
showing
faces
that
anthony
and
I
were
having
as
well
like
boston.
D
Yeah
and
like
one
of
the
things
is,
is
like:
if
if
this
is
a
ghost
specific
thing,
I
think
that
that's
why
anthony
wrote
the
language
in
this
pr
to
be
something
of
the
it's
a
recommended,
but
it's
not
a
requirement
just
because
some
languages,
this
may
not
be
a
thing
like
it
may
just
there
may
never
be
the
situation
that
this
could
actually
happen.
D
So
there's
never
a
reason
for
it
and
I
think,
if
that's
a
viable,
you
know
thing
to
consider,
but
I
definitely
think
that
in
go
like
we're
seeing
a
case
in
the
wild
like
and
and
a
request
from
users.
E
F
For
for
me
to
learn
new
things
does
any
other
language
besides
go
in
open
tracing.
Have
this
capability.
C
F
E
It
it
would
be
perfectly
fine
if
we
were
to
say
this
doesn't
belong
in
the
spec,
we're
not
going
to
specify
it,
but
go
can
have
this
implementation
and
we'll
be
fine
either
we
specify
it
and
we
we
save
compliance
with
the
spec
or
we
don't
specify
it.
We
don't.
What
I
would
like
to
avoid
is
specifying
something
that's
different
from
where
we're
going
right
now.
F
J
J
Okay-
and
this
is
fine
like
I
was
thinking-
maybe
there
is
an
easy
way
to.
E
E
D
Mm-Hmm,
I
do
know
that
we
have
fielded
more
than
just
this
user's
request
about
this
one
before
and
we
always
were
able
to
handle
the
global
choice
provider
and
it
satisfied
them.
E
Satisfied
should
probably
be
in
quotes
there,
because
I
think
redis
had
similar
concerns,
but
they
they
tolerated
the
use
of
the
global,
but
they
would
prefer
not
to.
G
Yeah,
I
I
wonder:
if
we're
encouraging
a
bad
practices,
I
guess
we
should
probably
move
on
from
this
subject,
because
for
backwards
compatibility,
it
does
seem
to
me
like
on
a
certain
level.
We
would
have
to
provide
it
and
go.
That's
that
to
me
seems
like
a
hard
line
there,
but
I
kind
of
wonder
if
we
got
into
it
with
these
people
disentangling
it.
This
is
something
that
should
be
happening
at
some
other
part
of
the
pipeline.
G
F
I
don't
know
if
we
have
enough
time
to
to
brainstorm
all
the
things,
but
I
it
will
be
interesting,
tyler.
You,
you
mentioned
couple
of
other
options
to
to
implement
this,
maybe
maybe
like
the
one
with
the
helper
that
passes
the
context
and
stuff
instead
of
having
a
method
on
the
interface.
So
there
are
a
couple
of
solutions
that
we
we
may
be
able
to
to
give
to
the
users.
It
will
be
interesting
to
think
about
all
of
them
see
which
one
is
the
trade-off
and
which
one
is
the
right
one
to
do.
Well,.
D
I,
the
one
I
described,
still
requires
the
span
to
provide
a
public
method
to
get
the
tracer
provider
because,
like
you,
have
to
remember
it's
coming
from
the
the
api
so
yeah,
we
could
definitely
do
something
in
the
sdk
where
you
could
ask
for
the
transfer
provider
and
it's
some
sort
of
private
thing.
That's
that
we
can,
you
know
handle,
but
the
instrumentation
doesn't
have
access
to
that
at
the
time.
So
it
needs
to
have
a
public
method
on
the
span
to
get
the
tracer
provider
and
I
can
wrap
our
convenience
function
around
it.
G
E
F
D
Option
you
could
do
that,
but
we
haven't
released
our
stable
release
yet,
and
we've
included
this
in
our
rc
right
now
and
so
there's
it's
equivalent
to
have
it
in
the
interface
and
since
it's
not
breaking
any
sort
of
compatibility.
Issues
like
it
would
be.
That's
a
great
way
to
describe
is
really
good
if
we
had
to
maintain
compatibility
going
forward,
but
in
fact.
F
Yeah
but
around
that
as
well.
The
reason
why
I'm
thinking
about
this
solution
is
actually
because,
if
we
find
no
reason
to
add
this
to
any
other
language,
maybe
for
consistency
of
having
the
functionality
on
the
span
perspective
almost
the
same
across
languages,
maybe
better
to
do
this
trick,
hack
and
and
well
news.
D
D
Comment
that
there's
two
other
languages
that
people
are
asking
for
this
functionality
and-
and
I
think
that
also
having
it
on
the
span-
is
not
necessarily
a
problem.
I
totally
agree
that,
like,
if
having
the
methods
on
the
span
be
different
than
other
languages,
that's
a
problem,
but
having
an
additional
method
on
this
fan,
I
don't
see
it
as
being
a
negative.
You
can
come
from
another
language
and
still
use
our
span.
Just
fine,
it's!
You
can
also
use
this
other
thing.
That's
added
to
the
span.
Okay,.
F
F
Next
one
is
an
announcement.
I
think
raleigh.
B
Put
this
one
or
oh
yeah
yeah,
so
so,
historically,
we
splitted
the
the
matrix
spec
into
the
api
sdk
and
the
data
model,
just
because
at
the
time
there
there
were
too
many
things
and
and
now
like
we
handled
like
many
many
items
so
so
now
we're
trying
to
merge
these
two
sig
meetings
back
all
the
existing
meeting
slots
will
remain
unchanged.
It's
just
there's
no
dedicated
data
model
or
api
sdk
meeting.
B
The
meeting
will
be
used
to
talk
about
anything
that
is
related
to
the
metrics
bank,
so
that
this
can
help
us
to
accelerate
the
speed.
So
just
for
people
who
who
were
not
able
to
attend
a
specific
meeting
due
to
the
time
zone
challenge
now,
like
you,
got
the
good
coverage
just
for
your
information.
B
Okay,
this
will
start
effective
right
now.
So
after
this
yeah
30
minutes
later,
we'll
have
the
meeting.
That
is
all
purpose
metrics.
Thank
you.
Riley.
G
Yeah
this
is
onorag's
otep.
I
wanted
to
bring
attention
to
it,
so
this
is
an
otep
to
have
a
dig
into
how
we
handle
instrumenting.
G
What
we're
seeing
when
people
go
to
instrument
right
now
with
metrics
is
they
are
recreating
a
lot
of
the
functionality
that
tracing
has
the
classic
case,
being
people
want
to
instrument
an
http
request
and
they
want
metrics
and
they
want
a
metric
called
request,
duration
and
so
they're,
creating
a
timestamp
and
passing
it
around
and
then
creating
another
time
stamp
later
and
then
measuring
duration,
but
they're
not
using
a
monotonic
clock
and
they're
doing
it
out
in
public,
and-
and
these
are
all
things
that
the
tracer
has.
G
Likewise,
when
recording
attributes
and
things
like
that,
recording
all
of
that
stuff
multiple
times
seems
like
overhead,
so
we've
been
looking
for
a
way
to
what
would
be
a
good
way
to
hand.
People
a
higher
level
object
that
handled
things
like
configuring,
configuring
this
whole
massive
instrumentation
people
are
going
to
need
and
then
simplifying
the
actual
act
of
instrumenting
their
code.
G
G
This
looks
like
something
from
a
practical
standpoint
that
would
be
really
useful
for
people
maintaining
contrib
instrumentation
in
particular,
because
it
would
also
help
normalize
what
configuration
looks
like
for
all
of
this
stuff
so
anyways.
That's
that's
why
we
want
something
like
this
honorable
made
a
proposal.
G
I'd
like
people
to
look,
have
a
look
at
it.
My
main
concern
with
the
proposal
he's
made:
is
it
it's
very
java
ish
and
looks
like
it
relies
on
things
like
generics
to
some
degree,
so
it
doesn't
really
look
like
a
general
purpose
solution,
but
I'm
not
sure
if
it's
feasible
to
have
a
general
purpose
solution
that
doesn't
come
with
extra
overhead
of
some
form.
So
I
think
it's
tricky
to
to
get
this
correct.
Basically,
so
it
would
be
great
to
have
have
eyes
on
this
concept.
F
I
think
it
would
be
very
important
to
have
multiple
language
owners.
Maintainers
read
this
because,
as
you
pointed
people
that
have
different
experiences-
and
this
may
be
to
java
for
for
us,
but
let's
give
it
a
chance
and
and
read
it.
I
Already
got
it
by
the
way
I
want
to
have
something
ted.
You
know
there
are
other
things
related
to
instrumentation
like
deciding
whether
like
well
like
having
multiple
supporters,
I'm
wondering
if
your
group
is
will
be
taking
that
on.
I
Yeah,
well,
we
can
probably
discuss
it
as
part
of
the
next
one,
because
it's
an
environment
variable.
G
I
would
just
yeah
just,
but
I
would
just
briefly
say
I
feel
like
instrumentation
should
be
decoupled
from
things
like
exporters
right,
that's,
an
sdk
level
concept
and
hopefully,
when
you
know
this
trace
provider
issue,
that's
coming
up
putting
that
aside.
Ideally,
people
writing.
Instrumentation
are
not
thinking
about
exporters
and
stuff
like
that,
because
that's
something
the
application
owner
would
be
configuring
when
they
start
their
program.
F
I'm
I'm
curious
by
the
way.
This
brings
us
a
good
topic.
Tyler.
Do
you
mind
asking
the
the
people
from
from
buildkit?
How
do
they
do?
What
do
they
do
with
logs,
for
example,.
F
Because
logs
have
their
own
export
path
as
well,
so
how
do
they
handle
logs?
In
that
case,
do
they
pass
a
logger
in
the
context
and
yeah?
I
don't
know
I
could
and
what
is
the
problem
why
this
problem
is
specific
to
tracing
versus
logging,
and
this
is
also
for
us
to
learn,
because
we
want
to
provide
like
low
correlation
and
stuff
metrics
the
same
thing
like
for
metrics.
Would
it
be
the
same
problem?
Would
they
want
to
get
the
current
meter
provider
for
metrics
as
well.
D
Yeah
I
mean
that's
too
deep,
but
I
I
imagine
so
yeah
I
feel
like
we
can.
We
can
take
a
look
at
their
code
to
see
what
they
do
for
logic,
because
they
definitely
are
logging.
So
I
don't
know
if
anthony
knows
offhand,
but
I
I
don't
know.
F
F
Great
good
questions,
so
so
that's
that's
one
thing
that
I
would
like
to
to
understand
and
it
doesn't
matter
which,
with
what
solution
we
go,
I
think
it
will
be
important
to
be
consistent,
of
course,
across
signals
for
us,
so
at
least
make
sure
we
we
have
a
decent
solution
for
for
the
three
of
them.
A
K
Hey!
That's
for
me.
K
Okay,
right
so
on
the
first
one,
11
30,
the
one
you
have
open.
Can
I
get
an
assignee
on
that
one.
K
It
was
started
like
in
the
fall
last
year
that
was
before
ga
and
then
we
said
this
has
to
wait
till
the
gs,
and
then
we
only
resumed
it
like
a
couple
of
weeks
ago.
F
D
K
And
this
one
second
one
I
just
linked-
because
it's
kind
of
similar
to
that
one
and
that
tigran
who
is
absent,
has
added
an
issue
about
environment
variables.
So
that's
another
topic.
The
first
one
is
the
11
30
in
general,
so
limits
on
attributes,
and
the
second
issue
is,
is
about
environment
variables.
F
Okay,
anything
anything
besides
me
figuring
out
how
to
assign
someone
randomly
and
then
anything
else
we
should
discuss
in
this,
like
probably
everyone
heard
about
the
existence
of
these
two,
these
two
pr's
that
we
need
to
review.
But
besides
that
is
there
anything
else
we
need
to
discuss?
Is
there
a
blocking
or
anything.
I
I
think
tigress
point
tigran's
point
is
very
important
like
he
thinks
that
there's
the
the
risk
of
for
you
know
the
big
proliferation
of
too
many
environment
variables.
We
should
discuss
something
before
we
go
ahead
and
merge
these
two
pr's.
F
Yeah,
I'm
all
about
that-
that
I
prefer
yaml
files
than
having
20
environment
variables
for
for
everything.
But
I
don't
think
we
made
any
effort
towards
this.
So
maybe
a
good
time
to
discuss.
I
I
I
F
I
I
would
say,
as
an
action
item
carlos
as
tigran
pointed
I
think
we
should
at
least
follow
a
file,
an
issue
to
track
this
discussion
about
what
is
the
future
of
configuration
and
and
at
least
have
this
discussion
commented
in
that
issue
and
we
can
move
forward
with
this.
But
but
I
think
it's
it's
a
valid
point
that
we
need
to
to
make
sure
we
we're
going
to
discuss
and
track
make
sense.
Yeah.
Let's
do
that.
Okay,
so
carlos
as
an
assignee.
I
Yeah
this
was
filled
by
nikita,
and
it's
about
the
transports
like
we
have
otlp
and
hc
probably
implements
different,
a
different
format,
and
we
should
probably
clarify
that
and
tigran
was
proposing
that
everything
should
implement
just
one
format
and
maybe
that
we
should
go
with
protobuf
over
http
as
a
default.
Probably
I'm
not
sure
that's
a
good
idea,
and
I
don't
know
whether
that,
like,
for
example
javascript,
I
don't
think
that's
the
preferred
format.
D
Is
the
preferred
format
in
javascript
the
json
over
http?
Yes,
that's
a
just
a
heads
up.
That's
like
the
format
we
really
don't
prefer
in
go
because
it's
really
hard
to
serialize
it
so
yeah.
This
is
gonna,
be
a
tough
one.
F
That's
also
true
and
is
also
the
only
one
that
is
unstable.
So
that
being
said,
so
I
would
say
that
that's
the
very
least
preferred
in
in
bunch
of
languages
and
even
in
the
community
in
general,
because
it's
unstable
okay,
so.
L
F
If
if
I
have
python
that
prefers
http
protobuf
and
if
I
have
go
that
prefers
grpc,
not
that
that's
the
case,
I'm
just
giving
an
example,
then
then,
if
I
have
a
collector,
I
need
to
set
up
two
receivers
and
stuff
like
that,
so
it
will
be
harder
for.
For
my
experience,
it
will
be
way
simpler.
If
we
know
everyone
is
using
a
default
one
grpc,
let's
assume
so
then
then
everyone
I
can
use
just
jrpc
and
worry
about
only
one
endpoint
to
receive
this
and
so
on
and
so
forth.
F
So
I
I
kind
of
believe
believe
that
it
would
be
better
to
have
a
mandatory
one
and
the
other
two
would
be
optional.
D
I
think
there's
also
the
configuration
side
of
that
like
I
agree,
it
does
the
convenience
thing
and
we
have
a
lot
of.
We
feel
a
lot
of
questions
like
this
like.
Why?
Don't
you
support
this
one
or
why
do
you
support
this
one?
Because
it's
it's
the
collector
side,
but
it's
also
just
like
you
know:
you're
sharing
configuration
across
a
lot
of
services
and
I'll
look.
The
idea
of
what's
limited
for
you
to
have
this
is
to
have
like
a
you
know.
D
Essentially
a
plugable
configuration
that
you
should
be
able
to
send
to
whatever
language
you
want,
and
so,
when
you
say
like,
I
want
to
set
it
up
with
the
grpc
endpoint
and
then
you
go
to
this
other
language.
That's
a
instrument
to
focus
on
the
tree
and
it
doesn't
have
that
support.
It's
a
little
frustrating
yeah.
A
G
F
D
I'd
like
to
understand,
I
think
the
javascript
challenges,
I'm
guessing,
it's
the
protobuf
library
being
you
know
really
big
or
non-existent
in
javascript.
D
One
thing
we
also
have
to
consider,
though,
is
in
modifying
the
specification,
if
we're
going
to
add
a
requirement
that
is
technically
a
backwards,
incompatible
change,
so
it
I
I
don't,
I
think
well
yeah.
If
you
have
something
that's
compliant
with
the
specification,
that's
you
know
1.2
and
then
all
of
a
sudden
you
know
1.3
comes
out,
but
it's
it's
not
comply
anymore
because
it
doesn't
implement
something.
I
think
it
that's.
D
D
F
It's
the
same
thing
as
adding
the
interface
with
the
span.
Get
trace.
Processor
is
not
going
to
be
forward
compatible
right.
Okay,
I
see
you're
saying
yes,
yes,
no!
I
I
would
not
be
worried
about
that.
Let's
put
this
way
I'll,
be
more
worried
about
the
amount
of
work
that
we
add
on
you
guys
so.
D
I
do
know
that
in
the
go
world,
the
reason
we
don't
support
the
json
one
is
because,
like
you're
saying
it's
not
stable,
so
it's
something
we
didn't
want
to
spend
too
much
time
on
and
the
serialization
of
trace
id
and
span
id
is
essentially
what
we
do
is
we
take
the
protobuf
library
and
we
try
to
just
you
know,
use
the
json
protobuf
library
to
try
to
use
that,
but
it
doesn't
serialize
the
trace
id
and
the
span
id
anthony
correctly
from
wrong,
and
I
think
it's
base64
or
or
it
uses
base64.
D
F
D
F
It's
pretty
hard,
you
have
an
easier
solution
and
go
by
the
way,
because
I
don't
know
if
you
know
in
collector
we
are
splitting
our
what
we
call
the
p
data,
our
internal
yeah.
F
We
are
splitting
as
a
standalone
module,
so
you
will
be
able
to
use
that
and
serialize
there,
because
we
implemented
the
right
serialization
in
this
reality.
F
Okay,
that's
awful,
but
that's
probably
gonna
be
a
couple
of
weeks
few
weeks
until
we
finish
the
split
so
but
coming
back
to
this.
B
F
G
G
The
only
issue
with
only
offering
a
grpc
implementation
is
the
practical
matter
that
we
often
encounter
compatibility
issues
with
versions
of
grpc.
G
That's
like
a
a
pretty
common
thing
since,
like
you
know,
I've
I've
written
software
that
leans
on
grpc,
like
shared
libraries,
including
tracers
and
other
things,
so
I
can
attest
to
like
this
is
just
a
super
common
issue
and
we
always
end
up
writing
a
non-grpc
transport
to
give
to
people
just
so
that
if
they
hit
a
compatibility
issue,
they
have
a
non-grpc
alternative
and
we
don't
run
into
that
nearly
as
often
with
http,
because
you
just
there's
a
lot
more
like
room
to
wiggle
around
over
there.
G
So
that's
the
only
required.
That's
the
only
issue
with
only
offering
people
a
grpc.
They
will
probably
come
back
to
us
at
some
point
and
be
like
I've
got
issues
loading
grpc.
I
need
something
else.
F
But,
to
be
honest
between
the
two
implementation-
the
code,
if
you
have
the
translation
between
internal
data
structure
and
the
protobuf
generated
protobuf
thing,
implementing
a
grpc
versus
an
http
exporter,
once
you
have
the
translation
to
the
protobuf,
it
should
be
like
50
lines
of
code
or
something
because
grpc
at
least
the
grpc
one
generates
a
client
for
you
manages
connection
and
everything.
So
you
it's
literally
a
couple
of
lines
of
code.
Just
the
conversion
to
the
protobuf
is
the
the
piece
that
is
more
like
a
lot
of
lines
of
code
yeah.
G
L
G
Of
course,
we're
gonna
get
people
coming
to
us
asking
for
json,
but
I
feel
like
less
so
because
it's
just
like
what
are
you
sending?
That
would
mean
you're
sending
this
to
something
that
only
accepts
json
as
input
and,
I
kind
of
doubt
there's
just
like
nothing
hanging
around
in
the
ecosystem.
That's
built
that
way.
Anything
that
accepts
otlp
is
going
to
accept
so.
F
F
Proto
they
can,
they
can
protobuf,
generates
typescript
and
and
js
plainjs
objects
for
for
this,
and
even
the
the
new
grpc
web
works
very
good.
They
release
it
like
six
months
ago
or
five
months
ago
for
for
web.
So
there
are
solutions
for
for
for
that.
But
let's.
F
Does
does
it
make
sense
to
everyone?
I
mean
I'm
happy
to
hear
objections,
but
I
think
that
will
move
us
towards
the
the
goal
of
having
share
configurations
once
we
also
have
to
discuss
that
shared
configuration
thing
that
carlos
is
going
to
file.
It
will
be
nice
if
the
same
yaml
can
be
used
for
to
start
python,
node.js
and
and
all
the
libraries
that
we
offer.