►
From YouTube: 2022-03-30 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
B
B
A
B
Let's
just
give
it
like
one
more
minute.
B
One
is
a
carryover
from
last
week
and
one
the
first
one
is
just
the
proposal
for
to
add
a
second
meeting
for
us.
We
just
have
a
lot
of
things
to
discuss
and
I
think
we
want
to
make
progress
a
little
bit
faster,
so
we're
proposing
to
to
have
a
second
meeting
weekly
meeting
at
least
temporarily
and
we're
proposing
it
looks
like
tuesdays
at
night.
9
a.m
is
best
right
now,
but
if
anyone
has
any
other
suggestions,
please
say
please
say
so.
B
Santosh
I
wanted
to
clarify
if,
if
like
this
wednesday
meeting
is,
is
would
be
different
in
that,
like
it's
more
just
like
status,
update
and
like
more
wider,
like
anybody
who
wants
to
know
the
status
going
to
attend
whereas,
like
the
second
meeting
like
is
more
working
like
we
like,
choose,
choose
yeah
focus,
we
choose
a
topic
and
work
on
it.
C
B
Okay,
so
if
nobody
has
yeah,
let
me
know
if
you're
interested
or
if
you
have
any
other
proposal
for
a
different
time,
but
if,
if
not,
then
it's
gonna
be
on
tuesdays
at
9am.
B
Okay,
and
sometimes
did
you
have,
did
you
want
to
talk
about
sessions
somewhere
today.
C
I
I
actually
wanted
to
go
over
the
fundamentals,
the
data
model
and
the
apis
and
semantic
conventions
sessions
yeah.
I
don't
know
if
people
have
any
questions
based
on
the
document
I
shared,
you
know
we
could,
you
know,
discuss
about
them,
but
there
are,
you
know
quite
a
few
pending
things
on
on
the
fundamental
aspect,
so
I
I
thought
I'd.
B
So
the
other
topic
that
I
have
on
the
list
is
kind
of
minor.
So
if
you
want
to
do,
you
know
focus
on
the
doc
first,
we
can
do
that.
Okay,
okay,.
C
C
So,
as
you
know,
we
are
working
on
when
we're
planning
on
using
the
logs
data
model
for
representing
the
ram
events,
so
for
that
I'm
planning
to
join
the
logsic
today
later
at
10
o'clock,
specific
time
to
go
over
some
of
the
you
know,
semantics
with
respect
to
using
the
you
know,
building
an
api.
You
know,
on
top
of
the
log
data
model,
specifically
for
the
purpose
of
generating
events.
C
There's
there's
nothing,
there's
no
question
here.
I
just
wanted
to
let
you
know
there
are
some
questions
that
I
have
for
for
them.
C
They
don't
have
a
logs
api
today,
a
separate
logs
api
because
they
don't
want
end
users
to
use
yet
another
api
for
generating
logs,
but
on
the
existing
you
know
log
apis
that
exist.
They
they
they
have
an
sdk
to
translate
those
logs.
You
know
into
a
tlp.
C
But
for
for
the
events,
we
do
want
an
end
user
facing
api,
so
my
proposal
is
that
we
call
it
an
event
emitter
instead
of
a
log
emitter,
just
to
avoid
confusion
and
and
and
then
discuss
some
semantics
with
respect
to
that.
C
C
Next
topic
was
really
with
respect
to
you
know
using
spans
to
determine
causality,
and
we
still
don't
have
good
clarity
on
how
to
represent
that
part.
C
The
I
think,
john
watson,
I
think
originally
had
brought
it
up.
I
I
don't
see
him,
you
know
in
this
meeting
lately,
so
we
need
some
clarity
on
clarity
and
some
prototypes
on
on
how
to
use
spans
to
represent
causality
between
two
events.
C
C
But
then
the
general
question
is
like
for
every
user
interaction.
Do
we
generate
a
span
and
then
when
does
it
end?
Because
the
button
click
itself
you
know
there
is,
there
is
no
concept
of
an
end.
It
it's
a
one-time
event
like,
unlike
a
network
request,
there
is
no
start
and
end,
so
it
feels
like
on
the
javascript
side,
even
though
it
will
be
good
to
capture
causality,
it
may
not
be
straightforward
and
feasible.
C
You
know
functionality
to
represent
causality
between
events.
I
think
we
need
more
clear
representation.
You
know
from
them.
B
Yeah,
I
mean
the
way.
The
way
I
have
been
thinking
about
it
is
that
the
span
just
gives
more
context
to
the
to
the
log
event
to
the
event.
So,
if
you
know,
if
you,
if
you're
able
to
generate
a
span,
that's
been
meaningful
for
that
for
that
type
of
instrumentation,
that
you
can
create
both
the
event
and
the
span
and
the
span
gives
more
context.
B
B
C
So
an
example
that
I
had
written
down
to
to
demonstrate.
You
know
this
causality
between
the
events
is,
let's
say
we
have
two
events.
First
event
is
a
button
click.
C
The
second
event
is,
let's
say
a
network
request
or
let's
say
a
route
change
you're
on
the
same
page,
but
you
you
you
go
to
a
different
route.
You
would
generate
two
spans
for
each
of
these
two
events
and
they
they
don't
have
any
attribute.
It's
just
a
blank
empty
span.
C
They
have
a
same
trace
and
then
you
know
the
spans
are
the
spans
and
the
trace
id
are
linked
in
these
two
events,
so
you
are
using
some
wrapper
spans
to
indicate
that
this
event,
one
cost
even
two
right.
So
this
requires
you
to
know
ahead
of
time
that
you
know
you're
100,
sure
that
you
know
this
kind
of
an
event
will
generate.
C
You
know
r
is
the
cause
for
the
second
event
and,
and
then
you
know,
once
the
second
event
is
completed,
you
take
explicit
action
to
come
back
and
close
the
span
for
the
event
one
right
and
so
that
it's
not
clear
how
how
you
would
do
it
in
a
generic
manner,
so
it
has
to
be
aware
of
the
situation
and
use
cases
that
you
have.
C
So
that
is
the
part.
That's
not
super
clear
to
me.
B
Yeah,
I
mean
I
mean,
like
the
sim
flex
in
my
kind
of
simplified
view.
So
if
you
had,
let's
say
that
you
have
instrumentation
that
tracks
user
interactions
and
that's
the
instrumentation
that
creates
a
span
and
event
so
it
it
listens
to
to
click
events,
and
then
it
also
creates
a
span.
B
And
then
the
span
is
in
the
context
and
route
change
event.
If
it
happens,
when
there
is
a
active
span
in
the
context
that
is
associated
that
active
span,
so
you
know
that
that
interaction
instrumentation
doesn't
necessarily
need
to
know
that
of
all
the
events
that
can
be.
You
know,
cascade
from
the
initial
interaction.
B
But
that's
that's
a
potential
there's
a
potential
implementation
of
the
india
sdk.
B
Yeah
I
mean
that
depends.
That
depends
like
what
you
know
you
could
have.
I
mean
I
imagine
right
now
right
now
that
interaction,
instrumentation
tracks
number
of
tasks,
like
a
number
of
all
the
network
network,
calls,
for
example,
that
that
were
started
in
the
same
execution
context
and
waits
until
the
last
one
finishes,
and
then
it
ends
the
span,
but
I
imagine
it
could
be
something
else
it
could
be
like.
Maybe
you
have
like
an
angular
ins,
plug-in
instrumentation.
C
C
Okay,
but
I.
C
Main
question
was,
you
know,
should
this
be
part
of
the
you
know,
initial
version
of
the
spec.
A
A
But
yeah
in
terms
of
using
spans
for
tracking
clicks,
it's
extremely
problematic
because
you
don't
know
when
it's
going
to
finish.
A
I
also
don't
want
to
start
relying
on
the
global
context
like
we
have
multiple
teams
that
are
all
running
on
a
page
and
relying
on
the
global
context
to
to
share
spans
is
not
going
to
work
at
all
for
them.
So
for
me
I
see
the
the
event
as
purely
so.
It's
a
fire
and
forget
their
you
know,
or
a
zero
time
span.
There's
no
easy
way
to
do
this.
A
Now,
if
you,
if
you're
the
application,
developer
and
you're
using
like
your
angular,
react
with
the
route
or
whatever
that's
a
different
story,
but
that
is
a
case
of
where
they
can
manually
start
it.
But
I
don't
think
you
can
automatically
start
a
spam
and
have
it
used
it's
it's
just
way
too
problematic.
Like
there's
a
lot
of
tricks,
you
can
use
based
on
your
javascript,
being
single
threaded
where
you
like,
just
stuff
stuff
things
into
into
globals
and
unwind
them
as
you
go.
A
But
if
you're
talking
about
bubbling
a
click,
you're
sort
of
like
unless
you,
unless
you
have
a
parent,
you
can
call
you
lose
control
as
soon
as
you
return
exit
out
of
the
app
which
leaves
the
only
other
option
as
a
callback,
you
know
so
on
the
next
javascript
execution
cycle,
you
go
cancel
the
span,
which
again
is
also
problematic,
so
I
would
say:
no,
we
don't
want
to
create
a
spam
for
things
like
this.
You
know,
spans
are
really
there
for
properly
scoped
requests.
A
A
Yeah,
like
I
said,
but
for
an
application,
it's
fine,
but
for
automatic,
that's
where
it
gets
problematic.
E
No
that
there
are
like
in
mobile
that
are
up
lifecycle
events,
which
are
actually
well
known
in
android
and
ios,
which
have
sort
of
you
know
that
causal
and
that
tree
structure
for
things
like
app
start
or
screen
transitions,
etc,
so
that
there
are
interesting
use
cases
beyond
the
network
calls
for
stands
today.
E
I
think
we
documented
that
in
a
different
document,
but
I
believe
the
general
consensus
was
just
to
explore
how
the
event
model
fit.
C
Would
it
be
possible
to
you
know,
do
a
write-up
on
the
mobile
use
cases.
E
We
did
actually,
let
me
see
if
I
can
remind
we
created
a
little
table
on
some
of
the
examples
where
either
the
timing
or
the
causal
relationship
sort
of
made
sense
from
a
span
perspective.
E
C
Showing
an
example
where,
let's
say
there
is
a
parent
view,
the
view
you
know
he
was
trying
to
represent
the
views
low
time
and
then
there
are
in
a
child
views.
Yeah.
E
C
Yeah
I
mean
he
was
trying
to
show
the
time
it
takes
for
for
a
screen
view
to
load
and
how
that
includes
the
initialization
of
the
child
components
so
there
it
does
make
sense.
C
So
I
think
if
we
could
write
down
specific
use
scenarios,
if
so,
I
think
you
know
this
is
what
you
know.
I
had
mentioned
to
john
as
well
last
time,
but
this
was
like
many
like
maybe
a
few
months
ago.
There
aren't
many
use
cases.
You
know
we
could
list
only
two
or
three,
you
know
use
cases,
and
if
that
is
the
case,
maybe
we
you
know,
I'm
still
wondering
whether
it
should
be
part
of
the
the
base
specification
for
client-side
telemetry.
C
You
know
this
could
be
an
advanced
use
case.
You
know
where
you
you
know
spans.
Are
the
right
data
model
to
to
use
and
and
just
let's
just
use
pans
for
that
use
case,
but
for
a
majority
of
situations,
if,
if
it's,
if
they're
best
represented
as
events,
maybe
you
know
we
should
include
that
as
the
as
the
as
the
main
piece
in
the
spec.
B
C
Yeah,
I
think
the
the
only
part
confusing
here
is
the
the
corresponding
examples
are
confusing.
So
if
we
could
replace
the
example
with
with
the
one
that
see
that
you
know
you
have
in
mind,
that
will
be
great.
F
A
But
just
to
clarify
with
the
loading
of
components,
that's
a
separate
controller.
On
top
of
that
light
so
like
if
you're
using
vgs,
react
or
angular.
I
think
you
can
do
this
in
the
route
if
the
route
is
instrumented,
so
for
the
mobile
like
loading,
the
sub
page,
that
would
be
a
similar
thing
right,
yeah,
so
that
would
be
effective,
instrumentation
of
or
auto
interpretation
of
that
component,
not
just
a
general
javascript.
Does
it
like
this
correct.
C
The
topic
of
classification,
so
we
we
want
some
way
to
identify
that
this
telemetry
is
from
from
the
client-side
components.
Client-Side
resources
you
know,
beat
browsers
or
mobiles
or
iot
devices,
or
I
think
somebody
even
brought
up
the
desktop
applications
and
it's
not
very
clear
how
to
do
the
classification.
C
The
classification
is
required
because
I
think
some
of
us
have
you
know
different
ways
of
processing
the
data
in
the
back
end.
So
so
you
need
some
way
to
classify
so
for
the
browser.
C
You
know
we
are
introducing
some
browser
attributes
in
the
browser
name:
space
like
browser
platform,
browser
user
agent.
So
that
is
clear.
So
the
presence
of
a
browser
attribute
can
be
used
to
classify
the
telemetry
as
coming
from
browsers,
but
for
mobiles
it's
a
little
confusing.
We
you
know
in
this
document
I
suggested
using
the
device
namespace,
but
then,
but
then
I
think
somebody
had
an
objection
that
you
know.
We
cannot
guarantee
that
nobody
from
the
infrastructure
or
back
end
telemetry
would
be
using
device
attributes.
B
So
so,
if
like,
if
the
sdk
is
not
able
to.
B
C
C
Like
you
know,
there
is
an
example
here
where
they
were
using
the
dp.name
and
as
an
attribute
to
if
the
the
db.name
is
is
present.
It
would
mean
that
you
know
the
the
service
is
a
database,
but
even
this
db.name
is
optional.
I
don't
think
it's
it's
a
mandatory
attribute.
C
C
I
I
think
there
was
this
clarification
this
this
appear.
I
think
it
it
got
closed
because
of
inactivity,
but
it
talks
about
you
know
two
possibilities
to
to
do
the
classification
one
is
you
explicitly
use
an
attribute
to
indicate
the
classification
whether
the
component
equal
to
database
or
component
is
http
server,
but
then
it
has.
C
C
So,
similarly,
for
for
mobiles,
it's
not
very
clear,
you
know
what
attributes
to
use
we
could
for
ios
applications.
You
know
they,
they
call
their
their
application
name
using
a
bundle
identifier,
so
a
bundle
dot.
Id
presence
of
that
could
be
used
to
classify
ios
apps,
but
for
android
apps,
the
app
name
is
called
you
know
by
the
name
package
name
but
again,
package
name
is
such
a
common
term.
You
know
we.
We
can't
use
that
too.
C
C
Unless
so
syrah,
could
you
find
out
again
from
john,
because
I
think
he
has
worked
on
android,
that
could
we
use
os.name
equal
to
android
as
the
means
to
classify
telemetry
coming
from
android.
E
C
Probably
you're
probably
saying
that
hey
there
could
be
android.
You
know
based
os
that
could
be
running
in
a
server
infrastructure
tomorrow.
Well.
E
C
Yeah,
so
I
I
don't
know
the
answer,
so
I
I
think.
E
I
think
the
fundamental
question
is:
do
you
think
the
client
side
telemetry
will
ever
go
to
the
same
end
point
as
any
of
the
back
end,
telemetry.
E
A
Let's
say
we
do
today,
for
both
our
internal
and
public
offerings.
E
C
Let's
say
you
know
you
could
have
component
equal
to
a
database
or
an
http
server,
but
then
you
could
also.
You
might
also
want
to
identify
whether
it
is
running
on
the
host
machine
directly
or
in
a
virtual
machine.
So
there
could
be
multiple
dimensions.
You
might
be
interested
and
and
and
using
the
same
attribute
for
for
multiple
purposes.
You
know
you
know
it
could
be
confusing
and
may
not
be
sufficient.
C
So
I
think
this
approach
has
some
drawbacks.
You
using
a
specific
attribute
to
you,
know
to
to
do
the
classification.
B
F
Yeah,
I
think
I'm
I've
just
had
this
feeling,
as
the
concept
was
introduced,
that
schema
url
gives
us
a
way
to
definitively
identify
something
so
that
you're
right.
The
current
definition
of
schema
format
has
been
exposed,
purpose
built
to
give
a
schema
conversion,
but
you
could
also
declare
a
schema
type.
You
could
declare
mandatory
fields,
you
could
declare
optional
fields
like
giving
a
schema
is
what
that's
for
so
so.
Conversion
is
nice,
but
having
a
schema
means
having
a
schema,
and
I
feel
like
what
we're
talking
about
here
is
that.
C
How,
how
does
how
is
it
represented
on
the
wire
that
for
every
attribute
use
you
also.
F
F
Resources
and
instrumentation
scopes,
also
known
as
instrumentation
libraries
both
have
the
field
as
I
understand
so
that
a
group
of
resources-
and
I
think
this
is
probably
a
question
that
should
go
to
tigran
in
the
in
the
bigger
audience.
Who's
been
developing
the
schema
url
concept,
but
you
can.
F
I
know
I
know
that
tigran
has
proposed
and
has
a
pr
open
to
say
how
do
we
identify
via
presence
or
or
absence
of
attributes,
and
that's
what
we've
been
talking
about,
but
I
think
that
you,
you
could
also
have
a
resource
and
give
a
schema
url
to
say
this
is
a
resource
for
a
particular
type
of
client
device,
and
not
reset
schema
could
declare
that
this
particular
type
of
client
device
must
have
these
fields
and
that
way
you
could
use
that
to
identify.
C
Yeah
and
we
I
I
think,
the
what
is
remaining
is
whether
to
use
you
know
just
a
few
attributes
to
cover
a
lot
of
situations
or
are
for
every
different
situation.
You
list
down.
You
know
a
specific
attribute
space.
You
know
specific
to
that
use
case
like,
for
example,
if
we
were
to
use
os
dot
name
equal
to
android
to
represent
hey.
You
know
this
is
coming
from
android.
Could
we
use
that
for
all
of
the
you
know,
mobile
operating
systems
so
for
for
windows
based
devices?
F
Well,
I
realize
that
I
have
spoken,
maybe
in
an
opinionated
way,
about
something
that
the
group
has
not
decided.
So
I
should
I
should
back
this
up.
Tigran
wrote,
you
know
that
pr
saying
you
there's
two
ways
you
could
identify
something
one
is
by
the
presence
of
certain
keys
and
one
is
by
the
value
of
certain
attributes.
F
F
Yes,
let
me
look
while
you
continue
talking,
I
will
find
some
links.
Okay,.
B
So
sometimes
I'm
wondering
like
would
it
be?
Would
it
be
maybe
useful
if
we
created
an
issue
and
yeah
for
like
you
know,
this
is
what
we
want
to.
This
is
what
we're
trying
to
do.
These
are
the
options
and
then
bring
bring
it
to
the
pc
to
discuss
it
in
the
specification
group
sure
so
I
can
I
can.
B
C
About
how
we
include
the
agent
in
in
the
application,
whether
it's
going
to
be
a
first
party
or
a
third
party,
because
yesterday,
when
I
was
thinking
about
implementing
the
storage
options
for
for
the
sessions,
there
are
restrictions
for
third
parties
on
on
the
cookies
and
local
storage.
C
So
it
occurred
to
me
that
so
far
for
vendor-specific
agents,
you
know
we
we
might
be
hosting
the
agent
on
like
third
party
domains
for
the
customers
to
include
in
in
their
application,
but
with
open
telemetry.
You
know,
given
that
customers
are,
are
free
to
take
the
agents
from
the
open,
telemetry
sources
and
then
instrument
their
application.
C
C
To
add
to
that,
I
see
that
there
are
distros
from
different
companies
like
there
is
an
aws
distro
for
open
telemetry.
Would
that
be?
Let's
say
you
know
in
future,
for
for
the
javascript?
Would
that
be
hosted
on
the
aws
domain
and
required
to
be
included
in
the
customers
applications
or
would
that
be?
A
C
Okay,
the
the
trouble
with
third
party
is
that
I
think
there
are
very
limited
options
for
storing
for
any
storage.
C
The
the
the
session
storage
and
local
storage
are
tied
to
the
domain,
so
so
third
parties
cannot
use
them
and
cookies
I'm
seeing
that
google
is
deprecating.
Our
is,
is
not
good
he's
going
to
stop
support
for
cookies
for
support
for
third-party
cookies
sometime
in
the
future.
C
So
third
parties
may
not
be
able
to
you
know,
set
cookies.
You
know
like
they
can
do
today.
C
So
there
might
be
some
restrictions
because
of
that.
A
Yeah,
the
the
third
part
of
cookie
restriction
is
based
on
who
owns
it.
Like
for
app
insights,
we
actually
set
the
host
as
the
the
page.
That's
loading,
so
it
really
is
about
sending
cookies
to
and
from
a
server
with
or
without
user
interaction.
So
really,
a
a
good
api
should
not
rely
on
on
that
occurring.
A
C
Yeah,
so
so
that
would
require
coordinating
with
the
customer
to
have
their
application
set.
That
cookie
right.
A
No,
the
sdk
can
set
the
cookie
itself,
but
the
the
app
insights
sdk
sets
the
cookie
in
the
in
the
current
domain
of
the
page.
That's
running,
we
get
pinged
all
the
time.
Oh
this
cookie
is
accessible
by
javascript
and
that,
rather
than
having
the
http
only
tag
so
but
yeah,
the
you
know,
the
sdk
running
in
a
page
can
manage
its
own
set
of
cookies
in
the
same
domain.
C
I
see
so
again
my
knowledge
is
limited,
but
I
thought
that
if
your
app
insights
script
is
loaded
from
a
cdn
which
is
a
different
domain,
can
it
set
a
cookie
on
the
the
the
applications
domain.
G
Aws
we
we
do
the
same
thing.
The
I
guess
the
the
one
advantage
of
cookies
over
this
session
storage
is
really
that
cookies
will
automatically
expire
at
some
point.
So
you
can
use
them
for
timing,
I'm
not
sure,
there's
a
huge
advantage.
Otherwise,
unless
you
need
to
send
the
data
with
every
request
because
to
the
host
as
well,
but
I
don't
see
that
as
a
use
case.
D
I
see
I
see
cookie
is
also
shared
between
different
tabs.
If
you
want
between
sub
domains
right
yeah,
no,
no.
C
C
Right,
you
know
you,
you
are
saving
something
on
on
the
local
computer,
but
then
you
know
it
gets
sent
to
the
server
as
well.
C
C
Okay,
I'm
sorry
this.
We
spoke
about
this
in
yesterday
in
the
context
of
sessions.
So
the
context
is
that
if
we
were
to
maintain
a
session,
that's
active
across
you
know
page
navigations.
You
know
you
need
to
persist
that
session
in
some
local
storage.
In
some
some
mechanism.
C
Right
so
for
that
you
know,
I
was
looking
at
you
know,
storage
options,
and
you
know
the
different
options
are
cookies
and
local
storage
session
storage.
The
index
db.
A
C
A
App
insight
uses
both
cookies
and
the
local
session
storage.
The
cookie
has
the
advantage
in
that.
If
the
back
end
is
also
instrumented
by
an
sdk,
it
can
actually
see
that
cookie
to
try
and
link
the
sessions
together,
which
is
how
we
did
it
before
trace
parent
headers.
A
So
sending
you
know
having
session
ids
in
cookies
is
a
good
thing
and
as
long
as
it's
documented,
I
I
don't
see
a
problem
with
that
and
it
would
be
a
case
of
the
effective.
The
domain
of
the
page
would
be
the
domain
of
the
server
that
has
been
you
know,
sent
to.
Hopefully,
if
you're
using
a
different
domain
for
different
backend,
then
it's
not
going
to
get
the
cookie.
So
it's
as
simple
as
that.
C
Okay,
typically,
any
data
that
is
propagated
to
the
other
services
is
through
the
package
api,
whereas
in
this
case
you
know
we,
instead
of
using
the
baggage
api,
the
baggage
headers,
we
would
be
using
a
cookie
and,
and
then
the
name
of
the
cookie
could
be
a
semantic
convention.
So
we
standardize
it
so
there's
a
small
difference.
There
yeah.
A
A
What
I'm
supposed
to
be
talking
about
is,
if
you're
doing
a
classic
server-side
post
you
know
so
so
it's
a
multiple
page
load,
that's
where
the
cookie
has
the
advantage,
because
it
can
stitch
together,
multiple
sessions
or
multiple
page
requests,
as
opposed
to
being
a
spa
and
doing
everything
via
ajax.
A
A
A
G
It
also
depends
on
the
size
of
the
information
you
want
to
store.
So
if
you're
storing
more
context
than
simply
the
session
id,
then
you
probably
don't
want
to
use
cookies,
because
there
is
a
cap
on
the
amount
of
data
you
can
store
and
application
owners.
You
know
they
generally
don't
want
you
using
up
a
lot
of
their
cookie
space.
So
if
it's
just
session
id
it's
it's
probably
fine,
but
if
you're
storing
more
context
information,
then
you
probably
want
to
use
a
different
browser.
Storage.
A
Yeah,
there
are
also
limits
of
for
session
and
local
storage,
which
we
have
to
for
our
internal
offerings,
because
we
support
office
and
everything
they
use
social
local
storage
quite
heavily
and
constantly
hit
bump
up
to
the
limits,
so
it
restricts
what
we
can
do
as
a
an
sdk
provider
for
them,
so
yeah,
just
having
the
id
is,
is
good.
I
wouldn't
go
and
persist
like
the
the
entire
config
to
try
and
rehydrate
it
between
sessions.
That
would
be
a
problem.
C
C
C
Do
you
want
to
go
back
to
the
schema
url
discussion
josh?
Could
you
go
over
what
you
mentioned
here.
F
F
This
will
be
a
tool
to
let
us
change
schemas
over
time-
and
I
am
personally
aware
of-
I
guess
what
I
want
to
call
schema
conflict
in
this
telemetry
world,
like
prometheus
systems,
have
a
pretty
well-defined
schema,
which
says
that
there's
a
job
and
an
instance
label
which
are
identifying
information
and
if
you
have
two
jobs
and
instances
that
aren't
the
same,
like
you
have
a
real
conflict.
That's
what
the
advantage
of
that
schema
is
that
I
know
job
and
instances
are
unique,
but
only
prometheus
systems
do
it.
F
That
way,
and
my
my
feeling
is
that
having
a
schema
tells
gives
us
the
power
to
say
what
is
identifying
and
what
it's
not
identifying.
It
might
help
us
solve
service
discovery
problems
which
is
kind
of
what
prometheus
is
good
at
and
but
I,
but
I'm
kind
of
saying
it's
like
a
blank
piece
of
technology
that
we
haven't
finished
in
the
sense
and
whenever
I
guess
I
feel
that
we're
not
done
with
defining
it.
So
I
I
throw
it
out
as
a
potential.
F
I
mean
to
to
tell
you
my
thinking
more.
I
would
have
to
give
you
a
brief
diversion
here,
but
I'm
interested
in
the
prometheus
system
has
this
service
discovery
mechanism
which
lets
you
identify
all
your
targets
now.
I
know
that
prometheus
is
pretty
far
away
from
the
client
world
that
many
of
you
are
thinking
in
right
now.
F
But
let
me
proceed
so
the
prometheus
system
goes
out
and
discovers
all
the
targets
that
it's
going
to
scrape
and
then
it
scrapes
them
all
and
each
one
of
those
will
have
a
job,
an
instance
when
you're
done
and-
and
this
gives
the
prometheus
server
the
power
to
attach
all
these
extra
labels
that
might
be
out
there
in
the
infrastructure.
So
I
know
my
cube
cube
service
name,
and
I
know
this
stuff
that
comes
from
kubernetes.
It
doesn't
come
from
the
process
itself.
F
The
thing
is,
you
have
to
do
it
the
prometheus
way
to
get
the
advantage
of
that
system,
and
I
was
so
the
thought
experiment
was:
do
we
have
a?
Is
there
a
way?
Could
we
have
a
way
to
push
data
from
an
otlp
producer
like
an
sdk
that
doesn't
have
a
port
open?
That
has
no
way
to
be
talked
to
externally?
I'm
going
to
push
my
data,
I'm
going
to
identify
myself
in
some
way,
and
that
is
the
question
before
us.
F
I
will
identify
myself
in
some
way
and
then,
when
the
infrastructure
receives
my
data,
it
will
know
how
to
identify
me
because
of
something
that's
where
I
think
schema
url
could
answer.
So,
if
I
say
I'm
an
open,
telemetry
schema,
I
have
a
service
name
and
a
service
instance
id
those
are
my
identifying
attributes.
I'm
going
to
send
my
data
to
the
infrastructure.
It's
going
to
do
some
service
discovery.
It's
going
to
find
that
there
is
supposed
to
be
a
service
with
a
certain
name
and
a
certain
instance
id
now.
F
It's
able
to
join
infrastructure
information
with
client
info.
You
know
with
telemetry
produced
by
an
sdk,
but
the
key
to
that
working
was
that
I
had
to
know
that
some
data
has
job
and
instance,
as
it's
identifying
attributes,
and
some
data
has
some
other
way
to
identify
itself
such
as
service
name
and
instance
id,
and
I'm
I'm
starting
to
be
aware
of
other
other
metric
systems
in
the
world
that
have
other
identifying
sort
of
coordinate
systems.
But
in
addition
to
those
coordinates
job
and
instance,
you
have
all
these
other
attributes.
F
I
was
proposing-
and
I'm
done
speaking
now,
that
that
we
could
use
schema
url
to
encode
information
such
as
to
be
one
of
these
schema
urls.
To
be
one
of
these
schemas,
you
must
have
these
identifying
attributes
and
then
you
are
considered
one
of
these
things,
and
that
way
you
could
say
we
are
the
client
schema
or
we
are
the
windows
client
schema.
I
must
have
these
attributes
to
identify
me.
C
Is
it
something
similar
to
an
enum
where
you
have
predetermined
possibilities
and
and
then
you
know
listed
somewhere
and
then
you
you
point
to
one
of
them
and
and
if,
if
you
were
to
add
one
more
to
the
category
you
you
have
to
register
actually.
F
And-
and
this
is,
I
think,
up-
opportunity
for
open
telemetry
to
answer
some
questions
like
it
is
a
url.
So
the
idea
is
that
you,
you
could
fetch
that
url
and
get
a
yaml
file.
That
would
define
your
schema
so
that
this
allows
an
external
contributor
to
create
their
own.
Maybe,
but
then
I
think
that
open
telemetry
is
also
trying
to
have
a
standard
schema
and
I
think,
the
probably
the
and
and
right
now
we've
kind
of
created,
one
schema
with
a
lot
of
optionality,
and
so
there's
no
schema
thing.
F
That's
there's
no
schema
url
that
is
tailored
to
services
in
the
back
end
environment,
there's
no
schema,
url
tailored
to
client
applications,
and
therefore
we
have
one
schema
to
fit
everything
and
it
does
give
us
this
ability
to
do
schema
change,
but
it
doesn't
give
us
the
ability
to
identify
styles
of
telemetry
and
I
think
it
could
have.
I
answered,
I
think
it's
vague
yeah.
No.
I
like
the
idea
josh.
A
Like
internally
like,
if
you
look
at
the
examples
that
I
pasted
in
the
chat,
there's
a
couple
of
key
fields
that
effectively
make
up
the
equivalent
of
the
schema-
and
that
is
like
the
name
field,
where
it
says,
like
your
microsoft-
application
insight
that
identifies
that
it's
a
client,
the
my
instrumentation
key
is
just
like
it's
a
good
normally,
but
this
is
my
sample.
A
The
exception
says:
okay,
I'm
playing
with
an
exception,
and
if
you
whiz
down
to
the
data
section,
which
is
where
the
the
guts
of
the
the
thing
is,
the
base
type
identifies
like
if
you're,
like
the
the
first
part
of
the
the
schema
name,
and
then
the
ver
identifies
the
version
of
that
schema,
so
the
backend
knows
how
to
pull
it
apart.
So
yeah,
I
like
the
idea
of
using
a
schema,
url
to
say,
okay.
Well,
this
is
how
we
represent
a
page
view.
This
is
how
we
represent
an
exception.
A
F
F
I
think
one
of
my,
if
I
may
one
of
my
background
sort
of
hopes
and
dreams
here,
is
that
if
telemetry
begins,
having
more
schema
information,
we
may
begin
as
vendors
being
able
to
automatically
produce
more
useful,
more
semantically,
conceptually
clear
dashboards,
so
that
you
know,
if
I'm
looking
at
a
page
of
graphs
that
all
have
the
same
schema.
F
In
some
loosely
defined
sense,
you
know,
I
know
what
my
target
variables
are
on
that
page.
So
if
I'm
looking
at
a
page
for
prometheus
graphs,
I
know
that
I
can
graph
every
single
plot
on
that
screen
by
job
and
instance.
That's
really
useful
information
that
as
a
telemetry
vendor
I
would
like
to
know,
and
but
if
it's
different
type
of
data
plotting
by
a
job,
an
instance
is
not
going
to
help
me
so
that
potentially
we
can
get
more
automatically
useful
dashboards
out
of
this
type
of
field.
G
We
also
like
to
use
these
things
for
things
like
validation
of
data,
since
it
is
coming
from
the
client
we
we
like
to
to
do
a
bit
of
extra
validation
and
then
yeah
the
use
case
of
being
able
to
interpret
that
data
once
it's
in
our
system
is
also
super
valuable.
C
A
B
Okay,
so
I
think
what
I
want
to
do
is
open
open
the
issue
with
the
out
the
different
options
of
that
we
talked
about,
and
the
schema
is
gonna
be
one
of
those
options.
I
mean
that
sounds
that
sounds
good
to
me
too,
and
if
it's
something
that
you
know
tigran
and
others
give
thumbs
up,
maybe
we
can
go
in
that
direction.
B
Okay,
we
are
at
time
I'm
just
gonna
move
the
the
last.
The
last
topic
that
I
had
is
I'm
just
gonna
move
it
to
the
next
time.