►
From YouTube: 2020-11-17 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
A
C
Well,
yeah,
so
some
of
the
some
of
the
api
endpoints
are
allowed
to
throw
errors
and
some
are
not
so.
The
spec
actually
defines
where
errors
are
acceptable
in
a
lot
of
places,
sometimes
yeah
we
may
be
able
to
there's
there's
sort
of
leeway
for
language
idiomatic
responses,
so
in
some
cases
we
may
just
haven't,
have
an
error
or
a
you
know,
a
results
response
where
other
languages
are
not,
and
that's
probably
fine,
but
there's
a
lot
of
cases
where
the
responses
are
sort
of
expected
to
be
uniform.
A
A
C
Yeah
the
matrix
implementation
is
based
mostly
on
the
way
the
go.
Implementation
was
done,
because
that
was
where
all
the
experimentation
for
the
metric
sig
was
happening.
C
So
I
would
assume
that
that's,
basically
the
accepted
list
of
errors,
but
from
a
rest
project
like
I'm,
not
sure
that
that's
the
final
list
that
we
want
to
stick
with
there
might
be
more
again.
There
was
some
discussion
of
that
in
the
issue.
C
A
C
And
that
is
one
way
to
go
up
again.
I'm
not
sure
how
people
will
end
up
using
this
in
their
applications.
People
maybe
just
want
one
trace
error
and
one
metrics
error
with
a
description,
I'm
not
sure
if
people
will
actually
want
to
dig
in,
but
for
some
cases
like
a
trace
error,
exporter
results
we
may
want
to
be
able
to
handle
those
cases
specifically.
So
then
breaking
out
the
enum
there
probably
makes
sense.
C
A
Yeah,
I
guess,
if
we
want
to
like
I
saw,
there's
the
ideas.
We
should
define
errors
for
each
workspace
grid,
but
if
that's
going
to
happen,
we
cannot
really
have
a
long
inside
our
main
crate,
because
that
would
close
the
ability
to
spend
that
error.
It
has
to
be
a
trait
I
would
imagine
so
they
can
add
new
things
into
it.
C
Yeah,
so
the
the
other
one
would
be,
the
the
enum
could
have
been
other
and
it
could
be
pub
okay,
so.
D
B
C
So
maybe
that's
the
way
we
want
to
go.
I'm
not
I'm
not
really
sure.
Have
you
seen
any
other
crate.
Do
this,
where
there's
sort
of
an
extensible
error.
A
I
think
from
api
prescriptive
most
api
doesn't
allow
to
zero
arrows
in
tracing.
I
mean
right,
so
I
don't
really
and
things
like
java.
They
have
long-term
exceptions,
so
they
can
basically
expectation
from
any
any
call
stacks.
So
that
won't
be
a
problem
for
them,
but
from
for
goal
and
us
we
need
to
propagate
one
layer
after
another,
so
it's
gonna
be
there
by
layer
yeah,
but
I
I
don't
so
like
from
a
user
perspective.
I
don't
think
people
care
about
whether
tracing
have
an
error.
A
That
would
be
a
problem
because
you
don't
want
your
main
function
being
suspended
by
the
tracing
abilities.
So
yes,
yeah,
that's
a
good
point.
I
guess
my
my
advice
from
the
the
discussion
issue
would
be
like.
We
have
means
repo
and
that's
the
case
through
that:
every
enum
2
api
and
user
and
the
api.
If
the
api
doesn't
allow
to
throw
errors,
they
just
call
the
global
error
handler
to
process
that,
so
whatever
you
don't
want
to
do
with
that
error,
they
can
do
that
in
api
level.
C
Yeah,
I
think,
that's
probably
right.
The
sdk
is
gonna,
have
a
variety
of
cases
where
there
are
exceptions
and
it
will
either
where
possible.
I
think
moving
them
to
the
a
to
the
api
makes
sense
and
then,
where
it's
not
possible,
it
uses
the
global
error
handler
or
some
other
strategy
yeah.
I
think
I
think
what
you're
saying
is
is
correct.
D
E
B
B
C
C
Yeah,
so
do
those
two
sound
about
right
like
we
basically
should
be?
We
should
be
both.
You
know,
returning
errors
and
dealing
with
errors
are
possible
and
we
should
have
some
form
of
extensibility
in
our
error,
maybe
in
the
form
of
another
case
that
allows
exporters-
and
maybe
third-party,
like
if
rocket,
has
an
open,
telemetry
middle,
where
the
rocket
middleware
should
be
able
to
throw
exceptions
potentially
to
or
have
error
cases
potentially
too.
Through
this,
this
method.
C
Cool
yeah
yeah.
So
if
there's
other
stuff
that
you
want
to
add
in
cards
or
or
other.
B
C
B
Do
that
I.
A
C
C
B
A
C
Yeah,
open
issues
were
added,
I
think
for
ga.
Most
of
these
probably
make
sense.
A
I
think
to
make
sense,
I
think
it
makes
sense
like
we
use
the
environmental
as
before.
That's
still
think,
we
need
need
a
function
that
well,
when
you
call
that
function,
it
will
override
the
current
config
into
the
the
environmental
variable.
One
hey.
D
A
C
Yeah,
I
agree,
I
think
I
think
that
does
I
think,
having
all
of
the
op.
I
think
we
can
actually
have
all
of
the
options
here
where
you
can,
you
can
and
override
it
at
the
end
and
at
the
beginning,
and
then
you
can
do
whichever
method
you
want
from
an
application
developer
perspective,
so
that
should
be.
B
Nice
so
first.
A
G
C
C
Pretty
cool,
so
I
guess
you,
you
may
have
missed
the
earlier
part
of
the
call,
but
we
were
mostly
discussing
exceptions.
So
this
would,
I
guess,
be
a
good
transition.
If
you
want
to
go
into
the
demo
that
you
wanted
to
do
for
the
otlp
exporter.
H
Okay,
can
you
guys
give
me,
is
this
audio
okay.
A
E
G
Before
so,
I
don't
know
how
this
thing
works,
this
tool
thing
yeah,
but
I
will
figure
out
how
to
check
my
screen,
I'm
not
so
sure.
How
do
you
share
your
screen.
E
E
H
Right
so
yeah
I'll
give
just
a
quick
breakdown.
H
About
the
idea
behind
this
change,
I
will
give
you
a
future
comparison,
a
little
deep
diaper.
What.
I
G
G
H
H
So
you
have
actually
two
transporter
implementations,
okay,
so
the
great
tonic
which
I
introduce
is,
as
you
have
seen
right
now.
I
don't
know
it's
a
hyperlink
project.
G
H
G
Okay,
so
the
most
important
feature,
I
think,
is
actually
in.
G
G
G
So
there
was
a
small
conclusion:
it's
introducing
a
breaking
change
right
because
it
now
changes
the
transport
layer
in
underneath
it,
but
users
have
a
choice
right,
so
they
are
not
logged
in
into
a
specific
vendor
and
tls
encryption
with
rust
here
is
optional,
so
you
can
turn
it
off
and
on
which
is
different
from
the
grpc
implementation,
because
openness,
open,
ssl
is
always
turned
on
and
the
other
is
required
for
compilation
and
yeah
it
uses
underneath
it
uses
hyperion
hyper.
G
So
you
might
know
it.
It
has
been
chosen
by
curl
as
the
next
http
library,
and
I
will
send
you
the
slides
afterwards.
You
can
read
about
it,
which
means
that
it
is
it's
getting
popular
and
it's
much
more
performant
than
the
grpc
native
http
library
that
they
are
using.
G
So
all
these
good
reasons
brought
me
to
the
idea
to
make
the
future
tonic
the
default
feature
for
the
crate
and
grpc
sys,
which
is
which
has
been
used
by
now,
to
make
it
optional.
It
is
also
a
reason
because
the
tonic.
H
G
Actually,
using
it,
it's
written
in
poor
white
pure
rust,
so
there
is
no
c
plus
one
spinning
behind
it
and
you
can
which
gives
you
the
ability
to
easily
debug
it
yeah
and
so
the
to-do's.
I
think
this
was
last
week
making
sync
optional.
I
think
it's,
oh,
you
can
make
it
optional
by
default.
I
think
the
tonic
has
no
dependency
on
messing
and
yeah
the
name
of
the
futurist.
I
called
it
tonic
and
grpc
sys.
G
I
have
changed
it
from
legacy
to
geophysics.
Today
I
have
no
ideas
for
better
names
and
you
can
of
course,
expose
more
tonic
configuration
options
through
the
crate
right,
so
things
like
pcb
keeper
live
and
user
asian
string,
and
you
can't
configure
this
at
the
moment.
So
it's
black
box,
it
should
be
exposed
and
I
haven't
added
any
tests
and
it
would
be
interesting
to
actually
run
benchmarks
against
the
c
plus
trust
blending
and
how
it
behaves
in
comparison
to
the
native
library,
tonic,
okay,
yeah
and
so
I'll.
G
Give
you
an
example
now
where
we
are
using
this,
and
so
what
we
are
doing
is
we're
doing
a
lot
of
things
from
google
cloud,
but
we
also
do
not
want
to
be
logged
in
to
the
cloud
to
a
cloud
provider,
and
so
we
are
using.
We
are
appreciating
open
telemetry
because
it
actually
creates
a
collector
and
we
are
independent
from
stackdriver,
which
is
google's
own
tracing
and
logging
solution.
G
So
what
we
are
doing
is
we
are
using
a
service
called
media
cache
and
many
other
services
which
is
actually
running
on
cloud.
It's
a
cloud
one
service
and
cloud
one
for
those
who
are
unfamiliar
with
this.
If
you
are
unfamiliar
with
google
cloud,
the
equivalent
on
aws
is
aws
fire
gate.
It's
a
serverless.
G
G
Platform-
and
we
are
doing
this
in
rust
and,
as
I
said,
the
equivalent
is
aws
far
gate.
It's
actually
very.
If
you
are,
if
you
are
like
us,
and
you
have
a
shoestring
budget,
we
don't
have
any
money,
and
this
is
quite
a
cheap
service
and
if
you're
doing
it
in
rust
and.
G
G
G
We
are
using
it
on
the
public
internet
tool
to
download
things
and
to
expect
so
it's
we
have
it
in
control
and
we
are
not
using
multiple
http
libraries
or
multiple
http
clients
or
whatever
we
can't
control
it.
What
is
going
on,
and
even
if
it
crashes,
it
doesn't
happen
on
the
community's
cluster,
and
this
is
very
interesting
for
you.
If
you
want
to
send
open
telemetry
data
back
from
a
serverless
client,
then
they
have
introduced
a
new
feature
which
is
called
the
service
to
pc
access
connector,
the
connector.
G
So
you
can
send
data
back
to
an
internal
network
because
you
should
not
forget
all
these
cloud
servers
cloud
run
services.
They
are
running
behind
public
internet
addresses.
Actually,
traffic
is
never
leaving
the
google
network.
Google
router
catches
all
requests,
but
nevertheless
you
have
the
option
to
send
it
to
send
such
data
back.
So
we
are
not
dependent
on
any
google
services
in
between.
We
are
simply
using
the
platform
to
host
the
container
yeah
this.
This
is
it.
C
Yeah,
that's
useful
context
or
great,
I
think
you're,
the
first
person
who's
come
to
one
of
our
sig
meetings
with
slides.
C
So
that's
that's
good
you're
raising
the
bar
there
yeah.
I
think
I've
used
tonic
in
a
few
other
projects
and
generally
find
it
great.
I
really
enjoy
working
with
tonic
and
I
think
the
developers
are
moving
that
project
in
a
great
direction.
Yeah.
Some
of
the
some
of
the
questions
that
I
had
I
had
opened
on
on
the
issue
itself.
You've
resolved
the
one
around
specifically
around
the
naming,
which
I
think
now
is
fine.
I
on
some
of
them.
C
We
don't
have
a
default
that
isn't
locking,
but
I
think
if
we
can
get
if
we
can
get
tonic
to
export
via
a
blocking
api,
that
should
work
for
just
sort
of
the
hello
world
case
for
most
users,
so
that'd
be
great.
It
might
be
as
simple
as
just
having
a
a
futures
executor
block
on
before
the
will.
No
because
it
still
needs
an
executor
present.
That
would
be
the
question.
Yeah
does.
Does
the
future
require.
I
Whether
I'm
going
to
explore
this,
this
was
the
next
next
step
after
this
meeting
yeah,
so
to
take
to
take
a
look
at
this,
I'm
not
sure
because
I'm
using
as
tinker
by
default,
so
we
are
not
interested
in
dropping
futures.
I
C
Yeah,
I
I
would
agree-
and
I
think
most
users
are
not
interested
in
that,
but
there
are
many
people
who
run
open
telemetry
as
something
like
a
a
script
or
a
process.
That
is
not
not
a
web
process,
but
just
you
know
an
otherwise
traced
process
that
isn't
using
any
current
executor.
So
supporting
that
use
case
and
not
requiring
one
to
be
not
requiring
an
async
runtime
to
be
started.
Is
nice,
it's
yeah,
there's
a
one.
C
One
option
would
be
to
look
at
how
request
exports
their
blocking
configuration
because
they're
also
based
on
hyper
and
they
offer
both
a
async
and
a
blocking
interface.
C
I
was
just
mentioning
that,
because
request
is
also
built
on
hyper
and
it's
a
it's,
not
a
very
large
layer
on
top
of
hyper
either
so
request
would
be
very
similar
to
tonic
in
that
sense,
and
request
already
solved
this
problem.
G
G
For
us,
most
importantly,
it
was
I
wanted
to
advertise
this
because
I
want
to
have
this
challenge
upstream,
so
we
don't
have
some
kind
of
fork
in
the
shadows
going
on
just
because
we
want
to
use
and
for
us
is
pretty
useful.
It's
it's
very
performant
and
we
are
doing
a
lot
of,
as
I
said,
image
transformations
with
also
multimedia
transformation,
video
transformation
and
vastus,
first
fantastic
language,
because
it's
it's
really
not
resource
intensive.
G
It's
actually
up
to
ten
times
faster
than
gold.
Previously.
G
Important
for
the
project
is
to
add
some
benchmarks.
I
said
this
before
because
I
think
with
with
this,
what's
the
ls
implementation
and
hyper
in
the
background,
and
this
crate
will
actually
be
the
fastest
grade
in
and
the
fastest
crate
in
the
open
television
universe
or
the
fastest
package
in
the
whole
telemetry
universe.
I
C
Yeah
there
are
there's
configuration
in
some
of
the
other
exporters
to
not
use
tls
at
all,
which
maybe
is
cheating
but
yeah,
with
with
tls
enabled
it
it
likely
would
be
faster,
which
would
be
really
cool
to
see
yeah.
I
agree,
I
think
benchmarks
will
be
very
interesting
here.
Have
you
have
you
written
tests
in
your
other
application
with.
G
And
where
is
it
so?
We
are
doing
complete
tests
to
put
demo
images
into
the
storage
and
then
we
are
checking
if
it
actually
is
being
consumed
by
fastly.
So
this
was
important
for
us.
It's
an
important
future,
because
users
upload
a
lot
and
and
yeah
these
things
usually
tend
to
crash,
because
if
you
download.
G
Of
nothing
could
also
be
so
yeah,
it's
an
attack
vector-
and
this
is
also
the
reason
why
we
put
it
on
the
challenge,
one
which
was
experimented.
I
think
it
would
be
even
more
efficient
if
you
would
use
it
with
web
assembly
instead
of
cloud
one
right,
and
so,
if
you
represent
beyond
the
edge
as
the
website
on
the
edge
actually.
G
I
G
Could
be,
I
will
send
you
the
start,
so
you
can
so
you
can
use
it
further
experimental
to
figure
out
if
this
was
actually
working.
You
can
really
save
a
lot
of
money
and
it
was.
It
was
surprising
for
us
that
how
cheap
it
could
be
to
serve
gigabytes
for
the
two
of
the
tools,
gigabytes
of
those
data
for
a
couple
of
cents.
Instead
of
some
20
30
dollars
every
day,
yeah,
it's
it's
actually.
G
Cost
productive,
okay
and
yeah
and
yeah,
and
so
this
is
also
open
to
change.
I
mean
we
don't
need
anything
default,
but
I
thought
this
might
be
easy
easier
for
the
user
that
he
does
not
have
to
configure
a
default
crate,
so
you
can
simply
use
the
crate
and
it's
working
in
the
background
automatically.
C
Yeah,
I
think
one
of
the
other
benefits
could
be
that
running
the
defaults.
Just
cloning
and
building
the
open,
telemetry
project
might
not
require
all
the
jrpc
libraries
to
be
installed,
so
it
could
be
a
benefit
for
first-time
users
as
well
so
yeah.
I
think,
there's
lots
of
there's
lots
of
advantages
to
doing
it.
C
This
way
so
appreciate
that
you
put
in
the
time
to
to
build
out
some
of
these
features,
but
were
there
any
other
things
we
wanted
to
discuss
about
this
one
at
the
time
or
most
of
them
just
going
through
the
to-do's
and
cleaning
things
up
before
it
can
be
reviewed
further.
G
Yeah
should
I
write
tests
because
in
the
crate,
they're
actually
an
old
test
at
the
moment-
or
maybe
I
haven't
seen
them-
I
think
metrics-
the
metric
adapter
is
also
implemented.
Maybe
it
is
and
see
it.
I
can't
remember
and
yeah
so
I
mean
I
have
time
I
can
spend
time
to
put
to.
G
This
for
longer
periods,
because
we
are
interested
in
using
vastly
important
telemetry
yeah,
so.
B
G
I
do
because
I
didn't
want
to
introduce
additional
features
right,
so
things
like
tcp
people
like
usa
swing.
All
these
kinds
of
things
are
very
nice
to
have,
but
maybe
it
will
be
a
little
too
much
for
the
first
full
defense
or
I
could
include
them
all
optionally.
I
could
also
work
on
a
branch
on
the
repo,
and
then
this
branch
would
be
merged
back
to
master
and
yeah
and.
C
Yeah,
I
so
I
think,
once
the
top
question
around
async
has
been
answered,
the
other
things
can
be
done
in
subsequent
prs.
I
think
that's
the
large
one,
because
that
would
be
a
regression
from
the
current
supported
feature
set,
but
once
the
async
question
has
been
answered
in
how
how
that
will
work,
maybe
the
answer
is
it
just?
It
doesn't,
and
you
well
yeah,
I
think,
for
default
users.
C
I
think
that
would
be
hard
potentially,
if,
if
async
can't
be
done
in
a
in
a
easy
way
to
support
to
support
other
runtimes
or
not
having
an
active
runtime.
If
that
can't
be
done
easily,
the
other
option
is
we
just
keep
the
grpc
sys
feature
as
the
default
and
then
do
all
these
in
subsequent
prs
and
then
switch
the
tonic
to
be
default
once
it
can
have
an
optional
runtime.
So
I
think
basically
based
on
the
the
answer
to
the
async.
G
G
News
for
for
the
last
project
itself
that
it
is
being
further.
H
On
there
yeah,
I
will
send
you
a
link.
C
Okay,
you
can
add
them
to
the
the
notes
as
well.
If
you
want
to,
then
other
people
going
through
the
meeting
notes
later
can
can
review
the
slides
as
well.
That's
great.
Are
there
so
we've
gone
through
the
the
agenda
items
that
I
had
added
before?
Are
there
any
other
agenda
items
that
we
should
discuss
or,
or
is
this
it
for
today.
G
I
C
Yeah,
I
think
the
answer
to
that
is
yes,
we
should
add
examples
again.
These
things
can
be
done
in
subsequent
pr's.
We
don't
need
to
do
this
all
at
once
in
one
big
thing,
but
I
think
having
examples
is
a
good
idea
and
having
and
adding
metrics
support
is
also
a
good
idea.
G
Yeah
there
are
just
a
few
constants
missing
I
mean
you
could
write
a
muscle
user.
You
could
use
all
the
tools
available,
but
you
could
add
them
as
default
content
into
the
library
and
yeah,
because
I
have
seen
it
when
you
guys
have
little
changes.
Then
you're
often
not
changing
the
examples
in
the
same
in
the
same,
commit
on
the
same
change,
but
they
are
being
changed
afterwards.
G
I
G
If
the
complexity
grows,
which
isn't
there
is
at
the
moment,
there
is
very
limited
complexity,
which
is
good,
but
if
the
complexity
should
grow
in
the
future,
then
there
will
be
someone
who
would
know
about
these
things.
I
C
Make
all
right
very
cool.
Well,
if
there
aren't
throwing
other
items,
then
I
I
guess
we're
we're
done
for
the
day.
That's
great
thanks!
Everybody
we'll
meet
again
in
two
weeks.