►
From YouTube: 2022-07-06 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
I
have
just
couple
things
that
I
wanted
to
just
briefly
touch
base
on
one
is.
A
And
I
I
was
just
wondering
like
I
think
there
are
a
bunch
of
people
who
are
concerned
about
breaking.
You
know
introducing
breakage
in
the
json
json
sterilization.
So
I
was
just
wondering
like
when
your
thoughts
about
how
hard
we
should
put
push
this.
A
Do
we?
Is
it
really
important
to
us
or
should
we,
I
guess
the
other
option
is
just
have
have
like
a
explorer
that
has
you
know
compression
on
it
and
then
end
users
can
choose
whether
to
use
it
or
not.
C
I
do
like
who's
overrun
christian's
comment
about
using
the
numeric
instead
of
the
having
short,
but
even
numeric
have
problems
below
numerical
if
you've
got
short
keys
in
some
browsers
that
get
quoted.
C
So
even
if
it's
two
characters,
it
becomes
four
characters
so
but
yeah
you
have
to
have
a
lookup
table
and
that's
part
of
the
problem
with
this
and
either
you
do
it
as
part
of
the
exporter,
which
means
you're
running
through
every
key,
transforming
it,
which
is
just
cpu
extensive
or
you
just
create
it
in
the
with
the
small
keys
which
the
proper
way
to
do
it
in
the
first
place.
So
it's
a
nice
to
have.
C
As
with
most
things
with,
you
know,
minification
there's
trade-offs,
cpu
versus
size
of
code
versus
current
sport
size.
So
it's
like.
C
C
I
don't
see
it
as
a
breaking
change,
whether
we
do
this
now
or
later,
as
long
as
you
say.
Okay,
I
know
that
my
back
end
supports
this,
so
therefore
I
can
send
it
to
it.
It's
like.
A
C
C
D
In
my
opinion,
I
think
it
does.
You
know,
help
to
some
extent,
although
it
is
still
not
solving
our
original
problem.
Correct
right,
I
think
you
know
doing
this
change
does
not
you
know,
take
away
the
need
to
have
you
know
the
ephemeral
attributes
and
the
resource
level.
D
Yeah,
I
I
personally
feel
that
you
know
if,
if
typically
compression
is
is,
is
never
considered,
is
purely
a
transport,
optimization
right,
transport
level,
optimization,
it
is
not,
you
know,
used,
you
know
as
part
of
the
you
know,
design
of
things
so
think
of
it.
As
a
you
know,
data
normalization,
you
know
it
is
very
common
to
you
know,
keep
things
like
once
and
for
place
instead
of
us
repeating
over
multiple
objects.
D
So
I
think
in
in
this
case,
I
think
you
know.
One
of
the
problems
with
you
know.
Ted's
proposal
is
that
you
know
it.
The
proposed
change
is
pretty
complex
right.
I
think.
D
It
is
actually
breaking
some
of
the
existing
semantics,
so
that
is
why
there
is
agitation
and
I
actually
suggested
one
other
alternative
where
you
know.
In
addition
to
the
you
know
resource,
you
also
pass
one
additional
key
value:
less
value,
prayers
separately.
You
know
from
the
resource
it's
going
to
be
a
sibling
to
the
resource
instead
of
modifying
the
same
resource
for
the
purpose
of
ephemeral,
attributes
of
the
resource.
You
know
you,
you
introduce
one
more,
you
know
field
in
the
protobuf.
D
That
is,
you
know,
sibling
to
the
source,
so
that
will
be,
you
know
backward
compatible
because
we
can
always
introduce
more
fields
in
protobuf.
D
Is
is
not
even
looking
at
you
know,
solving
the
addressing
the
original
problem.
I
think
they
somehow
feel
strongly
that
compression
you
know
is
the
way
to
go.
C
Yeah
and
that's
when
you
look
at
different
focuses
like
part
of
the
problem,
you
know,
an
additional
part
of
introducing
smaller
keys
is
depending
where
you
do
them
like.
I,
ideally
from
a
client,
as
I
said
when
you
set
the
attribute,
that's
when
you
want
to
set
the
key,
so
you
don't
have
to
go
and
transform.
Then
you
write
the
keys
during
sterilization.
C
The
problem,
however,
is
anything
any
instrumentation
or
any
processor
in
the
middle
now
needs
to
know
about
both
sets
of
keys
because
they
have
to
look
out
for
both
and
handle
them
in
whatever
manner
they
need
to.
So.
A
Are
you
proposing
that,
like
the
that
that
wouldn't
be
like
the
transfer
to
transform
that's
currently
happening
from
spans
to
otrp,
because
that
that
does
that
that
generates
those
that
json
right?
That
transformation.
C
C
A
C
You
know
part
of
me
thinks
yeah,
rather
than
using
the
standard
provided
stuff.
We
might
just
have
an
sdk
that
effectively
includes
everything.
You
know,
you
think
you
have
a
package
so
rather
than
say,
I
want
the
the
web
sdk.
So
therefore
I
want
the
api
and
I
want
this,
and
I
want
that.
I
want
this
and
I
want
that.
We
just
say
well:
here's
the
the
base
web
optimized
sdk
and
it
should
support
installing
whatever
instrumentation
you
want,
but
you
take
the
package
as
is
rather
than
take
the
individual
package.
C
I've
only
got
the
first
level
of
bundling
done
so
far,
so
each
individual
pro
package
in
my
local
sandbox
creates
a
bundle
and
even
the
api
bundle
is
like
14k.
So.
A
C
Yeah
because
like
it,
will
help
in
terms
of
the
the
final
size
going
out
the
door
depending
on
where
and
how
it's
done,
the
trade-off
being
we
have
these
extra
lookup
tables
that
now
need
to
exist,
that
increases
the
bundle
size
and
depending
where
it
is,
there's
some
complexity
in
terms
of.
Does
everyone
now
need
to
know
about
this
who's
handling
it
so.
C
Which
is
why
I
liked
christian's
comment
about
using
the
numeric
values,
rather
than
coming
up
with
characters,
because
at
least
the
numeric
values
most
things
that
you
know
the
product
buff
know
about
the
numeric
values.
So.
A
Okay,
we
can,
we
can
move
on.
So
I
have.
I
have
one
more
topic
and
I
just
want
to
quickly
go
back
to
to
the
semantic
dimensions
we've
been
talking
about
last
few
weeks,
and
I
just
I
just
wanna,
I'm
just
to
be
honest,
like
I'm
still
struggling
with
this
a
little
bit
like
I
we
started
talking
about,
you
know
the
spans
versus
logs
and
I'm
just
like
thinking
in
terms
of
one.
A
How
do
we
define
the
semantic
conventions
in
the
specs
and
two?
How
do
we?
You
know?
How
do
we
use
spans,
and
so
let
me
I'm
just
going
to
share
my
screen
really
quick
to
to
show
something.
A
So
I
I
have
this,
we
have.
We
have
this
poc
that
we
worked
on
a
few
months
ago,
and
I
just
I
modified
it
a
little
bit
like
so
the
show
the
span,
events
and
attributes
on
each
of
the
spans
and
logs
that
are
being
being
collected.
So
here's
a
session
that
has
that
has
that's
showing
a
timeline
of
spans
these.
These
are
spans
currently
generated
from
the
current
instrumentation.
So
there
is
people.
A
I
know
that
you're
familiar
with
this,
but
let
me
just
walk
through
it
really
quick,
so
the
way
that
it
currently
works
that
there
is
this
document
load
span
right
and
it
has
it
has
these
span,
like
the
the
the
measurements
from
the
navigation
timing
api,
which
we
discussed
last
week,
are
added
as
span
events,
so
each
each
of
those
each
of
those
measurements
is
an
individual
event
span
event,
and
then
the
span
kind
of
creates
kind
of
the
context
for
all
these
events.
A
So
they
these
these
span,
events
just
have
the
name
and
the
timestamp,
that's
all
they
have
no
attributes,
and
then
the
span
provides
the
provides.
The
context
for
all
these
spine
events,
right,
like
like
the
url
for
example,
and
the
same
the
same
thing
is-
is
happening
for
resources
for
the
resource
plans.
A
They
have
also
the
the
resource,
the
measurements
from
the
resource
timing,
api
that
are
collected
as
span
events
now
going
forward.
We
would
like
to
use
semantic
conventions
to
define
these
measurements
and
we
talked
about
using
logs
and
so
the
instrumentation,
the
prototype
instrumentation
that
we
have
generates
logs
like
this,
so
for
each
from
the
resource
timing.
A
D
Yeah
and
I
yeah
I
want
to
discuss
this-
I
I
like-
I
think
I
mentioned
briefly
to
you,
martin
earlier-
that
for
us
with
our
back-end
architecture
dynamics.
You
know
we
prefer
that
all
these
timing
data
we
present
in
the
span
itself.
D
A
D
Of
the
different
ones
yeah,
the
second
thing
is
like
within
the
span
I
you
know,
we
feel
that
you
know
they
should
not
be
individual
events,
but
assuming
that
the
nested
attributes
we
are
you
know,
goes
through.
You
know
we
prefer
that
you
know
all
those
timing
measurements.
D
You
know
they
are
collapsed
into
one.
Let's
say
you
know
one
attribute,
you
know
it
will
be
simpler.
D
C
A
A
C
The
log
entry
would
have
a
reference
to
that
to
what
what
the
current
name
is.
Yes,
yes,
still
achieve
the
same
thing,
whether
whether
it
got
sent
as
a
log
event
or
whether
it
got
included
in
as
a
span
event,
it's
based
on
the
pushback
I'm
getting
at
the
moment,
which
I
think
is
from
christian.
He
wants
me
to
define
in
the
spec
that
nested
attributes
only
exist
in
logs,
which
I
think
is
the
wrong
place.
To
put
that.
So
I'm
trying
to
think
how
I
can
reword
it.
C
All
his
reasoning
is
in
terms
of
today.
No
one
supports
it,
so
I
actually
want
to
spend
some
time
once
I
get
the
sandbox
going
going
through
all
the
individual
languages
to
see
if
I
can
spot
whether
someone's
inadvertently
supported
already
now
for
allowing
attributes
to
be
nested
because
protobuf
supports
it.
So
therefore
everyone
should
be
supporting
it.
That's
that's
my
view,
because
the
transport
does.
D
No
no,
but
that
is
not
yeah.
I
mean
that
doesn't
seem
to
be
a
valid
reason.
If
languages
don't
support
it
today,
I
think
they
might
have
to
add
it.
B
D
C
Like
even
in
microsoft,
we
don't
store
net
well,
mostly
some
of
our
citizenship.
Mostly,
we
don't
support
nested
attributes
so
from
the
protocol
perspective
that
shouldn't
matter
it
shouldn't
be
a
case
of
let's
use
the
lowest
common
denominator
for
features
yeah.
It.
C
At
the
point
of
in
ingestion
and
storing
in
the
back
end
it
which
I
put
in
the
spec,
it
should
have
a
strategy
to
do
whatever
it
needs
to
do
to
to
store
that,
including
flattening
yeah.
D
Yeah,
in
fact,
there
are
examples
where
the
nested
attributes
is
needed,
even
for
typical
spans,
where
let's
say
somebody
wants
to
record.
I
think
somebody
mentioned
this
in
one
of
the
peers
that
if
you
were
to
record
all
the
http
headers
request,
headers
or
response
headers
on
a
given
request.
You
know
you
it's
it.
They
are
better
put
in
one
attribute
as
a
nested
object.
Yeah.
C
C
So
you've
got
instrumentations
back
in
yes
yeah,
which
is
why
I
want
to
make
it
optional
now
and
then
we
can
start
pushing
down
to
the
languages
and
there
for
the
exporters
to
start
supporting
it
and
then
once
they
support
it.
We
can
then
make
it
and
say
well
as
of
version
two
of
the
spec.
It
is
it's
a
must,
but
because
the
specs
are
being
released,
it's
got
to
be
optional
today,
but
it
shouldn't
be.
I
yeah.
I
agree,
it
should
not
have
been
optional.
It
should
have
been
required.
B
D
D
So
I
think
the
question
is
martin:
do
you
strongly
feel
that
they
should
be
standalone
even
or
you
know
it's
okay
for
them
to
be?
A
Yeah,
I
can
think
of
one
reason
that
it
might
be
good
to
have
them
as
separate,
which
is
that
the
span
the
span
may
never
end
it's.
A
You
know
like,
for
example,
like
if
the,
if,
if
you
rely
on
the
document
load
event,
and
then
it
do
sorry,
the
window
load
event,
but
it's
it
does
not
it
never
fires,
then
the
spam
doesn't
get
collected,
but
you
could
still
collect
some
information
from
the
navigation
timing.
Api
as
an
event
yeah.
C
Probably
the
other
reason
is
if
these
are,
if
all
these
events
were
in
the
span,
events
and
the
javascript
happened
to
work.
So
we
say:
okay,
we
have
a
document
load,
we
have
the
span,
it's
all
living
there
and
we
have
like
in
this
case
we
have
like
a
lot
of
resources
and
then,
as
soon
as
the
javascript
runs,
it
does
a
cloud
side
redirect
as
soon
as
you
get
into
that
situation.
F
D
I
I
think
I
think
I
think
that's
those
are
fair
reasons,
but
consider
you
know
the
fetch.
Are
the
xhr
requests
right?
So
for
those
you
know
these
these
reasons
you
know,
don't
apply
right,
they
will
definitely
you
know
end
and,
and-
and
you
know
the
the
good
thing
is
you
know
there
is
an
ask
to
include
similar
timing
information
for
the
you
know.
Http
api
calls
that
occur
in
the
back
end.
You
know
what
microservice
calling
another
microservice.
C
C
While
the
span
will
end
the
resource
timing,
values
actually
don't
exist
in
the
resources
loop
for
until
a
small
period
afterwards.
So
if
you
have
the
the
fetch
and
you
create
the
span,
you
end
the
span.
Well,
since
you
end
the
span
you
because
you've
got
the
response,
you
can't
add
anything
to
it,
which
is
the
only
time
you
want
to
end
the
span.
But
if
again,
you
do
a
client-side
redirect
you're
not
going
to
get
your
resource
timings
anyway.
So
like
in
app
insights
I
had
to.
C
I
have
a
loop
that
I
have
to
wait
for
the
resource
timings
to
exist
before
I
can
effectively
fire
the
what
we
call
a
track
event
with
the
ajax,
so
it
won't
always
be
there
and
you
won't
always
get
it
so
just
clarifying
that.
F
So,
are
you
referring
to
the
the
performance
performance
in
the
resource.
C
A
Then
there's
a,
but
there
is
one
more
thing
that
I
that
has
been
on
my
mind
related
this,
which
is,
which
is
the
classification
of
these
spans
and
events
like
if
we.
A
So
like,
if
we
so,
I
think,
which
is,
is
it
what
you're
suggesting
is
that
santosh
is
that
if
you
use
spans-
and
we
we
put-
we
include
the
events
as
span
events,
then
they
would
follow
the
same
semantic
conventions
like
they
would
have
also
the
event
that
name
and
even
that
domain
on
them.
D
No,
no,
I
think
you
know,
I
think,
all
all
I
meant
there
was
that
if
the
timing
information
is
present
in
the
spam,
then
there
could
be
a
consistency
with
the
way
how
we
do
things
both
on
the
you
know,
browser
mobile
on
the
run
side,
as
well
as,
on
the
back
end
side,.
A
Yeah
yeah,
so
so
the
reason
I'm
I'm
bringing
this
up
is
because
we've
been
going
like
we
obviously
we're
going
in
the
direction
of
of
requiring
the
event
name,
even
and
in
a
domain
to
classify
events.
And
if
we
so
they're.
Like
the
background.
D
A
Right,
yeah,
no,
but
what
I
was
going
to
say
is
that
the
back
ends
processing
like
the
the
client-side
data.
They
one
way
they
would
be
identifying
events
this
way,
but
they
then
now
we
will
have
to
define
how
how
they
will
be
identifying
spans
so
from
from
semantic
conventions,
perspective
like
how.
How
would
they
we
would
need
to
define
ways
to
identify
the
span
as
the
document
load
or
like
the
navigation.
D
D
D
Yeah
sure
so,
if
we
standardize
that
attribute,
then
that
could
serve
to
as
a
way
to
identify.
You
know
these
fans.
A
C
And
then
you
you'd
still
have
an
overarching.
Well,
you
still
may
have
an
overarching
span
that
groups
them,
but
the
document
load
content
is
an
event.
A
Yeah,
that's
that's
what
I
think
is
it
the
same
as
what
I
have
here,
which
is
I
have
this.
I
have
navigation
event
here,
yeah.
C
D
Yeah
so
today
the
way
it's
implemented
is
there
are
three
types
of
spans
document
load
is
the
parent
spam
and
it
has
two
child
spans.
One
is
a
resource
fetch.
Another
is
a
document
document
stretch,
so
there
are
three
spans.
So
are
you
suggesting
that
all
three
be
converted
to
events
or
just
the
first
one.
D
But
my
understanding
is
the
document
load
is
the
parent.
The
document
fetch
should
be
its
child,
but
I
I'll
go
back
and
confirm.
C
Yeah
so
effectively,
because
it
really
is
just
events
from
events,
then
my
view
is
yes,
they
should
all
be
events,
but
I'm
not
saying
that's
the
only
way
that
it
can
or
should
be
done,
like
we
had
this
discussion
yesterday
in
that
today
we
have
some
instrumentations
that
use
spans,
because
that's
the
only
option
that
existed.
C
What
I
would
like
to
see
is
part
of
the
client
as
we're
defining
events.
These
are
the
events
that
go
and
they
would
include
the
document,
fetch
document
load
and
all
the
resource
stuff.
To
say
this
is
what
an
event
looks
like
to
describe
this
thing
that
does
not
preclude
a
particular
application
or
cloud
provider.
Saying:
okay,
well,
they're
all
the
standard
defined
events,
but
we're
a
legacy.
C
So
we're
still
going
to
use
this
old
instrumentation
and
all
that
would
mean
is:
if
application
provider
x
wanted
to
move
from
cloud
provider
y
to
z.
They
would
just
have
to
change
the
instrumentation
that
they
use
or
as
part
of
the
sdk
that
they
were
given
by
the
provider.
It
would
just
use
a
different
instrumentation,
so
I
I
don't
think
we're
saying
you.
This
is
the
way
just
like
this
is
the
only
way
that
you
can
do
it.
I
think
we're
saying
moving
forward.
A
Yeah,
I'm
just
gonna.
Have
I've
been
thinking
about
it
too?
It's
like
we
don't
we
don't
need
to.
We
don't
need
to
like
prescribe
like
how
how
the
instrumentation
is
gonna.
Do
it.
A
But
it
does,
but
it
does
relate
to
defining
semantic
conventions,
and
it's
like
when
I'm
when
I'm
thinking
about
like
proposing
semantic
conventions
for
a
certain
type
of
event.
So
I
am
thinking
the
options
that
we
have
is
is
like.
A
If
you
wanted
to
keep
it
the
way
we
have
it
currently,
where,
like
each
of
these
measurements,
is
an
individual
event,
then
it
would
be
some
kind
of
timing
event
and
it
would
have
a
like
name
and
and
value
as
opposed
to
like,
if,
if
you
define
it
as
a
like
one,
big
navigation
event,
then
it's
gonna
have
you
know
a
bunch
of
different
attributes
that
are
that
that
come
from
the
navigation
timing,
api.
C
C
Otherwise,
you
know
we
end
up
going
okay,
instead
of
like
for
this
particular
case.
Instead
of
defining
one
navigation
event,
declaration
we're
saying
well,
this
particular
one
has
what
six
seven
we're
saying:
there's
seven
different
navigation
events-
and
I
don't
know-
that's
just
way
too
much
documentation
and
way
too
much
overhead,
especially
considering
the
instrumentation
that
implements
it,
would
have
to
effectively
read
the
one
entry
and
then
go
and
create
multiple
edits.
It
doesn't
need
to
do
that.
E
So
I
have
a
question
here
so
if
we
are
using
events
for
the
document
load
in
the
resource
and
everything,
and
is
there
a
way
to
associate
the
events
like
if
there
are
separate
events?
How
do
we
know
that
that
resource
is
that
resource
event
is
released
to
the
document
load
event?
Yeah.
A
So
I
think
you
know
I
I
talked
to
ted
about
this
a
little
bit
and
just
to
get
his
perspective
and
what
he
was
saying
that
he
thinks
of
you
know
thinks
of
spans
as
context
at
the
dynamic
context.
A
Yeah,
so
if
you
have
multiple
things
that
like
kind
of
relate
to
the
same
thing,
you
can
link
them
to
the
span
and
the
other
thing
that
he
was
saying
is
that,
if
that
it's
obviously
spans
are
used
for
analyzing
attribution
so
like
in
certain
you
know-
and
there
are
definitely
use
cases
like
in
with
like,
for
example,
page
the
page
load
where
you
wanna,
you
wanna,
look
at
that
as
a
trace,
and
you
wanna,
you
know,
say
like.
A
Why
is
this
load
taking
a
long
time
and
it's
you
know,
you
can
clearly
like
in
the
in
the
graph
of
spans,
see
like
that
this
resource
is
taking
a
long
time
as
a
child
span.
So
that
is
there's
there's.
There
are
use
cases
for
like
for
using
spams
for
sure,
but
I
think
I
think,
having
the
events
like
that.
Come
from
the
browser
apis
as
a
separate
events.
A
You
know
they
can
still
be
linked
to
the
spans
as
the
context
in
the
graph,
but
they
they
can
also
be
standalone
in
that
like
it
may
be
like
you.
If
you
don't
include
that
instrumentation
that
generates
spans,
then
you
still
get
that
event.
That
gives
you
some
basic
timing.
Timing,
data.
E
A
D
I
think
if
we
are
still
talking
about
for
the
document
load,
you
know
not
being
able
you
know
not.
I
think
it
will
only
address
the
fact
that
you
know
it
will
only
address
the
sizing
constraints
right,
but
it
will
not
address
that
the
that
the
unload
event
you
know,
never
finishes
so
so
having
the
spam.
I
don't
know
if
it's
going
to
be
feasible.
For
that
reason,.
D
One
alternate
could
be:
one
alternate
could
be
that
if
there
are,
if
there
is
a
possibility
of,
I
think
this
this
should
we
should
do
a
you
know,
poc
and
do
some
calculations
to
see
if
they
say
there
are
500
resources
in
one
document
you
know
what
is
the
maximum
size?
You
know
it
could,
you
know
take
up
and
if
it's
going
to
you
know,
go
beyond
the
64k
limit,
then
you
know
one
option
you
know
to
still
use
fans
is
to
to
create.
D
C
D
I
think
the
events
thing
using
definitely
should
go
away.
I
think
it's
I
feel
it's
like
that
itself
is
an
inefficient
representation.
A
C
D
C
C
Yeah
500
resources
is
a
bit
excessive,
but
there
are
some.
There
was
one
customer
site.
I
was
looking
at
the
other
day.
It
took
the
browser.
I'd
know
three
minutes
to
load
because
of
all
the
resources,
because
it
was
like
installing
a
web
worker
and
a
whole
bunch
of
stuff
for
the
first
hit
after
after
plt
zero
was
fine
but
yeah.
There's
going
to
be
cases.
A
Yeah
yeah,
I
kind
of
I
kind
of
feel.
Like
the
I
mean,
I
don't
know
how
you
why?
How
are
you
thinking
about
this?
But
I
I
kind
of
feel
like
the
events,
are
more
important
yeah
because
you
know
like
if
you
lose
the
spans.
Like
you
know,
you.
A
C
C
Damn
I
hate
that
not
profiling,
there's
a
seat
on
thursdays.
A
Okay,
so
so
now
now
the
next.
The
next
thing
I
was
going
to
ask
but
for
opinion
sometimes
I
can
propose
something
like
how
would
we
define
this
in
the
spec
here,
so
I
think
we're
gonna
need
to
add
some
some
structure
for
domains,
so
maybe,
under
semantic
conventions
like
we
would
have
like
a
browser
domain,
mobile
domain
folder
and
define
semantic
conventions
underneath
that.
C
Yeah,
I
I
think
that
there's
going
to
be
multiple
subsets,
so
I
think
there's
going
to
be
a
common
set
of
events
and
then
we'll
have
browser-specific
events
like
the
navigation
stuff
that
you're
looking
at
there's
probably
going
to
be
some
mobile,
maybe
even
android
aos
specific
events-
I
know
stefan
do
we
have
the
mobile
guys.
G
C
C
Yeah,
I
I
look
at
the
combination
of
domain
and
name
as
the
uniqueness,
so
I
I
don't
really
care
a
great
deal
beyond.
I
think
santosh
in
the
the
way
he's
defined
the
api
effectively.
The
domain
is
linked
to
the
event
emitter,
so
it
would
probably
be
more
advantageous
to
have
a
single
domain
and
they're
all
shared
in
that
same
domain,
so
you
don't
have
to
get
different
event.
Emitters
for
the
different
types
of
events.
D
C
Martin,
do
you
want
to
try
to
stop
sharing
your
screen?
Is
that
that
helps
santosh's
network.
D
C
My
only
view
is
because
we
are
going
to
have
a
common
set
of
events.
I
don't
want
to
have
to
define
the
same
event
in
multiple
places.
That's
that's
really
all
on
and
unless
we
just
say
this
is
the
common
set
and
you
have
to
include
it
in
this
domain
or
this
domain.
That
would
work
too.
D
C
Like
a
page
load
event,
which
is
probably
akin
to
a
document
load
event,
you're
gonna
have
like
I,
I
loaded
this
page
and
that's
going
to
be
the
same
basic
idea,
whether
it's
on
a
browser
or
a
mobile
device,
or
you
know
a
spa
app
or
something.
So
there
will
be
a
set
of
events
that
are
common.
B
C
John,
I
think
john
watson
put
it
together.
It
was
roughly
a
couple
weeks
ago,
martin,
they
looked
that
list
of
events
and
there
was
a
common
set
just
by
looking
at
them.
We
just
haven't
gone
through
and
defined
them
all.
D
There
will
definitely
be
common
events
for
sure,
but
I
think
the
I
think
we
should
go
back
to
why
the
concept
of
domain
was
introduced.
I
think
it
was
only
for
the
purpose
of
avoiding
conflict.
So
let's
say
document
load
is
the
name
of
an
event
and
let's
say
somebody
in
a
completely
new
domain
completely
in
a
new
field.
You
know
they
also
can
possibly
come
up
with
the
same
event
name,
which
makes
sense
to
their
domain,
but
is
completely
independent.
D
So
so
it's
just
to
avoid
another
situation,
but
it
doesn't
mean
that
you
know
two
events
in
different
domains.
You
know
are
always
you
know
different.
They
they
can
mean
the
same.
C
Yeah,
because
I'm
thinking
from
a
from
a
cloud
provider
perspective
when
you're
going
to
visualize
that
so
from
our
providers
perspective,
the
domain
is
like
the
domain,
like
their
document
load,
event's,
always
going
to
be
the
same,
because
their
app
always
looks
like
this,
but
from
a
provider
perspective
when
they're
trying
to
create
a
view
of
that
if
they
that
they're
going
to
want
to
coalesce
okay,
this
thing
represents
a
page
view
and
therefore,
regardless
of
whether
the
app
is
a
mobile,
app
or
an
ios,
app
or
whatever
app,
this
is
how
they
should
do
it.
C
So
it's
really
case
of
that's
where
I
was
thinking
it
would
be
the
common
domain,
so
at
least
from
a
visualization
perspective
of
the
back
end.
So
from
microsoft's
perspective,
this
would
be
the
app
map
in
the
azure
portal,
and
I'm
sure
you
guys
have
your
own
views
of
that
as
well,
where
you
sort
of
link
them
all
together
and
rather
than
having
to
say
this
is
the
app
and
that
for
a
mobile
app.
This
is
the
app
map.
For
you
know,
domain
x,
domain
y
domain
z.
C
G
But
just
one
question:
that
would
also
mean
we
are
allowed
to
have
the
main
specific
attribute,
so
a
browser
would
add
other
attributes
to
an
event
compared
to
a
mobile
application,
because
the
user
agent
streaming.
G
D
A
C
C
C
C
Yeah
I
don't
know
name
is
probably
nicer,
but
that
would
be
an
alternative.
We
can
make
it
optional.
C
A
C
Yeah,
probably
if
we
can
get
that
and
stuff,
and
if
we
get
probably
someone
from
the
ios
and
android
to
look
at
that
and
or
maybe
come
up
with
your
own
version
of
the
same
type
of
thing
and
we
can,
we
can
look
to
see
what
or
if
there
is
any
anything
that
could
be
given
the
same
name.
C
A
Sounds
good
anything
else.