►
From YouTube: 2020-09-04 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
Yeah
it's
or
it's
it's
been
very
hot
in
portland
and
we're,
but
we're
going
out
to
the
coast
where
it's
going
to
be
about
30
degrees,
cooler,
30
degrees,
fahrenheit,
cooler,
so
probably
13
degrees,
cooler
celsius.
Something
like
that.
Something
like
that.
A
A
C
Yeah
same
for
me,
yeah,
so
excuse
me
for
the
branding
noise.
It's
all
right!
I
am
in
a
coffee
shop,
yeah.
B
C
A
A
A
Yeah,
I
think
it's
supposed
to
be
down
to
10
tomorrow
night
out
at
the
coast,
so
it's
gonna
be
well
right
when
you're
right
on
the
ocean,
it
gets
cold.
A
B
So
my
first
question
on
the
agenda:
if
you,
if
you've
seen
it
yeah,
we
do
the
the
question
is
when
I,
when
I
made
the
pull
request
to
spec
about
trace
state
and
just
enumerate
all
the
operations
taken
directly
from
w3c
specification.
B
B
My
initial
idea
was
why
why
I
haven't
added
that
to
api
is
that
I
thought
it's
it's
it's
vendor-specific
stuff
that
end
user
will
probably
not
use
it
will
be
used
only
by
some
existing
like
plumbing
thingy,
like
exporters
and
propagators.
I
haven't
realized
that
propagators
can
depend
only
on
api
right.
A
It
I
mean
at
the
moment
our
I
mean,
I
guess
I
don't
remember,
and
carlos
you
may
know,
are
propagators
intended
to
only
depend
on
the
api
or
are
propagators
allowed
to
depend
on
the
sdk
api.
A
I
think
we
have
to
then
the
the
speed
these
features
have
to
be
available
to
the
api.
Right,
like
I
mean,
if
you're
going
to
write
a
custom,
propagator
that
needs
to
be
able
to
you
know,
take
account
ids
off
the
wire
and
put
them
into
your
your
your
format
for
your
vendor,
like
you
have
to
be
able
to
get
access
to
the
trace
date.
A
B
C
Yeah,
that's
great
because
then
other
implementations
don't
have
to
rewrite
them.
So
yeah,
let's
go
with
api.
A
B
A
Be
I
don't
think
that'll
be
controversial,
I
could
be
wrong.
Everything
seems
to
be.
B
A
There's
nothing
else
on
the
agenda.
I'm
gonna
be
out
until
tuesday,
it's
holiday
here
on
monday,
carlos
said
he's
out
today
in
monday
as
well,
we
cut
we
released
o.8.0
on
tuesday.
Anyone
who
wants
to
use
it.
Please
kick
the
tires
and
make
sure
it
works.
Okay,
are
there
any
other
things?
People
want
to
talk
about?
I
hate
to
cut
it
all
short,
but
then
I
don't
hate
to
waste
everyone's
time.
If
we
don't
have
things
to
talk
about.
C
Just
for
your
information
notes,
I
will
I
will
be
working
on
the
updates
for
the
propagators
together.
The
prototype
I
didn't
have
time,
but
I
hope
to
work
on
that
next
week.
C
Yeah
yeah
there's
there's
only
one
small
thing
and
is
that
in
theory,
trade
state
may
use
many
headers.
You
know
multiple
entries
with
the
same
header,
so
I
may
end
up
changing
that.
I'm
installing
what
to
do
there
so,
instead
of
returning
the
keys,
the
iterator
would
return
both
keys
and
values.
Tyler
tyler.
I
think
you
mentioned
that
you
you
had
preferred
that
such
an
iterator
only
returns
keys,
but
you
know,
based
on
the
fact
that
we
may
need
to
support
multiple
entries.
We
may
need
to
return
both.
A
E
Are
we
then,
back
to
doing
it
like
open
tracing
with
having
the
the
extractor
just
return,
an
iterable
of
key
value
pairs?
No,
we
will
have
that
and.
C
C
C
C
Well
for
the
prefix
for
the
prefix,
we
only
need
to
get
the
iterator
for
the
keys,
but
if
it's
repeated
entries,
then
we
need
both.
E
All
right,
so
wouldn't
that
be
a
problem
on
the
the
get
field
as
well
shouldn't.
Maybe
git
should
return
a
list
instead
of
a
single
entry.
C
C
That
could
be
yes,
that
could
be
actually
that's,
not
a
bad
idea
yeah,
but
the
only
problem
with
that
is
that
we
would
end
up
with
three
methods,
one
together
instead
of
two.
So
that's
so
that's
an
option.
The
other
option
is
that
we
expose
iterator
with
the
values
as
well,
not
only
the
keys
so
between
those
two.
We
would
have
to
decide.
E
Right
so
my
suggestion
would
be
to
just
review
the
instrumentation
for
the
various
frameworks
and
make
a
judgment
call
on
what
ends
up
being
the
the
the
easiest
to
instrument
with.
E
I
say
that
is
because
looking
at,
for
example,
like
the
open
tracing
instrumentation
for
servlet,
that
was
always
kind
of
a
big
pain
building
that
iterable
it
required
a
lot
of
copying.
The
the
the
underlying
servlet
framework
didn't
make
that
easy
to
get
that
you
you,
you
had
to
copy
everything
and
that's
the
main
thing
I'm
trying
to
suggest
we
avoid.
C
A
So
I
guess
the
only
other
big
thing
that's
changed
is
post
0.8.
We,
I
did
get
the
I
merged
the
change
to
get
rid
of,
trace
id
and
span
id,
which
is
cool
for
it.
A
For
the
agent,
I
think
less
rapping
to
be
done,
and
I'm
probably
early
next
week
will
submit
a
pr
to
do
the
same
thing
with
the
trace
flags,
which
is
currently
just
a
single
boolean
and
also
I'll
just
put
a
sample
I'll
put
a
sample
boolean
onto
the
span
context,
and
we
can
use
that
instead
of
having
to
carry
an
object
around
for
that.
C
A
C
A
C
It
has
but
but
not
I
mean
it's
only
a
consumer.
C
A
Interesting,
so
the
so
the
scope,
so
the
scope
would
be
would
be
handed
back
by
that
with
span
method.
The
same
way,
I'm
just
trying
to
make
sure
that,
like
a
user
who's
trying
to
write
manual
instrumentation,
is
it
going
to
be?
Is
it
going
to
be
clear
what
they're
supposed
to
do,
because,
right
now,
it's
really
easy,
like
you
just
have
the
tracer
and
all
the
operations
on
the
tracer.
C
A
I
agree
it
definitely
will
get
a
little
more
complicated,
but
it
might
clarify
things
there's
like
a
lot.
There
is
definitely
a
lot
of
confusion.
We've
seen
a
bunch
of
people
talking
about
how
they
don't
understand
the
difference
between
start
span
and
with
span
and
why
they're
both
and
what's
going
on
and
what
is
the
context
or
what
is
the
scope
for?
So
maybe
this
would
actually
clarify
the
issue
to
really
separate
the
context
from
the
tracer
at
the
api
level.
A
B
A
I
haven't
written
any
written
any
automatic
instrumentation
at
all,
and
I
know
that
I
understand
the
apis
now,
but
because
I've
used
them
a
lot,
but
we
definitely
every
person
who
comes
in
and
tries
to
understand.
They
always
ask
the
question:
why
start
spaying
them
with
spam?
What's
the
difference?
Why
do
we
need
both
what's
happening
here
and.
B
E
C
I
am
fine
to
tell
you
with
removing
the
utils
parts
I'm
just.
I
just
would
like
to
have
a
name
that
is
not
only
better
but
much
better,
but
I
am
open
to
try
tracy
context
as
a
name
instead.
A
All
right:
well,
let's
keep
this
in
mind.
I
think
this
is
something
we
should.
I
think
if
we
do
to
make
this
change,
I
think
we
need
a
better
name,
and
so,
let's
keep
let's
keep
thinking
about
that.
A
Same
same
yeah,
the
other
big
thing
that
I'm
working
on
around
api
simplification
is
this:
switching
to
a
key,
a
typed
key
model
on
the
attributes.
A
It's
going
to
be
a
big
change,
so
I'm
trying
to
do
a
piecemeal,
so
there's
one
the
first
pr
which
is
seemingly
unrelated,
but
I
put
some
comments
about
it
about
adding
a
adding
a
type
on
that
on
the
key
part
of
the
attribute
or
the
internals
of
the
attributes.
So
I'm
not
quite
done
with
it.
There's
a
there's
some
comments
from
monorail.
I
need
to
address
that
I'll
get
to
on
tuesday,
but
that's
going
to
be.
A
Those
pr's
are
going
to
be
coming
in
starting
next
week
to
try
to
get
that
change
into
the
api
before
0.9.
So.
E
Oh
so,
with
regards
to
that,
I
haven't
had
a
chance
to
sit
down
and
like
write
some
some
code,
but
maybe
I
can
explain
it
really,
quick.
What
I
had
in
mind
with
regards
to
the
the
tag
consumer,
I
was
thinking
having
a
consumer
with
a
class
passed
into
it,
where
the
effectively
would
iterate
through
each
of
the
tags
check
to
see
if
it's
an
instance
of
that
type
and
if
so,
pass
it
to
the
consumer.
A
Yeah,
so
here's
the
here's,
the
issue
with
that
I
did
this
experiment
with
my
with
my
mentee
during
my
mentoring
time.
We
were
working
through
this
problem.
The
lists
don't
work
because
you
can't
do
you
can't
pass
in
the
type
contained
the
generic
type
on
the
list,
so
unfortunately
it
works
for
the
print
for
the
basic
type,
the
four
basic
types
with
the
list.
There's
no
no
way
to
distinguish.
A
A
A
E
Maybe
the
way
that
I
would
solve
that
would
be
making
list
be
a
special
case
of
oh,
but
I
guess
you
can't
figure
out
the
type
of
the
list
inside
the
the
collection
unless.
E
A
Yeah,
it's
a
pain
I
will,
I
will
say
so.
Anyway,
I
was
saying
we
could
have
two
consumer
apis,
one
which
is
the
big
giant
ugly,
one
with
eight
methods
on
it
or
eventually,
maybe
more
with
all
the
types
all
of
the
essentially
the
switch
broken
out
into
individual
methods
with
the
type
dispatch
and
then
a
second
one,
which
is
just
a
single
method
where
you
don't
get
any
type
information
and
you
have
to
do
whatever.
A
If
you
care
about
introspection,
it's
up
to
you
and
if
you
don't
care
about
it,
you
can
just
pass
that
data
along.
So
that
was
kind
of
the
way
I
think
we
can
solve.
This
is
just
having
those
two
separate,
two
separate
apis
that
you
can
choose
which
one
you
want
to
use.
What
types
of
lists
do
we
support
all
the
all,
the
all
the
basic
types,
boolean,
long,
double
string:
okay,
yeah
I
mean
the
other
option
would
be
to
stop
doing
lists
and
actually
pass
arrays
through.
But
then
the
mutability
is
bad.
A
Internally,
we
know
the
type
of
the
key
like
the
key
in
this
in
this
model
has
the
type
embedded
in
it.
What
type
of
list
it
is
right.
There's
a
there's,
a
string,
there's
a
string
array
key
and
there's
a
boolean
array
key.
So
I
know
that
type.
So
again,
this
is
where,
if
you
have
just
like
the
bear
api,
where
you
pass
the
key-
and
you
can
interest
that
you
can
do
a
switch
on
the
well,
you
can't
do
a
switch
until
java
when
you
switch
on
cloud
types
like.
E
That
the
types
go
through
well,
what
I
was
saying
is
you
could
have
a
primitive
or
a
basic
consumer,
and
then
you
could
have
a
list
consumer
where
the
list
consumer
would
have
its
the
the
generic
type.
As
the
argument.
A
So
like
so
you,
so
you
didn't
end
up
with
two
methods.
Instead
of
eight
methods.
E
A
Yeah,
I
mean
that's,
certainly
an
option.
My
initial
implementation
is
only
going
to
probably
do
the
eight
methods,
and
then
we
can
add
to
it
after
that,
because
my
I
mean
my
plan
is
to
do
the
minimal
api
that
we
need
today,
that
our
exporters
need
to
use
and
the
exporters
all
are
switching
doing
all
the
switching.
A
So
it's
easy
to
make
the
exporters
just
have
a
have
a
big
giant
interface
implementation
instead
of
the
switch,
and
I
don't
think
any
of
them
care
about
order
at
all
the
only
time
you
would
need
to
use
this
other
one
is,
if
you
cared
about
order
or
if
you
were
obsessively
refused
to
use
classes
and
only
wanted
to
implement
things
via
lambdas.
B
A
So
anyway,
I
think
there's
multiple
ways
to
attack
it.
I
think,
for
starters,
I'm
going
to
do
the
simple
thing
with
just
the
giant
eight-way
interface
to
implement.
E
A
But
I
think
it's
all,
I
think
all
of
it
is
possible
building
a
good
api.
That
doesn't
I
mean
the
the
main
goal
here
is
to
stop
wrapping
everything
right
and
so
as
soon
as
you
stop
wrapping
everything
getting
an
api
is
a
little
trickier
to
a
good
easy
to
use.
Api
is
a
little
trickier,
but
thanks
for
thinking
about
that
java,
generics
are
just
so
not
great.
A
I
think
I
would
love
that,
but
we
need
kotlin.
We
need
some
kotlin
authors,
kotlin
and
android
people
to
help
out.
So
I
think
that'd
be
great,
but
I
think
this
feels
to
me
like
it
would
almost
be
a
separate
like
a
separate
yet
another
language
project
like
we
have
go
and
we
have
java.
We
could
have
kotlin
as
a
separate
project
that
that's.
B
A
Well,
kotlin
java
interop
is
pretty
good,
but
the
api,
the
sdk,
is
directly
implementing
the
java
interfaces.
So
if
you
were
to
have
a
separate
set
of
kotlin
interfaces,
you
would
you
need
a
whole
separate
sdk.
Could
you
decompose
the
sdk
in
such
a
way
that
you
could
yeah?
I
don't
know
it'll,
be
an
interesting,
interesting
challenge
to
figure
out
how
to
do
that,
like
you
want
to
have
like
two
sdk
surfaces
with
one
implementation
underneath,
so
it's
something
I
don't
know.
It's
gonna
be
interesting
to
figure
that
out.
B
A
Yeah
it'd
be
interesting
for
someone
for
a
kotlin
someone
who's,
actually
a
kotlin
user,
to
use
the
api
as
it
is
and
figure
out
where
it's
it's
very
awkward
to
use
in
kotlin
I'm
I
have
not
written
kotlin
and
before,
like
since
1.0
came
out,
so
I'm
way
behind
on
and
really
understanding
how
to
write
it.
A
Well,
I
look
like
john
bly
put
in
that
pr
for
some
kotlin
co-routine
support
and
auto
instruments.
B
A
So
yeah
yeah
kotlin
we
knew
relic
is
a
as
a
couple
times
attempted
to
do:
co-routine,
instrumentation
and
but
it
was
early
on
before
their
apis
were
particularly
solid.
So
we
didn't.
We
got
something
hacked
together,
that
sort
of
worked
that
we
kind
of
recommended
hey.
If
you
want
to
do
some
manual
instrumentation.
A
This
is
how
you
might
put
it
together,
but
it
certainly
wasn't
perfect
yeah,
it's
gonna
be
interesting
when
we
get
to
java,
17
or
21
or
whatever
it
is
when
they
release
when
they
finally
release
fibers,
and
we
have
to
see
how
much
instrumentation
we
have
to
redo.
B
Oh,
I
still,
we
still
have
a
issue
in
the
backlog
to
properly
support
parallel
stream
for
joint
pools
all
right.
Well,
we've
got
money
to
work
on.
A
A
All
righty
well,
there's
anything
else.
I
think
we're
done
for
the
day
thanks
everybody
have.