►
From YouTube: 2021-11-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
That's
for
sure,
well,
anyway,
good
to
see
you,
man,
yeah,
how
you
been
all
right.
It
was
very
surprising
to
see
you
on
the
call.
Last
week,
I'm
like
wait.
That's
justin
rush.
What
the
heck
does
he
do.
C
D
Let's
start
okay,
so
I
attended
the
logsig
last
week
to
get
their
comments
on.
You
know
my
write-up
on
the
semantics
on
using
log
records
for
events,
and
they
were
mostly
okay,
except
for
the
name
field
I
think
tigran
wants
to
see.
If
we
can,
I
mean,
if
they
can,
the
logs
sick
can
eliminate
the
name
field
entirely,
and
you
know
if
we
can
use
name
using
an
attribute.
D
There
is
a
ticket
where
there
is
a
discussion
on
this,
and
I
strongly
feel
that
name
should
remain
name
or
a
type,
because
all
events
are
named
or
typed.
The
name
and
type
are
kind
of
the
same.
D
But
I
wanted
to
get
your
comments
whether
this
is
something
that,
whether
it's
worth
arguing
for
or
or
it's
okay
to,
let
go
because
if,
let's
say
in
the
data
model,
let's
say
the
name
field
doesn't
exist,
we
have
to
use
attributes
to
represent
the
name
or
a
type.
D
There
are
a
couple
of
problems
I
see
you
know
one
is
that
that
when
we
define
an
api
saying,
add
event,
and
then
you
take
name
as
a
argument
and
the
attributes
list.
As
the
second
argument,
you
would
have
to
explicitly
validate
that
there
is
no
attribute
again
with
the
same
name
right.
Otherwise
it
would
conflict.
D
Second,
is
you
know
it
might
also
give
chance
if
people
don't
use
the
api,
because
apis
are
more
a
convenience.
People
are
free
to
use
the
data
model
directly.
D
You
know
they
could
use
something
else
in
place
of
name,
let's
say
type
or
something,
and
that
I
don't
know
could
cause
compatibility
issues
you
know
going
forward,
so
my
preference
is
to
keep
the
name,
but
I
wanted
to
hear
your
comments.
You
know,
based
on
your
past
experience
working
in
in
this
six,
you
know.
Is
it?
D
C
So
is,
is
the
name
is
the
name
in
the
data
model
right
now.
D
So,
in
our
case
events
is
there
a
case
for
unnamed
events.
I
I
couldn't
think
of
in.
In
all
cases
you
know
events
are
usually
typed
or
even
named
they.
They.
A
A
Can
I
say
that
again
so
so,
if
there's
some
sort
of
exception
or
error,
does
that
need
to
have
a
name?
If
I
just
want
to
log
a
stack
trace,
for
example,
I
mean
we
could,
but
it
doesn't
need
one.
D
Yeah
yeah,
but
I
thought
the
name
in
that
case
would
be
an
error
right.
It's
a
it's
an
event
of
type
error
or
an
exception.
Let's
see.
D
Well,
it's
it's
a
convenience
right.
It's
helpful
to
have
a
name
for,
especially
for
you
know,
quick
routing
purposes,
let's
let's
say
even
in
an
event
driven
system,
let's
say
kafka
or
anywhere.
You
know
the
topic
represents
the
type
of
event.
A
I
mean,
I
think,
if
you're
talking
about
trying
to
do
routing,
you're
going
to
have
to
deserialize
the
data
either
way,
so,
whether
you're
pulling
it
out
of
the
name
field
or
whether
you're
pulling
it
out
of
an
attribute
called
event,
name
or
event.
Type
feels
like
it
seems
like
the
same
amount
of
work
would
be
necessary
to
get
that
data
for
routing
purposes.
C
A
Do
you
have
an
example?
I
mean,
I
think
I
don't
think
anyone
is
saying
we
couldn't
do
like.
I
think
that
what
the
log,
what
tigran
and
log
sig
are
saying
is
why
can't
we
just
have
an
attribute
called
event.type
rather
than
using
the
name
field
for
that.
So
I
think
what
we,
if
we
think
that
the
name
field
is
really
important.
We
need
to
come
up
with
an
example
where
we
really
need
the
name
field
in
order
to
do
this,
and
it
wouldn't
work
to
use
an
attribute.
D
Actually
I
wrote
when
I
I
searched
on
the
web
for
how
the
other
event
apis
are
designed.
D
C
A
Remember
to
remember
we
can
we
can
design
an
api
for
rum
events
that
is
independent
of
what
the
data
model
looks
like
right,
because
we
can
have
an
api
that
has
a
name
or
an
event
type
or
whatever.
We
want
to
call
it.
That
then
just
ends
up
being
mapping
into
an
attribute
with
you
know,
semantically
defined
name.
D
Yeah
and
the
like,
I
said
the
two
concerns
with
the
api
you
know.
One
is
that
you
need
extra
checks
to
make
sure
that
again
there
is
no
attribute
with
the
same
name
passed
in
in
the
attributes
parameter
and
secondly,
how
do
you,
even
though
there
are
70
conventions
on
what
is
the
attribute
name
for
for
that
name
field?
D
Maybe
it's
not
a
big
concern,
but
would
people
still
use
the
data
model
directly
and
would
that
have
compatibility
issues
going
forward?
Should
we
ignore
that?
Because
it's
not
the
right
way
anyway,.
A
A
If
it
happens,
it
happens
speaking
just
on
android,
for
example,
in
android
and
java,
we're
not
planning
on
creating
a
logging
api
for
open
telemetry.
We're
planning
on
just
you
know,
piggybacking
on
the
dozens
of
logging
apis
that
already
exist
in
the
java
ecosystem
and
then
just
having
an
appender
that
maps
to
otlp.
So
I
don't
think
people
will
be
using
like
if
you're
doing,
android
development
you're
going
to
use
the
built-in
logging
apis
you're,
not
going
to
you,
know,
bring
in
another
logging
api.
A
What
we
want
people
to
bring
in
is
the
rum
apis,
so
I
don't
think
we
need
to
necessarily
worry
in
the
android
case.
I
can't
speak
necessarily
for
ios
or
java
or
any
of
the
other
platforms,
but
I
think
in
that
case
we
want
to
have
an
opinion
that
says
use
the
rom
api.
If
you
want
to
do
logging
do
logging
and
it
can
be
mapped
into
otlp
if
you
need
to,
but
I
think
that'll
be.
I
think
that
will
be
fairly
rare,
that
people
actually
want
to
send
their
android
logs
to
otlb.
D
So
so
logs
and
events
from
a
hotel
developer
point
of
view,
they
are
separate
right.
D
So
I
I
didn't
fully
follow
what
you
mentioned
about
in
the
android
case.
So
let's
say:
if
the
android
app
wants
to
send
logs,
it
would
use
the
logging
api.
If
it
wants
to
send
events,
then
it
would
use
the
events
api
that
we
would
develop
right,
but
would
there
be
a
situation
where
somebody
would
use
the
data
model
directly?
You
know
to
use
to
build
their
own
apis
to
send
data
for
events
using
the
logs
data
model,
and
would
that
be
a
concern?
A
F
A
Like
if
people
do
that,
they're
on
their
own,
which
is
fine,
you
know
it's
open
telemetry,
it's
not
like.
We
tell
you
exactly
what
to
do
telemetry,
but
we
we
should
definitely
aim
to
provide
a
convenience
api
to
make
it
like
help
them
use
the
semantic
conventions
that
that
we
define
and
make
it
really
easy
for
them
to
for
people
to
write,
instrumentation
or
add
custom
events.
But
if
people
want
to
go
off
on
their
own,
that's
fine,
but
I
don't
think
we
need
to.
A
D
The
reason
I
bring
this
up
is,
I
was
initially
confused
and
there
were.
I
know,
few
more
people
that
in
my
organization
that
were
confused
where
they
were,
we
were
looking
only
at
the
protobuf
definition
and
thinking
that
hey,
you
know,
let's
say
an
attribute
value
can
be
any
type
right
and
whereas
we
later
learned
that
hey,
that
is
not
the
right
place
to
look
at,
you
should
be
looking
at
the
spec
or
the
apis.
D
So
that's
why
I'm
bringing
it
up
but
yeah,
I
see
a
point
then
then
the
only
other
concern
is
that
we
would,
which
is
which
is
possible
to
mitigate,
is
to.
If
somebody
passes
in
an
attribute
with
the
same
key
as
the
name,
then
we
need
some
extra
validation
in
the
api
implementation
in
the
sdk.
A
D
Okay,
okay,
now
especially
name
is
common.
If
you
are
even
a
type,
let's
say
I'm
adding
on
you
know,
items
right,
you
know,
and
then
it's
possible
that
there
could
be
one
of
the
attributes
is
the
type
actually
it
is.
I
don't
think
it's
a
rare
case,
so
it
will
be
good
to
add
a.
D
So
basically
make
the
attribute
like
uncommon.
A
D
Okay,
so
your
recommendation
is
that
we
don't
need
to
go
strong
on
keeping
the
name
field
as
long
as
the
api
you
know
can
support
it.
A
Yeah
I
mean,
I
think
this
is
one
of
those
cases
where,
if
the
logging
say
and
wants
to
remove
it
from
the
data
model,
because
they
think
it's
not
generally
useful,
and
we
can't
come
up
with
a
very
like
super
compelling
case
where
it
is
mandatory,
I
I
think
they
they
should
drive
that
and
we
should
be
able
to
work
around
it
without
it.
D
Yeah,
actually
the
term
compelling
is,
is
relative
right
to
me.
It
feels
like
you
know,
we
are
forced
to
use
this
data
model
because
you
know
we
don't
want
to
introduce
a
new
signal
and
and
therefore
we
have
to
we
have
to
fit.
D
You
know
requirements
into
what's
with
with
what's
available
right,
so,
but
otherwise,
if
we
had
a
free
hand,
then
you
know
I
I
would
prefer
you
know,
keeping
the
name
outside
or
type
outside
that.
I
think
I
I
guess
everybody
agrees
that.
C
I
had
a
related
question
to
this,
which
is
then
the
name,
the
values
of
the
name.
Should
they
come
from
a
pretty
final
list
of
values
or
is
a
free
form.
A
So
we
should
define
common
set
of
events,
but
I
think
we
absolutely
want
users
to
manually
instrument
their
applications
with
custom
business
events
right.
So
I
think
we
would
want
to
define
here
like
the
four
I
don't
know,
whatever
number
we
come
up
with
the
four
standard
ones
that
are
kind
of
built
into
the
instrumentation,
but
it
should
be
totally
free
form
for
users
to
build
business
events.
On
top
of
this,
I
think.
C
Yeah,
I
think
that
makes
sense
so
like
for,
for
things
like,
I
said
I
added
some
some
additional
examples
of
browser
events
in
in
that
plan
document.
C
So,
there's
like
like
browser,
has
a
lot
of
like
timing.
Types
of
events
like
like
the
window
load,
damn
content
loaded
time
to
first
bite.
Things
like
that.
C
So
would
we
have
kind
of
a
proposed
template
for
these
types
of
events
that.
C
C
It
I
mean
it
depends,
I
mean
if
you
they
should.
I
think
there
should
be
also
metrics
but
like
if
you,
if
you're,
trying
to
replay
a
session,
then
it
would
be
an
event.
A
But
the
event
would
be,
for
example,
screen
became
visible,
I
don't
know
I'm
making
stuff
up.
I
have
no
idea
how
browser
works.
The
event
is
not
the
timing.
The
event
is
the
event
that
happened
right
and
then
there
should
be
a
metric,
that's
associated
with
it.
That
has
the
timing
information.
I
would,
I
would
think,
maybe.
C
Well,
I
guess
I
guess
what
I
I
I
guess.
I
see
that
as
two
different
use.
Cases
like
the
metric
is
for
like
seeing
I'm
just
going
to
take
like
a
simple
example
like
the
you
want
to
know
like
how
fast
the
web
page
loads.
So
you
want
to
you
want
to
know
the
metric
across.
C
You
know
all
the
page
views
but
then
like
when
you,
if
you
track
similar
to
like
traces
like
if
you,
if
you
have
a
sampled
session,
that
you
want
to
see
like
when
all
when
all
these
events
happened
in
the
specific
session,
then
you
would
need
you
would
need
a
log
that
also
has,
like
the
you
know,
like
the
other
duration,
the
time,
the
time
stamp,
that
it
happened
right.
B
D
Talking
about
these,
if
they
see
my
screen
yeah,
these
are
one
of
them
is
some
of
those.
Yes,
okay.
They
are
currently
being
sent
as
events
in
the
current.
C
Yeah
events
on
the
on
the
span
yeah.
A
C
Yeah
I
mean
so
like
here
here
you
you
need
to
like.
I
don't
know
if
this
is
the
right
implementation,
because,
like
these
are
events
on
a
span
that
represents
what
like
represents
the
you
know.
The
span
goes
to
a
certain
point
in
time,
but
some
of
these
events-
some
of
these
timing
events,
could
happen.
You
know
beyond
the
the
end
of
that
span,
so
I
think.
C
B
C
Yeah,
so
maybe
I'm
getting
like
too
much
details
here
I
mean
there
are
some.
There
are
some
events
that,
like
some
some
of
these
events
that
happen
that
are
taken
from
the
navigation
timing,
api,
which
apply
to
both
the
page
view
and
xhr,
and
but
then
there
are
some
events,
some
similar
events
like
the
paint
events
or
largest
contentful
paint,
which
are
not
part
of
that
navigation
timing,
and
they
could
they
may
happen
sometime
after
this.
This
span
finishes.
B
Yeah
there
are
a
bunch
of
timing,
metrics
that
you
cannot.
You
don't
know
why
there's
no
spend
to
put
them
under
right
exactly
and
some
of
them
don't
have
a
duration.
Even
okay,.
F
Sorry
just
wanted
to
doesn't
that
feel.
Like
a
metric,
though
I
mean
the
cls
kind
of
metrics
that
do
come
in
much
after
a
document
is
loaded
that
just
feels
like
a
metric.
D
B
D
Yeah
on
the
topic
of
metrics
versus
events,
a
couple
of
things
I
think
events
can
capture
more
information.
You
know
like,
for
example,
these
objects.
Now
you
could
add
more
things
tomorrow
if
needed,
more
key
value
pairs
and,
secondly,
I
think,
to
be
precise,
these
will
be.
You
know,
individual
data
points
right
that
will
have
to
be
aggregated
into
a
metric
on
the
back
end.
D
So
that
also
leads
to
confusion,
because
I
think,
if
you
use
the
right
terminology,
this
would
be
measurement
objects
that
would
then
be
aggregated
into
a
metric
reading
the
documentation,
that's
what
I
understood.
D
B
A
good
point
because,
for
example,
web
vitals,
you
do
have
an
extra
you
have
like
the
duration
or
the
for
some
of
them
for
some
of
them
you
have
just
the
score,
but
you
do
have
extra
information
like
for
largest
content
for
paint.
You
have
like
what
was
the
paint
actually
like
the
image
or
in
info
about
that,
so
I'm
not
familiar
with
the
metric
specs.
So
I'm
not
sure
if
you
could
add
that
info
to
the
metric,
probably
not
so
event
makes
more
sense.
A
A
I
don't
think
we've
written
that
down
as
a
requirement
for
any
of
our
instrumentation
at
this
point,
and
if
it
is
something
that's
important,
we
should
absolutely
capture
it
and
it
sounds
like
that's
going
to
potentially
be
quite
complex,
but
that
does
sound
like
something
we
need
to
make
sure
we
write
down
and
don't
miss
because
it
wasn't
something
I
had
heard
before.
C
C
So
I
think
at
least
my
understanding
of
that
discussion
was
that
there
was
this
other
concept,
like
kind
of
similar
concept
to
traces
but
kind
of
more
kind
of
higher
level,
which
kind
of
includes
like
lots
of
traces,
lots
of
metrics
or
and
logs
like
this
concept
of
a
session
and
then
sessions
from
the
client,
you
know
they
could
be,
they
could
be
sampled
similar
to
traces
or
they
could
be.
C
We
could
just
send
everything
every
time
and
then
just
have
the
back
end
aggregated,
like
the
proposal
from
aws
was
like
sent
everything
right
sentence
and
everything
as
events
and
then
the
back
end
aggregates
stuff,
whereas,
like
I
think
kind
of
the
direction
that
I
thought
you
were
going
with.
This
was
that
you
know
we
want
to
capture
metrics
separately
for
sure
to
get
aggregated
data,
but
also
you
still
want
to
capture
things
about
the
session
in
a
sampled
manner
like
if
you
wanted
to
understand,
like
what
happened
in
a
session.
A
Obviously,
my
http
server
is
going
to
get
lots
and
lots
and
lots
of
requests
and
I'll
get.
I
have
statistics
and
I
can
do
various
kinds
of
aggregations
on
that
or
even
if
you're
talking
about
gauges
and
you're
talking
about
things
like
your
current
memory
that
you
use
your
process
is
using.
A
These
are
things
that
you
want
to
report
from
the
same
process
over
and
over
and
over
again,
when
we're
talking
about
these
metrics,
like
the
you
know,
largest
contentful
paint
or
whatever
again,
I'm
probably
using
the
wrong
words,
that's
going
to
be
reported
once
per
session.
A
B
Most
of
them
are
reported
like
once,
but
for
example,
largest
content
for
paint
changes
until
some
point,
because
there
can
be
a
larger
paint
and
but
you
know
you
can
gather
a
client
side
that
send
it.
But
in
client
side
you
usually
want
to
send
everything
you
have
as
fast
as
you
can,
because
it's
not
reliable
that
the
client
won't
die
or
or
something
will
fail
or
the
user
navigates
away
or
you
will
lose
your
wi-fi
or
whatever.
A
But
it,
but
I
don't
think
it
makes
sense
to
think
about
even
the
lcp
as
something
that's
client-side,
aggregated
over
a
long
period
of
time.
Right
you
probably
get
three
or
four
numbers
right.
You
don't
get
thousands
of
numbers
that
are
getting
aggregated
over
hours,
so
it
just
feels
different
than
open,
telemetry.
Metrics
to
me,
which
is,
I
don't
know
where,
to
put
them,
I
mean.
A
Yeah
no,
I
agree.
I
agree
it's
interesting
though
it
does
feel
like
this
is
something
that
maybe
maybe
we
should.
We
should
really
talk
to
the
spec
folks,
the
spec
sig,
about
this
particular
use
case,
which
definitely
feels
unique
to
client
instrumentation,
because
it's
not
generally
something
that's
aggregated
over
over
minutes.
A
A
I
mean
maybe
this
points
to
some
metrics
that
have
a
different
kind
of
aggregation.
That's
capture
all
the
data
and
send
it,
but
also
we
think
about
when
we
think
about
metrics
and
open
telemetry.
We're
working
super
super
hard
to
make
sure
that
they're
low
cardinality
in
the
attributes
and
the
things
we're
talking
about
here,
especially
if
the
session
id
is
associated
with
these
metrics.
That
is
absolutely
not
low
cardinality
from
the
back
ends
perspective,
that's
as
high
cardinality
as
possible,
so
it
doesn't
make
sense
from
that
perspective
to
shoehorn
these
numbers
into
metrics,
either.
C
A
F
A
Yeah,
so
in
this
this
this
case
of
using
logs
or
whatever
spans,
whether
those
span
events
or
logs
to
represent
timing
numbers
with
extremely
high
cardinality,
is
not
a
use
case
that
I've
heard
discussed
in
open
telemetry
and
that's
back
very
much
at
all.
If
at
all,.
A
B
A
B
A
F
Just
thinking
out
loud
here
I
mean
we
don't
have
to
wouldn't
the
session
id
sort
of
be
like
an
exemplar
in
the
metrics
api.
Somehow
I
mean
we
don't
actually
need
the
aggregate.
F
D
Actually,
john,
if
we
look
at
how
these
would
be
processed
on
the
back
end,
there
are
a
couple
of
ways
right.
I
think
if
let's
say
you
send
individual
metric
objects
for
each
end
user
for
each
client,
then
the
session
id
would
be
one
of
the
attributes.
So
once
you
aggregate
you
throw
away
the
original
data,
so
in
the
store
you
don't
have
high
cardinality
metric
anymore.
D
You
know,
but
if
let's
say
you
want
to
retain
these
individual
data
points,
then
I
agree
that
you
know
keeping
them
in
the
metric
store
might
result
in
high
cardinality
metrics,
but
if,
if
they
were
to
remain
as
events
then
for
for
events
you
know-
maybe
it's
it's.
Okay.
The
high
cardinality
is
okay.
A
D
D
C
C
So
so
I
think
we
yeah
just
just
like
a
circle
around,
so
I
think
we
want
to
bring
this
to
the
spec
sig
and
get
some
some
feedback
on
what
they
think
the
right
direction
should
be
martin,
like
do
you
want
to
collaborate
on
this
like
on
how.
D
B
I
guess
so:
okay,
maybe
they
have
some
very
strict
opinions,
how
this
is
given.
If
not,
we
will
just
probably
use
logs.
D
Okay,
let's
move
on
to
the
next,
so
the
next
one
is
actually
with
respect
to
your
pr
martin.
I
was
thinking
that
instead
of
keeping
two
separate
files,
the
device
and
the
browser
would
it
make
sense
to
have
one
document
for
everything
client
side
and
then
define
what
this
client
side
mean.
I'll,
tell
you
another
reason
for
that:
the
the
term
device-
I
was
thinking
more
about
it.
D
It
could
be
confusing
because
the
devices
could
mean
network
devices
right,
let's
say
routers
or
you
know,
network
devices
that
you
know
the
people
would
be
monitoring
and
there
are
cases
where
the
the
networking
the
network
devices
would
be
on
the
back
end
in
the
infrastructure,
and
there
are
also
cases
where
they
are
actually.
D
In
the
let's
say,
homes
right.
Somebody
is
monitoring
the
wi-fi
access
points
in
all
the
stores
in
all
the
homes,
so
they
would
then
qualify
as
client-side
iot
devices.
D
So
there
is
potential
confusion
here
where
the
devices
might
need
be
needed
to
even
represent.
Let's
say
even
on
a
linux,
there
are
are
a
server.
You
know
there
are
devices
in
the
hardware
that
you'll
be
monitoring,
so
device
might
be
overloaded
in
that
case,
so
it
better
be
explicit
that
these
are
client
set
and
by
client
side.
You
know
we
should
clarify
that
the
client
said
in
the
back
end.
I
think
we
should
make
a
explicit
distinction.
C
Yeah,
I
agree,
I
think,
there's
probably
potential
for
conflict.
I
I
think
we
discussed
this
before
and
I
think
the
feedback
we
got
that
the
device
was
intended
for
client-side
client
devices
only.
D
D
Is
there
a
terminology
document
glossary
document
for
open,
telemetry,
john,
where
we
could
add
this
term.
A
A
And
so
there's
a
there's:
a
loss,
there's
a
glossary.md
file
in
the
in
the
specification
directory.
A
D
It
would
have
been
better
if
these
are
in
one
document,
but
maybe
it's
okay
yeah.
I
now
I
don't
have
if
it's
clarified
in
the
glossary.
Maybe
it's
okay.
A
I
mean,
if
we
put
it,
put
the
definition
in
the
glossary
and
then
link
to
that
in
the
in
the
appropriate
places
like
this
is
only
appropriate
for
client-side
telemetry,
with
the
link
over
to
the
glossary
definition.
I
think
that
would
probably
be
the
cleanest
way
to
do
it.
C
C
D
Actually,
that
kind
of
relates
to
the
next
one,
because
I
was
experimenting
with
this
javascript
sdk
and
if
you
look
at
their
resource,
you
know
they
have
an
attribute
called
service
and
where
the
value
is
unknown
service.
So,
if
you
could,
you
could
have
a
device
dot
model
yeah.
B
A
So
the
so
the
reason
why
that's
there
is,
if
you
send
the
service,
if
you
send
the
service
namespace
in
your
resource,
you,
you
are
required
to
send
a
service
name,
it's
mandatory
and
that
and
the
value
there
is
the
default
that
the
sdk
provides.
If
you
don't
provide
one,
but
I
would
argue
that
we
should
these
applications
should
never
be
sending
service
name,
it's
not
a
service.
We
should
have
this
new
app
or
whatever.
We
call
it
this
new
app
name
space
which
will
fulfill
the
same
need.
A
I
mean
we're
we're
doing
the
same
thing
at
splunk
like
we
send
service
name
for
android,
because
we
don't
have
any
other
place
to
put
that
name,
but
if
we
had
a
place
for
it,
that
would
be
good.
It
would
be
a
better
thing
to
do.
D
Actually,
even
for
the
java
apps,
not
every
app
is
a
server-side
app
right.
There
could
be.
People
could
be
monitoring
standalone,
apps
too,
where
the
service
name
may
not
be
there.
A
It's
true,
I
don't
think
I've
heard
anyone
trying
to
do
that,
except
for
I
guess,
there's
one
narrow
case,
which
is
people
are
instrumenting.
Their
maven
and
gradle
builds
there's
some
instrumentation
now
for
maven
and
gradle
and
that's
probably
not
a
service
either,
but
we
send
service
name
because
that's
the
only
place
so
it
does.
There
is
kind
of
a
piece
missing
here,
which
is
the
non
the
resource
resource
attributes
for
things
that
aren't
services.
A
D
Okay,
so
then
we
would
need
to
add
app.name
as
a
name
for
representing
all
the
client-side
apps.
We
could
raise
a
pr,
but
one
other
challenge
here
is
for
mobile
apps.
I
know
the
apps
have
a
name
you
could
query,
but
for
web
applications
browser
applications.
I
am
not
sure
there
is
any
name.
You
would
query.
You
know
the
customer
will
have
to
pass
that
in
explicitly.
B
F
Speaking
of
the
app
name
space,
I
think
there
are
a
couple
of
other
things:
don't
necessarily
fit
into
sort
of
the
service
model
as
much
like
an
example
of
this
is
the
app
like
bundle
id
it's.
F
It
doesn't
matter
one-to-one
for
web,
but
you
know
it's
sort
of
the
technical
name
of
the
app
it's
usually
in
reverse
domain,
name,
notation,
it's
something
that
developers
do
want
to
see
in
there's.
Also,
you
know
sort
of
another
construct.
That's
sort
of,
I
think
developing
is
you
know,
sort
of
app
area
ownership.
F
Just
like
you
have
service
ownership
in
the
back
end,
so
an
app
is
made
up
of
multiple
modules
right,
so
you
have,
let's
say
a
full
stack
team
that
is
responsible
for
let's
say
the
payment
part
of
your
application
right
they
own
the
screen
they
own,
the
back,
end,
etc.
So
it's
almost
like
a
module
within
your
app
today,
which
is
I'm
not
even
sure
if
it
necessarily
fits
into
the
app
construct
at
all,
it's
sort
of
like
a
next
year
definition.
It's
almost
like
saying
you
know
here.
F
Is
it's
not
an
avail
but
like
there's
an
app
and
then
there
are
sort
of
sub
modules
or
sub
services.
B
Had
customers
ask
they
want
to
do
it
even
at
the
component
level.
They
have
like
one
chart,
one
chart
two
and
they
want
to
group
those
all
of
the
telemetry
coming
out
of
those
you
could
they
could
use
a
tag
like
a
random
tag
and
put
their
own
name,
but
maybe
there
should
be
like
a
guidance
for
it
or
something
in
the
spec.
A
F
F
Yeah,
so
just
a
summary
of
what
I've
just
mentioned
right.
So
there
is
the
app
name,
there's
a
friendly,
app
thing
that
customers
typically
do
want
to
put
out
there,
but
then
there
is
also
an
additional
layer
which
is
the
technical
name
of
the
application
in
android
like
it,
you
know,
there's
a
very
clear
requirement
to
mention
this.
This
is
how
your
app
is
packaged
and
also
uploaded
to
the
apps
or
the
play
store.
F
Ios
has
the
constructor
bundle
ids?
That
should
follow
the
same
notation
I
believe
it
doesn't
have
to,
though-
and
I
mean
websites-
no
matter
what
you
do
like
there
is
going
to
be
some
domain-
that
you
could
potentially
specify
now
the
same
app
might
be
in
multiple
domains,
so
I
could
have
a
code
or
uk
I
could
have
a
dot.
F
F
The
other
area
that
I've
seen
come
up
in
conversations
is
an
app
package,
so
this
is
almost
like
saying
there
is,
you
know
com.myapp.payment.
So
that's
basically
the
internal
directory
structure
of
your
application-
and
there
is
usually
you
know
some
kind
of
team
ownership
around
those
as
well
and
then
finally
is
sort
of
the
more
ui
construct
or
the
customer
deliverable
concept
construct,
which
is
the
app
area.
F
The
reason
I
want
to
call
these
out
separately
is
because
some
of
these
are
owned
by
various
teams,
whereas
some
are
just
you
know.
Well,
it's
it's
a
third-party
library
that
you
don't
necessarily
own
or
it's
built
into
the
android
package.
Someone
will
go
and
debug
it,
but
it's
very
unclear
who
actually
owns
the
bug.
If,
let's
say
you
run
out
of.
F
So
while
app
name
has
been
discussed
in
general,
I
think
like
we
should
maybe
think
about
an
app
bundle
or
some
other
technical
name,
app
version
very
similar
to
service
version
that
we
should
also
consider
for
sure.
I'm
sure
we
can
come
up
with
more
examples
around
this.
So
I'm
happy
to
share
this
document
later
this
week
once
I
clean
it
up,
but
those
are
the
other
areas
where
I
feel
like
the
service
construct
doesn't
fit
for
client
applications,
thoughts,
comments,
feedback
would
be
very
nice.
B
D
Yeah,
I
think,
for
the
browser-
I
I
don't
know
what
you
would
put
for
app.bundle,
so
it
could
be
left
out.
C
Yeah,
thanks
for
putting
that
together,
yeah,
it
sounds
like
it
sounds
like
there
could
be
a
lot
of
different
attributes,
and
you
know
we
probably
should
have
you
know
similar
to
some
of
the
name.
Spaces
have
defined
like
the
the
attribute
names
and
kind
of
like
with
examples
and
how
they
would
be
used
like
in
different
cases,.
C
Yeah
I
mean
that
this.
This
definitely
showed
that
there's
a
lot
of
complexity
like
in
client
side,
apps
yeah,
even
like
the
difference
between
mobile
and
browser
too,
I'm
not
familiar
with
the
bumble
side.
So
I
appreciate
this.
D
Yeah,
so
I
came
to
know
that
either
a
user
agent
is
being
you
know,
deprecated
in
favor
of
client
hints.
D
So
I
and
I
later
after
I
put
that
comment.
I
saw
your
pr
martin
that
you
did
not
include
user
agent
in
your
pr,
but
you
have
the
individual
elements,
so
I
think
we
might
be
good.
So
if
so,
we
just
may
want
to
make
sure
that
going
forward,
all
those
parameters
are
variable
right.
You
know
they.
You
can
obtain
them
on
the
client
side
and
in.
D
B
I
think
google
is
the
one
who
pushes
that
and
deprecated
pretty
loose
term
here
until
like
safari
agrees
that
nothing
will
happen,
so
I
think
it
we
will
have
user
agent
for
a
long
time
yeah.
So
I
think
we
should.
D
B
They
have
to
parse
user
agents
to
get
those
so
which
is
always
done
in
the
back
and
nobody
parses
it
in
the
client
side.
Exactly
so
should
they
should
they
be
even
being
spec,
because
the
browser
doesn't
send
them.
It's
like
the
collector
or
back-end
who
adds
them
to
the
data,
so
should
they
still
be
in
the
spec?
I
guess
so,
because
the
end
results
event
or
span
will
have
them.