►
From YouTube: 2022-02-23 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
C
C
A
D
A
A
Okay,
so
I
think
we
can
try
to
get
started.
I
don't.
I
only
have
two
things
that
I
want
to
talk
about
myself.
If
you
have
anything
else,
please
add
it
to
the
list
just
want
to
give
everyone
a
quick
update
that
what
we're
currently
doing
is
working
on
a
prototype
prototype.
That's
going
to
be
going
to
go
along
with
the
otep
for
client-side
data
model
proposal,
we're
working
on
browser
with
martin
and
t2
t2.
A
Even
if
anyone
else
wants
to
participate,
please
let
me
know
I'll
include
you
in
any
other
meetings
or
you
can
follow
progress
in
that
doc
that
I
linked
we're
also
still
looking
for
volunteers
to
work
on
mobile.
A
So
if
you,
if
you're
interested
or
if
you
know
of
anyone
that
would
be
awesome,
otherwise
I
would
I
might
go
to
the
other
to
the
swift
say
and
ask
as
there-
and
I
also
I
also
linked
at
the
top
of
this
document.
I
liked
linked
a
few
other
documents
that
we
have
been
working
on,
so
just
so
that
they're
easy
to
find
right
here.
A
So
so
far
we're
working
on
the
browser,
which
is
obviously
javascript,
there's
no,
since
this
is
gonna,
so
we
have,
we
have
repo
and
javascript
doesn't
have
any
logging
implementation.
Yet
so
at
this
point
we
just
or
I
worked
on
setting
up
some
some
basic
implementation
of
logging,
so
we're-
and
I
think
the
next
steps
would
be
to
to
use
that
in
the
instrumentations
to
update
the
individual
instrumentations
to
use
the
login.
C
A
B
C
Well,
I
mean
in
java
there's
you
know
log
for
j,
which
is
maybe
a
safe
choice,
but
yeah
there
are
safer.
B
C
C
I
mean
general
instrumentation,
but
you
know:
javascript
in
the
browser
is
an
example
right
I
mean.
B
So
I'm
not
I'm
I'm
trying
to
speak
for
the
log
sake
here,
but
yeah
I,
which
I
should
not
do,
because
I'm
not
even
involved,
but
I've
talked
a
lot
with
tigran
about
it.
You.
B
B
And
I
don't
think
we
have
any
semantic
inventions
that
involve
generating
any
sort
of
logs
at
this
point,
and
I
think
that's
probably
a
little
bit
illustrative
of
why
we
don't
have
or
have
any
plans
for
logging
api
like
if
you're
doing
java
instrumentation
the
java
agent,
which
is
where
all
the
instrumentation
live
uses
slf4j
and
that
is
kind
of
the
most
common
most
general
purpose
logging
api
for
java-
and
I
think
the
goal
is
unless
you're
there's
a
language
where
there
isn't
a
de
facto
logging
standard
or
like
java
4.
B
Then
we
then
the
language
shouldn't
define
an
api.
Now
I
do
think
I
do
strongly
feel
that
we
need
an
api
that
generates
logs
for
client
instrumentation
and
we
almost
certainly
as
a
community
bigger
community,
need
to
define
an
event
api
that
will
generate
things
in
the
logging
data
model,
but
I
think
that's
actually
distinct
from
a
logging
api.
C
Yeah,
well,
I
I
don't
know
if
it
feels
like
at
minimum.
We
at
least
need
to
pick.
I
guess
right,
like
for
every
language.
C
This
is
the
logging
api
open
telemetry
if
you're
writing
open
telemetry
instrumentation
to
be
distributed
to
the
masses
like
we
recommend
this
one,
and
this
is
the
one
we
use
for
the
stuff
that
that
we
maintain.
B
So
for
java,
for
java
at
least
there's
instrumentation
for
all
of
the
major
logging
frameworks,
so
they're
basically
like
if
you're
writing,
instrumentation
write
logs
whatever
you
would
normally
use.
Logging
in
your
in
your
libraries
and
it'll
get
picked
up
or
there's
plugins.
That
will
allow
you
to
map
it
into
open
source,
yeah.
E
Actually
ted,
it
has
to
be
only
a
new
events-
api
and
not
a
logging
api,
because
the
the
current
logging
api
doesn't
address
our
requirements
for
for
for
representation.
C
That's
that's
cool
anyways,
something
I
should
bring
up
in
the
the
logging
sig,
which
unfortunately
tends
to
meet
at
a
time
that
I
can't
go,
but
I
will
I'll
try
to
interface
with
them
about
this.
No.
E
I
think
I
think
they
might
be
okay
if
we
we
just
propose
something,
because
I
I
haven't
seen
any
maybe
you
know
I
haven't
attended
many
meetings,
but
a
few
meetings
I
attended.
I
don't
think
there
is
any
activity
around
events
in
that
scene.
C
Yeah,
I
think
I
think
they
would
they
would
welcome
proposals
and
it
might
make
it
go
down
easier
to
call
it
an
events
api
instead
of
a
logging
api,
I'm
probably
like
the
wrong
person
for
that,
because
I'm
like
the
cantankerous
person
who's
like
there's,
no
difference
it's
just
it's
all
events
and
that's
like
you
know,
not
there's
a
distinction.
C
Other
people
want
to
make
there,
but
at
any
rate,
we
keep
running
into
this
issue,
which
is
like
we
want
a
something
something
log
event
and
like
we
like,
I'm
just
watching
people
like
martin,
just
kind
of
shoestring
it
together
right
now
and
yeah
like
we
should
but
yeah.
C
If
this,
if
we
want
to
like
get
involved
with
the
logging
group
and
like
propose
an
events,
api
and
drive
it
like,
since
this
is
like
clearly
the
group
of
people
that
like
needs
it
the
most
at
the
moment,
it
probably
has
the
most
opinions
about
you
know
what
would
have
should
take
that
work
on
I'm
sure
they
would.
They
would
be
appreciative.
E
Yeah
and
in
fact
we
did
talk
about
a
basic,
very
basic,
rudimentary
api
for
events,
which
I
think
john
suggested.
I
think
it
came
from
what
they
were
already
using.
It
should
be
in
one
of
our
planned
docs
martin.
Let
me
bring
it
up,
we
could
quickly
go
over
it.
A
I
just
have
a
quick
question
also
on
that,
so
the
the
specification
for
logs
currently
defines
components
for
like
the
the
logging
library
sdk.
C
You
wouldn't
want
to
directly
reference
an
sdk
package
in
instrumentation,
because
the
sdk
is
an
implementation
and
the
basic
arc.
I
assume
this
is
what
you're
talking
about
you're
talking
about
something
that
lives
lives.
E
C
In
an
sdk
package
right
yeah,
we
just
open
telemetry,
takes
like
a
loosely
coupled
interface
model.
The
reason
for
that
is
twofold
one
when
you
haul
the
api
package
in
that's
the
cross-cutting
concern
that
gets
hauled
in
everywhere,
and
we
want
that
package.
Those
packages
to
have
minimal,
ideally
no
dependencies
because
they're
going
to
live
everywhere,
and
that
is
the
part
that
is
very,
very
difficult
to
remove
from
an
application.
C
It's
also
the
part
where
we
have
to
really
really
really
care
about
api
surface
area
and
never
ever
making
a
breaking
change.
So
it's
just
helpful
to
have
that
completely
it
off
from
the
implementation.
C
The
the
other
reason
is
to
allow
multiple
implementations
to
be
plugged
in
without
doing
something
hacky
like
forking,
open,
telemetry.
C
So
if
you
have
open
telemetry
instrumentation
installed
we're
specifically
thinking
about
open
source
libraries
like
shared
libraries
being
able
to
natively
instrument
themselves
rather
than
rely
on
like
us
or
somebody
else,
providing
an
instrumentation
plug-in
the
application.
That's
running
them
may
not
have
be
using
open,
telemetry
right,
it's
just
a
it's
just
a
dependency,
that's
that's
being
brought
in,
and
so
we
want
it
to
be
a
no
op
by
default.
So
it's
cheap.
C
And
then,
if
someone
does
install
an
implementation
that
that
end
user
who's,
the
application
owner
can
then
sort
out
any
dependency
stuff
that
that
has
to
show
up
and
be
dealt
with.
So
that's
why
yeah?
We
also
have
like
a
test.
Implementation,
like
alternative
implementations,
exist
for
reasons
other
than
like.
I
just
wrote
my
own
clone
of
the
sdk,
a
test
test,
test
implementation
or
mock
implementations,
one
example
in
the
future.
C
In
theory,
you
know
you
could
see
an
implementation
that
bound
to
like
c,
plus,
plus
or
rust,
or
something
like
that
and
was
more
like
more
high
efficiency
implementation.
So
so
those
are
the
reasons.
A
Okay
yeah,
I
suppose
I
just
got
a
little
bit
quite
confused
because,
because,
like
the
the
components
in
that
are
specified
right
now
in
the
logging
sdk
they're
they're,
like
very
similar,
like
the
like
tracing
api
concepts,
right
yeah,
like
there's
a
provider,
there's
a
you
know,
there's
a
processor
there's
an
emitter.
C
Yeah
yeah,
I'm
that's!
Why
I'm
a
little
surprised
I
mean
it's,
not
the
the
logging
group
has
has
done
everything
sort
of
backwards
from
all
the
other
work
we've
done,
which
is
we
tend
to
define
the
api
first
and
then
define
an
implementation,
because
the
you
know
desire
to
not
want
to
create
a
new
logging
api
and
just
create
something
that
can
bind
to
existing
logging
apis.
C
C
Okay,
so
that's
that's
why?
But
I
do
think
we
need
to
take
the
extra
step
and
define
define
you
know
like
if
we're
going
to
use
something
in
instrumentation
like
the
stuff
you're
writing
right
now,
for
example,
that
should
be
decoupled
and
live
as
an
api
package,
and
but
I
think,
maybe
that
but
you're
right
like
calling
it
an
events.
Api,
I
think,
is
probably
much
better
and
say
like
and
just
just
go
for
the
idea
that
that
these
are
for
events
and
maybe
for
languages
that
aren't
java
at
least
some
languages.
C
I
think
will
want
to
write
our
instrumentation
logs
in
this
in
this
thing,
and
I
could
maybe
even
see
end
users
choosing
it
long
term
as
like
their
logging
api
in
their
application,
just
in
the
sense
that
it's
like
low
dependency,
the
the
low
dependency
neutral
decoupled
aspect
of
it
might
be
very
attractive
to
people,
because
we
don't
have
a
version
of
that
in
some.
Some
languages
like
go,
for
example,.
A
E
So
we
could
go
over
this.
I
I
have
a
few
questions
as
well
on
this,
so
this
is
what
we
identified
last
time
a
couple
months
ago,.
C
E
It's
at
the
very
basic
it's
every
event
is
is
a
named
event,
yeah
and,
and
then
it's
just
a
bunch
of
attributes
and
the
name
was
removed
from
being
a
top
level
field
in
the
in
the
log
data
model.
So
it
will
be
yet
another
attribute
through
a
semantic
convention
when
represented
in
the
data
model.
Yeah.
C
E
So,
martin,
I
guess
you
could
build
something
like
this
in
your
poc
one
question
I
mean
I'm
not
so
much
into
the
implementation,
so
you
know
I'll,
ask
you
folks,
so
do
we
need
to
add
in
into
this
anything
related
to,
let's
say
a
trace
or
like?
How
do
we
specify
the
trace
id,
and
this
pan
area
is?
Is
that
implicit
taken
from
the
context
or
that
does
that
need
to
be
mentioned
in
the
api.
C
Implicit
for
languages
that
have
don't
have
an
implicit
context,
so
I
think
go
is
the
only
one
I
really
know
of
these
days.
Then
you
include
context
as
a
parameter
for
everything
else.
It
should
be
considered
a
hidden
parameter
and
that
allows
us
extensibility
right
in
the
future.
We
might
not
just
be
grabbing,
you
know,
span
id
or
something
there
might
be
other
things
in
the
context.
We
want
to
grab
metrics
or
something
like
that.
I
don't
know,
but
by
as
ensuring
that
every
every
api
method
has
access
to.
E
So
does
the
api
spec
talk
about
what
happens
behind
the
scenes
like
what
parameters
from
the
context?
Do
you
capture
the
maybe
the
sdk
documentation.
C
Yeah,
I
would
have
to
look
in
the
spec,
but
it
depends
on
what
is
installed
right.
If
you
haven't
set
up
tracing
or
you're
not
using
it,
you
know,
then,
then
nothing
would
happen
in
this
case,
but
but
that's
an
area
that
it
tends
to
be
written
down
in
terms
of
features
so
trace.
Exemplars
are
an
example.
D
A
C
By
the
way,
if
it's,
if
some
of
this
background
information
is,
is
helpful,
I
wrote
an
o'reilly
report.
I
don't
know
if
I've
provided
the
link
to
that
in
the
past,
but
I
can
provide
a
link
to
that.
If
people
are,
I
it's
the
place
where
I've
written
down
as
comprehensively
as
I
can
some
of
these,
like
high-level
architectural
stuff
and
like
tried
to
actually
explain
like
the
requirements.
E
C
Drove
some
of
these
design
decisions,
so
if
that's
interesting
to
people
I
can
I
can
fish
up
what
happened
today.
Oh
you've
got
it.
I've.
C
A
A
Also
ted
one
thing
that
a
couple
weeks
ago
I
we
talked
about
the
proposal
for
the
data
client,
and
there
was
just
one
clarification.
We
talked
about
which
the
my
proposal
was
for.
Interactions
was
to
use
spans
spans
to
represent
interactions
and
like
if
they,
if
they
had
no
duration,
then
there
would
be
zero
duration.
A
C
Okay,
yeah
yeah,
I
mean,
I
think,
that'll
to
me
that
also
it's
fine.
This
is
where,
like
I
think,
prototypes
are
really
helpful
like.
It
would
certainly
be
helpful
to
me
to
just
just
play
around
with
what
you
guys
make
it's
it's
a
little
bit
easier
to
see
this
stuff
in
action.
I
think,
but
in
theory.
A
So
we
haven't
quite
gotten
there
yet,
but
but
like
we
have
so
there
are.
There
are
existing
instrumentations
for
browser,
but
there's
existing
user
interaction,
instrumentation,
there's
existing
document
load
and
those
currently
generate
spans
right.
So
I
think
the
poc
would
also
generate
logs
that
represent
like
the
click
or
the
the
individual
timing
events,
but
it
will.
It
would
keep
the
spans
that
represent,
like
the
the
overall
duration
of
the
interaction
or
the
loading.
E
Okay,
I
I
I
have
one
question
on
the
user:
interaction
when
presented
as
a
span.
E
E
So
even
though
it
is
good
to
represent
it
using
the
spam,
its
duration
is
still
just
a
zero
duration.
So
how?
How
are
asynchronous
calls
in
a
represented?
You
know
in
you
know,
in
a
trace
under
ui.
You
know,
maybe
all
the
user
interactions
are
represented
using
spans
but
make
sure
that
durations
are
not
our
durations
are
set
appropriately.
E
A
A
Yeah,
I
mean
well.
All
I
can
tell
you
is
that
like
currently
like
the
the
javascript
instrumentations
like
for
asynchronous
operations,
typically,
they
represent
like
the
whole
operation,
including
wait
time.
A
A
So,
and
there
is
some
wait
time
in
between
and
the
same
thing
applies
to
user
interactions
like
you
will
have
a
click
at
the
beginning
and
then
there
is
potentially
some
some
work
like
network
calls
and
ui
changes
and
like
so
that
the
whole
thing
currently
is
is
the
top
level
operation
is
represented
as
a
the
user
interaction
span.
E
Yeah,
I
think
the
only
difference
is
the
the
top
level.
The
initial
spans
duration
cannot
be.
I
mean
it
has
to
be
a
zero
duration
in
the
case
of
a
click.
C
Well,
I
think
the
the
where
the
user
interaction
span
is
measuring
in
general
is
the
event
handling
right
you're,
it's
not
the
actual
click
itself,
but
the
click
combined
with
all
the
event
handlers
fired
by
that
click.
That's
what
you
want
the
the
top
level
span
to
represent,
because
that's
that's
what
you're
trying
to
measure
is
like
how
long
did
it
take
for
all
the
event
handling
that
this
this
event
initiated
to
complete?
That's
the
latency
that
you're
going
to
want
to
measure.
E
Well,
I
thought
that
was
implicit
anyway.
The
the
fact
that
we
are
representing
some
causality
is
enough
there
and,
and
then
in
the
in
the
trace
visualization.
You
anyway
show
the
complete
on
a
time
scale.
You
will
show
how
long
the
event
handler
took
place.
You
know
took.
A
So
I
just
I
want
to
clarify,
I
just
want
to
clarify
like
we
currently
do
not
generate.
As
far
as
I
know
like
in
javascript,
we
do
not
generate
spams
for
the
event
handlers
themselves
like,
if
you
think
about,
like
you,
click
and
then
there's
a
function
that
responds
to
that
click,
and
so
there's
no
span
for
like
that
function.
Call
which
might
take
just
you
know,
very,
very
small
time.
A
C
D
A
A
Yeah
and
so
it
seems
like
it's,
it's
very
dependent
on
what
the
sdk
is
capable
of
doing
like
you
know,
if
you
have
like
in
this
case,
like
the
browser,
the
browser
sdk
might
might
have
context
propagation
or
it
may
not.
So
in
that
case
the
span
duration
represents
two
very
different
things
and
and
then
like
in
mobile
applications
from
my
understanding
from
what
I've
heard
from
bryce
is
that
it's
not
even
possible
to
to
to
to
represent
like
the
causality
between
like
the
event
and
the
work,
that's
being
done
so
some.
C
Yeah
yeah,
just
just
an
aside,
I
think
in
swift.
They
are
coming
up
with
like
a
new
kind
of
content
context
management
model.
C
I
haven't
been
following
it
too
closely,
but
from
talking
to
bryce
and
some
other
people
who
looked
at
tracing
and
swift,
that's
a
thing
they've
mentioned
is
that,
like
the
next
big
version
of
swift
may
have
some
form
of
like
implicit
context
management?
That's
that's
different
than
what's
there
right
now
and
so
they're
kind
of
like
holding
off
because
they
don't
want
to
be
caught
sideways
with
whatever
that
thing
is
when
it
comes
out,
but
you
might
wanna,
you
might
wanna
ask
bryce
bryce
about
that
particular
situation.
C
Okay-
and
I
am
a
little
concerned
because
there
was
some
attempt,
I
think
by
bryce
and
other
people
to
to
mention
tracing
as
like
a
use
case
for
this
stuff,
and
the
swift
people
were
like
a
little
confused
about
that,
because,
for
whatever
reason,
when
you
bring
it
up,
they
think
you're
talking
about
using
swift
for
server-side
development,
which
they
don't
don't
care
too
much
about.
C
C
C
Don't
know
what
the
state
of
all
that
stuff
is,
but
if
it's
not
if
it's
like
not
done
yet,
there
might
be
an
opportunity
to
to
try
to
catch
them
while
it's
still
in
a
beta
or
experimental
state
and
give
them
some
feedback.
A
Okay,
yeah,
I
might
I
might
go,
and
I
think
the
swift
stick
is
on
thursdays.
Yeah
yeah.
Okay,
I
might
I
might
go
there
tomorrow.
A
Yeah
bryce
said
last
time
that
he
was
gonna
be
out
because
his
his
wife
was
due,
oh
so
yeah,
so
I'm
not
sure
like
if
he's
still
available
or
not
yeah,
but
yeah,
okay
and
is
there?
Is
there
a
separate
sig
for
android
development?
Or
is
it
part
of
java
right
now.
B
John
kind
of
doesn't
exist,
I
mean
there
is
some
android
related
to
code,
but
no
there's
no
like
specific
instrumentation
for
android
that
lives
anywhere
aside
from
then.
A
A
Okay,
so
so
it
would
be
just
going
to
the
javascript
and
see
if
there's
anyone.
B
Yeah,
I
think
that's
probably
the
best
bet
you
might
ask
just
also
like
open
up
a
a
discussion
item
in
open,
telemetry
java
instrumentation,
just
because
there
are
people
who
can
like
we're
very
globally
distributed
and
they're
people
who
can't
necessarily
attend
this
week.
Meetings.
Okay,.
A
B
A
A
Okay,
so
the
the
authors
of
this
of
this
blank
instrumentation,
are
they
attending
the
segment?
Well,.
B
Okay,
so
I'm
here
I'm
no
longer
I'm
no
longer
working
on
that
actively,
but
I
wrote
almost
all
that
code.
So
yes
got
it.
A
B
A
Okay,
so
the
the
other
item
that
I
had
I
wanted
to
ask
if
anyone
would
be
opposed
to
changing
this
sixth
meeting
from
8
30
to
8
00
am
on
the
reason,
for
that
is
that
we
overlapped
with
the
javascript
sig
and
probably
at
some
point
soon.
We
will
want
to
include
them
in
the
discussions
and
also
contribute
to
their
code
base.
So
it
would
be
good
if
those
meetings
didn't
overlap.
E
A
Okay,
is
that
something
you
want.
C
Yeah
I
mean
these
meetings,
hopefully
won't
go
on
forever.
You
know
we'll,
hopefully
hit
a
point.
You
know
where
we're
far
enough
along.
We
don't
we
don't
have
to
meet
every
week,
yeah
yeah,
I'm
fine
with
moving
it
back
to
eight
I
mean
in
general,
open
telemetry
with
its
europeans
and
it's
8
a.m,
meetings
every
day
of
the
week,
but
that's
that's
just
me
being
a
night
owl,
but
yeah,
I'm
fine
with
it.
A
Okay,
ted
is
that
something
that
you
can
help
us
with
change
the
calendar,
or
should
I
should
I
reach
out
to
more.
C
It's
that
easy
and
y'all
should
be
able
to
get
calendar
access.
If
you
look
at.
C
The
community
docs
there
are
some
docs
in
there
about
about
getting
calendar
access
or
yeah
pinging
pinging,
morgan
and
saying,
can
you
add
me
add
me
to
the
the
google
calendar
and
then
you'll
be
able
to
move
things
around,
but
there
is
also
an
open
telemetry.
Google
account
if
you
look
in
the
docs
folder
of
the
community
repo
there's
some
docs
around
calendar
management,
and
in
that
it
includes
the
login
information
for
that
google
account.
C
So
if
you
ever,
anyone
here
needs
to
set
up
a
meeting
or
do
anything
like
that
or
like
change.
The
zoom
links
and
stuff
like
that.
You
just
log
into
that.
Google
shared
google
account
to
do
all
that
stuff.
C
A
Okay,
great
so
next
next
wednesday,
let's
plan
on
done
eight
o'clock.
E
C
Yeah
fyi,
the
logs
sig
meeting,
is
at
10.
so
I'll,
try
to
pop
in
there
and
mention
that
we're
thinking
about
an
events
api,
but
if
anyone
who's
interested
in
working
on
that
wants
to
pop
into
that
meeting.