►
From YouTube: 2020-08-14 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
C
B
B
How's,
the
weather
in
all
of
your
countries
we're
getting
ready
for
100
degree
fahrenheit
weekend,
which
is
like
40,
I
think
40
degrees
celsius,
yeah,
that's
cool,
maybe
maybe
a
little
below
40
like
39.
I
don't
know
anyway,
somewhere
around
there
yeah
it's
gonna
be
a
hot.
It's
gonna
be
a
hot
weekend.
A
A
B
B
Well,
let's
start
at
the
top.
I
just
wanted
to
heads
up.
All
of
the
open
issues
have
been
tagged
as
necessary
for
ga
or
not
necessary
for
ga,
and
I
put
priorities
on
all
of
those
all
the
ones
that
are
required
for
ga
we
have
like,
I
want
to
say
six
or
seven
priority.
One
issues
I
expect
more
will
show
up
when,
as
the
specs
get
merged,
some
final
specs,
it's
going
to
get
merged,
so
priority
ones.
B
Those
need
to
get
done
if
there
are
people
available,
would
love
to
have
people
jump
in
on
some
of
that,
I
think
at
the
moment
carlos
documentation.
D
Yep
yeah,
that's
actually
a
good
time,
because
I
did
something
related
on
the
specification
side.
So
also
me
myself,
I
am
not
able
to
help
because
I'm
prototyping
the
something
in
the
in
the
getter
for
destruction.
You
know
to
support
the
multi,
the
variable
key
names
for,
but
there
you
know
we
have
sergey
who
worked
like
steps,
so
he
could
help
with
something
here.
D
I
think
some
long
story
short.
We
were
thinking
about
having
him
learn
little
by
little
on
the
instrumentation
side.
You
know
to
work
on
that
side
and
learn
from
there,
but
based
on
the
fact
that
we
probably
need
more
cycles
here,
I
can
bring
him
here
at
least
four
for
for
the
next
weeks.
B
Yeah,
it
might
be
easier
for
him
to
pick
up
not
the
priority
ones
unless
there's
like,
for
example,
if
he
has
gradle
expertise
the
priority
one
about
the
bomb
not
being
published
correctly,
that
would
be
a
you
know,
good
one
that
doesn't
require
any
open.
Telemetry
knowledge
that
I
know
of
it's
purely
just
gradle
and
they've
been
special.
B
D
Yeah
I
haven't,
I
have
a
yeah
okay,
yeah,
that's
a
good
thing,
even
yeah.
I
would
prefer,
of
course,
that
he
goes
and
works
on
p1
items,
but
yeah
p2
is
probably
the
second
best
thing
we
can
do
now
for
him.
I.
D
B
D
Okay,
and
by
the
way
I
I
don't
want,
I
would
just
I
want
to
mention
something
by
the
way
I
don't
want
to
spend.
I
just
want
to
get
a
preliminar
feeling.
I
don't
want
to
this
conversation
to
go
deeper,
but
you
guys
may
have
seen
that
somebody
jump
into
the
grpc
context.
Discussion
mentioned
in
this
project
call
man.
What's
the
name
of
this
project.
D
Yeah
yeah:
do
you
guys
have
any
feeling
I
was
reading
through
the
api?
It
looks,
looks
cute,
but
do
you
guys
have
a
feeling
that
that
could
work?
For
me
I
have
a
feeling.
B
B
Yet,
okay,
I've
started
reading
through
the
spec.
My
I
mean
the
big
question
I
have,
which
I
asked
on
that
on
the
grpc
issue
is:
does
it
work
with
java
7
because
it
looks
like
it
requires
completable
futures
which
are
java,
8,
plus.
B
B
I
mean
it
seems
like
it's
kind
of
the
only
way
you
can
deal
with
the
fact
that
there's
so
many
different
contexts
and
they
all
have
their
own
apis.
You
need
to
have
something
that
that
allows
plugging
in
the
implementation
and
allows
shimming
between
them,
and
it
seems
like
that.
Interface
is
a
good
idea,
but
the
details
don't
know
yet.
D
Okay,
so
it's
worth
taking
a
look,
I
will
try
to
get
some
like
at
least
one
solid
hour
for
me
to
go
through
that
things
week.
It
could
be
interesting.
Trask
didn't
comment
on
that.
I
could
be
curious.
B
D
Yeah,
actually,
I
was
thinking
about
that.
I
mean
he
can
at
least
go
and
dig
and
give
us
an
overview.
B
Fantastic
cool.
The
next
few
items
on
the
agenda
are
all
kind
of
things.
We
may
need
decisions
to
be
made
about
whether
we
want
to
move
forward
or
not.
B
The
first
is
removing
trace
id
and
spin
id
and
putting
all
of
the
information
into
this
main
context
itself,
which
my
prototype
draft
pr
is
fully
functional
works.
All
the
tests
pass
performance
wise
is
basically
equivalent
to
what
we
have
today
in
some
cases,
far
superior
in
other
cases.
About
the
same,
I
haven't
seen
any
places
where
it's
significantly
worse
in
any
of
the
benchmarks
that
I've
run
it's
very
much
more
efficient
when
you're
dealing
with
taking
already
hex
based
ids
off
the
wire
and
putting
them
into
this
main
context.
B
It's
a
little
bit
messy
having
to
handle
both
longs
and
strings
for
the
ids
inside
the
context
itself,
but
mo
for
the
most
part,
that's
hidden
away
inside
the
sdk
or
inside
that
api
class
inside
private
methods.
So
it
doesn't
matter
too
much
anyway.
We
need
to
make
a
decision,
because
I've
spent
a
lot
of
time
on
it
and
I
either
want
to
throw
it
away
and
not
worry
about
it
anymore
or
actually
make
it
happen,
because
otherwise
it's
just
going
to
sit
there
and
languish.
D
Yeah,
so
I
like
the
change,
I
am
fine
with
it.
My
only
slight
concern
is
I
don't
personally
like
so
much
having
two
representations
like
both
longs
and
strings,
and
if
we
were
to
decide
go
to
on
that,
I
could.
I
would
love
to
not
have
this
in
the
constructor
like
or
create,
there's
a
create
method
that
is
taking
the
representation
both
as
a
string
and
as
a
chart
sequence,
which
I
don't
think
it's
nice.
I
can
confuse
users
yeah,
that's
my
only
feedback.
Otherwise
I
could
be
fine
with
with
that.
D
If
we
go
strings
only
like
char
sequence,
on
chart
sequence
only
or
lungs,
only
if
you
mix
them
just
hide
that
very
well.
B
Yeah,
the
the
hiding
of
that
is
something
that
I've
been.
I
agree
with
you.
I
agree
with
you
100
it's
kind
of
messy
at
the
moment
and
that's
100
for
performance
reasons
like
it's
very
easy.
You
just
have
one
representation,
but
that
means
one
or
the
other
translations
will
be
expensive.
B
If
you
do
all
strings,
then
any
every
single
time
you
generate
an
internal
span
anytime,
you
generate
a
span
id
which
is
basically
every
single
span.
Then
you
have
the
expense
of
converting
from
or
generating
a
random
string,
a
random
hex
number,
which
is
not
cheap,
not
free.
Just
put
it
that
way,
it's
not
insane
incredibly
expensive,
but
it's
definitely
not
free,
and
if
you
go
the
other
way,
if
you
store
it
as
longs,
then
anytime
you
want
to
go
back
and
forth
from
the
wire.
B
B
B
So
I
wonder
if
we
could
actually
take
that
span
context
creation,
maybe
out
of
the
api
and
put
it
somewhere
else,
I'm
not
sure,
because
the
span
context
is
created
by
propagators,
so
maybe
that
there
should
be
like
a
propagator
api
for
spain
context
creation
and
maybe
a
separate
api
for
the
internals
in
the
sdk
for
the
span
builder
and
because,
like
end,
users
are
never
going
to
create
a
span
context.
As
far
as
I
know,.
D
I
have
a
small
question.
I
remember
that
in
open
tracing,
what
we
did
back
in
the
time
with
the
latest
version
is
that
we
used
to
mostly
handle
ids
as
longs
and
then
just
like
in
behind
the
scenes.
We
would
just
get
the
string
representation
of
them
and,
just
you
know,
say
stories
in
the
object,
so
you
have
both
of
them,
but
the
user.
You
know
like
when
he
specifies
aed,
it's
only
loans.
D
So
would
that
be
a
problem
for
us
like
in
the
create
method
during
you
have,
for
example,
two
overloads.
One
of
them
takes
a
charge
sequence,
so
you
create
you
parse
and
detect.
What's
the
what
are
the
long
values
for
that
one
and
the
other
ones
goes
the
other
way
around.
So
the
idea
is
that
you
don't
have
to
expose
what
both,
but
you
know
at
the
same
time,.
B
I
think
that
reasonable,
except
for
the
most
common
use
case,
I
think,
is
the
trace
id
is
coming
in
off
the
wire
and
the
span
id
is,
is
being
generated
right
so
like
this
trace
id
is
naturally
a
string
and
the
span
id
is
naturally,
you
want
to
generate
a
along
as
the
random
id
for
it.
So
the
actual
most
common
use
case
is
the
mixed
one,
which
is
why
I'm
like.
B
Well,
I
could
create
a
weird
mixed
api
that
was
a
string
for
the
trace
id
and
along
for
the
span
id,
and
that
looks
extra
strange
because
who
knows
what's
going
on
with
that?
So
that's
where
I
kind
of
ran
into
the
problem
and
I'm
like
well
what,
if
I
just
put
every
put
the
kitchen
sink
into
the
api,
which
is
not
not
really
pretty
at
all.
F
F
I'm
just
trying
to
figure
out
like,
as
you
said,
what
what's
the
common
path
and
it
seems
like
it's
it's
both
and
then
it
depends
on
if
you
want
to
have
it.
So
if
you
want
to
tag
your
logs
with
it,
then
we're
going
to
have
to
then
it's
going
to
be
to
the
string
and
for
the
incoming
trace
id.
Well,
maybe
we
never
need
the
long.
It
will
always
just
need
to
be
the
string
so.
F
C
B
The
real
problem
is
creating
an
api
for
creating
this
main
context
that
doesn't
look
hideous.
That's
I
think
what
carlos
is
pointing
out
and
I
100
agree.
What's
there
is
super
ugly?
It's
something
that
we
could
you
know
get
in.
There
document
really
well
and
then
figure
out
how
to
make
it
better.
As
we
go
over
time
and
as
I
said,
I
don't
think
any
like
end.
Users
are
going
to
be
creating
spain
contexts
like
spain,
contacts
look
for
are
for
propagators
and
they're
for
the
sdk.
B
I
don't
think
anybody
else
is
going
to
create
one
like.
I
wouldn't
expect
a
regular
instrumentation
authors
to
create
spam
context
directly
and
I
wouldn't
expect
end
users
who
are
just
instrumenting
their
code
to
create
spam
contexts.
B
B
B
D
Yeah
yeah
you're
right,
like
I
think
that
the
only
place
that
I
can
think
of
where
users
will
be
creating
spam
contacts
is
when
they
are
writing
their
own
instrumentation
like
like
instrumenting
like
spring,
but
that's
already
done
by
us.
So
it's
not
much
of
a
problem
and
then
even
then,
I
don't
think
they're
in
contexts
right
for
the
for
the
test.
A
B
B
A
B
E
A
B
F
F
Out
there,
oh
sorry
yeah
one
of
the
things
he
pointed
out.
I
think
it
was
well
was
it
was
not
sort
of
a
primitive
long.
It
was
a
long
object
as
well
or
something
like
that
of
uppercase
long,
which
is
sort
of
even
more
expensive
to
play
around
with
than
boxing
unboxing.
That
was
a
like.
I
just
sort
of
his
first
comment
in
there.
B
I
think
that's
vanity
trace
id
in
the
current,
like
on
the
master
branch
or
just
using
little,
okay,
pretty
sure
anyway,
so
yeah.
This
is
mostly
for
the
instrumentation
project,
which
is
you
know.
I
still
want
to
reiterate
the
number
one
consumer
of
the
apis
and
probably
will
be
probably
going
into
the
future
for
a
very
long
time.
A
Okay,
because
I
have
really
like
strange
concern
with
with
that
pull
request
is
exactly
so
currently
I
it
it
loses
in
some
way
type
safety.
B
A
B
Yeah,
that
was
what
I
was
why
I
was
asking
about
that
discussion
yesterday,
because
it's
definitely
like
the
api
is
much
nicer.
If
you
have
these
nice
objects
that
have
methods
on
them
and
you
can
actually
interact
with
them
and
like
they
have
that
it's
just
from
a
just
a
readability
perspective
having
those
trace
ideas,
vanity
objects
is
great
and
they
could
do
all
the
hiding
like
the
performance,
optimization
of
using
a
string
internally
if
it
comes
in
off
the
wire
like
from
that
perspective,
that's
already
optimizable
with
what
we
have
right
now.
E
B
B
And
yeah
so
same
motivation
same
so
I
mean
we
have
to
make
the
same
kinds
of
sacrifices.
The
type
safety
gets
a
little
bit
less
good
and
it
is
possible.
So
I
think,
there's
a
there's
a
decision
here,
it's
probably
more
motivated
by
the
instrumentation
folks
like
is
it
worth?
Is
it
worth
it
to
give
up?
Some
of
the
nice
features
that
we
get
in
order
for
the
performance
and
get
rid
of
some
wrapping.
A
E
B
All
right:
well,
I
will
leave
those
as
a
draft
right
now
and
leave
it
in
your
hands
so,
and
this
is
something
this
would
be-
a
really
significant
change
to
the
apis
that
we
want
to
get
in
as
early
as
we
can
before
ga
acknowledged
cool
all
right.
Thank
you,
awesome.
That
is
fantastic.
F
All
right,
john,
for
some
of
the
things
you
did
with,
where
is
the
performance
improvement
with
not
having
to
translate
as
much
is
that
something
you
can
put
into
the
span
id
instead
of
just
having
the
long
in
there
and
having
the
spring
yeah.
B
Going
in
there
yeah,
I
think
we
can.
I
think
that
is
something
we
could
think
about.
As
a
as
a
performance
improvement
for
propagators,
I
think
priority
wise
fairly
low
for
ga,
but
but
getting
the
api
really
like
locked
in
and
not
changing
is
more
important
to
me
right
now
and
then
those
performance
performance
things
could
definitely
be
done
post
or
done
later
near
the
end
of
the
cycle.
B
But
yes,
I
think
so
like
if
we
could,
if
we
had
a
creator
first
for
trace
id,
for
example
that
took
the
string,
then
we
could
internally
just
manage
that
all
right,
so
the
async
export
pr
carlos.
It
was
on
your
plate
to
take
a
look
at
that
and
give
it
a
thumbs
up.
D
So
yeah,
so
basically
my
thumbs
are
up.
I'm
just
a
little
bit
curious
about
the
latest
discussion
on
well,
two
things.
First,
what
christian
mentioned
was
super
interesting
and
the
second
thing
to
be
honest,
I
I
feel
that,
although
this
is
an
interesting
change
that
could
be
useful,
I
at
moments.
I
feel
that
this
is
some
kind
of
techno
religion.
You
know
about
that.
This
is
the
correct
thing,
but
other
than
that,
I'm
fine
with
that.
D
D
B
My
feeling
is
the
same
that
it's
not
strictly
necessary.
It's
maybe
async
for
the
sake
of
being
async,
but
I
also
do
it.
I
do
acknowledge
that
it
provides
more
flexibility
for
exporters
to
do
the
right
thing
and
not
have
to
kind
of
make
async
be
a
secret
in
the
inside
their
exporter.
D
So
yeah,
I
was
mostly
mostly
a
little
bit
worried
in
case.
The
sdk
needs
to
do
more
work,
but
that's
probably
not
something
we
can.
We
need
to
worry
about
now.
B
I
mean
right
now
we're
not
doing
anything
with
the
result
of
the
right
anyway
right,
so
it
feels
like
this
gives
us
more
flexibility
in
the
sdk
in
the
future
to
actually
deal
with
it
better,
and
I
think
the
bigger
thing
in
honor
of
pointed
this
out
to
me
last
night.
We
need
to
make
a
decision,
so
chris
christopher
the
contributor
doesn't
isn't
just
left
hanging
because
he's
been
left
hanging
for
a
really
long
time
and
that's
not
a
good,
not
a
good
experience
that
we're
providing
as
maintainers
so
well.
D
It's
I
mean
on
our
defense,
it's
a
it's
kind
of
polemical
and
it's
a
kind
of
big
change
so
and
it
wasn't
the
worst
time
for
us
because
yeah
there's
too
much
specification
stuff
happening
as
you
know,
so,
okay,
I'm
going
up,
but
I'm
putting
now
comments
about
like
like
I
approve
and
let's
go
all
right.
B
D
B
I
will
then
take
it
and
get
it
over
the
finish
line
with
christopher
cool,
all
right,
the
big
one
and
without
bogdan
here
it's
going
to
be
hard,
maybe
carlos
you
bogdan,
and
I
just
need
to
have
a
meeting
offline,
but
we
I
mean
the
decision-making
process
is
incredibly
slow
right
now
and
for
me,
it's
very,
very
frustrating
because,
like
I,
these
this
work
on
trace,
eddie's,
vanity
and
attribute
value
has
been
going
on
literally
for
four
months
now
and
and
for
external
contributors.
The
decision-making
process
is
very,
very
slow.
B
D
Yeah
yeah,
I
am
a
little
bit
I.
I
am
mostly
concerned
concerned
with
things
like
the
asynchronous
exporter
like
which
are
things
that
are
not
well,
then
it's
not
a
requirement
in
this
certification.
D
What
we
have
to
review
is
still,
but
anyway,
my
one
of
the
things
that
I
was
thinking
about
is
that,
well
I
don't
know
probably
that
you
could
tell
smoke
down
and
me
what
you
know,
because
we
can't,
even
if
we
wish,
we
don't
have
time
to
review
everything,
tell
us
what
things
based
on
your
own
gods
are
are
required
for,
for
you
know,
for
work
done
to
review
with
the
rest.
If
you
don't
have
a
a
reviewer
approval
after
a
pair
of
days,
go
with
your
gut
feeling
and
just
merge
it.
D
D
B
The
api
guy
changes
are
something
that
I
think
we
all
agreed
that
we
need
at
least
maintain
our
consensus
on
api
changes.
Sdk
internals,
I
think,
are
less
of
a
issue.
B
D
I
was
actually
yeah
exactly.
That
was
something
I
realized
later
I'm
trying
to
go
over
my
my
pile
of
stuff,
and
then
I
see
a
mention
of
you
know
I
mentioned,
and
then
I
see
like
I
see
that
three
days
after
so
I'm
thinking
there's
a
better
way
to
communicate
this.
You
know
like
hey,
like
what
probably
could
have
to
be
outside
github.
I
don't
know
otherwise.
It's
gonna.
A
Yeah
yeah
so
go
ahead.
What
about
obvious
solution?
Don't
can't
you
promote
some
of
approvers
to
maintainers.
B
I
think
well
so
process
wise.
We
need
to
make
sure
that
those
people
a
want
to
be
a
maintainer,
because
it
is
a
very
large
responsibility,
as
I'm
sure
you
know,
and
b
they're
actually
active
in
the
project.
So
I
think
that
having
people
active
in
the
project
is
really
important
and
I
don't
feel
like
we
have
very
many
people
in
that
in
that
mode.
A
B
A
A
B
D
A
D
B
D
They
could
be.
That
would
be
useful,
so,
okay,
so
it's
good
to
know.
Actually,
as
I
was
saying,
I
was
saying
before
I
was
thinking
what
things
he
could
help
us
with,
so
I
will
bring
him
so
yeah.
Okay,
I
will
talk
to
you
probably
over
here
on
what
things
he
could
start
working
on.
Hopefully
he
will
be
able
to
take
over
more
important
things
in
the
near
future
and
that's
the
thing
that
we
can
do
for
for
going
forward.
B
Great
and
I
think,
if
there's
other
like
nikita,
if
there's
anyone
from
splunk
who
wants
to
start
diving
in
more
to
this,
that
would
also
be
really
great
or
from
giovanni
you're
at
dynatrace
right
yeah.
B
Cool
all
right:
well,
no
real,
no
real
answer
there,
but
I
will
hopefully
we'll
get
some
help
from
sergey
and
yeah
I'll.
Just
wait.
B
I'll
try
to
get
that
scheduled
next
week
early
next
week,
great
carlos
your
next
one.
D
Yeah
giovanni
is
there
in
an
update.
C
D
C
D
Fantastic
and
finally
yeah
it's
something
similar
this
item
similar
to
the
async's
border,
it's
about
separating
the
sdk
into
artifacts.
I
wanted
to
have
boxton's
opinion
on
this
he's
not
here,
but
it
seems
that
there's
a
soft
general
agreement
on
doing
this.
B
Yeah,
I
don't
think,
there's
any
real
harm
to
it.
It
might
I
mean
there's
a
potential,
it
could
make
things
more
tricky
in
the
sdk
in
the
future.
But
at
this
point
I
don't
think
that's
a
big
deal
and
I
think
that
the
what
ken
is
interested
in
doing
is
very
interesting,
and
I
think
it's
something
we
should
probably
support,
which
is
having
a
mixed,
a
mixed
sdk
for
people
who
want
to
use
micrometer
ow.
D
B
So
yeah
my
feeling
was
the
same
as
well,
and
then
once
I
understood
they
really
wanted
to
since
they're
doing
pre-compilation
to
to
native
having
the
fewest
number
of
classes.
There
was
really
important
to
them,
which
I
think
is
is
a
totally
valid
reason.
B
D
D
We
would
wait
for
weeks
and
weeks
and
they
pay
attention
till
we
release
and
then,
of
course,
they
of
course
pay
attention
and
of
course
we
have
to
do
another
quick
release,
because
that
way
you
are
kind
of
forcing
them
to
pay
attention
so
yeah.
If
I
think
this
seems
like
it's
not
like
a
breaking
like
too
much
of
a
breaking
change,
it's
on
the
sdk
there's
a
soft
agreement.
D
There
are
clear
requirements,
and
after
a
pair
of
days
you
can
just
leave
a
comment
like,
but
then
we
are
proving
because
we
think
it's
a
good
change.
There's
enough
background
to
support
this
feel
free
to
open
an
issue.
You
feel
this
is
not
true,
not
fright
whatever
and
just
remember.
B
Yeah
exactly
so,
the
general
opinion
seemed
to
be
that
nobody
really
cares,
which
I
think
is
fine.
Sdks
can
make
decisions
that
make
sense
for
their
language.
D
B
I'll
handle
that
one
I
got
it
cool
and
I've
been
chatting
offline
with
ken
just
about
like
understanding
the
apis
and
what
it
takes
to
write
an
sdk
so
on
helping
him
out
with
that
cool.
Well,
that's
the
end
of
the
agenda.
B
I
think
we
have
some
action
items
for
nikita
to
go
back
to
the
instrumentation
group
and
talk
about
these
wrappers
and
whether
we
really
need
whether
these
changes
are
worth
worth.
The
api
pain.
B
F
B
The
context,
question
grpc
context:
question
is
still
open.
There
was
a
very
interesting
note
added
by
one
of
the,
I
think,
one
of
the
maintainers
of
micro
profile
for
the
micro
profile
context,
which
seems
like
a
super
interesting
idea
that
will
allow
interop
between
many
different
context,
implementations
and
a
write,
a
common
api
that
all
of
them
can
work
with.
F
B
F
I
can
see
if
I
get
some
time
take
a
look
at
that.
I'm
gonna
try
and
update
sort
of
the
jfr
pr
that
I
have
with
any
latest
changes,
but
I'll
leave
it
with
your
pc
for
now,
but
interesting
to
see
sort
of
how
that
api
looks
and
how
it
would
fit
in
with
what
I
need
to
do
here.
B
D
Yeah
so,
as
I
said
sergey,
I
will
surrogate
to
to
do
an
overview
and
initial
digi
yeah.
I
think
this
is
honestly,
probably
the
last
opportunity
to
change
bro.
You
know
from
jrpc
context.
What
was
we
stay
with
that?
So,
let's
see,
let's
see
yep.
F
D
F
One
completely
separate
question
is
a
quick
one.
Is
there
like
for
protobar
for,
like
the
protocol
for
for
sending
through
the
open
telemetry
pipeline?
Is
there
any
sort
of
generic
one
where
you
can
say
like
okay?
This
is
this
type,
and
then
you
send
a
binary
globe.
If
you
wanted
to
use
the
pipeline
for
sort
of
extending
things
flooded
online
for
easy
proof
of
concept,
for
example,
that
could
translate
into
more
direct
protobuf
later
on.
F
I
know
we
have
defined
like
protobuf
for
tracing
and
metrics
and
how
they
will
look
on
the
wire,
but
would
it
be
possible
to
have
like
a
protobuf
that
is
okay?
This
is
this
type
of
data,
but
then
it's
just
one
binary
global
for
dynamic
size
or
or,
if
that's
possible,
so
that
you
can
say
like
okay,
here's
data
I
know
about,
and
I
can
start
sending
it
through
the
pipeline
and
change
the
collector,
for
example,
to
send
it
to
my
internal
service,
but
you
could
use
sort
of
the
sort
of
the
whole
pipeline.
F
So
one
example,
like
one
thing
we
do
internally
here,
we
we
do
sort
of
thread
dumps
on
a
continuous
basis
and
upload
them
to
our
services.
We've
interested
like
okay,
that's
something
we
could
build
into
sort
of
the
open,
telemetry,
apm
and
then
test
out.
If
that's
something
that
could
go
through
this
pipeline
and
we
could
get
the
same
tagging
of
service
and
and
everything
else
we
get
from
metrics.
So
you
can
correlate
quite
quite
nicely
between
things
and
yeah.
I
think
there
was
a
line.
It
could
be
other
things.
B
Yeah,
I
think,
there's
an
issue
in
the
either
in
the
proto.
I
think
it's
in
the
proto
to
support
arbitrary
bite
arrays,
but
I
honestly
I'm
not.
I
have
not
been
following
the
proto
changes
very
much
at
all,
but
it
feels
like
that
would
be
a
great
issue
or
a
great
feature
to
bring
up
in
the
proto
repo.
B
B
Relic
does
something
very
similar
right.
We
have
a
lot
b.
We
have.
We
have
binary
blobs
that
we
send
up
for,
like,
like
you
said,
like
stack,
trace
or
detail
tracing
data
in
internals
that
there's
not
really
a
place
for
right
now
in
open
telemetry
and
there
probably
shouldn't
be
a
general
like
a
collector
for
it.
But
maybe
if
there's
a
way
to
like
you
said,
send
send
blobs
through
the
pipeline
that
could
be
used.
Yeah.