►
From YouTube: 2021-01-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
A
Yeah,
as
usual,
you
know,
if
you
could
add
your
name
to
the
attendees
it'd
be
great
seems
like
we're
getting
less
and
less
people.
It's
hilarious.
B
Hey
didn't,
can
you
hear
me.
A
I
don't
know
if
diego's
joining
today,
either
so
we'll
see
what's
up
alex,
damn
we're
getting
like
less
and
less
attendees.
For
this
thing,.
C
That's
wow,
we
just
lost
aaron,
as
you
were
saying
this.
C
A
Yeah,
it's
might
be
a
shorter
meeting,
so
it's
not
much
to
talk.
I
mean
there
is
a
lot
to
talk
about,
but
you
know
not
many
people.
So
it's
the
thing.
Okay,
I
guess
we
could
get
started.
Let
me
just
share
my
screen.
A
Okay,
so
I
think
this
global
providers
thing
was
added
by
aaron,
so
we
can
wait
until
he.
He
comes
back
well
what
the
hell,
okay
yeah.
A
So
in
the
meantime,
we
could
talk
about
this
kind
of
stuff,
so
we're
planning
to
do
a
release
by
the
end
of
this
week,
just
to
get
everything
you
know
up
to
date
and
we
are
planning
the
rc1
release
by
the
end
of
this
month,
which
is
pretty
much
the
ga
for
tracing
so
1.0,
which
is
tracing
context
baggage
and
propagators
alex,
and
I
have
already
been
working
to
close
most
of
the
rc1
issues
and
get
our
repo
ready.
A
This
includes,
like
you,
know,
moving
all
the
components
to
where
they
should
be,
if
they're
not
specked
out
like
how
we
discussed
like
the
configurators
configuration
api
last
week,
as
well
as
like
removing
the
auto
instrumentation
stuff
out
of
the
sdk.
A
Yep
and
the
last
thing
we
probably
have
to
do
before
our
release
is
to
go
through
the
our
documentation
to
make
sure
that,
like
all
of
our
stuff
on
read
the
docs
and
our
docs
strings,
and
our
readmes
have
you
know,
are
still
valid,
like
the
api
services
still
makes
sense.
Nothing
breaks
stuff
like
that.
A
A
Yeah,
that's
pretty
much
it
for
that.
Does
anybody
have
any
questions
regarding
this
timeline
in
this
release?
This
is.
A
A
So
we
have
these
remaining
rc1
issues.
The
ones
to
that
I
talked
about
the
issue
was
the
one
of
these
ones
right
here:
stable
docs,
not
opting
and
read
the
ducks.
We
still
don't
really
know.
What's
up
with
that,
and
I
don't
think
anyone
has
really
took
time
to
tackle
this
either.
A
A
So
I
don't
know
what's
going
on
with
that,
we
might
have
to
come
up
with
a
solution
for
this
yeah.
For
that
I
mean
this
review.
Documentation
is
kind
of
a
generic
thing,
but
it's
pretty
much
what
I
just
said
before
so
yeah,
so
we're
gonna
be
focused
mostly
on
the
release
so
like
if
you're
an
approver.
A
Please
try
to
like
close
out
the
pr's
that
are
assigned
to
you
within
here
and
in
the
contributor,
mostly
here,
the
contrib
repo
stuff,
a
lot
of
the
stuff
related
to
instrumentations
they're,
not
up
for
ga
but
stuff
like
this,
like
this
configuration
api
stuff
also
applies
so
yeah
cool.
A
All
right,
nice,
okay!
So
now
we
have
this
whole
other
issue.
A
D
I
believe,
like
I
don't
I
did
that.
I
also.
D
Basically,
like
setting
an
object
accidentally.
A
Yeah
this
has
been
up
for
a
while,
and
we
probably
should
solve
this
before
before
we
release.
So
it
seems
like
a
lot
of
discussion.
That's
going
on.
I
haven't
been
following
this
pretty
closely,
but
like
has
there
been
like
a
consensus
on
what
we
should
be
doing
like
a
solution.
D
So
so
like
we
are
giving
a
workaround
currently
using
environment
variables,
but
still
there
are
so
so
basically
there's
a
odl
racer
powered
area
which
solves
this
for
them.
But
there
are
certain
limitations
to.
A
D
Are
imported
the
tracer
the
provider
is
set
before
the
actual
initializations.
D
So
so
we
like
we
provided
them
a
workaround
solution
like
use
the
environment,
variable
odl,
tracer
provider,
that
would
that
would
at
least
help
for
now.
D
Yes,
yes,
so
so
anton,
like
the
guy
also,
you
know
raised
a
question
like
how
do
I
set
the
sampler,
and
this
was
attributes
for
that.
Also
we
have
a
env
server.
E
I
had
to
call
in
on
my
phone
so
I'm
doing
the
audio
through
there,
but
yeah
all
good
yeah.
I
think
what
srikant
said
was
pretty
accurate.
E
I
did
I
just
want
to
say
I
checked
with
bjs
repo,
the
jsig,
and
they
do
have
like
a
proxy
solution
for
tracer
right
now,
which
is
almost
exactly
what
we
were
describing
and
yeah
it's
I
I
messaged
them
on
gitter
and
daniel
said
that
they're,
basically
trying
to
solve
the
same
issue
and
they're
planning
to
do
the
same
thing
for
metrics.
E
I
asked
if
they
have
any
any
plan
to
add
it
to
the
spec
and
they
said
no,
because
it's
like
sort
of
an
implementation
detail
which
I
guess
is
true,
because
the
spec
is
very
vague
about
what
a
global
provider
is
yeah.
So
I
I
guess
that's
that's
fine,
like
we
wouldn't
need
to
update
the
spec,
even
though
it'd
be
nice.
If
you
know
two
sigs
are
implementing
it
to
have
some
guidelines
but
yeah
I
was
gonna,
say
it's
right.
It's
fine!
E
It's
like
relatively
okay
for
tracer,
but
for
meter
it
gets
a
little
more
complicated
because
the
user
has
a
handle
on
the
instruments
so
that
you
have
to
proxy
like
another
level,
so
it
just
gets
a
little
bit
messy
and
honestly,
like.
We
just
need
to
decide
if
we're.
Okay
with
that,
I
think
it's
a
good
solution.
E
I
still
think
we
should
log
like
if
they
change
the
provider
and
there's
some
spans
or
like
metrics
lost.
I
think
we
should
still
at
least
log
it
so
that
they
know
and
they
could
try
to
restructure
their
code
because,
like.
E
So
in
like
when
you
have
a
you,
have
a
tracer
handle
you
just
get
spams
from
it
right.
E
A
A
Is
that
a
route
that
we
want
to
go,
or
is
this
environment
variable
things
sufficient
enough.
C
Yeah
the
way
we've
addressed
this
with
some
of
the
other
environment
variable
configurable,
things
is
via
entry
points
right,
like
defining,
defining
the
like
an
entry
point
that
maps
to
like
a
class
method
and
then
using
the
environment
variable
to
load
that
entry
point.
So
I
think
the
propagator
does
this
today
and
the
exporter.
Does
this
as
well.
D
E
Yep-
and
I
think
also
another
issue
is
like
what
anton
is
saying
here,
is
that
they
want
to
load
like
a
configuration
from
somewhere
like
over
the
network
or
something
so
like
a
sampling
ratio
or
something,
and
if
you
need
to
pass
it
as
an
environment
variable,
you
can't
really
do
that
because
you'd
have
to
like
I
mean
you
could
do
it
but,
like
you
said,
you'd
have
to
have
a
process
run
beforehand
and
then
start
the
process
with
the
right
environment
variables,
which
is
kind
of
kind
of
a
lot.
But.
A
Okay,
so
I
guess
first
question
like
do:
we
need
this
for
our
release.
E
That's
true,
but
we're
changing.
We
would
be
changing
the
implementation,
so
it
would
be
definitely
different.
I
guess
it
would
sort
of
be
like
if
we
implemented
it
correctly.
It
would
be
a
no-op
for
people
who
have
it
set
up
correctly
already,
but
yeah
it
doesn't
change
the
api.
It
should
just
be
an
internal
detail.
A
E
So
if
they
were,
if
they
had
no
up
ones
by
accident,
then
it
would
change
to
be
correct.
But
if,
if
they
have
like,
if
they're
doing
everything
correctly
already,
then
it
should
be
basically
no
up,
because
the
provider
would
just
be
set
once
right.
E
D
A
E
I'm
I'm
okay
with
it,
but
I
think
it'd
be
good
to
have
like
a
consensus.
So
I
think
he
has
a
anton
put
up
a
pr
for
the
tracer
one.
So
you
can
sort
of
see
the
added
complexity
there
and
we
can
and
we
can
like
maybe
prototype
it
from
metrics
and
decide.
If
we
want
to
take
that
on
on
that
complexity
or
if
it's.
E
Overkill,
I
still
think
if
we
do
the
proxy
thing,
we
should
be
logging,
if
there's
any
spans
that
are
lost
or
maybe
add,
like
a
count
of
like
the
spans
that
were
supposed
to
be
created
for
for
the
default
tracer
or
something
so
that
when
it
gets
reset,
we
can
at
least
log-
and
they
can.
E
You
know
like
search
through
and
see
what's
happening,
because
my
concern
is:
if,
if
people
do
this,
they're
gonna
stop
worrying
about
the
import
order
and
they're
just
going
to
like
end
up
initializing
their
telemetry
late
and
then
they
might
lose
like,
especially
when
we
have
logging
they
might
lose
like
startup
logs
or
they
might
lose
startup
traces
that
are
really
important.
So
I
think,
as
long
as
we
have
some
availability
for
that,
yeah.
E
B
Makes
sense
and
at
some
point
down
the
line
we
could
also
then,
as
an
improvement
later
hold
on
to
the
spans
and
flash
them
later
once
the
pipeline
is
set
up.
D
Also
one
one
thing:
one
thing
in
this
pr
is
like
it
is
allowing
to
overwrite
the
global
dresser
provider,
but
I
think
I
don't
think
we
should
be
following
this
like,
like
you,
created
one,
removing
a
resource
from
spam.
I
think
that's
that
some
kind
of
related
to
them.
D
D
A
Okay,
so
if
that's
an
issue,
can
you
can
you
comment
on
this
pr,
then.
D
A
All
right,
thanks
aaron
also
it
looks
so
looks
like
you
made
some
comments
with
anton.
It's
like
everything
resolved
or
like
it's
just.
E
Yeah,
I
told
him
like
hey,
let's
decide
if
we
wanted
to
take
this
approach
and
then
if
we
do
then
I'll
come
back
and
I
can
leave
more
comments
and
we
can
resolve
it.
But
yeah.
A
C
I
think
the
proxy
approach
makes
sense.
I'm
you
know.
Looking
at
the
pr
doesn't
look
super
complex.
I
guess
it'd
be
good
to
understand
what
this
looks
like
for
the
meter
provider
but
like
in
the
short
term.
This
seems
to
be
a
good
solution.
A
I
feel
like
it's
going
to
be
kind
of
for
meter
to
be
honest,
but
we'll
see,
and
I'm
actually
kind
of
like
I'm,
not
that
stressed
out,
because
our
api
layer
doesn't
really
change.
So
I
think
it's.
This
is
fine.
A
E
The
discussion
is
just
sort
of
getting
putting
all
the
options
out
there
and
deciding
on
one,
so
I
think
we
just
hopefully
resolved
it.
A
Okay,
can
can
one
of
you
guys
just
comment
on
this
issue?
Well,
we
talked
about
yeah
all
right
thanks.
Thank
you!
Cool
cool,
nice
yeah.
So
we'll
revisit
this
once
the
meter
provider
comes
up,
so
okay
does
anybody
else
have
any
topics
they
want
to
talk
about
before
we
get
into
prs
and
such.
A
Okay,
so
I
recently
updated
the
versioning
document
again.
This
will
reflect
what
we
talked
about
before
the
break
in
which
we
are
splitting
up
the
the
package
for
each
of
those
individual
signals,
and
I
kind
of
give
an
example
of
how
to
do
that
here.
A
So
as
long
as
people
understand
what
we're
doing
it,
how
we're
doing
this
there's
no
rush
to
get
this
merged,
but,
let's,
like
it'd,
be
good
to
take
a
look
at
this
document
and
if
you
have
any
like
questions
or
like
you
know,
something
isn't
outlined
pretty
clearly
or
we
should
do
things
in
a
different
way
like
please
like
say
this
early
and
now
before
we
go
ahead
with
it
in
like
a
month.
A
This
is
pretty
much
what
the
community
has
decided.
Not
the
implementation,
but
like
a
lot
of
languages,
are
doing
it
this
way
so
yeah.
Please
take
it.
Please
please
review
this.
A
We
can't
really
go
back
after
we
release
so
yeah
any
questions
on
this
all
right,
nice
cool.
Next
up,
I
don't
think
diego's
here
right
now,
so
we
could
talk
about
this
after.
C
But
yeah
dude.
What
do
you
want
to
just?
I
just
wanted
to
mention
one
thing
about
the
the
contrib
pr.
C
Yeah
yeah,
so
this
there's
this
one.
One
thing
that
I
wanted
to
mention:
can
you
open
up
the
code
in
here?
There's
like
the
the
exclude
url
is
like
something
that
seems
pretty
common
across
a
lot
of
our
instrumentations,
and
I
feel
like
having
this
be
like
duplicated
code
everywhere
in
the
instrumentations
themselves
seems
like
a
pain.
C
What
do
people
think
of
having
like
a
open,
telemetry
comments,
package
or,
like
I
don't
know,
open,
telemetry,
instrumentations
commons
package,
or
something
like
that,
whatever
we
call
it
to
include
this
kind
of
stuff
and
the
instrumentations
could
depend
on
that
package
for
things
like
exclude
urls,
but
it
wouldn't
like
it,
wouldn't
be
necessary
for
the
sdk
or
the
api
or
whatever.
C
A
Yeah
we
discussed
it
because
instrumentations
aren't
really
ever
going
to
be
like
in
a
stable
state.
So
it's
fine
for
us
to
be
pretty
flexible
with,
like
the
implementation
details
like
like
convenience
methods
and,
like
you
know,
apis
that
aren't
stable
kind
of
thing.
A
Does
that
make
sense
to
everyone
any
questions
about
this,
so
we
are
still
going
to
be
removing
the
configuration
api
out
of
the
sdk
and
removing
all
traces
of
like
configuration,
dot
whatever
and
using
the
environment
variables
directly
for
those
those
are
okay
and
yeah
cool
sounds
good.
All
right.
C
To
the
to
this
pr,
then
about
the
so
would
would
you
expect
the
comments
package
to
come
out
of
the
contributor
then,
or
would
it
be
out
of
the
core?
Repo,
like
I
feel
like
contrib,
is
probably
the
right
place
for
it.
A
C
Thought
is
that
true:
do
we
not
have
any
instrumentation
like
does
the
open
tracer
should
not
rely
on
it?
Oh
I
guess
we
have
one
all
right.
I
guess
you
can.
I
I
don't
know
if
this
relies
on
the
instrument
or
interface
or
not,
but
maybe
you
can
check
on
the
setup
config.
A
I
think
we
discussed
this
because
it's
not
an
instrumentation
but.
A
A
Yeah
cool
cool,
so
yeah
anyways.
I
guess
what
my
previous
thing
makes
sense
then.
So
we'll
have
the
instrumentation
move
to
the
control,
repo
and
we'll
have
a
kind
of
commons
or
utils
or
whatever
package
as
well
that
actually
in
such
a
like,
like
we
can
actually
even
add
it
to
the
instrumentation
package.
Right
like
this,
just
be
like
the
common.
A
B
A
Yeah,
okay,
cool.
I
think
I
think
that's
what
we
will
do.
E
A
Cool
nice,
hey
alex,
do
you
think
you
can
create
an
issue
for
that?
So
we
don't
forget
and
also
maybe
link
the
the
open
tracing
gym.
One
two
to
that
issue.
A
A
Exactly
yeah
right,
I
added
this
here
I
think
strikant's
pr
has
been
up
for
a
while.
I
have
already
approved
this
looks
like
it
just
needs
one
more
pass-through
or
one
more
review,
and
this
is
one
of
the
rc1
pr's.
So
if
someone
can
take
a
look,
this
it'd
be
good.
If
I
can
assign
someone
like
right
now
can
can
someone
take
this
on
and
we
need
to
you're
going
to
sign
me.
Oh
thanks,
aaron.
A
Yeah,
so
these
are
just
like
few
of
the
rc1
stuff
that
we
still
got
to
finish,
and
I
think
it
also
has
a
contrib
repo
one.
All
that
I
approved
already
so:
okay,
never
mind
yeah.
This
is
good
I'll.
Take
a
look
at
that
after
nice,
all
right
looks
like
away
added
a
couple
more
stuff.
B
Yeah,
it
has
been
open
for
a
while,
so
this
initially
I
was
fixing
the
postgres
instrumentation,
which
had
a
serious
bug
where
some
advanced
use
cases
where
making
the
instrumentation
crash
actually
make
instrumentation
was
making
the
library
crash
so-
and
this
is
pretty
common,
especially
with
frameworks
like
django,
so
as
it
turns
out,
if
you
used
open,
telemetry
postgres
instrumentation
django
would
would
crash
on
startup.
B
So
this
this
fixed
the
issue
and
with
it
it
also
updates
updates
the
span
names.
So
earlier
we
were
using
the
entire
sql
queries
as
fan
names.
This
updates
it
to
confirm
the
spec,
so
two
solutions
in
this
pr:
it
somewhat
refactors
the
db
api
instrumentation
a
bit
to
accept
a
custom
class
that
implements
the
instrumentation
for
db
api.
B
A
Right,
oh,
wait:
you
did
the
name
change
for
sql,
alchemy
here
already
too
right.
Yes,.
B
Yeah
instrumentation
yeah!
That's
that
that's
the
other
pr
I
have.
I
have
linked
below
this,
so
sql
alchemy
doesn't
use
db
api.
That's
why
it
has
a
different
appear.
A
Yeah
cool
awesome,
yeah.
I
guess
we
just
need
eyes
on
this.
Oh
wait
again
like
we're
kind
of
focused
on
the
release,
so
we'll
try
to
get
to
this
when
we
have
time
so.
B
Yeah,
I
think
that's
okay,
the
sql
alchemy
one
is
much
simpler
to
review,
would
appreciate
if
you
could
get
that
in
for
the
next
release.
A
B
Yeah,
it's
not
it's
not
updated
here,
but
I
think
we
settled
it
in
the
in
the
last
sig
meeting.
Okay,
cool.
E
A
Yeah,
okay,
can
I
assign
you
to
this.
A
All
right
yeah,
so
if
you
could
just
comment
on
like
the
result
of
this
and
also
a
way,
if
you
can
like
solve
this
complex
too
that'd
be
great,
then
I
could
just
merge
this
in
yeah
all
right,
yeah.
A
Along
oh
yeah,
that's
that
one
yeah!
Okay,
all
right!
Anybody
else
have
any
other
pr's,
not
we're
gonna
go
to
issues
yo
alex.
Do
you
like.
C
C
Nope
nope,
please
change
it.
I
do
have
a
quick
pr
and
I
guess
trikond
also
put
a
pr
in
there.
D
A
Oh
right,
yeah,
sorry,
you
had
to
deal
with
this.
It
doesn't
really
have
anything
to
do
with
this,
but
I
didn't,
I
think
I
think,
according
to
this
discussion
like
it,
was
put
in
for
a
reason
right.
A
According
to
yusuke,
there
are
some
use
case.
Use
cases
when,
like
the
default
span
is
being
used,
but
I
don't
know
if
that's
the
case
for
like
an
exporter
right
like
the
exporter,
relies
on
the
sdk.
D
Yeah,
like
you
like
it's,
it's
not
just
for
attributes
like
it's
for
everything,
yeah.
D
Yeah
so
like
among
all
exporters,
so
I
don't
think
it's
still
the
case.
D
But
just
like
just
a
question
like
we
can
leave
it
as
it
but
like
there
are
events
that
are
directly
accessed.
A
Yeah,
I
I
agree,
and
I
don't
think
that
I
can't
think
of
this
actually
being
like
a
problem.
You
know.
C
A
Yeah
so
sir,
I
think
it's,
I
think
it's
fine.
I
think
you
can.
C
A
All
right,
nice
cool
all
right,
so
any
other
prs
I
need
to
be
talked
about
before
we
move
on
to
issues.
A
Oh
right,
this
docs
thing
alex:
do
you
think
we
should
talk
about
this
first
or
the
span
thing?
The
readable
spam
thing.
C
I
mean,
I
think
we
just
need
to
fix
this.
I
don't
know
that
there's
a
discussion
that
needs
to
happen.
A
A
Oh
man,
I
didn't
do
anything
for
this.
I
probably
should,
but.
E
Did
you
just
click
that
link
right
there?
Here's
listed
no,
no
below
that
that
one
yeah
and
then
sorry
go
to
the
but
you're,
not
logged
in.
Do
you
even
have
access
to
in
to
do
builds,
or
is
it
just
alex.
A
A
Okay,
cool
yeah,
so
we'll
just
we'll
just
try
to
kick
off
the
build
once
alex
and
I
have
access
so
right.
Okay,
so
I
think
there's
a
one
more
issue
that
we
need
to
talk
about.
That
pertains
to
this
last
outstanding
issue
for
the
rc1,
which
has
been
out
for
a
while
sdk
should
not
provide
access
to
spam
attributes
besides
spam
context.
A
So
there's
like
a
lot
of
discussion
that
happened
and
basically
like
it,
boiled
down
to
the
fact
that
our
apis
are
okay,
but
it's
like
too
easy
for
the
user
to,
like
you
know,
do
like
span.events
or
something
like
that
and
have
them
not
be
using
our
sdk,
which
would
in
in
theory,
would
crash
their
application
and
also
like
there's
no
attributes
in
the
apis.
A
So
if
this
wouldn't
work,
the
the
solutions
that
were
discussed
were,
I
think,
usq
outlined
that
like
we
could
just
make
it
difficult
or
like
difficult
for
users
to
not
do
that.
So
it's
like
introduce
some
getter
methods
for
the
span
and
also
move
attributes
to
protected.
This
is
very
like
pythonic,
python
kind
of
problem
and
then
christian.
He
proposed
the
like
the
whole
readable,
read,
write,
span,
concept
in
which
we
have
interfaces
that
specifically
like
readable
spans
that
only
are
read
only
and
like
users
cannot
modify
them.
A
A
I
think
other
languages
are
kind
of
doing
this
as
well,
so
I
think
we
might
actually
go
with
that
approach
unless,
if
someone
else
has
like
a
kind
of
compelling
reason
for
us
not
to
implement
this,
I
think
there
was
a
link.
Oh
I
just
closed.
It
there's
a
link
in
the
spec
where
it
actually
outlines
some
of
these.
A
Although
briefly,
some
of
the
implementation
details
behind
how
we
should
handle
this
kind
of
use
case-
and
this
was
actually
kind
of
new
to
me-
I
didn't
actually
even
see
this
until
recently,
but
yeah
this
whole
readable
span
and
read,
write
spam
thing,
so
we
might
actually
want
to
do
this
before
release.
So
let
me
know
what
you
guys
think
like
read
over
this.
A
You
know
read
over
this:
what
the
hell,
why
isn't
it
not
yeah
read
over
the
issue
and
you
know,
look
at
this
link
and
let
me
know
what
you
guys
think.
A
Yeah,
just
that
it's
like,
I
think,
more
work
yeah,
instead
of
just
like
simply
doing
the
getters
thing.
A
A
Does
that
make
sense
to
everyone
any
even.
E
A
Yeah,
so
I
think
the
readable
span.
So
if
you
take
a
look
at
this,
it's
like
the
api
level
definition.
It
only
defines
write
only
access
to
the
span
so
like
when
we
do
like
tracer.startspan
or
something
that
should
be
like
this
read
write
span
thing.
A
This
is
good
because
instrumentation
applications
are
not
meant
to
use
the
data.
However,
the
sdk
needs
to
eventually
read
back
the
data
in
the
location,
so
this
is
like,
like
you
know,
upon
export
or
like
instrumentations,
might
need
to
access
this.
E
A
Yeah,
I
think
I
think
these
are
just
suggestions
right.
It
really
depends
on
what
we
want
to
implement.
As
far
as
I
know
like
for
javascript,
they
have
a
specific
readable
span
and
then
the
regular
like
just
normal
span
is
just
the
just.
The
read
write
span
so
really
depends
on
how
we
want
to
do
this
so
like
you're
right
like
if,
what's
it
called
like,
if
we'd
only
if
we
want
everything
to
be
like
not
modifiable,
you
know
or
not
accessible.
E
A
Right
right-
and
I
also
want
to
point
out
that
like
so
that
that
issue
that
we,
this
issue
sdk,
should
not
provide
access
to
spanish
abuse
but
outside
of
spam
context.
It's
it's
not
like
this.
That's
related
to
this,
like
this
won't
solve
that
what
will
solve
it
is
like
what
christian
is
outlining.
It's
like
having
a
span
class
and
having
like
a
like
a
data
field,
or
something
like
that.
A
So
so
that's
these
two
are
kind
of
separate,
but
I
think
we
we
would
want
to
have
this
interface
first
and
then
maybe
address
this
see
if
it
addresses
this.
A
A
All
right
cool!
Well,
if
there's
no
other
topics,
I
think
that's
pretty
much
it
for
this
week,
cool
cool
all
right,
so
I
guess
we'll
end
12
minutes
early
I'll,
see
you
guys
next
week,
cool
thanks.