►
From YouTube: 2021-03-30 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
A
B
If,
if
underlying
exporter
does
not
support
certain
type,
then
it's
pretty
much
like
the
way
how
this
exporter
is
designed
and
you
should
not
try
to
feed
unsigned
64-bit,
for
example,
if
the
system
tells
you
that
it
doesn't
right,
so
I
think
it's
hey
johannes.
We
were
just
discussing
that
issue
that
we
already
discussed
in
in
on
github
and
offline.
A
A
A
C
The
weather
here
it's
actually
pretty
good.
I
mean
it's
sunny.
It
was
sunny
yesterday,
most
of
the
day
and
today
so,
but
it
will
be
raining
this
week.
So
probably.
B
About
the
same
for
us,
but
rain
is
not
surprising
me
anymore,.
A
Yes,
perhaps
perhaps
we
can
start
now,
yeah
feel
free
to
add
your
name
to
the
attend
list
and
also
add
the
topics
you
want
to
discuss.
I
think
max
you
are
going
to
add
other
topics
in
the
list
to
the
list.
A
A
B
B
B
This
is
an
implementation
that
allows
any
flexible
key
value
pair,
strongly
typed
key
value
player,
descent
over
event,
tracing
for
windows
in
open
source
and
we're
going
to
use
that
in
hw
exporters.
So
pretty
much
any
a
company
can
build
a
receiver
of
those
events
as
like
logging,
sync
or
tracing
sync
on
the
other
side
out
of
prop
and
then
do
whatever
they
want.
B
With
those
events,
either
returns
made
like
remade,
using
open,
telemetry.net
sdk,
for
example,
or
export
to
whatever
other
destination
of
your
choice,
so
this
will
be
hopefully
finally
is
toggled
to
oss.
In
april,
like
we
got
most
of
it
done,
there
are
some
minor
things
remaining
in
that
open
sourcing
process,
but
we'll
share
that
a
plastic
document
that
I
showed
in
on
github,
like
in
my
pr
that
describes
how
to
use
that
form.
B
So
we
fully
democratized
that
so
my
question
is
going
to
be
mostly
like:
when
do
you
guys
think
it's
going
to
be
the
next
release
level,
so
I
can
adjust
accordingly
to
do
my
best
to
make
sure
that
my
code
makes
it
into
that
next
release.
A
B
Yes,
I
can
add
that,
and
I
just
was
trying
to
think
like
I
guess
just
like:
do
we
have
any
regular
release
cadence.
I
think
we
just
recently
made
the
version
0.3.
B
A
B
Yeah,
that's
fine,
okay,
cool,
it
doesn't
doesn't
affect
any
of
my
internal
testing,
because
I
can
pretty
much
package
a
test
package
for
my
customers
to
try.
I
just
want
to
make
sure
that
we
get
to
the
point
where
I
can
say
this
is
the
official
open
source
label
and
anybody
who
wants
to
package
it.
They
just
fetch
it
from
the
open
source,
like
from
the
main
line,
open,
telemetry,
okay
I'll,
be
targeting
like
mid
mid
april
to
finish
off
work.
B
I
don't
think
we
have
much
disagreement
about
the
api
parameters.
I
think
we
cannot
discuss
it
in
a
github.
A
B
B
The
only
case
where
it
might
matter
is,
if
you
exceed
the
size
and
use
like
unsigned
a
64-bit
integer
beyond
the
range.
How
does
that
work?
It
seems
like
we
can
either
flip
it
and
it's
becoming
a
negative
number,
which
is
some
customers
may
say
hey.
This
is
not
the
number
that
I
gave
to
the
api
surface
right.
B
Maybe
we
should
have
some
good
description
in
documentation.
What
should
what
is
expected
in
this
case?
One
easy
answer
is
that
this
is
unsupported.
Behavior
is
undefined.
B
C
Yeah
I
mean,
I
think
the
problem
here
is
that
if
we
provide
the
interface
with
with
an
unsigned
64-bit
integer,
if
we
provided
in
the
interface,
it's
it's
hard
for
us
to
argue
that
it's
undefined,
because
we
provide
it
to
the
customer
to.
B
B
Fine
print
which
suggests
in
this
path
this
value
does
not
make
any
practical
sense.
Then
I
guess
we
still
should
expect
that
customers
read
the
contract
right,
like
the
fine
print
in
the
contract,.
C
But
still,
then,
on
top
of
that
we
have
to
answer
the
question
yeah,
but
what
if
a
customer
still
provides
a
64
onsen
64
bit
distorter
like
the
expo,
we
just
leave
it
completely
the
exporter.
What
to
do
with
that?
I
mean
either
the
exporter
could
even
like
convert
it
to
a
double.
The
exporter
could
also
kind
of
convert
it
to
a
string.
Yeah
window
exporter
can
do
like
meaningful
things
to
to
work
around
that.
B
Yes,
yes,
I
mean
well,
I
I
have
a
question
here,
so
we
talk
about
span,
attributes
or
do
we
also
talk
about
ad
event
like
event
attribute
values
as
well.
B
So
then
here's
my
suggestion,
so
there
are
two
ways
to
handle
it
either
if
there's
a
higher
level
abstraction
wrapper,
which
knows
how
to
convert
to
fundamental
types.
For
example,
let's
say
I
pass
a
good
which
is
not
even
a
concept
in
open,
telemetry,
higher
order
thing
might
say:
hey,
it
is
actually
a
byte
buffer,
then
bomber
we
actually
have
an
issue
by
buffers
are
not
supported
either.
B
I
can
say
it's
a
buffer,
very
unfortunate
buffer
of
you,
ain't
like
in
64
or
it's
a
string
notation,
but
then
I
also
add
some
type
hinting
information
such
as
like
attribute
dot,
name,
dot
type
good,
like
I
decorate
and
append
more
information
to
my
event
and
it
still
fits
within
the
existing
channel.
I
mean,
but
then
that
event
carries
additional
formation.
Then
well,
you
know
that
column
is
supposed
to
be
good.
B
Now
the
backend
transform
has
to
be
applied,
and
somebody
who
operates
on
the
table
like
on
a
storage
table
then
knows
that.
Well,
it's
not
really
a
stream,
because
there's
an
extra
type,
hinting
information
appended
by
some
layer.
I
mean
whether
it's
the
higher
order,
where
that
does
it,
whether
it's
the
exporter
itself,
that
does
it,
you
can
argue
either
this
or
that.
But
that's
one
way
to
get
out
of
that
nasty
situation.
The
other
one
is.
B
We
keep
the
parameters
on
api
surface
that
allow
to
accept
like
unsigned
integers,
64-bit
width,
byte
buffers
and
then
for
each
concrete
use
case.
We
describe
what
happens.
Is
this
just
lost
or
is
it
that
exporter
is
trying
to
do
its
best
to
implicitly
convert
to
whatever
appropriate
type
depends?
I
mean
maybe
the
easy
answer
right
now
is
we
do
not
guarantee
anything.
B
The
behavior
is
not
guaranteed,
not
determined,
but
then
we
can
tune
it
as
long
as
we
allow
it
an
api
surface,
we
can
later
on
tuned
behavior
and
say
well
now
we
predict
that
it's
gonna
be
exported
as
like
array
of
two
values,
for
example,
or
it's
gonna
be
cast
to
unsigned,
but
then
you
would
also
get
a
type
hinting
information
and
you
yourself
may
actually
transform
it
back
to
like
from
signed
64-bit
to
unsigned
64-bit
in
the
back
end
as
an
option
I
mean.
B
I
would
rather
future
proof
it
and
keep
those
things
on
api
surface,
because
that
gives
us
the
flexibility
to
enhance
it
in
future,
especially
since
we
probably
don't
want
to
respin
due
to
abi
constraints.
It's
like
no
future
proofing.
It
kind
of
makes
sense
to
me.
C
I
mean,
I
think
the
situation
we
have,
then,
is
that
here
we
have
a
range
of
types
and
in
the
documentation,
we'll
just
say
all
of
those
types
except
of
two
are
like
your
guarantees,
according
to
the
stack
and
for
these
two
types,
this
will
be
like
the
buffer,
like
this
array
of
bytes
yeah
and
the
unsigned
64-bit
integer
for
these
two
types.
I
think
we
rather
not
say
this.
This
is
undefined
behavior,
but
rather
say
we
give
no
guarantees,
and
this
depends
on
the
exporter
using
yes,.
B
That
version
is
good.
Yes,
we
can
probably
iterate
on
good
on
better
wording
like
and
if
you
send
in
the
pr
yes.
A
I'm
thinking
about
as
a
spec,
it
doesn't
require
us
to
to
support
all
the
types.
Could
we
request
the
deaths
back
to
support
other
other
types
which
I
think
max
mentioned
are
very
useful.
A
B
Be
two
ways
see:
I
was
trying
to
bring
up
that
issue
for
the,
for
example,
for
the
bytes
support,
and
I
have
not
seen
any
pushback
there's
no
disagreement
that
byte
way
support
is
valuable.
Is
a
nice
thing
to
to
have,
I
think,
tigran
uploaded
it
and
christian?
B
C
Already
left
stage,
I
think
people
currently
are
very
hesitant
to
make
breaking
changes
to
the
span
spec.
So,
as
mark
said,
I
think,
they're
very
unlikely.
I
think
to
get
this
into
the
spec
before
we
release
the
1.0
version,
and
I
think
we
on
our
side.
We
definitely
should
try
to
avoid
adding
or
the
need
to
add
attributes
after
we
do
a
one
zero
release,
because
that,
basically,
that
would
us
already
required
and
to
make
a
new
major
release,
because
it
will
break.
B
And
I
think
we
are,
unlike
unlike
more
flexible,
like
less
strongly
typed
languages,
we're
in
a
situation
where
we
also
initially
can
committed
to
that
api
requirement,
which
is
like,
I
don't
think
others
have.
That
requirement.
Even
I
mean
other
languages
are
more
flexible
in
this
regard.
Usually
it's
like.
We
are
shooting
ourselves
in
our
own
foot
by
trying
to
attain
that
abi
compat
requirement.
B
Now,
because
of
that,
I
guess
we
should
also
say
well
we're
we
need
to
future
proof.
We
follow
the
spec
in
general,
but
there
are
a
few
types
which
we
believe
are
here
are
gonna
be
in
version
1.1,
and
this
is
the
tricky
behavior
explicitly
spell
it
out.
These
are
the
types
where
which
users
should
be
careful
about
in
version
1.0
and
then
in
1.1
we
can
say
now.
We
finally
support
bad
buffers,
for
example,
that
it's
probably
something
that's
fine.
B
A
It
seems
like
we
are
going
to
support
more
more
than
what
the
spec
requires
right,
so
just
wondering
how
about
in
in
after
that
year.
Maybe
if
later
the
spec
supports
that
then
which
is
incompatible
with
us,
then
we
break
our
compatibility
right.
B
B
It's
like
I.
I
want
to
hear
your
feedback
because
three
of
us
we
work
in
kind
of
different
dimensions
at
microsoft
and
that
shouldn't
be
a
single
company
decision.
D
B
No
problem,
maybe
thomas,
can
open
the
issue.
B
B
Yeah
this
one,
so
the
issue
is
that,
right
now
our
api
surface
supports
more
types
than
the
open.
Telemetry
spec
requires
so
either
we
chop
them
or
we
describe
that
these
types
have
been
reserved
for
future
use
and
we
cannot
guarantee
any
behavior
if
you,
for
example,
pass
an
unsigned
integer,
64-bit
integer
as
a
property
value.
How
does
sdk
respond
to
that?
B
Should
we
say
that
the
behavior
is
non-deterministic,
in
this
case,
at
least
for
version
1.0,
or
should
we
say
it's
up
to
exporter
to
try
to
convert
it
to
whatever
appropriate
value?
And
my
main
argument
here
is,
for
example,
we
say:
otlp
is
the
default
exporter
cool.
B
We
also
say
that
one
can
build
a
custom
export
and
in
case
when
we
build
a
custom
exporter,
let's
say
sorry
for
bringing
this
event
racing
for
windows
example,
but
in
event,
tracing
for
windows,
unsigned
64-bit
integer
is
a
perfectly
valid
property
value
and
there
might
be
other
flows
where
you
know
like
and
randomly
say,
like
google
stackdriver
or
some
other
exporters
or
some
other
storage
destinations,
where
64-bit
unsigned
integers
may
be
perfect
values
for
kind
of
for
a
column.
B
In
a
database
and
by
the
other
use
case
is
byte
buffers
also
to
me,
bytebuffer,
8-bit,
byte
buffer
is
a
fundamental
necessity
in
any
embedded
kernel
driver,
a
system
service
scenario,
a
little
touchscreen
touchpad
going
bad,
and
I
need
to
fetch
those
32
bytes
and
I
don't
want
to
repack
them
as
64-bit
integers,
because
that's
a
huge
waste
of
space.
B
For
that
reason,
I
was
trying
to
advocate
that
we
have
a
wider
tapping
system
available
on
api
as
reserved
types
for
future
use
and
maybe
have
a
document
that
says
says.
Yes,
these
are
the
base
types
that
are
supported
by
a
gop
exporter
and
we
are
fully
and
compliant
with
the
spec.
B
We
support
all
of
these,
but
we
have
a
few
more
which
have
been
reserved
for
future
use,
because
our
sdk
were
also
committed
to
abi
stability
and
abi
stability,
like
types
that
we
list
on
variants
force
us
to
future
proof
this,
because
otherwise
we
are
in
that
maintenance
burden
of
extending
classes
verifying
what
version
of
sdk
it
is
it's
just
going
to
be
more
wasted
kind
of
cool.
You
see
what
I'm
saying
the
best
we
reserve
it.
D
An
example
where
we
use
this
32-inch
type,
even
64-bit
unsigned
no,
I
mean
the
one
which
is
out
of
the
spec.
What
what
will
be
the
the
if
you
think
an
example
in
the
api?
What
will
what
what
is
outside.
B
D
Of
the
spec,
because
this
will
maybe
help
me
better
or
understand.
B
D
B
Emit
an
event
somewhere
in
the
application
flow
and,
let's
say
just
hexadecimal
like
permissions
or
something
like
I
don't
know,
process
id
would
process
idb
always
fitting
in
in
64-bit.
Is
it
has
to
be
a
scenario
where
we
need
to
express
a
64-bit
unsigned
integer?
B
Well,
it
could
be
like
sum
of
all
file
sizes
in
a
directory,
and
I
think,
exceeding
64
exceeding
the
range
of
signed.
64-Bit
is
a
possibility
in
this
scenario
as
well.
Then
I
need
to
emit
an
event
like
total
size
this.
So
now
I
exceeded
that.
B
What
is
the
expected
result
and
if
I,
if
I
emitted
an
event
with
the
field
total
size
and
they
exceeded
the
spec
now
in
otp
receiver
example,
that's
probably
worst
key
is
going
to
flip
to
negative
number.
B
So
you
you,
so
you
are
asking
what
real
world
example
may
include
emitting
an
event
which
includes
a
field
positive
integer,
larger
than.
D
B
64-Bit
integer,
sorry,
I'm
just
checking
something.
C
B
I'm
thinking
on
the
opposite
side,
let's
say:
let
me
explain
my
logical
thing
so
do
you
guys
think
that
some
database,
such
as
oracle,
that
was
I'm
gonna,
take
some
other
non-microsoft
example?
Has
a
reserved
type
for
column
type,
unsigned
64-bit?
B
I
believe
that
those
systems
do
have
that
type
now
going
back.
Why
did
they
invent
a
storage
type
of
unsigned
64-bit?
There
were
scenarios
for
that.
The
other
are
a
useful
example.
Why
do
databases
have
a
variant
like
binary
array
type
which
allows
you
to
store
binary,
byte
log?
B
They
do.
We
don't
have
that
on
api
surface
I
mean
in
this
pack,
and
there
are
no
objections
to
add
one.
It's
just
the
train
has
left
station,
so
we
couldn't
add
it
in
time.
So
going
back
to
all
these
storage
table
questions,
the
other
example
is:
why
does
event
tracing
for
windows?
Allow
you
to
emit
a
property
which
is
unsigned
64
bit.
B
Like
for
the
file
system
level
for
the
user
accounts,
now
again,
we
don't
have
that
in
spec
either,
then
I
would
argue
that
we
should
have
had
it
inspect
if
train
hasn't
left
the
station
and
maybe
right
now
we
need
to
future
proof
and
have
those
types
on
api
servers
and
say
that
this
is
the
result
for
future
use.
B
C
You
know,
I
think
I
think
you
got
your
point.
I
think
to
just
revert
it.
I
think
your
point
is
that
our
api
should
support
our
primitive
c
data
types
and
we
should
not
leave
one
primitive
data
type
out,
because
that
would
be
a
kind
of
unexpected
for
many
users
or
primitive
data
types
except
one.
B
B
Yes,
my
understanding
is
javascript
type
race.
Okay,
they
have
well,
they
do
have
you
in
8
array.
At
least
I
mean
even
javascript
has
that
for
the
byte
buffers
which
we
don't
have
inspect
so
means
we
should
probably
future
proof
like.
I
don't
exactly
so
to
me.
Personally.
Maybe
let
me
be
blunt
on
this
to
me.
Personally,
we
are
trying
to
optimize
for
concrete
exporters
for
concrete
flow
for
concrete
distillation.
That
only
supports
these
types.
To
me,
the
world
is
much
bigger.
There
are
other
systems
again.
I'm
gonna
use
non-microsoft
example.
B
Oracle
database,
for
example,
where
column
types
maybe
could
be
of
other
wider
types
like
I'd
use,
blocks
eight
bit
byte
blocks
and
64
unsigned
64-bit,
primitive
type,
and
this
is
valid
and
like
even
postgres,
whatever
I'll
use
other
stories
like
azure
tables-
and
we
should
have
this
future
proof
reserved
in
api
surface
in
case.
B
If
we
want
to
support
one
to
one
mapping
to
those
other
storage
systems
and
this
dimension,
and
then
one
can
build
an
exporter
and
I'd
say
like
postgresql
exporter
or
oracle,
dbp
export
and
I
have
the
code
instrumented
in
a
way
that
it
allows
the
unmodified
original
value
like
binary
globe
stored
in
a
table
when
they
emit
those
traces
or
logs
or
metrics.
B
For
that
matter,
and
I
think
in
some
other
systems
we
like
expressing
metrics
as
unsigned
64-bit
numbers
rather
than
floats
or
doubles,
because
sometimes
you
can
just
use
the
ratio
and
all
that,
and
in
that
case,
when
your
values
are
only
positive
and
never
negative,
you
can
use
the
entire
spectrum.
You
can
use
the
entire
range
bigger
range
for
expressing
your
like
values
and
super
big
numbers
are
not
unheard
of
in
the
domain
that
we
are
operating.
B
So
for
that
matter,
I'd
say
we
document
what
we
officially
support
as
required
by
spec,
and
we
document
that
these
things
have
been
added.
Like
other
things
like
and
sciences,
profit
integers
have
been
added
reserved
for
future
use
and
behavior
right
now
is
not
guaranteed,
but
we
don't
remove
them
because
we
already
have
them.
B
I
mean
removing
is
always
easy.
Adding
it
back
is
probably
always
easy,
but
it
comes
at
the
cost
of
api
compatibility
issues
that
would
have
to
resolve
later
on
extra
checks,
extraversion
checks,
extra
extensibility
extra
inheritance,
for
why,
like,
let's
just
build
it
for
this
to
last
for
another
20
years
instead
of
a
year.
C
B
I'm
I'm
trying
to
see.
Maybe
if
you
guys
want
to
hear
more
reasons,
I
can
either
use
the
forum
or
slack
like
some
other
alternate
media,
to
bring
a
list
of
examples
like
more
concrete
examples
where,
in
embedded
scenarios
and
kernel
tracing
scenarios
by
buffers
are
becoming
very
relevant
where,
in
big
data
scenarios,
large
numbers
unsigned
64-bit
integers
becoming
relevant,
so
that
we
can
be
aware
of,
like
what
scenarios
have
in
mind,
which
we
may
be
able
to
support
with
version
1.1.
B
Sure
yeah,
just
like
apologies-
if
I
sounded
harsh-
that
I
have
very
strong
opinion
about
it
against
again,
I'm
looking
based
on
what
other
systems
are
capable
of
and
if
I
need
to
abstract
away
some
concrete
system
again
as
etw,
I
would
like
to
have
a
mapping
from
open
telemetry
api
surface
to
my
favorite
httw
export,
so
that
I
can
kind
of
map
things
one
to
one.
I
have
that
feature
on
etw.
Then
I
don't
have
the
feature
on
the
apa
on
open
telemetry.
B
My
question
is
well:
why
didn't
we
have
this
added?
I
mean,
if
needed,
be
I'd
like
to
join
the
next
community
meeting
and
say
that
I
would
strongly
advocate
for
inclusion
of
bite
buffers
in
1.1,
for
example,
and
I
haven't
seen
a
single
pushback
on
this,
everybody
is
agreeing
to
that.
I
mean
most
people
have
voted.
D
That
is
there
any
in
the
specification.
Is
there
any
open
issue
related
to
these
binary
buffers?
Yes,.
B
I
can
send
the
link
to
the
chat
window.
Yes,.
D
B
Yes,
absolutely
so
it's
specification
issue,
780,
oh
just
a
moment.
I
have
to
comparison
boy,
of
course,
so.
A
B
And
my
impression,
when
I
initially
logged
it
in
july
last
year,
I
thought
that
un-64t
are
there.
I
didn't
even
add
the
original
attribute
value
specification.
I
think
ryan
introduced
it,
as
in
his
first
commit,
so
I
mean
I
was
totally
in
alignment
with
what
we
already
had
in
the
very
first
stab
at
this
in
the
very
first
implementation
of
attribute
value.
My
only
complaint
was
the
arrays
as
bytebuffers,
but
now
we're
discussing
that
we
want
to
constrain
it
even
more
by
removing
more
types.
B
D
B
There
are
two
linked
issues.
We
can
also
link
the
new
one
to
the
original
specification
issue.
I
think
I
just
pasted
it
incorrectly.
Actually,
let
me
just
see.
B
Sorry
is
another
issue
in
our
repo
which
is
linked
to
that
speculation,
but
not
the
weighted
one.
So
I'll
just
add
the
link
here.
Is
it.
B
B
B
I
remember
I
used
to
work
on
a
mobile
devices.
Telemetry
blackberry
and
capturing
white
buffers
was
absolute,
a
base
foundation
requirement
and
it
doesn't
matter
how
you
transform
that
you
may
transform
it
base64.
You
may
transform
it
in
a
string
as
long
as
you
retain
the
knowledge
that
the
original
property
value
actually
contained
a
bite
buffer,
then
you
can
provide
some
special
treatment
for
that
and
you
also
reduce
the
need
for
the
customer
themselves
to
base
60
for
it.
B
B
B
A
A
A
Okay,
then,
let's
continue
the
discussion
in
github
asia
and
any
other
topics
for
today.
Besides
the
api
service
issue,
I.
B
Have
a
quick
question
about
there's
a
new
pr
about
certificates.
B
Yeah,
so
it's
a
great
start
and
I'd
probably
I
I
think
which
I
I
will
approve
it-
here's
my
question
here:
it's
maybe
a
more
of
a
question
to
grpc
library
developers.
If
I
want
to
obtain
a
certificate
using
some
other
mechanism,
for
example,
from
key
vault
or
from
windows,
server,
key
store
or
from
mac
os
key
store.
B
I'd
rather
fetch
it
from
us
where
it's
going
to
be
in
memory,
and
I'm
going
to
be
supplying
that
search
by
passing
that
structure
rather
than
a
file
path.
I
mean
for
linux
container.
I
understand
fine
cool,
some
permissions
are
in
place
and
we
are
all
secure.
We
know
that
we
can
just
stop
that
file
on
some
path
and
pass
it
to
our
tlp
client,
grpc
client,
but
in
a
real
production
system.
B
If
I'm
running
sorry
for
this
example
on
azure-
and
I
have
some
certificate
rotation
in
place-
it's
not
like
I'm
gonna-
be
saving
my
cert
to
temp
puff
every
time.
That's
too
long,
that's
wrong,
and
I'd
argue
that
there
has
to
be
some
abstract
implementation
which
accepts
the
sort,
even
if
it's
in
memory
already
it's
going
to
be
more
secure.
That
way,
I
don't
know
like
I'd
like
to
hear
your
feedback.
C
I
mean
just
just
as
a
note
here
when
you
look
at
the
code.
I
mean
trpc,
actually
what
we
passed
to
gpc
itself,
it's
not
the
path
I
mean
the
file
is
opened,
is
read
and
what
we
pass
to
your
pc
options:
the
contents
of
yeah
okay.
So
maybe
we
should.
You
should
add
this
as
a
comment
to
the
pr
that
we
should
like
in
the
interface
of
our
otp
options.
We
should
not
accept
the
sign
paths,
but
actually
the
string
with
the
certificates
if.
B
That
works,
maybe
like
I'm
not
against
having
a
path
supplied
to
it,
but
also
the
actual
certificate
contents.
That
would
work
too.
C
B
Yeah,
I
mean
it's
a
good
start.
I
I
think
it
has
to
be
integrated.
It's
a
great
start.
It's
just.
We
need
to
make
sure
that
we
also
support
scenario
well
to
pass
that
cert
contents
as
well.
C
I
don't
want
blocks
down,
because
if
you
go
a
bit
lower
here
in
the
bit
further,
I
think
we
have
to.
We
have
to
go
lower,
I'm
not
sure
which
line
it
is,
but
there's
like
still
a
bit
lower
still
a
little
bit
down.
Oh
here
we
are
see
here.
It
is
assigned
like
this
ssl
ops,
that
is
the
trpc
function
here.
The
file.
B
C
B
Yeah,
so
that
that
that'd
be
good
good,
then
it
gives
you
flexibility,
you'd
either
like
read
manually
from
past
points
or
you
just
pass,
read
from
elsewhere,
like
from
keyboard
using
some
remoting
api
and
then
passed.
A
Yeah,
I
think,
for
to
support,
like
the
the
other
case,
store
or
online
case
store.
Maybe
that
should
be
a
separate
pr
and
we
we
may
need
to
find
whether
some
sdk
can
do
that
right.
C
I
think
we
should
try
to
get
it
resolved
in
this
pr
device.
You
know
we
run
the
danger,
I
mean
now.
I
was
thinking
about
this
now
that
we
have
monthly
releases.
If
we
just
commit
stuff-
and
we
say
okay,
we
fixed
it
in
a
photo
or
power.
I
mean
it
might
easily
happen
that
we
release
before
we
get
the
follow-up
pr
in.
So
I
think
we
have
to
be
more
careful.
That's
true.
B
Yeah,
I
agree.
Yes,
I
mean
I
I
I
can
easily
see
how
some
of
my
customers
are
gonna
ask
this
question.
A
Okay:
okay,
any
other
topics
for
today.
D
I
just
wanted
to
ask
if
there
are
no
more
comments.
Well,
I
saw
some
comments,
but
I
think
the
the
they
are
now
well
not
relevant
or
resolved,
result
related
to.
B
Lalit
already
approved
it
right.
Yes,
yes,.
D
It
was
approved,
I
saw
some
comments
from
john
johannes,
but
if
you,
if
you
still
have
some
comments,
we
can
we
can,
we
can
chat
about
them.
If
I
can,
if,
if
I
can
resolve
any
or
maybe
doubts
no,
no,
I
know
this
was
a
misunderstanding.
C
So
we
yes
initialized
exporter,
and
I
mean
then
my
only
my
only
concern
here,
but
that's
a
small
one
institution
blocking
emerging
is
that
we
basically
a
customer
who,
who
has
a
custom
exporter
that
they
implemented.
D
I
think
at
some
point
I
saw
in
the
open
elementary
cpp
a
plug-in
mechanism
for
exporters,
which
is
like
an
open
pr.
So
if
this
one
gets,
but
it
was
abandoned
many
months
ago,
so
I'm
not
sure
what's
the
state
of
this
pr,
but
maybe
you
use
you
sold
this
one
as
well.
I
can
send
you
a
link
to
the
one
which
I
saw
some
time
ago.
D
C
I
remember
that
that
was
a
long
quite
long
time
ago,
but
yeah,
I
think
start
to
mechanism,
would
be
the
nicer
way
to
do
it,
but
we
don't
have
that
in
place
yet
so
I
think
that's
a
big
kind
of
forms
to
open
down
here.
It's
just
yeah,
basically,
even
when
we
have
like
a
list
of
different
exporters
in
there
everybody,
even
when
you
use
kind
of
a
standard
out
exporter,
you
would
still
have
the
cherry
pc
dependency,
because
the
whole
thing
depends
on
that.
C
So
that's
just
a
little
kind
of
knit
I
would
have,
but
I
think
for
now
we
are
probably
ready
to
go
with
that.
That's
the
first
shot
as
soon
as
we
don't
have
this
plugin
interface
in
place.
I
think
there's
not
much
else.
We
can
do.
D
B
I
have
one
question:
slash
thought
yes,
so
disclaimer,
I'm
all
focused
on
just
the
tw
right
now,
because
that
I
have
a
customer
for
that
now.
B
I
was
thinking
that
technically,
as
I
follow
the
same
standard
api
surface
and
you
have
implemented
a
tlp
based
exporter
for
apache,
once
I'm
done
with
atw
I'd
be
curious
to
see
what,
if
I
plug
in
the
alternate
exporter
and
run
it,
maybe
we
can
come
up
with
a
few
cleanups
in
terms
of
how
to
pass
whatever
abstract
meta
tracer
provider,
which
could
be
either
otlp
or
any
other
exporter
in
a
follow-up
pr.
D
B
D
B
Is
I
don't
know
how
often
people
use
apache
on
windows,
because
the
stuff
that
I
worked
on
is
like
unique
to
windows
and
I
think
in
most
cases,
apache
http
gonna
be
mostly
used
on
unix
linux
right
and
it's
like
folks
on
windows
would
use
something
like
internet
information
server,
maybe
and
probably
less
of
a
party.
I
can.
I
don't
know
the
market
share
on
windows.
A
I
remember
we
don't
have
a
build
a
script
setup
for
file
control
ripple
for
for
the
new
newly
added
like
in
this
engine.
Instrumentation
I
mean
I
remember
you
mentioned
it's
apache
right,
not
engine
or
is
it
part
of
the
I'm
just
wondering,
there's
a
setup
built
to.
B
Script
as
part
of
this
pr
for
the
http
okay-
maybe
this
is
another
opportunity
where
we
can
consolidate
and
see
like
we
were
discussing
tom.
What
should
include
what
men
are
adding
country
but
contributing
main,
and
maybe
we
could
have
consolidated
some
of
the
build
scripts
in
the
central
sport.
A
B
And
if
we
don't
couple
them
directly,
then
how
the
build
system
looks
like,
maybe
it
just
needs
to
separately
issue
two
git
commands
to
clone
those
as
separate
repeats.
B
A
B
Country,
for
some
reason
I
have
my
first
impression-
is
how
about
for
each
module.
You
just
have
a
rhythmic
that
describes
how
and
that's
like
total,
like
freedom,
no
structure
or
we
go
with
certain
structure
but
again
imposing
certain
structure
and
contribute.
A
B
So
it's
like,
if,
if
I
for
example,
contribute
an
example
of
how
to
create
a
listener
for
hcw
events,
I'd
go
and
submit
it
in
country,
and
it's
purely
just
a
a
reference.
Implementation
example:
there's
no
strong
structure,
there's
no
push
for
everybody
to
do
it
exactly
that
way.
It's
more
like
a
guideline,
a
recommendation
and
like
for
each
concrete
case.
Somebody
contributes
something
engines
or
apache
or
sqlite
proxy
mysql
proxy.
Basically,
they
start
with
the
concrete
scenario
with
me.
I
guess.
A
B
A
B
A
Okay,
any
more
topics.