►
From YouTube: 2022-05-18 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
B
Yeah
so
yesterday
we're
talking
about.
B
B
How
do
we
so
so?
The
issue
is
we
want
to
validate
and
in
some
cases
we
want
to
validate
the
data
that
is
coming
into
the
system,
so
the
the
the
attributes
in
the
event
we
want
to
make
sure
that
they
are
they
exist
and
the
the
types
are,
the
the
types
that
we
expect
and
there
isn't
anything
extra
in
in
some
cases
and
so
we're
talking
about
what
should
the
event
dot
name
field
contain.
B
Should
it
be
something
like
a
user-friendly
name,
or
should
it
be
a
globally
unique
identifier
that
points
to
a
specific
schema
and,
and
does
it
involve
the
is
that
in
combination
with
the
resource
so
like?
Is
it
a
browser.event
schema
or
do
schemas
span,
potentially
multiple
domains
like
mobile
and
and
javascript?
So
we're
talking
about.
B
A
Does
it
well
in
that,
if
you
have
some
schema
that
defines
like
how
all
of
the
data
should
look
like,
then
we
have
to
change
it
every
time
we
want
to
want
to
add
new
stuff
or
how
does
that
work.
C
Yeah,
that
was
my
concern
as
well.
I
think
we're
more
looking
at
we'll
define
a
set
of
known
events
with
an
optional
section
for
just
random
objects,
but
that
doesn't
preclude
third
parties
from
creating
your
own
event
with
their
own
set
of
accidents.
C
Personally,
I'd
like
to
see
the
validation
primarily
done
on
the
back
end,
but
we
could
optionally,
have
you
know
some
additional
component
that
could
be
loaded
on
the
front
end
so
that
developers
can
validate
it
before
they
even
get
sent
out
the
door,
but
you
wouldn't
use
that
in
production
from
a
size
perspective.
A
B
A
Let's
say
we
have
something,
let
let's
say
span
id:
it
will
be
some
something
invalid
and
it
fails
to
schema
what
happens
you
just
throw
it
away
or
that's
for
the
back
end
to
decide,
because
the
problem
will
have
with
ram
data.
Is
that
you
get
all
of
these
invalid
data
for
like
timings,
don't
make
sense
they're
like
let's
say,
timing
is
minus
one
when
it
should
be
like
whatever
timestamp
but
and
you
want
to
somehow
still
get
this
data
all
of
all
the
time.
So
you
know
that
it's
wrong.
C
B
B
Yeah
and
different
levels
of
trust
between
users,
so
like
an
internal
system,
you're
going
to
treat
the
data
differently
than
data
coming
from
the
public
space
as
well.
So
I
mean
that's
what
that's
probably
our
primary
concern.
B
A
C
Yeah,
I
think
the
the
other
thing
martin
brought
up
yesterday
was
it's
it's
also
to
do
with
versioning
of
the
schema
so
that
the
backend
knows
how
to
process
the
young
request.
C
So
my
view
would
be
where
they
just
have
the
event
name
as
as
fixed,
so
it's
like
my
dot
event
or
whatever,
but
we
could
have
a
schema
field.
That
identified
the
version.
I
think
martin
was
leaning
more
towards
the
the
name
being
without
having
the
schema
encoded,
either
way
works.
It
doesn't
really
make
a
great
deal
so
that
way
in
the
future
we
can
go
okay
version.
One
has
this
set
of
fields.
Version
two
now
has
optionally
this
additional
set
of
fields,
because,
of
course
we
have
to
be
like
non-breaking.
C
I
thought
yesterday
button
was
talking
about
in
a
separate
schema
field,
but
it
works
either
way.
It
doesn't
really
make
a
great
deal
of
difference
because
you're
going
to
have
a
particular
instance
there's
always
going
to
like
unless
it
hot
reloads
on
the
fly.
It's
always
going
to
be
the
same
schema
that
it's
generating.
C
C
Yeah
yeah,
I
I
think
the
schema
really
is
about
the
the
fields
that
we
want
validated
because
I'm
like
with
martin
here,
I
prefer
just
to
have
a
a
a
field
that
just
is
anything
the
user
likes.
C
C
This,
like
for
internal
systems,
that's
the
internal
system
so
so
effectively
we
have,
we
have
application
insights,
and
then
we
have
our
internal
version,
that's
built
on
top
of
that,
but
they
actually
go
to
two
different
backends,
although
even
in
the
public
one,
we
have
a
generic
data
object
that
people
can
just
drop
in
their
own
thing
so
effectively.
C
We
have
a
fixed
set
of
fields
and
then
there's
a
data
blob
and
that
just
ends
up
in
properties
in
the
azure
monitor
ui,
and
if
it's,
if
we
can't
decode
it
properly,
it
just
ends
up
in
there
as
a
stringified
jason.
Bob.
D
Regarding
schema,
versioning,
more
exotic
problem
that
often
arises
in
from
mobile
clients,
it
depends
how
you
distribute
them,
but
it
could
possibly
happen
that
the
client
has
a
higher
schema
version
than
the
the
backend
system.
C
My
approach
to
that
would
be,
it
would
depend
on
it.
It
would
be
up
to
the
back
end
how
it
dealt
with
this.
Would
it
completely
reject
the
event,
or
would
it
just
try
and
go
okay?
Well,
it's
the
latest
version
that
I
know
I'll
try
and
deal
with
it
that
way
and
validate
based
on
that,
but
that's
always
a
problem.
You
hope
you
never
get
in
that
situation,
but
it's
gonna
happen.
C
Especially
their
customers
changing
providers,
they
might
be
in
provider
a
that
supports
the
latest
schema
and
they
switch
to
provider
b.
That
doesn't
exactly.
B
E
Hi,
I
I
I
don't
have
the
full
context,
but
I
I
want
to
quickly
answer
that
question
on
how
the
existing
the
schema,
open,
telemetry
schema,
is
handling
that
so
they
it's
like
a
you
know,
database
migration
chain
right.
You
know
you
you
have
to.
They
basically
tell
you
the
sequence
of
transformation
of
the
attribute
names
from
one
version
to
another.
E
So
similarly,
so
basically
you
know
any
receiver.
If
you
know
if
they
support,
let's
say
version,
20
and
and
the
client
is
sending
let's
say
version
10,
then
they
have
to
apply
those
series
of
transformations
from
10
to
20
on
those
attribute
names.
So
the
the
name
of
the
attribute.
If
let's
say
it's
changes,
you
know
between
these
versions.
E
So
similarly
any
schema
change
that
we
are
going
to
have
needs
to
be.
You
know
backward
compatible
in
a
sense.
There
has
to
be
a
defined
path.
How
you
you
know,
go
from
one.
You
know
schema
version
to
another
schema
version.
Let's
say
you
drop
just
just
like
you
know
a
database
typical
database
migration.
So
you.
E
E
You
know
an
older
version
of
your
message
confirming
to
an
older
version
of
the
schema
to
the
version
that
it
supports.
But
if
let's
say
it
receives
an
a
payload
that
confirms
to
a
newer
version
that
it
doesn't
support
yet
then
yeah
then
I
think
it
it
has
to
drop
it.
But,
as
you
can
see,
you
know
this
is
making
the
you
know
schema.
You
know
quite
complex,
so
yeah.
I
think
we
will
have
to
compromise
on
a
few
things
and
identify
a
middle
ground.
B
E
Like
an
easy
thing,
because
it's
something
that
the
open
telemetry
committee
I
mean
our
open
telemetry
already
has.
E
So,
rather
than
inventing
something
totally
new,
you
know
we
could
extend
the
you
know
that
schema
okay.
E
Yeah
we
we
certainly
don't
want
to
make
it
so
complex
to
make
it
fully
foolproof
it.
I
think.
Definitely
you
know
it.
May
not.
I
mean
it
will
not
have
all
the
robust
features.
If
we
were
to
you
know,
keep
it
simple.
B
Right
and
it
supports
like
the
idea
of
customization
right
and
it
doesn't
have
to
be
a
full
full
schema.
B
I
guess
that's
probably
a
silly
question
like
you:
can
you
can
in
your
schema,
you
can
define
just
blobs
of
stuff
or
you
know
that
additional
attributes
can
be
added
yeah.
E
Yeah
I
mean
some:
some
of
the
attributes
can
have
like
a
free
form,
data
type,
any
and
and
then
you
know
we
will
not
do
any
validation,
but
maybe
we
will
do
a
size
validation,
not
a
type
validation
on
that.
D
I
would
have
another
question
related
to
the
name
discussion
from
yesterday,
so
I
had
a
quick
chat
with
one
of
our
product
managers
and
he
told
me
for
from
his
point
of
view,
a
human,
readable
name
or
the
possibility
to
transfer
a
human,
readable
name
would
be
very
interesting,
because
that's
something
that
we
would
like
to
show
in
our
system
and
lots
of
tools
already
do
this.
E
To
the
names
of
the
attributes
that
we
were
looking
at
from
the
ecs,
the
elastic.
D
F
So
is
the
idea
like
similar
similar,
like
so
that
if
you
have
some
kind
of
visualization,
but
you
don't
have
to
you-
don't
have
to
like
generate
the
names
of
the
events
that
you're
displaying
to
the
user
right
like
you,
would
just
display
what
was
provided
by
the
instrumentation.
D
E
When
we
review
the
the
semantic
conventions
in
in
the
other
document
that
martin
has
where
we
are,
we
are
essentially
listing
down
for
each
event.
You
know
what
are
the
different
attributes.
We
want
to
capture
yeah,
we
at
least
you
know
this
team
you
know,
can
ensure
that
you
know
those
names
are
or
we
can.
You
can
get
it
reviewed
from
your
product
manager
as
well.
E
C
C
You
don't
want
to
use
the
text
because
once
you
get
into
translations
that
just
it's
just
silly
but
you'd
have
some
sort
of
programmable
id
that
you
pick
up
in
the
case
of
the
browser,
we
have
like
a
quick
analytics
plugin
and
it
would
get
the
id
from
either
the
id
attribute
the
name
attribute,
or
you
can
actually
have
a
data
dash
attribute
that
we
can
pick
up
from
that.
So
I
think
that's
just
as
santosh
has
already
said.
C
D
Name,
I
would
opt
for
that,
so,
of
course
you
will
need
something
that
identifies
the
kind
of
the
the
the
id
of
a
button
or
the
view
id
or
something
to
identify.
Where
did
it
happen
if
you
want
to
have
aggregated
fuels
on
on
such
values?
But
in
addition,
I
think,
and
a
human
readable
name
would
also
be
a
very
good
option.
B
B
C
I
I'd
change
the
the
definition
and
say
we
provide
a
field
called
id
and
then
it's
up
to
the
application.
What
the
value
of
that
field
is,
whether
it's
human,
readable
or
a
number
or
some
other
good.
C
F
I've
been
thinking
about
it
like
like
similar
to
like
what
span
name
is
right
now,
like
spam
name
like
doesn't
define
the
what
the
span
is
but
like
in
like
a
distributed,
distributed,
tracing
anal,
you
know
analytical
tool
like
you
can
just
display,
like
the
just
bad
name
and
like
you
know
that
it's
gonna
be
descriptive
of
what
what
it
is
like
to
like
a
human
person
right,
end
user.
G
F
G
Yeah,
I
think,
in
our
product
we
do
not
like
put
any
customized
or
human
readable
name
to
the
pillows,
and
we
do
that
in
the
back
end,
we
have
a
like
a
kind
of
rules
that
are
defining
what
kind
of
events
that
are
represented
based
on
the
payloads.
G
I
think,
if
we
do
this
in
the
front
end,
we
invitably
need
to
put
a
very
long
list
of
like
a
room
matching
to
the
actual
name
in
the
front
end,
and
that
might
not
be
not
big,
a
good
idea
and
seeing
good
idea
to
doing
the
content,
especially
we
have
a
very
long
list
of
with
whatever
customized
event
name
that
you
want
to
match
for
the
front
end.
A
G
One
thing
is
that
if
we
change
the
the
like
definition
or
the
even
name,
then
historical
data
won't
change
since
it's
being
defined
in
the
collection
time.
But
if
we
pass
that
to
the
back
end,
we
can
always
retractly
change
the
event
name
later.
F
F
So
I
joined
a
little
bit
late.
I
think
there
was
a
discussion
about
the
schema.
F
Okay,
what
I
wanted,
what
I
wanted
to
do
is
we
can
we
can
continue
working
on
the
semantic
conventions,
but
before
we
do
that,
I
wanted
to
I've
been
thinking
it
might
be
useful
to
to
do
a
quick
status
update
where
we
are
like
with
the
whole
project.
I
don't
know
if
they'll
be
useful.
E
And
yeah,
I
think
I'm
I'm
interested
in
talking
about
that
too,
especially,
you
know,
given
that
the
logs
api
spec
is,
you
know
close
to
you
know
being
ready.
I
I
have
to
work
out.
Maybe
you
know
one
or
two
open
questions.
I
have
a
meeting
with
the
locks
sick
today,
with
with
that,
I
think
you
know
we
could
start
implementing
the
api
spec
and
then
it
it's
ready
available
to
implement
the
the
different
events.
E
Now,
the
only
blocker,
as
far
as
I
know,
for
from
a
functionality
perspective
is
the
sessions.
So
how
much
of
a
you
know
blocker?
Is
that
because
it
looks
like
you
know,
that's
that
might
take
more
time.
E
So
can
we
go
ahead,
create
the
ram
you
know
overall,
the
bigger
tap
for
for
ram
as
a
you
know,
as
a
separate
product
domain,
can
we
go
ahead
with
the
tip
for
it
without
the
sessions
or
go
with
the
sessions
in
an
alternate
temporary
way
or
wait
until
the
sessions
aspect
is
ready?
E
That's
number
one
and
number
two.
I
also
want
to
know.
Maybe
you
know
not
necessarily
you
know.
We
need
to
answer
that
in
this
call,
but
we
should
start
defining
what
is
the
minimum
set
of
features
minimum
set
of
functionality
you
know
required
for
for
a
think
of
it
as
a
1.0.
You
know
release
and,
and
then
we
should
start
creating
issues
and
and
then
create
a
plan.
E
F
Yeah,
so
I
basically
write
wrote
down,
which
is
what
you
just
said
with
some
additional
things,
and
I
I
agree
so
so
we
have
yeah.
We
have
like
a
few
different
like
categories
of
work
that
we
have
started
like
you,
you
sometimes
you
have
talked
about
the
events.
You
have
the
events8
proposal
out
there
and
I
agree
that
we
could.
F
We
could
start
implementing
a
prototype
of
that
of
that
api,
actually
like
in
the
in
the
in
the
sdks
in
the
existing
sdks
and
with
the
intent
that
they
could
actually
be
merged.
F
You
know
like
both
like
the
the
js
sdk
and
I
think
java
as
well,
have
like
experimental
experimental
packages.
So
I
can.
I
can
see
this
being
an
experimental
package.
You
know
probably
without
a
problem.
C
F
C
C
F
Yeah
yeah,
so
I
I
don't
yeah.
I
I
think
I
asked
at
the
js
sig
meeting
last
week,
but
the
plan
is
for
implementing
the
the
logs
sdk
and
I
think
dan
was
saying
that
it's
that
it's
coming
soon
like
within
about
the
next
couple
of
weeks
or
so.
C
F
F
E
On
the
exporter,
I
had
a
question
I
I
was
thinking
to
submit
an
issue
in
respect
to
you
know,
get
feedback
about
having
a
common
expert
like
merging
the
you
know.
Three
experts
are,
rather,
you
know
different
exporters
into
one,
the
reason
being
you
know
so
far
in
our
existing
products.
You
know
all
the
data
was
going.
You
know
in
in
one
api
call
now
each
of
the
you
know
traces,
metrics
and
logs
have
their
own
exporter.
E
So
there
will
be
separate
api
calls
to
send
the
data,
which
is
probably
unnecessary.
E
So
I
I
want
to
explore
if
they
can
be
combined,
that
is,
there
is
one.
Secondly,
you
know
what
are
you
guys
thinking
protobuf
versus
json
and
grpc
versus
http?
What
what
support
exists
today
for
the
javascript.
C
F
C
C
E
Okay,
but
what
is
the.
C
But
it's
gonna
depend
on
the
client
right
so
for
browser.
I
would
only
be
using
json
for
mobile
apps.
It
would
make
sense
to
use
protobuf
because
you
can
more
readily
package
it
up
in
in
binary
form.
C
So
I
think
we
probably
want
both
eventually,
so
my
focus
is
gonna
be
adjacent.
A
Actually
have
a
otlp
exporter
for
js
that
works
in
browser
for
logs.
We
built
it
it's
like
experimental,
but.
E
Okay,
okay,
so
far
for
the
browser
world,
we
will
go
with
http
with
json
right
and
for
for
mobile.
Do
we
have
any
representation
from
mobile
here?
Anybody
who
understands
the
mobile
aspects
well.
E
F
So
I
think
in
general,
like
in
bid
mobile,
like
we
need
more
participation,
like
we've,
been
very
much
focused
on
browser
in
this
group,
and
I
wanted
to
actually
ask
all
of
you
like
if
you,
if
you
know,
if
you
can,
if
it's
possible
for
you
to
reach
out
like
within
your
companies
like
for
engineers
like
who
might
be
participating
to
be
with
prototyping
and
the
implementation
work,
then
that
would
be
great.
F
Okay,
I
think
what
I'm
also
going
to
do,
I'm
going
to
go
to
the
swift
and
javascix
and
and
ask
there
if
there's
if
they
can
help
us
find
someone.
D
Right,
so
what
I
got
confirmed
from
our
management
is,
I
have
a
20
resource
working
on
anything
that
we
intend,
so
we
have
mobile
developers
who
can
work
in
java.
We
also
have
swift
and
objective
c
developers,
so
I
have
some
resources,
but
not
that
many.
F
F
All
right
so
moving
on
to
this
to
the
sessions
stream,
so
we
had
a
lot
of
discussions
around.
I
think,
like
you,
said
santosh
like
we're
kind
of
stuck
on
where
exactly
to
put
the
session
in
the
data
model,
the
last
there
is
a
I
think,
ted
mentioned
that
he
he's
going
to
work
on
a
proposal
for
updatable
resources.
F
So
I
think
it's
that's
something
that
that's
gonna
work
on
and
I'm
I'm
helping
with
like
I'm
working
on
tigran
asked
for
if
you
can
estimate
like
the
overhead
for
adding
session
attributes
to
individual
signals,.
E
If
we
want
to
do
that,
I
I'm
thinking
we
should.
I
don't.
E
The
I
think
I
think
we
should
push
back
the
reason
being
any
shortcuts
we
take
right
now.
I
think
it
it's
going
to
you
know
we'll
be
stuck
with
that
forever.
Yeah.
C
I
agree
and
and
like
for
the
duplicated
attributes,
there's
going
to
be
more
non-duplicated
attributes
than
duplicated
ones
and
then
that
well
just
come
up
with
the
you
know
the
argument
that
well
it's
only
like
less
than
one
percent
of
the
payload
so
yeah.
E
So
I
I
feel
like
we
should
go
without
sessions
sessions
or
only
microsoft
has
sessions
in
in
their
current
agent.
You
know,
but
I
I
don't
know,
if
others
we.
E
E
I
think
it's
okay,
so
then
what
do
you
think?
Should
we
go
ahead
with
tigran's
suggestion
of
putting
it
in
the
in
the
individual
spans
and
locks
spans
and
even.
A
C
Yeah,
my
approach
is
slightly
different.
I
think
we
just
say:
let's
get
the
proposal
out
and
say
we
rely
on
having
the
resources
for
the
session
and
we
just
keep
moving
forward,
and
then
we
have
a
whole
right
up
until
we
release.
C
So
if
the
resources
looks
like
it's
not
going
to
go
ahead,
then
then
we
then
say
fine,
we'll
compromise
and
put
it
into
an
attribute
because
santosh
said,
if
we
put
in
that,
if
we
define
it
as
putting
it
after
we
in
the
first
version,
that's
it
it's.
It's
not
going
to
get
pulled
out
because
the
pushback,
along
with
like
the
estimating
the
duplicate,
will
be
but
you're
ready
to
find
it.
There
you've
got
to
be
backward
compatible.
So
I
I
think
we
just
say
we
want
it
up
in
the
resources.
C
So
therefore
we're
going
to
define
it
based
on
we're,
relying
on
the
ted's
resource
proposal
and
then
on
the
clock.
E
But
there
is,
there
are
more
reasons
right.
I
think
we
are
not
talking
about
just
one
attribute.
We
are
talking
about
multiple
attributes.
Oh.
E
Yeah,
so
so
I
I,
I
strongly
feel
that
we
should
give
it
more
time,
but
go
ahead
with
the
rum
proposal
without
the
sessions
for
now.
E
No,
so
there
won't
be
any
overhead
right,
I
think
the
pro.
I
don't
understand
that
overhead.
You
know,
how
do
you
analyze
it
like?
We
are
talking
about
one
browser,
client,
right,
yeah,.
A
C
E
E
Be
there
so
so
how
does
it
function
the
current
batch
exporter?
Does
it
export
every
minute.
E
A
C
Yeah,
so
for
us,
our
internal
version
exports
by
default,
which
can
be
changed
every
one
or
two
seconds,
depending
on
the.
We
have
this
concept
of
whether
an
event
is
critical
and
for
app
insights.
It
defaults
to
30
seconds
so.
E
That
actually
goes,
you
know
the
other
direction
right,
so
this
the
more
frequent
you
send,
the
smaller
the
payload
will
be
the
smaller.
The
number
of
events
will
be,
and
therefore
it
doesn't
matter
whether
you
put
the
session
id
in
the
signal.
C
Yeah,
there's
a
variety
of
reasons
why
you
want
to
change
it
so,
depending
on
the
team,
we
have
some
teams
that
send
on
startup
of
you
know.
Hundreds
of
events
you've
also
got
the
time
required
to
serialize
the
the
object
into
into
a
string.
The
more
events
you've
got,
the
more
stuttery
the
the
ui
becomes
versus
the
amount
of
memory
that
you're
holding
while
you're
batching
these
things.
So
it's
a
trade-off,
which
is
why
we
have
as
a
config,
and
we
can
change.
F
Okay,
I'm
gonna
just
we
have
like
five
minutes
left,
so
I'm
just
gonna
go
through
this
really
quick.
So
we
can't
talk
about
the
sessions
like
we.
I
think
we
agree
that,
like
we
need
need
some
envelope
or
someplace
like
to
put
shared
attributes,
so
I
think
we're
just
gonna
continue
pushing
on
that.
F
Then
there
is
still
this
classification.
I
I
opened
an
issue
a
while
ago
and
the
the
two
options
for
browser
we
could
either
implement,
use
the
process,
runtime
name
attribute,
which
is
already
defined.
We
just
have
to
implement
it
in
the
js
sdk
or
we
could
use
the
browser
attributes
which
are
about
to
be
merged
in
the
spec
soon,
but
we'd
have
to
probably
make
some
of
those
one
of
those
attributes
required.
F
So
I
think
either
one
would
would
work,
I'm
kind
of
leaning
towards
the
first
one.
It
just
needs
to
be
implemented
based
on
the
spec
and
for
mobile
options.
There's
there's
a
few
few
different
options
here
and
something
somebody
just
needs
to
take
it
and
create
a
proposal.
C
C
C
F
C
F
Okay,
so
anyway,
if
somebody
wants
to
take
this
and
create
a
proposal,
I
think
about
this.
F
That's
up
for
grabs,
then
I
think
the
browse
for
semantic
conventions-
that's
this
is
the
work
in
progress
right
now,
and
the
browser
attributes
that
are
going
to
be
emerged
in
the
spec
would
be
could
be
implemented
in
the
in
the
js
sdk
and
beyond
this
I
know,
neff
you've
talked
about
the
current
js
sdk,
not
being
suitable
for
your
player,
so
I
think
we
can
start
thinking
about
what
like
a
browser,
optimized
sdk
would
look
like
what.
C
A
mini
version
yeah,
so
the
problem
I've
got
is
my
time.
So
I
think
I've
mentioned
before
our
team
is
actually
relatively
small
and
we're
actually
a
man
down
at
the
moment.
So
I
I
manage
both
the
app
insights
and
the
internal
version
for
the
entire
company,
so
it's
we're
leaning
to
move
to
hotel,
but
I
things
keep
getting
in
the
way.
Maybe.
C
Yeah
yeah,
that's
what
I've
been
trying
to
get
to.
We
just
did
a
release
which
is
going
to
be
interesting
to
try
and
get
hotel
to
work
where
we
now
support
fully
unloading,
the
sdk
for
an
internal
team
so
effectively
they
get
yes.
C
The
an
sdk
instance
gets
loaded
into
a
into
a
div
and
when
they
close
that
that
div
we
completely
unload
and
I've
got
a
follow-up
version
of
that,
where
I'm
going
to
like
add
the
ability
to
update
the
config
on
the
fly
most
of
which
I
have
no
idea
how
I'm
going
to
make
the
motor
once
we
want
to
flip
out
and
put
hotel
under
the
cabins.
A
I
mean
config
on
the
fly:
okay,
I'm
taking
the
last
few
minutes,
but.
C
Now
this
is
for
eutb,
so
so
the
the
the
the
client
detects
that
okay,
this
user
is
a,
is
a
european
user.
So
therefore
we
have
to
send
the
data
to
a
different
endpoint.
C
A
C
Yeah,
I
think,
ideally,
we
probably
want
to
take
the
the
api.
If
we
can,
I
think
it's
probably
still
too
big
and
then
just
build
our
own
sdk,
using
minification
techniques
to
keep
the
damping
small.
F
Yeah,
so
I
just
wanted
to
list
list
out
these
things
like
if
folks
are
looking
for
places
to
contribute.
There
are
a
number
of
places
where
like
which
needs
attention.
F
Like
what
I
might,
what
I
was
thinking
about
focusing
on
myself
is,
I
was
I
wouldn't.
I
would
like
to
start
working
on
the
the
events
api
prototype
in
the
in
the
js
sdk,
so
that
it
can
so
that
that,
like,
as
we
talk
about
semantic
conventions
like
we
can
actually
implement
instrumentations,
they
like
demonstrate
what
the
data
is.
C
F
Okay,
we
didn't
get
the
semantic
dimensions,
but
we'll
just
continue
next
week.