►
From YouTube: 2022-10-25 meeting
Description
Instrumentation: Messaging
C
C
Okay,
so
I
think
it's
been
a
it's
probably
been
a
week
since
we
discussed
the
schema
and
stuff
I
went
through
the
schema
docs
and
took
some
notes
on.
You
know
work
that
we
still
needed
here,
I
think
when
Santosh
joins.
We
can
probably
start
talking
about
concrete's
next
steps
for
the
wrong
Skinner.
C
Some
of
the
things
have
been
done.
You
know
we
want
to
start
looking
at
implementation
and
start
talking
about
how
we
can
get
get
going.
C
So
we
should
talk
about
this
and
then
we've
been
carrying
over
some
of
these
agenda
items
from
previous
weeks.
I
threw
them
back
here.
I
went
through
this
spreadsheet
and
the
dock
and
I
noted
a
few
discrepancies.
C
You
know
Mystic
fields
and
and
stuff,
depending
on
where
people
want
to
start
between.
They
start
with
this
first
agenda
item
or
go
through
these
little
ones,
and
you
know
get
them
out
of
the
way.
Thoughts.
C
All
right
do
you
wanna,
do
you
want
to
get
started
sometimes.
D
I
think
last
time
we
spoke
briefly
about
it.
Right
I
think
we
said
there
are.
The
next
step
is
to
I
mean
basically
make
progress
on
those
spec
items
that
we
are
blocked
on.
D
And
the
two
items
that
were
identified
were
support
for
nested
attributes
and
then
the
support
for
the
ephemeral
resource
attributes.
Okay,.
C
So
I
think
these
are
the
two
things
who
is
kind
of
driver
from
our
side.
You
know
participate
in
respective
I.
B
Since
March,
but
now
we
have
both
Ted
and
tigran
who've
got
a
new
proposal
which
opens
the
door
up
again
and
yeah
we're
gonna
follow
through
with
that
one,
but
based
on
that's
based
on
the
issue
376,
which
has
been
open
for
like
two
years,
so
we
will
see
how
we
go,
at
least
from
a
logs
perspective.
We
have
Nestor,
which
that's
not
an
issue.
B
The
the
issue
that's
been
raised
is
more
about
getting
nested
attribute
supported
across
the
board,
so
that
would
be
how
which
I
guess
is
one
of
the
next
steps?
How
do
we
map
an
event
from
a
log
event
to
the
span
event?
If
we
have
nested
attributes,
it
becomes
easy,
because
we
just
said
same
thing:
if
we
don't,
then
we
have
to
say
this
is
how
you
convert
it
or
something
so.
C
D
So
I'm
in
two
minds
on
that
aspect:
I
I,
think
I
I-
think
it's
unfortunate
that
we
are
depending
on
the
log
signal,
because
the
if,
if
eventually
you
know
no
matter
what
we
you
know,
the
documentation
says
people
are
going
to
look
at
the
you
know
the
data
on
The
Wire
and
it's
confusing.
You
know
it
starts
off
with
every
event.
You
know
starts
off
with
being
a
log
record
and
it
has
attributes
and
inside
the
attributes.
D
Once
again,
there
is
the
event
name
and
then
another
substructure
for
the
event
data,
whereas
the
attributes
itself
was
supposed
to
be.
For
the
you
know,
the
other
data
additional
data
right.
A
D
Maybe
I
think,
if
you
go
to
the
spreadsheet,
can
you
share
the
spreadsheet
and
go
to
the
last
sheet?
10
she
10
yeah,
I'll
just
show.
So
let's
say
there
is
a
log
right
and
it
has
a
bunch
of
fields.
Timestamp,
then,
in
a
few
other
fields,
and
then
there
is
attributes.
D
This
is
a
log
recorder.
But
as
an
event
is
the
attributes
is
expanded
right.
It
has
a
domain,
a
name
and
then
data
right
and
then
here
we
are
putting
the
fields.
A
D
D
Yeah,
so
maybe
we
make
progress
on
that
proposal.
First,
like
within
this
team,
we
we
agree
on
because
I
think
you
know
one.
One
of
the
observations
in
the
locksig
is
only
we
are
asking
for
events.
It's.
There
is
no
other
team,
that's
asking
for
events
at
the
moment
so,
but
but
there
are
use
cases
where
events
are
needed
with
the
backends
too,
so
they
will
come
back
later
and
they'll
start.
You.
A
Know
asking
for
the
same
thing:
yeah.
B
Yeah.Net
is
already
asking
for
that
and
I
think
that's
one
of
the
things
that
spawned
pigment
to
create
the
proposal
to
effectively
remove
events
completely,
which
is
now
closed.
C
So
reading
through
that
that
proposing
all
the
comments
and
stuff
I
I,
don't
think
it's
just
that
is
asking
for
events,
there's
a
lot
of
people
that
are
that
want
events-
and
you
know
yeah
and-
and
you
know,
they're,
opposing
killing
that
eventually.
C
Okay,
yeah
I
I
think
you
know
I
like
that
idea
of
within
our
RC.
We
figured
out
in
a
way
to
start
representing
these
things
and
just
go
forward
with
that.
Yeah.
D
I
think
if
you
go
back
to
the
previous
doc,
I
think
nav
had
three
items
in
his
proposal.
If
you
go
to
the
last
week's
meeting,
yeah
yeah
those
three,
you
know
the
right
way:
your
cursories
there
are
three
sublets.
C
B
And
I
guess:
there's
a
third
one
which
I
put
into
that
chat.
Let
me
see
if
I
can
find
it
again,
which
is
really
an
extension
of
the
the
data
object,
because
that
proposal
started
off
the
schema
discussion.
I
I
sort
of
like
documented
in
that
thread
a
little
bit
more.
A
C
For
adoption,
okay
sounds
good,
do
we
do
we
want
to?
You,
know,
go
through
and
let's
see
what
you
know
do
some
sort
of
according
to
see
which
one
you
want
to
go
with
or.
D
Yeah
I
I
want
to
understand
the
third
option
here
when
you
suggest
prefix
what
what
do
you
mean
by
preference.
B
A
B
C
We're
doing
sorry
so.
A
C
D
That
but
I
think
the
event.data
prefix
is
redundant.
Why
do
we
need
like
what
is
event
data
I
think
that
could
be
a
controversial
prefix.
B
D
Maybe
in
the
same
Excel
sheet,
maybe
we
should
put
some
examples.
D
Let's,
let's
write
down
what
is
option
three.
A
D
Let's
take
an
exception
right,
I
think
in
an
exception,
let's
say,
there's
an
attribute
called
exception
and
then
the
subfields
called
type
message.
This
is
one
option.
Another
option
is
now
you'll
have
exception:
DOT
type
exception,
Dot
message,
yeah.
D
Is
event.data
in
this
case
is
well.
B
There
wouldn't
be
so
in
in
the
case
of
so
a
window
data
is
really
just
where
the
relevant
properties
for
an
event
limb,
so
that
they're
completely
separate
from
any
other
attributes
that
you
may
want
to
pass.
I
found
the
link
and
I
posted
in
the
in
last
week's
notes,
which
I
tried
to
describe
it
in
in
that
chat
as
well.
So
it
would
be
just
that.
You
know
it's
a
bit
like
a
span.
It's
just
a
grouping
mechanism
so
effectively,
rather
than
repeating
event.data.xyz.
B
D
B
B
B
Yeah
but
option
one
effectively
is
yeah:
it's
you
know,
there's
data
object
and
everything
associated
with
that
event
directly
is
is
in
that
data
object.
There
may
be
other
attributes
associated
with
the
request,
depending
on
the
instrumentation,
but
the
data.
The
data
is
the
data
for
that
event
that,
as
we
Define
it
as
opposed
to
option
three,
because
there
is
no
nesting,
we
have
to
come
up
with
something
else.
B
B
For
exceptions,
yeah,
and
if
we
have
to
go
to
convert
from
a
nested
structure
to
a
a
span
event,
that
would
probably
be
the
way
we'd
have
to
do
it
option.
Two
I
think
was
the
one
where
we,
in
fact
you
say
no,
there's
still
an
event.data,
but
we
just
serialize
it
as
a
decent
object.
C
C
Yeah
option
two:
is
the
Json
yeah
yeah.
B
So
so,
if
you
like
it
yeah
option,
one
is
nest:
full
District
attributes
where
we
Define.
For
that
event,
what
what
is
a
nested?
Attributing
data
option,
two
indicator?
Well,
we've
still
defined
what
the
fields
are,
but
instead
of
being
nested
attributes
there
there's
a
single
attribute
of
end.data,
fully
encoded
as
Json
and
then
option
three
is
okay.
Well,
we
can't
have
nesting,
we
don't
want
to
convert
it
to
Json.
So
if
we
put
a
prefix
on
those
fields
in
stable
and
we
have
more
or
less
top
level
attributes.
B
So
we
can
say:
we've
got
this
field,
then
we
expect
it
to
be
a
number
and
that
helps
when
we
convert
it
to
Json
encoding,
because
all
we've
really
got
is
like
strings
and
numbers,
and
you
can
use
the
schema
to
infer
okay
well,
this
was
passed
as
a
string,
but
it
really
should
be
converted
to
something
else.
So.
C
How
how
would
that
you
know
to.
A
D
C
Sort
of
a
prevalent
thing
right
so
having
that
schema
information
is
anything
needed.
If
you
want
to
decipher
in
any
of
these
things,
or
do
you
see
that
required
only
when
you
serialize
this
Json
or
something.
B
No
that
so,
when
you
have
a
nest
record
the
attribute
today
effectively,
if
you
go
to
the
that
link,
it's
probably
and
then
we
can
scroll
up.
I've
got
a
little
bit
mapped
out
in
there.
So.
C
Do
you
have
it
on
chat
there?
It's.
B
So
so,
where,
where,
in
this
case
here
I'm
saying
Hotel
browser
one
we're
saying,
we've
defined
version,
one
of
the
of
the
browser
schema
and
it's
it's
just
defined
like
we
go
and
Define
it
in
a
dock
somewhere.
The
reason
for
saying
otel
colon
was
because
we
took
in
the
log
scene.
Last
week
we
talked
about
having
it
as
a
urn,
so
you
could
actually
have
custom
ones,
saying
it's
https
So
in
theory
it
could
be
downloaded
but
effectively.
What
we're
doing
now
in
the
spreadsheet
is
defining
what
that
schema
is.
B
So
we
say
you
know
that,
then
that
schema
would
contain
all
of
the
the
browser
domain
level
things.
So
in
this
particular
case
I'm
explicitly
saying
we
have,
we
have
it
as
appealed,
but
by
just
by
having
event
domain,
we
can
infer
that
and
say
well,
because
the
domain
is
browser.
We
really
mean
Hotel
browser
version
one.
B
So
that
can
be
inferred
at
least
for
the
first
edition.
The
schema
just
makes
it
a
bit
more
scalable
so
effectively
in
the
future.
We
just
have
to
go
and
Define
a
new
schema.
We
don't
have
to
do
anything
else
to
the
to
the
definition,
so
really,
in
this
case
schema
replaces
the
combination
of
domain
domain
and
name
well,
except
I've,
got
name
in
the
data.
If
you
scroll
up
I've
got
another
comment:
a
bit
higher
up
which
talks
about
decent
encoding
there.
We
go
this
one
here
yeah.
B
So
this
is
where
the
difference
is
today
so
effectively.
If
we
just
said
it
was
Json
encoded,
we'd
say
you
know
key
one
value,
one
key
242.
as
opposed
to.
If
it's
otlp
encoded,
it's
key
key
one
value
string,
value
value.
One!
B
Sorry,
then,
while
that
effectively
completely
caters
for
the
fact
that
okay,
this
this
field
is
being
passed
as
an
into
or
as
a
string
or
you
know,
as
an
array
or
whatever
else
you
could
in
theory
in
Jason
you
could
actually
say:
ketu
is
42
as
a
string,
but
you
really
want
to
encode
it
as
a
number.
So
today,
I
don't
know
what
happens
with
the
conversion.
Pervy.
Do
you
with
the
otlp
Json
stuff.
You
were
doing.
A
B
D
My
understanding
of
why
you
know
the
type
was
explicitly
added
in
that
value.
Attribute
value
was
you
know
in
in
different
languages,
I
think
when
you
deserialize
there
is
no
confusion.
B
From
a
binary
perspective,
yes,
but
that's
also
about
what
a
schema
can
do,
you
can
say
the
the
metadata
is
so
we
like
in
Jason
we
have
42.
Is
that
it
needs
or
is
it
a
plug?
The
schema
could
Define
that
that's
a
plug,
because
under
the
covers,
everything
in
JavaScript
isn't
float
anyway.
B
So
the
other
thing
which
I
didn't
mention
here,
because
I
I
thought
it
was
beyond
this
is
a
schema
then
gives
us
the
the
additional
additional
capabilities
which
I
alluded
to.
If
you
read
all
of
my
discussions
into
validation,
the
validation
can
also
include
the
fact
that
okay,
this
field
may
contain
pii
data.
B
So
therefore
it
should
be
masked
or
not
stored,
or
you
know
have
something
done
to
it,
so
that
even
if
it
inadvertently
gets
sent
the
back
ends
know
not
to
do
anything
with
it,
which
you
can't
do
in
the
existing
definitions.
Today,.
D
So
that's
schema
that
you
have
in
mind.
Is
it
some
published
PDF
or
something.
B
So
when
I
think
schema,
I
think
back
to
the
old
X
and
old
days,
where
you
know
the
very
top
of
the
document,
you
specify
what
the
schema
for
the
XML
is
right,
like
I
I
have
no
no
interest
in
completely
defining
something
completely
brand
new
I
want
to
leverage
whatever
else
whatever
is
out
there
like.
If
we
can
use
the
otlp
conversion
stuff-
let's,
let's
do
that,
but
yeah.
It
really
is
it's
a
guiding
document
to
say
I've
I
expect
this
or
I've
got
this
and
I
want
it
to
be.
This.
D
I
think
what
what
I'm
my
question
is
like?
Are
you
thinking
that
we
should
enhance
the
open,
Telemetry
schema
specification
to
to
allow
for
defining
the
details
of
each
field
in
in
the
event.
B
I,
but
that
discussion
is
more
General
and
it
has
been
opened
by
several
people,
I
think
including
tigran
and
yeah
I
think
Josh
had
been
pushing
for
it
for
a
while
and
I
think
Cleveland
keeps
pushing
it
down
this
one
in
particular,
I
I
spoke
to
just
the
event,
because
there's
going
to
be
lots
of
third-party
events
to
be
defined
and
we
don't
want
to
have
to
go
and
Define
them
all,
but
we
want
a
way
for
backends
to
be
able
to
infer
from
that
which
originally
was
like.
B
You
know,
we
just
say
event
domain
event,
name
and
event,
data
and
that's
the
that
identifies
the
event,
so
people
so
backends
can
just
look
at
the
data
and
say
this
is
this
is
an
event
store,
but
that
that
really
poor
custom
events
that
negates
any
any
form
of
validation
that
they
could
do
and
the
schema
brings
in
that
possibility.
Yep.
C
I
think
you
know
this.
This
brings
up.
Another
thing
also
I
noticed
that
today,
in
some
of
the
events
we
had
I
can't
remember,
I,
think
useration
or
whatever
it
is
had
a
version
field
which
we
went
through
and
said
yeah,
you
know
it's
the
version
for
the
schema
or
something
I
didn't
talk
about
it
in
detail.
C
Let's
see
what
the
version
tables
maybe
exception.
Has
it.
A
C
Was
yeah
there?
You
go
schema
version
so
that
one
here
so
this
field
here
we
anyway
need
this
schema
version,
we're
defining
schemas.
We
need
a
schema
version,
because
what,
if
we
add
a
new
field,
you
know
something
you
know
only
additive.
We
need
to
come
up
with
ways
to
add
it.
You
can
have
to
break
into
this
and
stuff,
but
that
needs
to
be
version
specific.
C
So
we
know
which
version
we're
complying
to
when
the
event
is
sent
out
so
I
believe
the
The
Proposal
that
never
has
here
Works
nicely
with
that
I
think.
D
So
one
thing
I'm
I'm
not
able
to
follow
is
like
the
schema
aspect
is,
is
a
separate
topic
compared
to
how
we
want
to
structure
the
payload
right,
correct.
C
Yeah,
the
the
question
would
be,
you
know:
do
we
have
domain
and
name
as
attributes
that
we
have
to
figure
out
that
are
going
to
be
part
of
a
schema?
That's
the
thing:
if
we're
able
to
get
the
schema
going,
then
we
don't
even
need
to
worry
about
the
main
and
name.
That's
a
separate
discussion.
Yeah.
D
No
so
so
schema
is,
is
a
long,
Pole
right,
I!
Think
it's
a
at
this
point.
I.
You
know
it's
clear
that
you
know
defining
a
schema.
There
is
there's
a
lot
of
you
know,
spec
work
and
then
a
lot
of
open
questions
to
me.
It
is
something
that
will
come
as
an
incremental
enhancement.
In
addition
to
what
we're
doing
so,
the
basics
that
we
Define
now
should
work,
irrespective
of
schema
schema,
would
be
an
additional.
D
You
know
supplement.
You
know
that
you
would
use
to
strengthen.
You
know
the
the
type
system
Implement.
B
C
You
want
to
do
that
or
do
we
want
to
actually
start?
You
know,
recording
an
attribute
called
version.
You
know
for
that
particular
schema
and
then,
when
schema
becomes
solidified
we
remove
that
version,
separate
separate
version
field.
I
guess
my
point:
is
we
assume
that
every
one
of
our
events
will
have
domain
name
and
version
if
schema
would
help
represent
those
two
things
together?
Fine,
if
not,
we
really
need
the
you
know.
We
need
those
three
things.
A
C
D
Yeah
I
think
I
I
think
we
need
to
first
finalize.
You
know
that
part.
The
schema
I
think
we
should
take
it
up
separately
because
there
is
am
I
I,
don't
know
it
might
have
more
things
to
be
considered.
C
B
Yeah,
there's
lots
that
could
could
be
included
in
the
schema
just
doing
what
we're
doing
in
the
spreadsheet
here
is
defining
version
one
without
a
schema
dock.
Okay,.
B
So
my
my
preference
on
this
is
option,
one
purely
from
you
know
it.
It
holds
everything
together.
The
concern
I
have
about
option.
One
is
when
we
go
to
map
it
to
a
span
event.
How
do
we
do
it?
So
that's
concern
number
one
concern
number
two
was,
as
you
saw
in
that
chat.
It's
the
if
it's
protobuf
encoded,
it's
just
like
a
object
of
objects.
That's
just
painful!
It's
not
just
straight
Jason,.
B
Which
is
where
with
option
two,
we
could
say:
well,
we
just
Define
it
as
normal
Json
and
not
otlp
encoded
attributes,
so
that
reduces
the
size
and
it
also
has
the
mapping
of
okay.
Well
when
we
take
it
to
a
span
event,
it
is
just
it's
just
actually
called
event
data
with
the
value
and
option.
B
Three
is
just
an
extension
of
that
saying:
well,
we
don't
want
to
have
it
as
completely
encoded
Jason,
because
the
back
ends
have
to
decode
it
which
I,
don't
think,
is
a
big
deal,
but
anyway
back
end
back
ends
after
decode
it,
but
then
we
have
to
duplicate.
We
have
to
have
the
segregator
by
having
some
form
of
prefix
on
the
front
and
then
you've
still
got
the
same
thing
as
that,
because
it's
an
attribute,
it's
still
going
to
have
the
string
value
in
value
structure,
so.
C
Right
what
what
you
know?
Yes,
yes,
my
thought
on
choosing
one
of
these
things.
Whatever
you
know,
we,
what
are
the
ideal
for
us
if
we
had
our
way,
which
would
just
you
know,
which
is
the
option
we
would
go
with
trying
to
stay
close
to
that
would
help.
You
know,
drive
that
I.
Think
especially,
you
know.
If
we
go
go
with
this
works
works
with
you
know,
existing
definitions
and
stuff
and
it'll
just
be
fine.
That'll
be
they'll.
C
Give
us
a
lot
less
leverage
to
drive
these
discussions
in
the
yeah
in
the
spec
I
would
think.
Let's
not
paint
ourselves
into
a
corner
is
what
I
would
say
in
option.
One
or
two
is
what
I
would
prefer
yeah
I'm
going
with
so
that
way
you
can
still
continue
the
private
discussions,
so
it
could
be
painful
in
certain
cases,
I.
D
I
think
with
option
both
one
and
two,
where
there's
an
event.data
that
you
know
getting
approval
from
the
semantic
conventions
you
know
could
be
difficult
because
then
we'll
have
to
justify.
You
know
how
it
is
applicable
to
a
broader
set
of
so.
C
Why
is?
Why
is
even
that
data
I
think
that
we
need
to
get
approval
on,
and
even
that,
that
data
is
just
another
interview
right.
We
call
it
even
that
data
what's
contained
in
it.
B
I
would
prefer
to
see
it
defined.
As
for
a
log
event,
it
is
the
expected
way
to
to
pass
the
right.
D
So
if
we
say
that,
then
then
I
think
it
will
invite
wider
scrutiny
so.
D
D
It's
strange,
but.
A
C
Help
me
understand.
Okay,
if
that's
the
case,
then
we
go
with
this
this
option.
Then
you
know
all
of
the
fields
that
we
Define
here
yeah.
C
D
I
think
the
point
is
within
the
ramsig
itself.
You
know
that
serves
as
a
standard
like
whichever
tomorrow,
you
know.
If
there
is
a
third
party
implementation
of
browser
instrumentation,
they
are
supposed
to
generate
Telemetry.
Following
that.
B
So
that
would
mean
to
avoid
causing
that
level
of
pain.
The
prefix
would
have
to
be
specific
to
The
Domain,
so
it
would
probably
have
to
become.
You
know,
browser.page
view
DOT
first
page,
that's
a
bad
example,
but
anyway,
so
it
would
probably
have
to
be
that
the
attributes
associated
with
that
domain
name
combination
actually
have
the
domain
name
combination,
prefix,
which
is
just
awful
to
avoid
that
thing.
So
you
can
say
that
the
the
the
semantic
convention
for
those
attributes
are
at
least
organized
off
into
their
own
thing.
B
But,
like
you
know,
all
the
HTTP
ones
are
all
there.
Although
exceptional
ones
are
there,
because
otherwise
you're
gonna,
get
name
clashes
and
I.
Think
that's
why
the
names
had
to
be
run
through
the
approval
process,
to
avoid
multiple
teams
creating
the
same
name
having
different
meanings.
B
It
avoids
all
that
discussion
because
it
means
you
don't
have
to
have
semantic
conventions
painted
for
everything.
It's
against
the
world.
You
say
for
this
combination
of
domain
name.
You
can
go
and
Define
that
yourself
and
then
the
back
ends
know
that
if
I've
got
this,
they
just
go
serialize
it.
However,
they
want
to
or
deal
with
it.
However,
they
want
to
yeah,
which
is
an
advantage
of
the
data.
C
Yeah,
that's
the
thing
my
thinking
is
getting
even
that
data
approved
is
probably
you
know
a
good
thing
right,
and
we
do
that
and
everything
instead
of
that
is
within
that
I'm,
saying
yeah.
B
And
I
I
think
tigrants
opened
the
door
to
to
reevaluate
the
event
thing
with
his
proposals.
I
think
he's
he
doesn't
want
it
anymore.
Simplistically,
foreign.
B
There's
there's
two
sets
of
downside,
so
we
have
to
have
a
prefix
on
the
front
of
every
attribute
that
we
put
at
that
top
level
and
that
prefix
is
effectively
duplicated.
So
if
you
ram,
if
you
go
back
to
the
resource
timings,
this
is
like
a
really
good.
So,
okay,
you
had
a
big
list
of
all
the
or
was
that
the
word
Doc
Page
navigation
type
and
maybe
the
first
paint
one
I'm.
C
B
Either
one
like
this
list
here
so
I
think
we
say:
okay,
we've
got
all
these
attributes
on
this
event,
so
every
one
of
these
attributes
would
have
to
have
repeated
same
prefix
which,
from
our
payload
perspective,
is
awful
and.
C
I
I
also
think
each
one
of
them
will
have
to
be
approved
by
the
government's
Community
or
something
right
so.
D
Now
I
think
I
think
we
I
know.
We
had
discussed
this
in
the
past,
where
you
ruled
out
compression
right,
I,
think
and.
A
B
D
From
from
your
past
experience
what
how
does
it
look
like
like?
Let's
say
if
you're
talking
with
the
Horizon
of
let's
say
five
plus
years
well,
how
many
of
the
browsers
that
do
not
support
that
API,
the
new
experimental
API
will
be
exactly.
B
B
So
your
dentist
office,
your
you,
know
your
small
doctor's
office
and
effectively
the
people
who
take
who
write
the
software
for
them
effectively.
They
don't
want,
they
don't
upgrade
their
Hardware.
So
therefore
they're
still
running
on
XP
with
ie
today,
but.
B
B
So
if
we
say
from
from
now,
I
would
expect
some
people
will
still
be
running.
Ie,
11.
D
Can
you
tell
me
more
about
that?
What
do.
B
You
mean
so
so,
if,
like
Chrome
yesterday
announced
that
they're
actually
going
to
as
of
version
110,
they
will
not
support
Windows
7.
as
a
good
example.
So,
if
you're
with
chrome
today
like
up
to
version
110,
it'll
support
send
Beacon,
we
have
a
64k
limit,
so
if,
in
five
years
time
we
still
have
people
running
Windows
7,
with
version
of
Chrome
less
than
110,
if
we
create
a
payload,
that's
greater
than
64k
or
a
total
of
outstanding
of
64k.
Those
events
won't
even
make
it
off
the
blocks.
B
Okay
Chrome
will
support
the
compression
API
by
that
time.
Hopefully
so,
therefore,
that
portion
will
at
least
happen,
but
they
may
be
using
some
older
browser
or
you've
got
some
other
like
on
some
older
phones
back
on
upgrade
I.
Think
iOS
is
probably
a
good
example
there
that
they
don't
have
the
experimental
compression
API.
So
none
of
your
phone
devices
mobile
devices,
your
iPads,
your
iPhones,
will
have
that
compression
capability.
So.
D
About
the
64
KB
size,
if
it
gets
to
that
I
think
that's
a
smaller
problem
to
solve
right,
I,
think
that
can
be
solved
through
you
know
some
other
mechanism,
no.
B
Depends
on
the
event,
so
the
other
field
that
I
want
to
introduce
as
part
of
or
just
general
semantic
conventions,
just
it's
just
a
custom
event
blob,
because
we
we
have
customers
today
where
they
want
to
pass
their
own
set
of
data.
B
So
this
was
also
part
of
my
driving
back
in
March
of
the
nested
attribute
and
trying
to
address
376
as
part
of
my
initial
one,
they're
saying:
okay,
while
there's
no
General
semantic
conventions
for
hotel,
there
should
be
a
bucket
where
people
could
throw
in
their
own
attributes
and
I
have
teams
today
where
they
have
a
single
event,
which
is
greater
than
64k
times
generally
it's
slightly
under.
But
there
is
a
team
that
can
generate
events
because
of
all
the
extra
data
that
they
gather
is
huge.
Now.
A
D
B
D
Yeah
I
I
find
it
hard
to
believe
that
it's
you
know
it's
going
to
be
a
significant
number
of
such
scenarios.
C
D
Think
we
will
come
up
with
mechanisms,
but
I
think
you.
C
Know
I
think
some
of
the
fundamental
things
that
we
choose
should
not
block
those
things
right.
So
if
we
have
to
you
know,
we
don't
have
to
solve
that
problem
right
now,
but
you
know
roughly,
how
would
we
solve
it?
No.
D
But
my
my
point
is
my
point:
is
I
think
the
the
default
fundamental
Solutions
should
address
the
larger
Mass
right
and
and
then
I'm
sure.
If
we
discuss
you
know
in
detail,
we
should
be
able
to
come
up
with
solutions
for
those
fewer
scenarios.
I.
A
D
We've
even
spoke
in
you
know
in
one
other
context
earlier
that
we
will
have
events
with
priority,
so
some
events,
you
know,
could
have
a
higher
priority
where
they
won't
go
through
the
batching
process.
You
know
they
they'll
skip
the
patching
process
and
they'll
just
get
sent
down
the
wire
right
away.
Yeah.
B
And
you
know
coming
back
to
Europe
in
terms
of
the
majority
it
there.
That's
a
debatable
measurement,
because
it's
a
case
of
is
the
majority
of
applications
or
the
majority
of
events
created
and
for
some
of
my
teams
it's
actually
they
generate
millions
of
events,
so
they
actually
become
the
the
majority,
as
opposed
to
the
minority.
B
In
terms
of
the
size
like
not
every
event
out
of
their
system,
is
that
large?
But
there
are
some
scenarios,
which
are
quite
common,
that
do
get
that
large,
of
course,
showing
up
periods
of
time.
C
So,
coming
back
to
choosing
one
of
these
options
and
stuff,
one
of
the
things
that
I
had
is
that
every
attribute
that
we've
come
up
with
has
to
be
approved.
C
D
I
think
I
would
say
the
other
way.
The
event
already
you
know
there
has
been
I
mean
I
I
still
feel
the
other
teams
are
aren't
coming
forward
as
much
with
their
requirements
on
events.
B
I
I
think
that's
because
the
law
there
is
their
logs
of,
though
there's
fewer
logs
implementations
at
this
point
in
time.
I
think
they're
coming.
They
just
haven't
made
a
mechanism
today,
okay,
like
if
you
look
at
that
thread,
there
was
people
like
there
were
some
people
saying
yay.
It's
now
funny
in
Java
and
I'm,
saying
boo
you're
trying
to
rip
it
out,
we
need
it.
D
Yeah
and
and
with
the
current
API,
you
know
where
we
pass
the
actual
event
data
in
the
attributes.
They
just
go
as
other
attributes,
whereas
if
we
introduce
event.data,
then
the
additional
attributes
passed
for
the
event
through
the
API
will
will
have
to
be
sent
in
in
this
event.data
attribute.
So
the
spec
will
also
change.
D
D
It's
confusing,
you
are
saying,
you
know
you
send
attributes
for
your
event
and
then
you're
again
saying
you
know,
send
the
data
of
your
event
in
one
specific
attribute.
B
B
There
are
other
events
where
you
will
have
event.data
where
we
have
our
Define
set,
but
you
will
also
have
other
attributes
that
you
may
want
to
pass
a
like
this
custom
data
object
that
I
was
just
talking
about
so
yeah
I.
Don't
see
that
as
a
confusing
thing,
it's
a
case
over
here,
you're
firing
an
event
yeah.
We
could
add
I.
D
I
think
that
it
could
be
potentially
confusing
is
when
you
map
events
from
an
external
Source,
let's
say
kubernetes
events
or
our
Windows
events.
Even
we
want
to
map
them
into
open,
Telemetry
events,
then
what
goes
into
event.data
and
what
goes
into
other
attributes.
I.
Think
that.
B
That
would
that's
based
on
what
the
schema
is.
So
what
the
domain
name
combination
is.
A
B
We
Define
them
saying
hey
this
domain
name.
We
expect
this
to
be
in
data
and
if
we
haven't
defined
it,
but
for
that
event
then
you'll
probably
send
it
as
other
attributes.
If
you
already
want
to
send
it
or
we
update
the
spec
and
say
this
is
now
a
new
optional
field.
D
But
yeah
things
should
work
even
in
the
absence
of
a
schema.
B
Correct
because
we're
defining,
as
we
had
in
the
spreadsheet
that
this
event
name
combination,
is
the
schema,
we're
just
not
defining
a
document
as
the
schema
and
as
I
alluded
to
in
the
in
the
other
discussion.
It's
a
case
of
having
the
event
API
just
say:
name
attributes
does
not
preclude
helper
functions.
B
That
say,
Okay
I
want
to
create
a
page
view
of
it
and
you
give
it
all
the
all
the
things
there
or
I
want
to
create
a
real
event
and
say
you
know,
name
data,
other
attributes,
because
that
was
one
of
the
pigeons
thing
he
seems
to
want
to
get
rid
of
the
events.
Api
I
think
we
still
need
one
I
think
a
lot
of
everyone
else
was
saying:
we
still
need
one.
B
It's
just
the
case
of
what
does
that
look
like
and
is
it
just
like
helper
functions
which
are
defined
or
is
it
the
main
specific
apis?
So
do
we
create
a
set
that
is
just
for
the
browser
and
then
just
for
Android
and
then
just
for
iOS
and
Etc
I
think
that
discussion
is
still
working.
B
Think
secret
will
bring
it
up
in
the
logic
tomorrow.
Yeah
there
is
a
another
thread
going.
D
Somewhere
I
think
he
has
a
larger
topic
but
specific
to
event.data,
as
as
an
attribute
to
hold
the
data.
Maybe
we
should
explicitly
bring
it
up.
B
B
Okay,
but
as
random
said
you
know,
we
could
have
a,
we
could
also
extend
it
with
version,
but
it
said
that
the
absence
of
a
version
could
also
mean
version
one.
But
that's
where
the
schema
thing
comes
in.
Do
we
push
for
a
version
or
do
we
just
say
schema
and
schema
becomes
the
combination
of
the
main
version,
which
does
really
wonderful.
B
B
D
As
a
backup
to
option
one,
what
is
your
second
preference
yeah.
B
D
B
Option
three
so
we're
left
with.
If
we,
if
we
cannot
have
an
event.data,
then
we
have
to
have
a
prefix
on
all
the
attributes
that
we've
got
unless
someone
else
can
think
of
something
else.
Okay,.
D
And,
and
could
you
quickly,
you
know
help
with
the
disadvantages
of
option?
Three,
the
prefix
is
repeated.
What
else
is
repeated.
B
But
it's
a
combination,
so
the
prefix
is
when
you're,
comparing
one
and
three
it's
the
repeater
prefixes
is
the
downside.
When
you
compare
two
and
three
It's
a
combination
of
the
prefix
and
the
fact
that
every
attribute
is
encoded
as
a
as
an
attribute,
I.E
string
value
in
value,
which
is
the
also
the
the
Delta
between
option,
one
and
two
okay.
So
the
the
different
levels
of
issue.
D
Okay,
okay,
yeah
I
think
so.
Let's
discuss
this
in
the
log
set
tomorrow
and
maybe
next
week
we
we
could
get
together
and
see
if
we
can
pick
one.
A
B
Oh,
we
start
up
a
bigger
discussion
with
events
now
that
figure
throughout
that
proposal.
I
think
he
did
mention
he
closed
it
because
I
don't
did
we
make
it
in
there.
C
C
Yeah,
so
you
basically
says:
there's
not
much.
Love
represent
space
too
many
indications.
B
D
Yeah
now
I
think
these
problems
are
unavoidable.
Given
we
are,
we
are
reusing
logs
to
represent
events,
yeah.
B
C
Okay,
another
four
minutes,
there's
a
few
other
items
that
we
should
go
through.
You
know.
Perhaps
we
can
do
this
offline.
Also
I
threw
out
a
few
disadvantages
here.
Where
did
that?
Go.
C
A
C
Perhaps
you
can
look
at
them
and
then
you
know
in
a
fixed
them
or
tell
us,
you
know
what
it
is.
I
think
that'll
be
good.
D
Okay,
are
you
planning
to
join
tomorrow's
meeting.
C
C
C
Sounds
good
cool,
okay,
any
other
topics
yeah
all
right.
Thanks,
though,
thank.