►
From YouTube: 2022-05-10 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
So
santa
I
just
made
one
note
in
the
spec
about
logging
levels.
So
where
did
the
existing
ones
come
that
you
had
in
there
or
was
that
just
a
proposal.
C
A
Didn't
follow,
can
you
explain
once
again
logging
levels.
C
A
So
yeah
so
severity
level
I
have
not
considered
so.
Let
me
share
my
screen
and
show
the
api.
C
Yeah
so
effectively
when
I
did
the
diag
log
for
the
javascript
api,
I
think
I
I
came.
I
I
populated
this
based
on
all
my
previous
history
with
all
different
logging
systems,
so
it
sort
of
gave
space
for
that
and
I
actually
had
the
the
values
the
reverse
of
the
way
around.
So.
B
A
A
So
you
know,
if
you
get
a
chance
in
a
please
review,
that
I'll
put
the.
Let
me
put
that
link
in
the
notes.
C
A
So
nav
to
answer
your
question,
I
had
designed
it
like
this.
Where
there
is
an
event
emitter,
you
know
you
can
get
an
even
builder
which,
given
a
name
which
will
return
a
log
record
builder
and
on
the
log
record
builder
you
you
can
set
the
severity.
A
You
know
you
can
set
every
field
that's
available
on
the
log
record.
You
know
yeah.
A
C
A
Right
so
once
you
create
an
event
with
this,
you
can't
further
extend
it,
because
this
will
also
emit
that
event
right
away
now
in
in
these
functions,
I
did
not
include
the
you
know
severity.
So
if
somebody
needs
it,
they
need
to
put
it
out
but
alternately.
I
can
repeat
all
of
these
and
have
one
with.
C
I
don't
think
that's
needed.
No.
My
question
really
was.
I
was
hoping
that
logs
had
not
defined
their
severity
because
the
javascript
api
defined
effectively
the
severity
a
long
time
ago
and
therefore
we
could
actually
just
unify
and
make
them
all
the
same.
C
Because,
like
for
some
events,
especially
on
the
client,
you
want
to
say
well,
I
want
to
log
this
event
and
you
can
say
well
anything
of
this
severity.
I
want
to
log
out
the
door
so,
but
if
they're
different
there's
a
mapping
required,
which
is
just
extra
code
that
makes
life
messy
yeah.
A
I
think
it's
a
little,
you
know
tricky,
I
initially
had
I
mean
this
is
one
approach
or
you
can
even
have
our
standard
logging
api
interfaces
where
you
could
have
void.
A
You
know
debug
and
then
say
you
know
a
message
right
and
then
you
know
whatever
parameters,
you
need
where
the
civility
level
is
in
the
function
name.
So
this
word.
C
C
It's
a
case
of
there's
going
to
have
to
be
a
mapping
and
and
the
reason
that
the
javascript
one
does
it
in
that
order
is
so
you
can
actually
say
logging
level,
and
then
it's
like.
C
Yeah,
so
do
you
see
the
the
dialogue?
Okay,
I
didn't
see
when
you
jumped
in
no.
D
C
I
I
just
have
more
well.
This
was
based
on
my
history
with
a
bunch
of
logging
apis
in
different
languages,
so
it
allows
for
applications
to
effectively
define
their
own
verbosity
levels
from
like
80
up
to
99,
and
then
you
set
the
logging
level
to
whatever
you
want
and
that's
what
pops
out.
So,
if
you
set
the
login
level
to
30
you'd
only
ever
get
your
survey
level
zero
through
30.,
if
you
said
to
50
it'll,
be
anything
between
zero
through
50..
C
C
Yeah
and
I
guess,
if
you
scroll
up
or
down
you'll,
see
the
helper
functions,
but
we
do
have
like
you
know:
debug
warning,
yeah,
those
yeah,
so
you've
got
error.
So
log
function
is
just
that
it
defines
the
function
that
takes
a
message
and
a
variable
number
arguments.
So
you've
got
error.
One
info
verbose
and
those
names
are
deliberately
left
small
because
in
javascript
they're
top
level
names
that
can't
be.
B
A
But
but
so
so,
this
is
for
logging
purposes
right.
This
is
not
for
creating
events.
C
Correct,
but
it
would
be
really
really
useful
if
they
were
the
same,
because
that
way,
you
only
have
one
concept
of
severity.
So
therefore
you
could
have
a
as
part
of
the
firing,
an
event
you
could
say.
Well,
I've
got
an
interceptor
that
says:
okay,
if
I
get
an
event
of
fred,
which
has
this
very
level
of
this,
it
just
sends
it
out
over
here
and
therefore
will
pop
out
automatically
right.
Okay,
if
they're
different,
because
logs
has
already
defined
them,
then
yeah.
We
have
a
mapping
that
we're
gonna
have
to
do.
Okay,.
A
Actually,
I
would
suggest
that
you
I
mean
we
for,
for
the
purpose
of
expanding
these
log
levels
to
a
wider
range.
I
think
that
will
have
to
be.
You
know
another
issue
or
no
tip
against
yeah.
D
D
D
A
Yeah
but
but
your
other
point
about
including
severity
in
the
events
api
we
could
we
could
do
that
like,
for
example,
before
he
joined,
I
was
showing
that
I
originally
had
something
like
this,
where
there
is
an
event
emitter
equivalent
to
a
tracer
where
you
could,
you
could
use
this
event
builder,
giving
an
event
name
and
get
a
log
record
builder,
and
this
log
record
builder
has
a
bunch
of
setters
and
you
could
set
the
severity
right.
A
So
so
you,
if
you
want
to
set
severity
on
an
event,
you
know
you
could
use
this
approach
r.
There
are
helper
functions
to
to
create
the
log
records
for
events
directly
and
emit
them.
A
A
Yeah
r
or
I
could
actually
name
the
methods
using
the
seriality,
which
is
which
then
makes
it
a
log
api.
A
logging
api.
D
I
mean
so
this
is.
This
is
like
a
very
like
kind
of
like
java
flavored
approach,
but
the
the
way
I
would
do
it
and
go
in
other
languages
is
to
have
your
to
basically
like
have
have
it
like
all
of
the
you
have
like
a
list
of
all
the
options
that
you
provide
on
the
log
builder
and
to
have
like
the
convenience
method.
D
Basically
take
a
have,
like
the
you
know,
name
attributes
like
whatever
the
convenience
stuff
is
at
the
front,
but
allow
you
to
then
tack
on
a
list
of
options
as
like
the
last
parameter
like
like.
D
I
don't
know
how
you
would
express
it
like
what
the
the
language
convention
is
for
expressing
that
this
way,
but
you
know
if,
if
you're,
just
like
you're
gonna
name
it
you
can
give
it
a
bag
of
attributes
and
then
optionally
attach
any
other
log
option
to
this
thing
like
severity
or
anything
else
that
you
define.
That
would
be
a
a
convenient
way
to
do
it.
It's
just.
E
A
Is
there
is
one
problem
with
that,
though?
I
think
if
you
pass
it,
as
you
know,
a
dictionary
key
value
pairs
that
would
go
in
the
attribute,
whereas
there
is
a
top
level
field
for
severity.
So
if
we
want
the
severity
to
go
in
the
top
level
field
and
not
in
the
attributes,
then
it
better
be
an
explicit
argument.
D
Well,
I
mean
it's
just.
I
think
this
is
just
like
a
language
thing.
The
way
you
would
do
that
in
go
or
or
javascript
is.
You
would
have
a
dictionary
that
you
passed
in
as
like
your
your
attributes,
but
then
you
would
have
like
in
go.
It
would
be
like
an
options
struck
or
it
would
just
be.
You
have
optional
arguments
and
go
where
you
know
it
would
be
like
the
the
like
the
option.
A
Dictionary
that
options
key
values
key
correspond
to
the
these
fields.
Do
they
map
to
the
function,
arguments.
D
Yes,
I
mean
you
could
maybe
just
in
go,
do
it
or
in
java,
do
it
as
a
builder
pattern
still
potentially,
but
in
these
other
languages
you
would
tend
to
you
in
these
other
languages.
You
don't
use
the
builder
pattern
at
all.
Right,
like
you
know,
when
you
create
a
log,
it
would
just
be,
it
would
just
be.
D
D
D
Oh,
I
think
you
would
just
the
the
arguments.
The
attributes
dictionary
is
for
like
attributes
and
then
the
options
dictionary
is
for
these,
like
top
level
official
things,
so
you
would
just
keep
them
separate.
So
there's
no.
A
D
Exactly
for
languages
that
that
give
you
some
way
to
to
validate
that
you
would
you
would
do
it
that
way,
which
might
be
like
a
typed
like
us,
either
like
a
struct
with
type
definitions,
or
you
know
like
a
a
validator
of
some
kind
and
in
go.
It's
like
you
could
give
it
go.
Polymorphism
is
like
you
can,
give
it
like
a
list
of
things
of
the
same
type.
So
as
long
as
everything
you
pass
in
is
of
the
like
log
option
type,
you
can
pass
in
like
an
arbitrary
number
of
them.
It's
just.
D
This
is
like
one
of
the
ways
where,
like
every
language
has
their
own
preferred
flavor
of
how
how
you
pass
in
options
and
arguments,
but
you
might
want
to
just
define
it
as
like.
What
are
the
three
types
of
things
you
you
want
to
pass
in
and
it
seems
like
for
logs.
It's
like
you
want
to
give
it
a
message:
a
set
of
attributes
and
a
set
of
options
and
for
an
event
you're,
giving
it
a
name,
a
set
of
attributes
instead
of
options.
D
These
are
the
allowed
options
and
for
every
language,
maintainer,
all
the
different
language
designers.
They
can
decide
the
the
best
way
to
express
that
that
specification
in
in
their
language
and
the
java
people
will
probably
do
something.
A
lot
like
what
you're
proposing
here
with
like
a
builder
object.
C
D
D
If
you
look
at
what's
already
in
the
spec
around
objects,
like
start,
like
start
span
and
stuff
like
that,
you'll
see
that
it
it
it
tries
to
be
a
little
neutral
about
describing
how
you
pass
these
things
and
instead,
just
kind
of
focuses
on
like
these
are
the
these.
Are
the
available
options
that
this
this
thing
gets.
D
You
know
you
can
hand
it
attributes,
you
can
hand
it
these
other
things
and
then
then
each
individual
sig
can
have
their
own
little
bike
shed
about
what
the
language
specific
you
know,
interpretation
of
that
spec
is.
A
Okay,
so
so
all
right,
so
I
think
in
these
spec
I
had
written
something
like
this
yeah.
D
Yeah
and
I
mean
we'll
we'll
help
review
these
santosh
like
we'll
get,
you
know
I'll,
try
to
help
review
it
and
we'll
get.
You
know.
Other
pc
members
like
tigran
to
kind
of
help
like
other
people
from
the
log.
Stick
that
help
you
know
just
clean
it
into
spec
language,
but
but
this
is
like
a
really
good.
A
There
is,
there
are
a
couple
of
open
questions.
You
know
I
want
to
get
opinions
from
from
this
group.
A
So
how
do
we
pass
the
span
context
into
into
the
events
right?
So
when
we,
when
we
in
in
the
trace
api,
when
you
create
a
span,
it
is
not
explicitly
added
as
a
child
of
the
current
span
right,
it
has
to
be
explicit
unless
you
you
make
the
the
the
you
know
the
the
current
span.
As
you
know,
as
a
current
span
like
there
is
you,
you
have
to
explicitly
set
a
span
as
a
current
span,
and
then
you
know
any
expanse
you
create
will
automatically
get
that
as
a
parent.
A
So
so
there
are
two
options
available,
at
least
in
the
java
api.
So
in
the
case
of
logs,
I
understand
that
you
know
we.
We
want
people
to
use
the
existing
log
api,
so
there
is
not
much
option
to
not
include
the
span
context
there.
A
A
span
is
in
progress
and
then
you
navigate
to
another
page
or
you
navigate
to
another
route,
or
you
know
your
network
changed.
You
moved
from
wi-fi
to
you,
know
cellular.
So
that's
nothing
to
do
with.
You
know
your
span
and
progress.
So
you
I
you
know
there
may
not
be
any
harm,
but
you
know
at
least
we
should
give
an
option
to
the
users,
to
you
know,
create
events
without
an
ex
without
you
know
explicitly
specifying
the
span
context.
D
So
the
actually
the
the
way
this
the
api
works
is
you
you
never
explicitly
specify
like
the
context.
The
way
these
apis
work
is
every
api
gets
access
to
the
full
context,
object
and
un.
Under
the
hood,
things
like
span
context
are
getting
automatically
attached.
A
A
A
Is
you
you
make,
you
know
a
span
as
a
current,
make
current
right
right.
D
And
that's
for
the
span
that
that's
for
span
management
like
actually
managing
your
spans,
the
event
api
and
the
logging
api
shouldn't,
probably
I
mean
maybe
as
an
option,
take
a
specific
what
you
would
hand
them
a
specific
context,
though
not
a
spank
context,
but
probably
you
don't
don't
ever
want
to
do
that.
D
This
stuff
is
showing
up
here
explicitly
because
that's
the
point
where
you're
actually
piecing
these
things
together
to
handle
situations
where
like
work,
is
moving
from
like
one
thread
to
another
and
there's
this
little
bit
of
like
stitching,
you
need
to
do
manually
in
order
to
to
make
it
clear
what
the
the
flow
of
execution
is
in
the
program.
D
I
think
that
the
expectation
is
if
you're,
just
creating
a
an
event
or
a
log
it
should
you
know
like,
like
you,
shouldn't,
have
to
worry
about
this.
This
level
of
context
when
you're,
creating
events
and
logs
like
you
shouldn't,
have
to
be
thinking
about
active
spans
one
way
or
the
other.
It's
just
that
context
should
be
set
up
by
the
bit
of
like
the
the
little
bit
of
code.
That's
doing
this,
this
thread
switching
or
or
whatever
it
is
that
that's
requiring
this,
this
kind
of
stuff
to
happen,
but.
A
D
A
I'll
give
examples
to
address
both
both
the
possibilities.
You
know
one
is
in
the
same
con
execution
context.
You
know
another
is
so
in
so
in
at
least
in
the
in
the
javascript
for
web.
In
the
browser
world,
there
is
only
one
execution
context,
whether
it's
a
single
threaded
yeah.
So
everything
happens
on
the
on
the
same
thread.
So
if
you
are
making
an
api
call
and
then,
while
that
is
in
progress,
you
you
navigate
or
you
do
something
you
click
a
button
or
you
navigate.
A
Do
we
do
we
want
to
associate
that
span
and
pro
there
can
be
multiple
stance
in
progress
by
the
way
you
know
when
yeah,
when,
when
you're
doing
something
your
browser
can
make
multiple
api
calls
simultaneously
there's
a
limit,
but
you
know
it
can
do
more
than
one
for
sure
and
in
android
I
know
I
was
reading
about
it.
You
can,
you
know,
set
up
event
listeners
and
there
is
an
option.
A
Where
you
specify
the
callback
should
be
given
to
you
know
which
handler
you
know,
which
thread
so
by
default
it
will.
The
callback
will
come
in
the
same
thread.
You
know
that
set
up
that
listener
right,
so
it's
possible
that
I
created
a
listener
for
a
certain
event
and
in
that
same
thread
you
know
I
then
go
on
to
make
an
api
call
and
then,
when
that
event
is
independently
fired
it,
it
happens
in
the
same
thread.
E
C
Yeah
and
you
could
also
say
in
in.net,
you
know
when
you're
doing
gui
stuff
the
dispatcher
thread,
all
the
ui
stuff
happens
in
in
one
thread,
so
you've
got
the
same
problem
there,
but
yeah.
The
the
the
background
ajax
called
for
web
is
the
exact
thing
I
was
going
to
bring
up
as
well.
It's
like
you
know,
you're
doing
an
ajax
call
in
the
background,
but
then
the
user
is
independently
or
the
app
is
firing.
Events
you
do
do
not
want
them
associated
in
any
way
shape
or
form,
because
they're
completely
separate
things.
E
So
go
ahead
now
I
was
going
to
say,
like
it's
not
handled
by
by
the
context
manager
yeah
like
the
context
manager
like
it's.
It's
like
in
browser,
it's
event
based,
but
if
you
like
click
on
something,
then
the
context
manager
will
propagate
the
context,
the
callbacks
that
relate
only
to
that
event
that
started
it
right.
So.
C
Well,
if
you've
got
if
you're
in
an
ajax
call-
and
you
say
I'm
doing
I'm
going
to
start
a
span
that
will
set
the
span
as
current.
So
from
that
point
onwards,
if
anything's
looking
up
the
current
span
and
auto,
attaching
it
game
over,
it's
like.
C
D
There's
a
context,
so
in
and
again
I
don't
maybe
there's
edge
cases,
it
doesn't
work
well
in
javascript,
because
javascript
is,
as
far
as
I
can
tell
very
crudely
and
unfortunately,
bolting
on
actual,
like
co-routine
management
like
javascript,
is
essentially
what
you
call
co-routines
and
in
other
languages
you
can
actually
build
like
a
co-routine
environment
on
top
of
the
threaded
environment,
so
you
have
like
g
event
in
python.
I'm
sure
there's
these
like
async
things
going
on
in
java
and
what
happens
there
is
open.
D
Telemetry
is
integrated
into
that
context,
manager
as
a
plug-in.
So
there's
this
thing,
that's
managing
all
the
contacts,
and
whenever
that
thing
switches,
contacts,
the
open,
telemetry
plug-in
is
is
swapping
out
which,
which
context
object
is
current,
based
on
which
which
context
is
actually
happening.
Co-Routine
is
running
on
that
thread
and
that
same
thing,
kind
of
in
go
except
you.
Do
it
all
by
hand,
and
my
understanding
is
the
javascript
context.
Managers
are
supposed
to
be
doing
that.
C
Well,
you
can
pass
around
the
context,
but
there's
also
the
global
all
the
instrumentations
tend
to
use
the
global,
which
is.
D
Right
because,
prior
to
context,
managing
management
becoming
like
a
well-supported
thing
in
javascript,
the
only
option
you
had
was
to
do
the
go
version,
which
is
you
just
pass
the
context
as
an
argument.
Now
your
callback
stack,
which
is
hell
because
you
just
it,
breaks
every
api
along
the
way,
and
it's
it's
it's
terrible.
D
So
like
it's,
not
it's
not
very
realistic
to
to
do
this
kind
of
stuff
in
a
js
environment
where
you
can't
run
one
of
the
context
managers,
but
I
do
know
they
had
to
kind
of
abstract
how
context
management
works
in
javascript,
because
you
also
can't
depend
on
one
particular
context
manager
being
available.
D
It's
not
like
java,
where
you
have
thread
locals
or
some
other
like
you
know,
you
have
some
some
more
fundamental
concepts:
you're
you're
working
with,
so
I'm
not
I'm
not
sure
what
the
edge
cases
are
in
like
the
browser
versus
nodejs.
D
C
This
probably
comes
back
to
discussion
in
terms
of
how
do
you
get
the
api
to
then
record.
So
if
we
said
we
root
the
api
after
the
current
context
manager,
so
you
say
context
manager.event
api
dot
blah
then
that
probably
solved
some
of
that
issue
except
you've
then
got
this
nested
object
hierarchy
that
again
in
javascript,
can't
be
minified
because
they're
all
public
names,
but.
D
You
know
like
a
whatever
it
is:
a
network
change
or
page
switch,
or
something
that
that
should
be
generating
a
fresh
context.
When
that
happens,
it
shouldn't
be
just
grabbing
some
other
context
that
happened
to
be
lying
around,
but
so
it
should.
It
should
work.
Fine.
You
shouldn't
end
up
in
a
situation
where
you're
getting
this
stuff
mixed
in,
but
I
would.
D
I
would
believe
that
there
are.
There
are
edge
cases
where
you
you
do
have
to
do
some
manual
context
management
to
to
make
sure
that
happens,
especially
maybe
in
like
the
case
santosh
mentioned,
where,
like
you're,
just
using
thread
level
context
management
and
you
have
some
risk
of
sometimes
a
pollution
between.
D
Into
the
same
thread,
but
you're
not
using
like
a
co-routine
manager
or
something
just,
you
might
just
mix
the
work
in
in
some
way
where
and
those
are
the
moments
where
you
have
to
do-
that's
kind
of
why
there's
this
manual
span
level,
setting
the
span
parent
kind
of
thing
that
goes
on,
because
that's
kind
of
how
you're
expected
to
do
it.
But,
okay,
I
mean
yeah.
D
Maybe
it's
the
case
that
you
need
to
have
the
ability
to
clear
out
the
context
or
or
on
an
event
explicitly
set
the
parent
context
to
like
and
then
set
it
to
like
an
empty
context
if
you're
like.
Actually,
this
thing
should
not
be
attached
to
to
anything
else.
E
Maybe
just
yeah,
maybe
somehow
just
yeah
like
you're,
saying
like
overwrite
the
trace
context.
A
Complexity,
yeah,
I
think
we
could
for
the
purpose
of
events.
I
understand
that
we
could
do
something
for
the
users
to
explicitly
override
and
not
use
the
other
context.
But
yeah
imagine
you
know
the
the
standard
logging
use
case.
You
know
so
that
event
handler
has
is
emitting
logs
right
and
now
those
logs
will
be
emitted
by
an
appender
into
a
tlp
and
that
that
doesn't
have
any
configuration
options
so
I'll
I'll
discuss
in
the
in
the
log
sig.
But
there.
C
A
Be
potential
gaps
here
that
will
remain
yeah.
D
I
I
would
encourage
prototyping
to
explore
this.
This
is
actually
context.
Management
is
like
the
specific
domain
where
we
historically
going
all
the
way
back
to
the
early
open
tracing
days,
have
like
a
lot
of
bike
sheds
that
only
get
resolved
when
we,
when
we
write
example
code,
because
there's
there's
just
so
many
potential
edge
cases
here,
but
we've
found
a
a
lot
of
the
time.
Prototyping
either
dispels
like
the
need
for
something
or
or
really
reinforces
the
the
need
for
it.
A
A
You
know
I
I
just
put
just
one
one
liner
here
that
you
know
the
individual
language
should
just
make
a
provision
for
yeah
for
that,
but
I'll
I'll
expand
with
examples
and
yeah
prototype
code.
A
Get
a
separate
event:
emitter,
you.
D
Want
to
be
resetting
the
context
here
in
some
way,
yeah,
because,
if
you're
doing
that
on
every
individual
event
that
implies,
you
are
actually
tracking
this
context
somewhere.
Somehow
you
know-
and
we
want
to-
we
want
to
encapsulate
that
yeah.
D
D
Right
and
that's
like
kind
of
expected
to
be
the
the
default
and
then
there's
just
a
question
of
do
you
need
to
make
sure
you
are
setting
up
the
right
context
for
these
events
to
be
firing
in,
or
do
you
in
addition
to
that,
need
a
way
to
manually
pass
a
context
to
an
event
where
you're
saying
like
do
this
event?
Specifically
in
this
context,
I'm
handing
to
you
because
I'm
doing
something
weird
one
case
where
that
shows
up
is
synthetic.
D
Events
like
there
are
some
cases
where
what
you're
doing
is
synthetically
recreating
something
like,
for
example,
synthetically
recreating
spans
out
of,
like
log
events
have
been
recorded,
or
some
some
weird
thing
like
that.
That's
kind
of
a
weird
edge
case,
but
there
are
cases
where
you're,
just
synthetically,
generating
data,
and
so
you're
just
manually
passing
start
time
and
end
time
in
context
and
like
all
of
this
stuff,
to
everything,
because
you're
just
building
this
out
of
some
data
structure,
you
have
laying
around
yep.
C
D
Do
it
in
this
context,
because
there
might
be
other
things
in
that
context,
object
that
the
method
implementation
might
be
digging
around
in
you
know,
metrics
context.
Some
kind
of
log
context
might
be
in
there
some
context.
We
added
the
future
that
we
haven't
added
yet
might
be
in
there.
So
yep.
D
Yeah,
exactly
exactly
that's
that's
why
we
extracted
out
this
context.
Object
from
from
just
having
span
context
was
for
this
reason,
so
that
we
can
we
can
pass
around
this
bag
and,
under
the
hood,
the
implementation
can
start
doing.
Fancier
things
as
more
different
kinds
of
things,
get
added
to
that
bag.
Yep.
A
Okay,
so
I'll
move
on
to
my
second
open
item,
so
this
came
up
in
the
in
a
log.
You
know
sig
last
week
where
it
was
mentioned
that
if
I
use
hotel
dot
event,
dot
name,
as
you
know,
as
the
attribute
name
for
my
event,
name.
A
The
value
needs
to
be
name
spaced
right,
but
how
do
we
ensure
that,
like
you
know,
people
must
use
browser.click
or
or
a
mobile.click,
and
if
they
just
use
a
click,
you
know
it
could
be
in
a
in
a
desktop
application.
You
know
it
could
be
in.
You
know
ten
different
ways,
so
we
don't
know
what
kind
of
an
event
that
is,
so
it
has
to
be
prefixed
with
the
namespace.
A
But
since
it's
hard
to
enforce
there
are
a
couple
other
options.
You
know
one
is
to
not
use
like
a
two
generic
event.
Name
attribute,
but
you,
you
know
prefix
with
the
domain,
but
then
you
know
there
are.
There
will
be
too
many
of
them
right.
You
know
for
every
domain
you
need
to
add.
The
third
option
is
to
have
you
know
two
separate
parameters.
A
A
Is
it
coming
from
you
know,
which
vertical
or
depending
on
their
needs,
they
can
make
a
decision,
but
then
the
the
the
concern
I
had
with
this
third
approach
is
that
the
name
space
so
far
has
been
has
not
been
a
like
a
first
class
concept.
A
It
has
only
been
you
know,
implicit
in
the
attribute
value
as
a
prefix,
but
I
haven't
seen
I
could
be
wrong.
I
haven't
seen
the
namespace,
you
know
being
explicitly
passed
separately,
yeah.
D
D
There
isn't
a
concept
of
a
span
namespace
to
go
with
the
span
name
for
better
or
worse,
but
with
a
service
name,
I'll
post,
a
link
to
that
that
resource,
there's
a
service,
dot
name
and
the
service
dot
name
space
attribute,
which
is,
I
think,
what
you're
talking
about
right,
like
this
need
to
to
further
name
space.
A
But
then
this
namespace
is
something
I
believe.
A
You
know:
are
there
semantic
conventions
for
the
values
that
this
namespace
will
take?
They're
there
are
for.
A
You
know
database
has
a
domain,
so
any
events
in
the
database
domain
should
use
the
value
database
or
db
for
for
this.
For
this
m
space
parameter,
I
shouldn't
use
something
anything
else.
D
I
think
that's
where
instrumentation
scope
comes
in
so
so
all
of
these
events
are
emitted
inside
of
an
instrumentation
scope.
So
when
you
create
a
tracer
or
in
a
metrics
object
or
an
event,
emitter
that
that
object
should
take
an
instrumentation
scope
like
a
set
of
attributes
that
are
going
to
be
attached
to
to
every
event
that
that
come
out
of
it
have
a
look.
That's
a
a
proposal.
Tigran
has
right
now
for
this.
So
far,
we've
only
had
the
instrumentation
name
and
instrumentation
version,
and
now
we're
adding
like
instrumentation
attributes.
D
D
So
you
can
see
these.
All
of
these
events
came
from
this
particular
version
of
this
particular
sql
client.
D
Yes,
let
me
see
if
I
can
look
this
up
really
quick
in
the
in
our
proto
definitions.
C
C
Yeah
so
I
like
I,
I
would
prefer
to
just
say
hotel.event.name
and
then
we
define
a
set
of
standard
events,
so
the
shape
of
those
events
are
always
fixed.
So
if
a
browser
event
and
a
mobile
event,
click
have
the
same
values,
then
it
is
the
same
event.
But
I
understand
why
you'd
want
to
have
a
effective
source
for
or
the
domain
to
effectively
fork
that
out
into
a
different
back
end.
D
So
I
posted
a
link
to
how
this
this
is.
So
this
is
how
logs
actually
get
reported
so
logs,
come
in,
like
you
have
like
resource
logs
which
attach
a
set
of
resource
attributes
to
a
set
of
instrumentation
library.
Logs
instrumentation
library
logs
are
a
set
of
log
records
associated
with
an
instrumentation
library,
and
if
you
go
into
the
common
proto
to
look
at
instrumentation
library,
their
instrumentation
scope
here
I'll
post,
an
a
link
to
that,
and
I
have
it
yeah.
You.
A
D
It
yeah
that's
right
now,
that's
just
the
instrumentation
name
and
version
and
we're
gonna
add
attributes
to
this
as
well,
and
I
I
think
this
is
the
if,
if,
if
by
domain,
this
is
the
kind
of
scoping
you're
talking
about
is
trying
to
specify
the
the
source
of
the
event
from
the
perspective
of
like
what
which
library
emitted
this
event,
then
this.
I
think
this
is
the
thing
that
you
want,
and
it's
really
nice
because
you're,
you
don't
have
this
repeat
issue
of
like
attaching
this
data
repeatedly.
A
So
I'm
convinced
that
this
has
to
be
at
the
scope
level,
though
that
makes
sense,
but
you
know
we
still.
I
I
feel
like.
We
still
need
the
values
for
this
attributes
to
be
standardized
as
well.
D
Yes,
right
right
now,
there's
just
name
and
version
so
library,
name
and
and
the
version
of
the
librarian,
the
only
two
defined
fields.
If
there's
so,
if
there's
other
instrumentation
attributes
that
we
want
to
define,
I
think
that's
definitely
doable.
That's
that's.
A
Attributes
it's
the
same
attribute,
but
the
value
that
attribute
can
take.
It
has
to
be
from
a
from
a
fixed
set
of
values
that
that
is,
you
know,
defined
as
a
semantic
convention.
D
A
A
It
could
be
right,
for
example,
you
know
the
event
is
click,
but
then
multiple
libraries
could.
A
E
So
I
was,
I
was
thinking
like
I
just
recommend
just
jumping
right,
quick.
I
was
thinking
about
this
a
little
bit
differently
and
I'm
not
sure
if
that's
the
right
way,
but
I'm
just
gonna,
throw
it
out
there
as
a
as
a
counterpoint.
E
So
instead
of
a
name
that
like
specifies
like
the
specific
instance
of
the
thing
like
it,
would
be
more
like
a
type
so
like
the
event,
event
type
wouldn't
be
the
event
name
wouldn't
be
click,
but
it
would
be
like
interaction
and
then
you
have,
then
you
have
a
set
of
semantic
conventions
around
like
what
the
interaction
might
look
like
and
the
reason
I've
been
thinking
about
it.
This
way
is
because
there
is
a
precedent
for
it.
E
Already
like
there
is
like
in
the
span
events
you
have,
you
have
exceptions
and
for
like
for
a
span
event
that
represents
an
exception
like
the
name
of
the
event
is
exception,
and
then
you
get
additional
like
sort
of
attribute
that
define
like
you
know
is
it
is
it?
Does
it
have
a
message?
Does
it
have
a
type?
Does
it
have?
A
stack
trace
like
those
are
the
like?
The
semantic
conventions
for
the
type
of
the
the
event
for
the
exception
right,
so
I
was
thinking
about
it
similar.
E
A
D
A
Actually,
I
don't
have
specific
examples
yeah,
but
you
know
people
bring
it
up.
That's
why.
D
I
I
I
might
suggest
that
I
don't
think
we
need
a
generic
concept
of
domain,
just
think,
because
I
think,
what's
often
what
was
traditionally
used
as
domain
in
like
java
and
stuff,
like
that,
I
think,
is
covered
by
by
instrumentation
library
name,
but
a
thing
to
think
about
when
you're
exploring
this
are.
Are
there
additional
attributes
that
you
would
want
to
attach
to
the
scope
of
the
event
emitter
right,
where
anything
that
comes
out
of
this
event?
D
Emitter
should
have
this
attribute
attached
to
it
and
what
are
some
semantic
conventions
for
that
which
would
do
the
job
that
you're
describing
of
letting
you
differentiate,
okay
and
then
is
there
anything
additional
to
that
that
actually,
wouldn't
you
wouldn't
want
to
attach
to
the
event
emitter,
but
you'd
want
attached
to
individual
events,
because
maybe
somehow
somehow
changing
around
it's,
not
it's
not
associated
with
that
instrumentation.
D
Likewise,
when
it
comes
to
like
event,
type
event
attributes,
I
think
we
try
to
just
name
space
those
attributes,
so
if
it
was
just
to
martin's
content
like
if
it
was
like
an
interaction
event,
I
don't
know
that
we
need
to
name
the
event
interaction.
I
mean
that
might
be
helpful,
but
we
would
definitely
want
to
have
like
interaction,
dot
type
interaction
dot
this
or
that,
so
that
it
would
be
easy
to
identify
this
as
being
an
interaction
event.
D
That's
I
don't
know,
that's
yeah
the
composition,
approach
versus
the
type
system
approach
has
been
the
the
thing
we've
been
doing
so
far.
Yeah.
E
D
Just
just
saying
you
might,
if
it's
like
an
interaction
event,
whatever
that
is
like,
then
you
might
be.
If
you're
saying
there's
like
an
interaction.type
click
as
an
attribute,
you
could
use
the
event
name
for
maybe
something
more
specific,
like
you
might
have
a
better
index
or
more
accurate
index
than
just
interaction.
Maybe
for
that
particular
kind
of
click
event,
there's
there's
a
name
that
would
that
would
make
like
a
good
primary
index.
That's
all
those
things
you
could
you
you
don't
have
to
reuse
that
field
to
just
declare
the
type.
E
Yeah
yeah,
I
guess
like
are
we
thinking
of
the
event
name
more,
like
a
span
name
like
where
it
can
have
like
different,
like
wider
possibilities,
values
or
is
it
more
like
a
type
where
it's
like?
You
know.
D
D
That's
that's
not
that
if
there's
a
some
some
category,
that's
that's
actually
very
specific,
more
specific
than
like
a
type
or
something
like
that.
The
name
is
like
a
good
place
to
put
that
the
information,
but
it's
not
always
possible
the
name's
a
little
bit
of
a
squishy
concept.
Sometimes
I
wish
it
didn't
exist,
but
okay.
E
A
D
Yeah-
and
we
tend
to
do
that
with
name
spacing
the
attributes,
so
if
you're
going
to
include
and
again
talking
more
about
spans,
but
if
you're
going
to
include
like
http.status
code
like
if
you're
going
to
include
something
from
the
http
convention,
there
are
rules
about
how
you
apply
the
http
convention.
Overall,
like
you
like,
there
are
some
required
fields
like
if
you're
going
to
say
you're
going
to
apply
the
http
convention.
D
You
have
to
include
these
attributes
and
they
have
to
have
this
value
format
and
then
there's
a
set
of
other
ones
that
are
optional.
D
But
but
there's
rules
to
like
the
http
name,
space
like
like
as
a
whole,
and
I
think
we
can
apply
the
same
thing
to
events
which
is
like
if
you're
gonna
record
an
interaction
event
you
you
have
to
include
actually
this
set
of
attributes
and-
and
it
needs
to
to
look
this
way.
So
what?
If?
What?
If
you?
What?
If
you
added
like.
E
Multiple
sets
of
attributes
like
how
would
you
then
decide
like
what
that
type
of
event?
It
is.
D
Well,
that's
that's
why
we
try
to
avoid
having
like
a
type
system
for
spans
and
events.
It's
just
it's
more
like
composition
right!
So
if
it's
an
interaction
event,
that
means
the
interaction
namespace
of
attribute
search,
so
interaction.blah
interaction,
dot
this
or
that
are
applied.
If
it's
also
somehow
some
other
type
of
event,
then
that
would
mean
there's
a
semantic
convention
for
like
a
namespace
set
of
attributes
that
you
attach
for
that
convention
and
you
would
have
to
to
fully
attach
that
set
as
well
and
then
back
ends
when
they're.
D
Looking
at
all
of
this
data,
they're,
basically
doing
they're
sniffing
those
attributes
to
see
to
see
what's
in
there,
which
might
have
some
overhead,
but
so
far,
that's
like
the
feedback.
We
we
really
get
from
people
consistently
is
they
would
prefer
that
over
having
like
a
single
field,
that's
like
span
type
or
event
type.
E
E
D
I
mean,
I
guess
it
would
be
both
an
exceptional
interaction.
I
mean
in
practice.
I
think
these
things
fall
out
kind
of
reasonably
because,
like
like
you,
don't
end
up
with
incoherent,
namespaces,
correctly
being
attached
to
the
same
event
or
span,
but
the
the
way
it
works
is
basically
every
every
name
semantic
invention.
Namespace
should
have
at
least
one
required
field.
D
You
know
if
you're
going
to
like
include
this
like
you
have
to
have
at
least
this
one
field
there.
So
there's
always
one
field
there's
one
key
whose
presence
you
can
detect
to
notice.
This
is
an
http
request
or
a
database
request
or
an
interaction
event
or
something
okay,
and
then
you
yeah,
maybe
just
detecting
one
of
those
is
enough.
D
Maybe
you
want
to
for
every
event
running
all
your
detectors
so
that
you're
performing
all
the
types
of
analysis
that
might
be
on
there.
I
don't
know
we.
We
haven't
gotten
feedback
from
people,
yet
that
there's
some
there's
like
an
over
processing
overhead
there.
That's
that's,
really
terrible
people
seem
to
be
fine
with
with
that
stuff,
for
whatever
reason
yeah.
A
Only
one
comment
on
on
that
approach:
ted
is
so
far.
The
semantic
conventions
to
my
understanding
is
for
the
attribute
names
not
for
the
attribute
value.
So
here
we
will
have
to
come
up
with
70
conventions
for
the
attribute
values
as
well.
D
Like
instance,
id
like
we
were
sort
of
like
whatever
instance
id
means
to
your
system.
You
put
that
in
here,
but
for
anything,
that's
more
like
a
standard
protocol
or
describing
something
standard
like
sql
or
http,
or
something
like
we're
very
strict
about
the
but.
A
C
C
So
that's
where
I've
sort
of
said
it
might
be
hotel.interaction.click
and
then
the
valid
values
of
action,
type
for
a
click
event
is
left
and
right
and
then
like
the
next
one
is
like
the
the
type
of
event
is
point
of
movement,
and
then
the
action
types
are
enter
hover
and
leave
and
stuff
like
that.
So
so
this
is
really
any
saying
with
that.
One:
two,
that's
like
six
events
there,
but
they
have
different
sets
of
values
for
the
action
type
within
that.
With
that
interaction
event,.
D
Yeah
and
I
think
in
in
hotel,
we
would
tend
to
define
these
as
all
having
separate
keys
that
might
be
like
burdensome
for
client
systems.
We
we
in
general,
we
have
tried
to
avoid
a
situation
where
the
proper
formatting
or
value
for
an
attribute
is
conditional
on
the
value
of
another
attribute.
We've
just
tried
to
avoid
that
that
complexity,
yeah.
C
This
is
really
just
defining
the
mapping,
so
we
say:
we've
got
a
we've,
got
an
attribute
name
called
type
or
action
type
in
this
particular
case,
and
these
are
the
potential
possible
values
which
happen
to
map
to
the
actual
name
of
the
event
right.
A
C
Like
in
theory,
you
could
pass
like
left
as
a
pointer
movement,
but
that
doesn't
make
sense,
so
the
back
end
would
just
either
drop
it
on
the
floor
or
characterizes
unmatched
or
something.
E
C
So
this
came
about
in
the
logs
sig
last
week,
where,
if
we
wanted
to
find
the
event
name,
there
could
be
existing
logs
today
that
are
already
using
event
name,
so
they
could
already
be
sending
a
click
event
so
and
then
the
other
reason
for
namespacing
the
name
of
the
event.
So
we
say
hotel.event.name
is
instead
of
just
click,
it's
autoclick,
because
you
could
have
some
framework
some
platform,
some
vendor
who
wants
to
say
I
want
to.
I
want
to
send
my
own
event
so
you're,
effectively
namespacing
that
event.
C
So
so
there
is
another
definition
somewhere
and
ted
might
remember,
because
I
don't
where
we
actually
specified
the
cloud
type.
So
we
have
a
prefix
for
a
namespace.
So
it's
like
aws
dot,
azure
dot.
I
I
don't
remember
the
actual
context.
That
is,
but
that
I
thought
was
in
relation
to
the
name.
I
don't
know
if
it's
the
span
name
or
the
metric
name
or
the.
D
Yeah
I
mean
we
don't,
I
would
say
again.
The
event
name
doesn't
necessarily
need
to
be
hotel.
Interaction.Click.
If
you
are
applying
a
bunch
of
attributes
that
are
like
you
know,
you
know,
clicked
up
button
is
light
left
or
right
click
that
button.
You
know
like
or
think
things
like
that.
If,
if
those
are
showing
up
as
attributes,
then
you
don't,
you
don't
need
the
name
to
specify
the
event.
D
I'm
not
saying
like
that,
isn't
a
good
name
for
the
event,
but
but
it
shouldn't
it
should
be
possible
to
figure
out
that
this
is
a
click
based
on
looking
at
the
the
attributes
that
were
attached
to
it.
You
shouldn't
have
to
you:
shouldn't
have
to
use
the
name
to
so.
C
As
an
example
like
this
is
just
the
the
action
type
of
a
field,
but
for
microsoft
we
actually
have
the
event
name
as
like.
I
think
it's
ms.web.page
action,
it's
the
and
then
we
have
action
type,
which
is
click
and
then
its
value
is
the
cl
and
cl.
C
That's
how
we
identify
it
so
that
the
back
end
gets
gets
it
and
then
sort
of
says,
like
all
the
ms.web
event
names,
we
we
fork
off
and
say
they're
client-based,
that
that's
what
we
happen
to
do,
yeah
we're
trying
to
find
a
standard
here.
So
we're
just
throwing
around
ideas.
D
D
I
just
think
we
just
we
just
don't
make
a
requirement
that
the
name
field
is
used
as
like
a
type
switch.
We
we
try
to
do
our
type
switching
based
on
looking
at
attribute
the
presence.
D
Keys
but
I
don't.
E
D
Yes,
if
and
like,
if,
if
your
back
end
wanted
to
to
attach
like,
like
reflexively,
attach
a
primary
index
to
these
things,
the
name
field
is
like
kind
of
like
the
suggested
primary
index,
which
is
sometimes
sufficient.
But
not
always
that's
why
I
say
the
names
a
little
squishy.
D
D
So
we
don't
want
names
that
are
like
full,
full,
urls
and
stuff
like
that.
Yeah.
D
Yeah,
what
what
I
mean?
Maybe
you
could
have
it
again.
This
is
where
it's
like.
Well,
maybe
there
are
like
exception
types
that
would
make
a
better
a
better
index,
but
I
don't
know.
B
D
Like
like,
every
language
tends
to
have
exception
types
you
know,
and
so
maybe
that's
better
than
just
exception,
but
but
you
don't
want
you
wouldn't
want
to
put
like
the
the
trace
is
the
same
or
something
like
that.
D
C
Yeah
so
martin,
I
saw
you
all
ping
on
slack
yesterday
that
you've
got
that
doc.
I'm
actually
oof
like
the
next
week
after
today,
so
I'm
probably
not
gonna
get
to
it
before
the
next
meeting.
C
Ram
might
do
because
he's
effective
ram
is
my
manager.
So
in
terms
of
the
hierarchy,
I
think
so
our
team
is
effectively
ramzo
manager
and
then
we've
got
the
trust.
Clayton
hector
and
myself
or
hector
doesn't
attend
the
hotel
meetings.
But
you
probably
know
crosstalk.
C
Yeah
things
were
a
little
bit.
We
had
a
new
guy
start
who's
gonna
be
joining
hotel
python.
Yet
he
started
yesterday
and
we've
got
a
an
intern
starting
next
week,
which
we're
going
to
contribute
to
hotel
for
some
snippet
stuff.
For
for
java.
I
think
that
one.
E
Okay,
no
problem,
I
guess
yeah
I
mean,
if
I
don't
know
if,
if
you
just
want
to
just
scan
through
it
and
just
say
like
something
like
glaringly
like
wrong,
I
think
one
thing
that
I'm
gonna
do
is
now
I'm
just
gonna
change
the
event
type
to
event.
Name
and
just
you
know
make
that
obvious.
Make
that
clear.
C
Yeah
I'll
see
if
I
can
harvest
out
some
of
because
I
I
look
at
our
internal
common
schema
definitions
and
they're,
not
really
very
consumable
so
I'll
see
if
I
can
harvest
out
what
some
of
our
sdks
do
in
terms
of
identifying
what
the
events
look
like,
because
I
guess
from
our
perspective
this
the
more
similar
the
less
work,
our
back
end
guys
have
to
do,
but
it
also
defines
all
the
different
types
of
events
that,
at
least
from
a
web
perspective
that
we
find
okay
yeah.
C
E
Right
sounds
good.
I
can
cover
way
over
time
so
anyway,
so
yeah
I'll
talk
to
you
later.