►
From YouTube: 2021-05-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
My
camera
is
breaking
slowly,
so
it
looks
pretty
cool,
see
this
right
now
yeah.
I
just
ordered
a
new
one,
but
it's
not
here
yet.
So
you
have
to
deal
with
this
sorry.
A
C
A
A
E
G
Yeah,
so
how
do
I
plan
to
run
it
or
like?
Do
you
want
me
to
share
the
screen
or
you
can
yeah.
G
G
H
H
E
A
C
I
think
it's
more
than
that,
though,
right.
It's
also
like
a
unified
way
right,
because,
as
tiger
pointed
out
on
the
issue,
we
only
do
it
one
way
currently
in
jager,
but
it's
also
just
like
how
do
we
also
do
this
like?
I
think
the
otp
should
also
have
something
like
this,
which
I
think
it
does,
but.
A
Well,
there's
almost
like
a
meta
convention
because
I
opened
a
bug
recently
about
dropped,
metric
points
and
how
we
have
no
way
of
reporting
that
whatsoever.
So
that's
why
I'm
like
kind
of
curious
what
the
scope
of
this
is
and
and
how
we
want
to
handle
it
so.
H
G
And
tigran
I
see
you're
assigned
this
to
yourself
to
so.
Do
you
plan
to
have
this
like
in
the
like
upcoming
milestone
or
yes,.
G
E
Yeah,
actually
on
that
riley,
I
was
actually
wondering
if
I
could
talk
to
you
for
planning
this,
because
I
think
that
we
have
a
set
of
items
that
we
we
really
would
like
to
really
have
for
the
next
tracing
milestone,
or
something
like
that.
So
we
can
probably
coordinate
after
the
call
but
yeah
this
one
is
important
enough
that
we
should
include
it.
E
I
Id
yeah
the
outdoor
specifically
refers
to
some
implementation
issues
with
using
mdc
and
filling
this
attribute,
but
but
I'm
not
sure,
what's
really
the
problem
here
and
honestly.
I
think
that
that
would
be
like
a
duplication
of
of
having
attributes
there.
Maybe
it
would
be
like
a
good
topic
to
cover
during
log
6,
since
it's
specifically
related
to
logs.
I
don't
understand
honestly
the
reason
for
adding
a
new
container,
though.
F
The
span
doesn't
have
a
record
for
context
either,
and
people
ask
for
us
to
put
those
extra
context
labels
into
the
span
as
well.
I
wonder
if
this
is
a
common
issue.
G
Yeah,
so
so
tigran
would
you
be
okay
to
take
it
and
follow
up
yeah.
H
H
G
Yeah,
and
and
this
is
I
stick
another
api,
I
believe.
G
So,
what's
the
urgency
of
this?
Do
we
want
to
assign
this
to
someone-
or
this
is
like
for
people
to
pick
up
if
they
have
energy.
D
D
I
think
it
could
be
used
in
a
solution
to
this
issue.
Maybe
but
1653
is
a
bit
got
a
bit
complicated,
so
I'm
not
sure.
H
K
Yeah,
I
am,
I
think
this
is
not
super
high
priority.
It's
just
that
this
actually
came
up
from
carlos
your
spec
review
of
js,
and
we
just
noticed
that
the
link,
the
very
you
know
the
specification
and
protos
they
just
don't
exactly
match,
and
it
would
be
easier
if
they
did
to
me.
It
seems
like
the
easiest
solution
would
be
to
extend
to
the
proto
to
include
the
whole
span
context
for
link,
but
I
don't
have
a
strong
opinion
either
way.
I
just
noticed
it
doesn't
match.
D
I
was
thinking.
Maybe
there
is
some
back-end
that
waits
for
the
uplink
expands
to
occur
and
if
it's
sampled
false,
then
it
pro
maybe
doesn't
have
to
wait
or
it
doesn't
have
to
wait
as
long
because
it's
less
likely
that
there
will
be
any
spends.
G
I
I
guess
it
might
be
a
hint
for
indexing
like
if
I
can
receive
that
it
knows
it
doesn't
have
to
wait
for
the
other
spence
to
come
on
this
particular
thing,
because
the
trace
flag
can
tell
all
like
the
upstream.
So
it's
decided
not
to
sample
that.
G
I
think
it
might
be
simpler
if
we
just
say
like
the
span.
Contacts
is
contained
in
the
link
instead
of
saying:
hey
like
there
are
three
fields
in
the
span
context,
but
this
particular
thing.
We
don't
think
it's
needed
because
it's
very
hard
to
justify
what
is
needed.
What
is
not
unless
you
have
a
broader
view
of
all
the
vendor
requirements.
E
E
A
I
just
want
to
say
so
I
think
the
if
I'm
looking
at
history
on
the
specs
I
was,
I
was
doing
some
spelunking,
I
think
span
context
was
chosen
to
be
easy
in
the
api
right
and
then
it's
it's
possible
that,
like
that,
makes
it
easy
to
use
from
an
api
standpoint
to
attach
a
span
context
to
a
link,
but
that
not
all
the
components
of
spam
context
are
needed
in
the
link
right
so
like
this
is
implying
that,
like
all
the
things
in
spam
context
should
go
into
the
link,
but
I
I
guess
my
question
is
if
this
was
done
just
for
convenience
and
I'm
looking
at
trying
to.
A
I
was
trying
to
read
through
the
the
comments
I
just
didn't
have
time.
Sorry,
but
but
I
just
want
to
throw
that
out
there
as
a
possibility
for
why
this
exists.
The
way
it
is,
and
so
it
might
be
totally
acceptable
not
to
include
all
that
information
from
spam
context.
Yeah,
nobody
might
want
it.
It
might
have
just
been
an
api
convenience
thing.
I
think
that
was
the
case.
G
I
think
spam
contacts
is
not
just
for
api,
it
is
capturing
all
the
information
that
is
supposed
to
flow
across
services,
of
course,
there's
baggage,
but
we're
talking
about
the
tracing
part
and
and
if
that
thing
flow
across
service
I
I
guess
there
might
be
some
vendor
who
can
depend
on
the
flag.
So
we
make
a
distinction
saying
only
these
fields
are
needed.
We
got
to
clarify
that
and
it's
hard
to
like
describe
the
situation,
and
given
that
flag
is
just
a
single
thing,
it's
not
a
lot.
A
G
E
E
Yourself,
no,
not
particularly
okay,
so
I
could
say
it's
not
high
priority,
but
the
sooner
we
can
get
an
idea
about
that.
The
better
okay,
okay!
I
will
be
coming
back
with
them
with
some
initial
digging
myself.
E
Yeah
perfect,
I
think
you're
done
with
the
charging.
So,
okay,
the
next
points.
First
one
is
mine.
We
have
a
pair
of
pr's
by
the
way
they
are
related
to
semantic
conventions.
E
The
first
one
is
for
json
rpc
and
all
the
second
one
is
for
mobile
os
and
version,
so
basically
they're
having
something
there,
but
and
we
they
have
some
initial
reviews
and
approvals,
but
we
haven't
merged
them
because
we
don't
have
somebody
who
is
an
expert
in
those
fields.
So
if
you
know
somebody
in
your
company
that
could
provide
feedback,
please
do
so.
Otherwise
we
will
probably
end
up
merging
them
soon,
because
there's
no
point
in
keeping
them
reviewed
and
approved
without
merging
them.
J
J
E
Yeah,
would
you
mind
linking
the
java
code
or
the
java
branch?
For
this
I
mean.
J
J
E
J
I
think
it
very
much
depends
upon
how
controversial
the
proposed
pull
request
will
become.
So
if,
if
my
proposed
pull
request
will
just
get
accepted,
then
that's
it.
If
there
will
be
a
lot
of
different
opinions
and
controversy,
then
maybe
we
need
another
beauty.
E
Opinion
yeah
yeah-
and
I
I
did
read
this
this
comment
that
you
put
there
my
impression
that
both
john
and
you
at
least
from
the
java
world,
would
be
fine
with
this
approach
right
because
you
mentioned
there
an
alternative
about
freezing
set
status,
but
I
think
you
you
guys
personally
are
fine
with
the
current
approach.
L
I
propose
to
nikita
the
the
idea
of
freezing
freezing
the
status
when
an
okay
is
called,
because
if
I
recall
what
okay
is
supposed
to
mean,
it
has
one
meaning.
It
means
that
the
user
is
overriding,
an
error,
and
it
means
that
it's
saying
that
I
don't
care
that
the
instrumentation
or
whatever
or
the
response
was
an
error
or
whatever
I
don't
care.
This
is
okay
and
back
ends
should
consider
it
as
a
non-error
span.
L
So,
given
that
kind
of
semantics
of
okay,
it
feels
like,
if
a
user
ever
sets
okay,
that
should
be
the
end
of
it
like
nothing
else,
can
change
the
status.
At
that
point,
the
user
has
said
that
I
don't
care.
If
there's
an
error,
this
one
is
okay,
and
so
I
think
that
we
can
implement
this
in
the
sdk
without
any
difficulty
at
all
and
for
the
hypothetical
magical
streaming
sdk
back
ends
can
just
treat
this
as
if
they
see
an
okay,
then
it's
okay
and
they
don't.
L
L
Yeah,
I'm
not
saying
we
shouldn't
update
the
description
of
what
that
means.
I'm
just
saying
I
don't
think
we
need
a
like
an
api,
a
change
to
the
api
surface,
yeah
we're
going
to
implement
this,
it's
more
behavioral,
behavioral
change
of
the
sdk
and
the
expectation,
but
not,
but
not
a
like
a
breaking
change
from
the
api
perspective.
J
E
L
J
E
C
I
I'm
just
so
I
understand
the
idea
here
is
that
if
you
have
like
really
complex
code,
which
I'll
be
perfectly
transparent
like
go,
doesn't
have
that
kind
of
complex
code,
but
the
auto
instrumentation
side
of
things.
Then
this
seems
to
make
a
lot
of
sense
but
like
in
simple
cases
like
it
could
also
be
very
disastrous.
C
If
say,
a
user
writes
some
sort
of
instrumentation
that
can
go
through
many
different
iterations
and
one
of
them
is
to
set
okay
and
then
maybe
it
wants
to
also
set
error
afterwards,
and
it
would
be
a
bug
at
that
point
because
it
wouldn't
be
setting
error
and
they
wouldn't
be
very
understanding
of
like
how
that's
actually
like
going
to
change
if
we
have
a
performance
or
a
behavior
change
in
the
implementation,
and
I
feel
like
this
is
going
to
be
shared
across
multiple
languages.
C
Not
particularly
just
go
but
like
it
seems
like
first
in
being,
the
only
winner
is
not
something
that
we've
like
built
into
the
user's
expectation.
At
this
point
I'm
like
I
don't
know,
if
that's
something
that
we
want
to
change
universally
well,
it's
not
first
in.
C
Yeah,
sorry,
I
guess
you're
right,
that's
not
correct,
so
yeah,
but
having
preferential
treatment
for
this
okay
status
like
it
seems
like.
If
the
user
then
wants
to
come
back
and
say
like
well,
it
was
okay,
but
now
I'm
later
down
into
like
the
execution
path
or
something
like
that,
and
it
is
actually
going
to
be
an
error
because
there's
another
thing
that
happened
during
this
processing.
They
can't
override
that
at
that
point.
C
Yeah,
I
don't
know
like
they,
they
have
a
recoverable
error
and
they
recovered
from
that
error,
and
they
said
no,
never
mind
that
that's
not
an
error,
that's
okay
and
then
they
go
and
they
try
to.
I
don't
know,
write
the
payload
to
some
sort
of
external
source
and
that
external
source
is
like.
No,
that's
that's
not
something
I
can
do
you
overload
my
buffer
or
something
like
that,
and
then
it
returns
an
error.
C
L
Well
that
we
I
mean
this
has
been
very,
very
specifically
called
out
that
if
you,
if
we
were
to
make
the
status
readable,
it
would
make
force
every
sdk
to
have
to
carry
state
about
the
span.
That's
more
than
just
its
identity,
and
this
this
hypothetical
magical,
streaming
sdk,
which
cannot
keep
any
state,
would
not
be
able
to
handle
that
it
would
introduce
a
force
of
state
into
the
into
the
sdk
back
end.
G
Yeah,
I
tend
to
agree
with
the
proposal
from
nikita
and
I
I
think,
the
okay
flag.
Even
if
you
look
at
the
current
spec,
it
is
saying
the
okay
is
only
set
by
the
application
owner.
So
that
means
we
have
determined
it's
okay
and
there's
no
way
for
them
to
regret
that
later.
If
you
will
regret
that,
don't
use
okay,
you
can
put
whatever
attributes
or
other
stuff
on
the
space,
but
once
you
said
okay,
that
means
you
confirmed.
G
L
E
Okay,
I
guess
that
yeah,
what
this
shows
is
that
we
need
a
prototype
in
another
language
as
well
just
to
validate
this
in
a
perfect
world.
I
don't
know
how
that
how
feasible
that
is
in
the
current
timeline,
probably
could
be
yes.
C
So
yeah,
if
that,
if
that's
the
absolute
prototype,
is
asking
then
like
that
doesn't
seem
impossible,
because
I
know
and
go
like
we
I'm
not
entirely
sure
what
the
track
and
state
issue
is
in
java
that
we're
talking
about.
But
I
do
know
that
and
go
like
a
spam
status
is
tracked
with
this
fan
value
itself
so
like.
If
the
span
value
is
okay,
we
could
just
you
know,
have
a
conditional
there
like
that's,
not
hard
to
implement.
L
The
the
issue
with
the
state
is
not
with
the
java
implementation
at
all.
It's
with
some
hypothetical
nobody
has
actually
written
purely
streaming
sdk
that
would
keep
no
state.
I
know
josh
mcdonald
has
been
a
big
proponent
of
this,
although
I
don't
know,
if
he's
written
one.
F
Well,
I
I
did
actually
write
one
and
I
think
I
said
the
last
time
I
mean
this
was
like
almost
two
years
ago
that
the
prototype
had
been
written,
and
I
think
I
said
at
the
last
time
this
was
discussed.
You
can
just
imagine
you're
going
to
log
the
event
that
you're
saying
I,
the
application
and
setting
the
status
and
the
consumer
will
see
those
records.
Presumably
they
can
order
them
and
then
once
you
have
order
on
those
records,
you
could
say
I
saw
one
already.
I'm
gonna
ignore
this,
so
I
don't
think
it
rule.
B
L
E
Okay,
I
could
suggest
we
don't
do
any
prototype
in
any
of
the
languages
that
hasn't
released
1.0
yet
because
we
would
be
just
distracting
them.
So
I
guess
that
python
is
probably
a
good,
a
good
candidate
for
this,
probably
similar
enough
to
java,
but
I
think
they
are
already
released
that
I'm
probably
could
find
myself
sometime
next
week
to
work
on
a
prototype
or
have
somebody
help
me
to
do
that.
So
that's
one
proposal
for
to
try
this
out
unless
anybody
else
wants
to
try
this
in
their
own
language.
E
It
yeah,
I
would
say
that
we
need
a
prototype
for
both,
but
the
one
that
you
did
for
java,
that's
the
one
that
would
require
more
work,
the
other
one
I
mean
yeah.
I
know
it
sounds
simple,
but
you
know
it's
like
when
we
wanted
to
let
known
values
go
through
a
tracer
and
it
turns
out
to
be
painful.
So
we
have
to
test
that
anyway,
but
anyway
in
case
in
case,
you
wanted
to
prototype
what
you
did
for
another
language
that
could
be
done
in
python.
Probably.
G
I
think
indonesia
is
like
asp.net
and
redis
and
like
database,
so
if
we
can
try
it
in
donate
and
all
the
existing
scenarios
should
work,
then
that
might
give
us
quite
a
nucleus.
Do
people
agree?
If
that's
the
case,
I
I
can
send
a
small
pr
and
download
just
try
to
touch
the
water.
Yes,
that
would
be.
G
E
G
J
E
Perfect
yeah
and,
as
I
mentioned
before,
if
if
there's
something
that
still
needs
to
be
prototyped,
I
can
do
that
next
week
in
python,
probably
okay
and
just
and
also
to
be
clear,
I
we
will
be
releasing
this
month's
specification
releasing
iteration
this
week
without
this
change,
of
course,
because
you
know
I
would
rather
spend
more
time,
you
know
make
sure
this
is
a
good
way
to
go
fantastic.
Thank
you
so
much
for
that
guys,
that's
all
in
our
agenda,
so
anybody
wants
to
mention
anything
else.
L
Want
to
talk
some
more
about
the
using
the
contact
special
concept,
ski
for
suppression
of
tracing.
K
Yeah
happy
too,
let
me
throw
it
on
the
agenda,
so
it
was
clear
we
talked
about
it.
I
was
going
to
bring
it
up,
but
then
I
saw
yuri's
not
on
the
call
and
since
he
was
the
most
vocal
detractor
I
didn't
know
how
productive
a
conversation
would
be.
K
I'm
sure
by
this
point,
most
people
on
the
call
here
are
familiar
with
this
issue,
though
there
are,
I
guess
three
problems
that
you
could
consider
to
be
solved
by
this.
The
exporter,
infinite
loop,
we've
talked
about,
obviously
could
be
solved
with
the
sdk.
Only
the
second
one
is
the
instrumentations
suppressing
lower
level
instrumentations.
K
K
The
the
pr
itself
has
been
a
little
bit
more
controversial
than
I
had
actually
expected
it
to
be,
but
I
do
think
it's
worth
mentioning
that
there
are,
to
my
knowledge
at
least
four
languages
that
have
already
implemented
mechanisms
like
this,
whether
in
the
api
or
the
sdk,
and
to
me
I
think
that
that
speaks
to
the
value
of
the
mechanism
itself,
at
least,
but
it
yeah.
As
far
as
I
know
it,
you
know
at
least
javascript,
obviously,
but
I
think
python,
ruby
and
dotnet
all
have
similar
mechanisms
for
this.
J
J
So
that
health
check
elimination,
that's
simpler
and
infinite
loop
during
the
export.
That's
again
sdk
change,
sdk
problem,
so
change,
sdk
problems,
their
api
is
fixed,
sdk
problem.
The
api
changed
seems
strange.
K
So
I'm
not
sure
that
I
agree
with
the
health
check
one
but,
like
I
said
earlier,
I'm
not
sure
I
believe
as
strongly
that
that
is,
you
know
a
use
case
for
this
particular
mechanism.
Anyways.
I
agree
the
exporter.
Infinitely
could
be
solved
in
the
sdk
only,
but
I
I
think,
there's
a
lot
of
value
in
instrumentations
being
able
to
suppress.
K
You
know
what
they
consider
to
be
implementation
details.
So
if
you
have
like
the
aws
sdk,
for
instance,
uses
http
under
the
hood,
but
http
standard
library
is
patched
so
that
it
creates
spans.
K
You
know
the
aws
developers,
don't
necessarily
want
the
http
span
to
be
you
know
shown
or
if
you
have
some
database
like
you
know,
mongodb
that
uses
http
under
the
hood
or
something
like
that.
Yeah
you
end
up
with
duplicated
spans
and
we
need
that's.
That's
the
real
value
of
having
it
in
the
api.
J
We
have
a
separate
issue
inspect
for
some
time
already
about
proper
modeling
of
such
situations,
because
you
can
totally
imagine
that
a
lot
of
users
do
want
to
know
about
http
expands
during
db
calls,
so
we
have
a
separate
issue
about
modeling
such
multi-layer
instrumentation,
and
I
don't
think
that
proposing
this
context.
Solution
for
that
problem
without
properly
discussing
that
separate
issue
about
modeling
is
a
good.
M
But
I
don't
think
we're
talking
about
forcing
this
oppression,
though
right
it
would
be
an
option
that
is
given
to
instrumentation
authors
and
those
instrumentation.
Authors
could
then
bubble
up
that
option
to
users
of
the
instrumentation
so
say
with
the
aws
sdk
they
could
expose
to
the
user.
Please
show
me
the
the
dynamodb
http
calls
under
under
the
hood.
Don't
suppress
those
I
think
here.
What
we're
doing
is
putting
into
the
api
a
means
of
communicating
to
the
sdk.
Please
don't
continue
to
trace,
which
seems
like
a
reasonable
thing
to
do.
A
Binary
like
one
of
the
things
I
want
to
call
out
this
is
this
is
a
binary
thing
right
like
what
would
be
cool
and
again
I
don't
want
perfect
to
be
the
enemy
of
good
here.
I
think
we
need
to
solve
the
issues
that
javascript
is
facing
right
now,
like
that's
that's
the
most
important
thing
is
instrumentation
is
broken
without
this
like
we
need
to
focus
on
that,
but
then
the
second
thing
is,
I
think,
a
binary
flip
of
on
or
off
is
just
not
going
to
be
enough
long
run.
A
For
example,
you
know
our
exporters
right.
We
actually
would
love
to
have
that
go
out
some
separate
channel
where
we
get
information
observability
into
our
exporters.
We
don't
just
want
to
suppress
them
like
we
want
to
know
the
stats
of
our
exporters
as
well
and
find
a
way
to
get
that
information
out
and
in
a
separate
channel,
and
I
think
that
deserves
some
longer
term
discussion.
A
F
You
agree
with
nikita
as
well.
I
just
wanted
to
say
that
I
I've
resisted
pointing
out
that
there's
been
a
proposal
or
two
over
time
in
open
telemetry,
that
you
could
put
the
current
tracer
or
the
current
meter
into
the
context
for
a
lot
of
reasons
that
people
have
thought
about,
making
it
easier
to
write
your
instrumentation.
F
J
E
Not
a
good
thing
yeah!
That's
that's
why
I
was
wondering
what
about-
and
we
mentioned
this
in
the
past,
but
what
about
moving
this
part
into
some
instrumentation
code
like
you
know
us,
so
so
it
doesn't
exist
in
the
api,
but
javascript
instrumentation
can
still
use
that
it
is
that
could
be
that
bad
daniel
for
javascript
or
do
you
think
it
could
be
too
much
work
or
it
could
be?
It
couldn't
work.
K
No,
I
I
don't
think
would
be
too
much
work
necessarily,
but
I
do
think
like
having
it
in
a
a
separate
package.
Is
still
it's
still
a
contract
between
you
know.
If
I,
if
I
call
this
method,
the
sdk
behavior
will
change,
it
doesn't
change
the
fact
that
it's
in
a
you
know
an
api
that
exists
somewhere
that
we
expect
instrumentations
to
call.
We
just
moved
it
out
of
the
package
that
we
call
api.
K
J
Again
again,
I,
when
I
don't
think
that
suppression
is
necessarily
the
the
solution
that
you
want
to
commit
to
right
now
for
multi-layered
instrumentation
and
and
sdk
infinite.
Loop
and
sdk
is
already
solved
in
all
language
in
hackish
way
in
internal
way
in
non-standard
way,
but
that
solves
problem.
It's
not
p0
issue
that
we
have
to
come
up
the
solution
for
so.
F
K
E
E
Yeah,
but
I
think
it's
it's
some
trade-off.
I
think
that's
my
feeling
because
then
you
of
course,
instrumentation
code
depends
on
that
module
or
package,
but
end
users.
Don't
have
to
depend
on
that
and
you
can
just
you
know,
change
it
without
breaking
the
main
api.
So
for
me
that
could
be
a
good
trade-off.
Yeah
go
ahead.
B
B
K
M
Part
of
our
versioning
strategy
is
to
ensure
that
developers
are
always
comfortable
updating
and
if
we've
got
code
that
may
you
know
it's
not
part
of
the
official
api.
But
it's
part
of
the
api
that
instrumentation
is
using
that
may
introduce
complications
to
upgrading,
because
you
know
a
version
of
the
the
instrumentation
uses
a
new
version
of
that
extra
api
package
that
the
user
isn't
ready
to
upgrade
to
that
can
present
problems
for
us.
So
I,
I
think,
just
saying
put
it
into
a
separate
package.
M
J
E
E
Instrumentation
has
a
very
specific
strategy
for
that,
so
I
think
we
have
seen
the
need
for
sure,
but
we
should
probably
still
work
on
a
unified
way
to
do
this,
even
even
if
java,
you
know
that
has
a
different
approach,
but
probably
the
rest
of
the
languages
can
subscribe
to
something
that
is
similar,
and
I
think
that
there
was
also
the
discussion
that
probably
we
will
be
needing
something
more
advanced,
not
only
like
binary,
you
know
so,
for
that
I
could.
I
would
propose
to
go
with
the
country
package
solution.
K
Yeah,
I
mean
either
way
for
js
we're
gonna
have
to
do
something
before
1.0
and
it
sounds
like
this
spec
issue,
even
if
it
does
end
up
being
accepted,
is
not
going
to
be
in
any
sort
of
timely
manner.
So
it
sounds
like
I
just
have
to
work
out
something
else.
I
guess.
E
K
F
K
Sorry
yeah,
I
mean
I
don't
think
difficulty
of
maintenance
is
the
problem,
because
that
the
mechanism
itself
is
so
simple
that
it
seems
extremely
unlikely
that
it
will
be
any
sort
of
maintenance
burden
in
the
future.
I
think
the
issue
is
if
the
specification
adds
something
that's
just
not
compatible
with
it
in
the
future,
then
we
then
we're
in
a
bind.
F
Okay,
then,
on
the
spec
side,
I
think
we
should
imagine
scenarios
where
this
power
wouldn't
be
appropriate,
but
I
I
feel
like
it's
an
appropriate
outcome.
It's
just
that
we
don't
want
to
fix
the
api
right
now.