►
From YouTube: 2022-01-26 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
B
B
C
B
D
Yeah,
it
looks
like
the
attempt
itself
is
safely
to
to
merge
it.
We
still
have
some
work
on
this
another
pr
for
smiling
convention
specification
for,
tries
and
direction
for
their
structure,
and
that's
actually
the
topic
that
I
got
for
today's
meeting.
Okay,
we
do
have
a
couple
of
people
from
from
microsoft,
layton
and
nev.
D
Those
are
like
a
latin
nf
and
hector.
They
are
helping
me
with
verifying
the
possibility
or
feasibility
of
all
this
stuff
for
gs
and
node.js
and
for
python,
so
nice
so
yeah.
We
have
some
use
here,
but
I
will
let
you
guys
to
to
take
it
over.
C
Okay,
cool
yeah
yeah
thanks
dennis
I've
been
working
with
him
hector
and
nev,
trying
to
see
if
this
is
feasible,
at
least
for
for
the
python
side.
So
for
python,
it's
not
as
simple
as
automatically
being
able
to
allow
this.
C
As
for
net,
we
do
have
to
modify
each
instrumentation
http
instrumentation
library
manually,
there's
not
really
an
abstract
way
to
do
this,
but
I
did
I
did
prototype
one
for
url
lib,
so
it
is
possible
to
do
this
for
python
so
once
if,
if
the
change
goes
into
the
semantic
conventions
as
as
addressed
as
should,
then
I
believe
that
it's
just
an
onus
on
whatever
instrumentation
library
implementer
to
also
implement
this
feature
like
retry,
redirect
feature.
C
C
It
won't
be
automatically
possible
to
generate
these
kind
of
spans
automatically.
So
I
think
our
guidance
for
that
would
be
to
you
know,
provide
some
good
documentation
and
examples,
maybe
perhaps
have
like
a
helper
library,
slash
extension
for
them
to
be.
C
Do
this,
whatever
way
it
is
if
they
want
this,
this
extra
thing
will
market
it
as
a
extra
feature,
but
it's
not
inherently
automatically
supported
by
open
telemetry.
So
yeah,
that's
the
kind
of
stance
we're
taking.
B
Yeah,
that's
awesome,
that's
it
probably
as
part
of
like
expanding
out
the
material
in
these
semantic
conventions,
because,
like
in
general,
I
think
this
represents
like
an
expansion
to
to
what
we
put
in
there
right
in
the
past.
It's
mostly
just
been
like
these
attributes
mean
this
operation
represents
a
thing
and
now
we're
getting
into
more
detail
and
maybe
listing
there.
Some
of
the
exceptional
cases
might
might
be
helpful
like,
like
you
were
just
saying
it.
Might.
B
It
might
be
worthwhile
in
the
spec
to
mention
that
in
the
case
where
users
are
manually
doing
retries
and
redirects
rather
than
having
it
occur,
as
internal
behavior
within
a
library,
then,
like
the
user
needs
to
do
this,
I
think
the
other
situation
we
discovered
the
one
that
specifically
switched
the
wording
from
us
to
to
may
was.
B
Situations
where
the
the
headers
are
being
hashed
as
part
of
like
a
security
check,
so
oauth
comes
to
mind.
I
think
the
aws
clients
do
some
kind
of
header
hashing,
which
means
you
can't
actually
change
the
span
id
and
the
header
on
each
retry.
B
So
it
would
probably
be
good
to
to
list
those
and
right
make
it
clear
that
that
I
don't
quite
know
how
to
use.
I
want
to
say:
must
I'm
not
sure
it's
kind
of
weird
to
be
like
you
must
implement
this
unless
you
can't,
but
so
it
should
yeah.
B
It
should
you
should
do
this,
but
maybe
in
the
wording
we
could,
after
this
should
using
less
official
language
kind
of.
B
C
I
think
that's
a
great
idea
like
adding
that
documentation
that
excerpt
I
was
gonna
ask
about
that.
I
I
didn't
know
if
that
fit
under
semantic
conventions,
that's
more
like,
oh,
like
if
you
run
into
implementation,
details,
implementation,
problem,
kind
of
information,
but
I'm
I'm.
I
would
be
very
happy
if
it
existed
somewhere
right.
B
For
the
spec
to
to
do
that,
I
mean
the
other
option.
You
know
the
way
you
see
it
done
is
you
have
the
spec,
which
is
very
very
terse,
and
then
you
have
some
addendum
document
that,
like
explains
what
the
spec
means
and
like
I
I
don't.
I
don't
think
we
need
to
do
that.
D
B
Exactly-
and
this
will
also
maybe
combat
like
a
thing
we
have
seen
where,
for
things
we
have
marked
optional
in
the
past,
like
these
are
required
attributes,
these
attributes
are
optional,
it
means
the
person
implementing
them.
Just
sometimes
just
like
doesn't
do.
B
D
Okay,
yeah
sounds
great
to
me,
so
I
will
add
this
like
additional
information.
D
Yeah
and
the
main
question
that
I
probably
have
is
like
which
wording
we
should
use
so
must
will
not
work
just
because
we
do
have
some
kind
of
you
know,
limitations,
let's
say
in
javascript
language,
for
example,
yeah
and
but
yeah.
Currently
we
can
post
it
as
should
or
may
and
I'm
not
really
sure
which
exactly
which
exact
verb
we
should
use,
but
maybe
maybe
an
afghan
can
provide
us
some
more
details
about
javascript
before
we
start
this
conversation,
because
javascript
looks
like
it's
not
really
easy
at
all.
A
Yeah,
if
you
look
at
like
the
the
two
instrumentations,
mainly
because
I
mainly
look
at
the
web
stuff
is
you
know,
xhr
and
fetch.
Now
fetch
is
just
a
function
where
you
can
pass
in
the
url
and
headers.
There
is
no
context
object
to
play
with
xhr.
You
have
an
object,
so
in
theory
we
could
patch
the
the
open
and
the
creation
to
to
imply
a
context,
but
both
of
these
are
global
so
effectively.
The
instrumentations
would
have
to
provide
this
as
global
hooks.
A
So
you
then
get
a
global
callback
and
the
application
would
have
to
say:
oh
I'm
doing
a
redirect
and
they
would
have
to
remember
that
they're
doing
a
redirect
for
said
url
or
whatever,
and
if
you
put
it
in
the
headers,
you
know
in
in
the
browser
case,
you
don't
want
the
header
going
out
the
door,
because,
if
you're
going
cross
origin,
that's
going
to
cause
an
options,
call
which
just
slows
everything
down-
and
you
may
not
want
your
server
to
get
that
anyway.
A
In
the
case
of
the
aws
that
ted's
already
mentioned,
it's
yeah,
if
you,
if
you're
doing
a
retry,
you
can't
go
and
adjust
it
and
retries
are
all
manually
driven
by
the
application.
In
the
case
of
fetch
and
xhr
there
are,
there
are
fire
and
done
one
and
done
scenario.
You
want
to
do
a
a
retry.
A
The
application
has
to
handle
doing
the
retry.
You
want
to
do
redirects
with
xhr.
You
can't,
because
the
browser
just
automatically
follows
it
and
for
fetch
from
memory
there's
an
options
you
can
set
to
say:
don't
follow,
redirect,
which
means
you'll
get
the
status
code
of
the
300
or
whatever,
and
then
you,
then
you
can
turn
right
to
the
redirect
so
yeah,
at
least
for
those
who,
like
in
terms
of
other
instrumentations
for
higher
level.
A
Libraries,
like
you,
know,
jquery,
you
can
start
to
build
something
there,
but
right
now
for
the
web,
all
we've
got
is
xhr
and
fetch
hector's,
not
here,
but
it
would
have
been
for
for
node.
You've
got
like
the
http
one,
you
it's
a
very
similar
sort
of
situation,
but
you
have
more
of
an
object.
So
you
have
more
more
options
to
play
with,
but
not
everyone's
going
to
use
the
http
by
default.
A
B
Cool,
so
so,
just
just
for
for
clarity,
it
sounds
like
there's
a
like
a
couple
separate
issues.
One
is
just
like.
B
We
have
to
write
more
instrumentation
right
for
any
case
where
people
are
using
some
kind
of
non-non-standard.
B
B
If
I
recall
correctly,
and
then
on
the
browser
side,
you've
got
higher
level
things
and
again
you
would
need
to
supply
instrumentation
specific
for
those
things.
So
it's
just
a
matter
of
writing.
Instrumentation,
that's
kind
of
the
same
situation
in
like
all
the
other
programming
languages.
So
it
doesn't.
That
part
doesn't
sound
special,
but
it
does
sound
like
what's
what's.
Special
here
is,
maybe,
if
I
understand
correctly
for
the
browser
things
like
you
know,
xhr
and,
like
other
forms
of
doing
http
requests.
A
B
Right
so
so
that's
the
situation
where
either
people
are
using
some
higher
level
thing
to
handle
retries,
in
which
case
we
have
to
instrument
all
those
things
or
they're
doing
it
by
hand,
in
which
case
you
know
we
could
give
them
essentially
a
helper
of
some
kind,
but
it's
yeah.
I
mean
it's
almost
like
at
that
point.
They
need
to
just
go
use
some
kind
of
framework,
because
they're
gonna
do
that.
A
Yeah,
and,
and
and
in
the
case
of
the
helper
like
today,
the
instrumentations
for
fetching
xhr
are
monkey
patch,
the
the
functions
and
internally
create
spans.
So
that
would
not
be
possible
with
the
helpers.
You'd
have
to
say:
well,
don't
you're
not
going
to
use
those
instrumentations
at
all,
I'm
just
going
to
use
these.
B
B
I
see
I
see
okay,
I
get
it
because
we're
monkey
patching
in
here
and
the
monkey
patching
has
no
idea
that
this
thing
is
supposed
to
be
a
retry
and
it's
because
it's
a
lower
level
monkey
patch
there's
also
maybe
no
way
for
the
user
to
to
decorate
that
span
with
additional
information
is
that
is
that
true.
A
A
A
Quite
sure,
especially
when
it
comes
to
xhr,
because
I
think
you
open
it,
we
monkey
patch
open
and
at
some
later
point
you
call
send
now
if
they
go
and
do
a
promise
or
something
in
the
middle
there,
it's
going
to
screw
everything
up.
B
Oh,
oh
boy,
yeah,
and
that
sounds
honestly
even
in
the
situation
where
you
do
have
a
higher
level
thing
like
jquery,
I
guess
I
don't
know
it.
Is
it
like
easy
to
tart
do
targeted
to
turn
the
monkey
patching
off
in
a
very
targeted
way?
I
kind
of.
B
Yeah
right
and
that's
extremely
helpful,
obviously
to
to
have
that
and
if
the
only
choice
is
to
like
turn,
that
off
completely
that
that
sounds
rough.
You
know,
I'm
sure
there
are
some
people
where
it's
like
literally
everything
is
wrapped
up
in
jquery.
Like
you
know,
that's
pretty
common,
but
that
just
sounds
rough.
So.
A
B
B
It's
not
it's
not
the
end
of
the
world
in
the
sense
that
this
means
you're
still
doing
the
right
thing
of
like
generating
a
new
span
id
every
time.
It
just
means
we
wouldn't
be
able
to
add
the
links,
essentially
in
the
with
the
re
and
the
retry
account.
Those
would
be
the
the
two
things
you
couldn't
add
and
I
don't
know
personally
I
the
way
these
ietf
words
should
means.
B
B
D
Yeah
that
actually
sounds
good
to
me
from
from
the
same
perspective,
so
we
just
might
want
to
you
know,
say
there
that
do
whatever,
wherever
you
can
do
your
best
efforts,
and
if
it's
like
a
cannot
be
done
for
some
for
some
for
some
platform,
then
we
can
also
also
like
a
work
here
or
improve
the
overall
experience
by
providing
some
helper
methods
to
you
know
just
help.
People
to
you
know
do
this
instrumentation
yeah
kind
of
manually.
B
Right
but,
but
it
actually
sounds
like
in
this
case,
helpers,
don't
even
help
in
the
sense
that,
if
I
understand
correctly,
there's
no
way
to
actually
if
there
was
a
way,
a
reasonable
way
to
be
able
to
grab
that
context
and
decorate
these
spans
further.
It
would
work,
but
it
actually
seems
like
that's,
not
reasonable,
which
is.
B
Yeah
but
which
means
you'd
have
to
go
in
and
actually
disable
automatic,
instrumentation
yeah
or
or
this
is
maybe
where
the
the
fancy
span
collapsing
stuff
that
ludmilla
was
interested
in
might
actually
help
potentially
well.
B
As
you
know,
for
things
that
are
automatically
doing
retries
like
and
back
off,
like
jquery,
you
could
plug
it
in
there,
but
you
would
need
something
like
what
lumila
was
proposing,
which
is
the
the
monkey
patch
instrumentation
would
first
crack
open
the
context
and
check
whether
the
currently
active
span
is
in
fact
already
an
http
span,
and
if
it
is,
then
it
just
wouldn't
do
anything,
because
it's
like
oh
okay,
somebody
outside
of
me
has
got
this,
and
so,
if
a
mechanism
like
that
were
added,
then
then
you'd
be
able
to
to
have
it
be
like
automatic
by
default.
B
But
if
the
automatic
instrumentation
detects
that
some
higher
level
instrumentation,
that
knows
how
to
do,
handle
the
retry
stuff
and
whatever
is
doing
it
and
fine.
But
I
don't
know
how
feasible
any
of
that
stuff
is.
So
you
know
that
would
be
like
its
own
investigation
and
you
know
for
the
time
being.
B
D
B
Great-
and
you
already
have
enough
approvals
to
to
merge
it,
I
believe
once
you've
got
right
right
in
some
cases
I
would
say:
you'd
need
to
go
back
and
get
it
reapproved
if
you
like,
made
like
material
changes
to
the
the
spec,
but
I
would
say
in
this
case
we're
not
really
doing
that
we're
just
adding
we're
just
adding
additional
nuance
to
what's.
What's
already
there
so
right.
B
Yeah
yeah,
I
guess
what
I'm
trying
to
say
is:
if
you
made
these
changes
and
then
merged
it,
it
wouldn't
count
as
like
pulling
a
fast
one
on
the
spec
committee
by
changing
it
after
you
got
got
the
approvals,
so
so
I
would
say:
go
for.
D
So
yeah,
I
will
probably
do
these
changes
by
next
meeting
and
then
we
can
have
another,
maybe
follow
up
and
after
the
second
I
can
just
go
ahead
and
merge
so
we'll
be
on
the
same
page,
great.
B
D
D
Yeah
one
more
thing
I
wanted
to
mention
is
that
we
have
for
for
this
hotep
that
we
want
to
merge.
We
have
several
items
that
they
are
still
open,
so
it
might
be
beneficial
to
get
some
help
from
from
community
to
work
on
these
items,
so
we
can
make
it
done
by
the.
B
B
Dennis
do
you
actually
have
a
list
of
what
so
we
in
that
otep,
we
spelled
out
what
right
what
we
intended
to
do
before
marking
these
things
stable.
Do
you
do
you
know
what's
still
outstanding
on
that
list?
Yes,
actually
I
can.
D
Copy
it
from
the
meeting
that
we
got
in
january
great,
so
I
will
be
just
pasting
it
here
so
done
so
we
have
three
three
items:
error
status
defaults,
we
need
to
you,
know,
clarify
all
this
stuff
from
the
clan
client
spend
perspective.
D
We
do
have
this
required
attribute
sets
we
discussed
several
times
and
another
one
is
context
propagation
and
it's
really
really
corresponding
to
what
we
just
discussed
like
how
how
to
actually
propagate
some
information.
If
you
have
or
for
different
platforms,
for
example
in.net.
We
can
have
this
ambient
context
thing,
so
you
can
easily
add
some
information
that
flows
within
the
request,
but,
for
example,
in
javascript
there
is
no
possibility
to
do
so.
You
can
only
use
some
kind
of
global
callbacks,
a
global
context,
which
is
not
really
a
great
idea.
D
B
For
for
the
error
defaults,
I
thought
that
it
had
already
gotten
changed
in
the
spec.
I
should
double
check
on
that.
B
I'm
having
trouble
looking
at
this
yeah,
oh
okay,
well
I'll,
have
a
look.
I
thought
we
had
already
changed
this,
but
I
believe
it
was.
It
was
to
not
make
400s
count
as
errors.
If
I
recall
that
was
like
the
change
we
wanted
to
make.
B
See
you
next
week
and
definitely
if
anything
comes
up
during
the
week
post
it
on
slack
sound
great.
Thank
you.