►
From YouTube: 2021-01-06 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
A
B
B
Okay,
so
I
think
you
know
my
focus
right
now
is
on
the
api
and
getting
it
ready
for
1.0.
So
that's
what
most
of
this
agenda
is
about.
B
If
anyone
else
has
anything
that
they
want
to
bring
up,
feel
free
to
add
it
to
the
agenda
as
we
go,
but
I
just
wanted
to
pull
out
some
issues
and
prs
related
to
api
preparation.
B
You
know
basically
you're
ready
to
go.
Some
of
them
are
not
really
these
first
two
pr's
are
ones
that
I
made
and
this
one's
actually
a
draft
this
this
first
one
I
feel,
is
important
when
we
go
to
1.0.
B
What
it
does
is
it
uses
the
current
version
of
the
api
package
to
check
compatibility
instead
of
having
a
version
like
an
identifier
that
we
manually
increment,
I'm
not
sure
who
is
familiar
with
our
current
api
version
compatibility
check
function,
but
that
was
sufficient
when
we
were
in
alpha
and
beta,
but
once
we
got
a
1.0,
I
think
we
should
have
a
more
solid
solution
in
place,
so
I
did
create
a
pr
that
uses
the
current
version
and
uses
like
proper
semver
semantics
to
check
based
on
feedback
from
bart.
B
It
does
not
use
december
package,
so
I
re-implemented
the
basic
compatibility
check.
So
I
would
appreciate
it
if
you
guys
would
take
a
look
at
that.
I
really
only
finished
that
this
morning,
so
it
definitely
needs
eyes
on
it,
but
the
test
should
make
it
pretty
clear
what
it
does.
B
It
does
not.
I
created
this
internal
folder
and
created,
you
know
a
minimal
semver
implementation.
B
B
B
B
I
created
this
based
on
feedback
from
florina
that
our
api
naming
schemes,
don't
doesn't
really
have
any
name
spacing,
and
some
of
the
the
names
are
like
overly
general,
so,
like
status
code
only
applies
to
spans,
so
renaming
it
to
span
status
code,
makes
it
a
little
bit
more
obvious
what
it
is
and
some
things
like
that,
so
it
is
still
just
a
draft
because
I
don't
know
if
all
of
the
changes
I
made
are
necessarily
good
ideas,
but
I
would
appreciate
some
feedback
on
at
least
this
summary
of
changes.
B
They
are
used
in
some
tests
for
some
other
modules,
but
only
in
tests.
So
I
thought
it
would
be
okay
to
import
them
using
their
direct
path
like
this,
because
it's
only
for
testing
and
that
makes
the
no
op
classes
not
officially
a
part
of
the
api.
A
A
B
B
B
This
is
a
honestly,
a
pretty
simple
fix
that
paul
made
a
long
time
ago.
He
made
this
pr
in
october
and
I
think
he
he
hasn't
really
replied
on
it
in
a
while
other
than
about
two
weeks
ago,
where
it
kind
of
looks
like
he's
just
frustrated
with
how
long
the
process
is
taking.
B
He
doesn't
seem
willing
to
to
make
changes
to
this
pr,
but
I
do
think
it's
an
important
change
that
we
should
merge,
so
I
think
I
will
probably
send
he
has
the
permissions
of
his
branch
set
so
that
I
can
make
changes
to
it.
So
I
will
probably
update
this
and
make
the
changes
this
afternoon,
but
I
do
think
this
is
an
important
one.
So
I
would
appreciate
it
if
people
would
review
this
and
I
will
fix
the
linting
issues
and
add
the
test.
B
This
issue
also
opened
by
florina,
was
sort
of
the
the
reason
that
I
opened
that
api
cleanup
issue.
We
haven't
gotten
too
much
feedback
on
it
and
I
would
appreciate
it
if
you
guys
would
at
least
read
this
issue
and
and
give
us
your
thoughts.
B
B
So
that
was
part
of
the
reason
that
I
made
this
draft
pr
was
in
response
to
that
issue.
So
I
just
would
appreciate.
B
Feedback
and
then
the
other.
The
last
thing
that
I
wanted
to
talk
about
was
this
issue
that
I
made,
which
is
essentially
just
a
tracker.
Before
we
go
to
1.0.
I
would
appreciate,
as
many
people
as
possible
to
just
read
the
trace,
spec
and
look
over
our
current
api
implementation
and
make
sure
that
it's
spec
compliant
and
that
it
makes
sense.
B
Yesterday
florina
mentioned
that
the
timestamp
type
is
inconsistent,
so
I
created
an
issue
based
on
that
and
then
we
also
got
an
issue
that
I
think
this
is
just
a
user
that
opened
this
just
like
an
hour
ago
and
I
replied
to
him.
But
if
you
know
people
want
to
give
feedback
on
this
issue,
it
seems
pretty
well
thought
out.
So
I
don't
want
to
make
him
feel
like
we're,
not
listening.
C
So,
at
the
end
of
last
year,
at
the
end
of
last
year,
I
managed
to
find
some
time-
and
I
came
up
with-
I
did
the
once
over
on
the
on
the
api
and
came
up
with
these,
which
I
think
we
at
least
need
to
discuss
whether
we
want
to
get
make
some
api
changes
or
not
on
the
first
one.
If
you
click
on
it
on
1753,
it
does
look
like
there's.
C
This
is
potentially
a
duplicate
of
another
one
where
bart
had
started
to
do
a
pr
for
so
I
went
and
added
my
comments
to
the
the
pr,
but
I
sort
of
like
left
the
left.
This
is
a
a
point,
so
we
can
actually
restart
the
discussion
because
it
looks
like
it
went.
Stale.
B
Yeah
we
talked
about
this
kind
of
a
long
time
ago.
We
probably
if
we
didn't
document
on
the
issue
we
probably
should
have.
The
issue
is
that
with
const
enums
we
had
constenoms
before
and
the
issue
is
that,
let's
see
the
lookup
object,
that's
true.
There
was
an
issue
with
webpack.
E
B
Maybe
bart:
do
you
remember
what
the
is?
I
I
seem
to
remember
that
if
you
had
a
const
enum
in
like
the
api
package,
then
when
you
web
pack,
something
that
depends
on
the
api
package,
you
had
to
specifically
mark
the
const
enums
for
some
reason,
I'm
not
entirely
confident
in
that.
C
So
constantinops
get
a
raise
at
compile
time
which
can
cause
issues,
especially
if
you've
got
config
like
there
was
one
comment
in
the
other
linked
in
538
that
if
you've
got
someone
who
is
trying
to
create
the
config
and
wants
to
use
the
constants,
if
they're
not
referencing
the
the
constantinum
or,
if
you're,
using
straight
javascript,
then
it
doesn't
work
because
the
object
isn't
there,
which
is
sort
of
why
I
called
out.
We
have
two
sets
of
of
constants.
C
C
And
if
you
look
a
bit
further
down
in
my
comment
there,
just
at
the
bottom
of
the
screen
yeah
so
effectively,
rather
than
export
it
as
a
enum.
If
you
actually
export
it
as
a
constant,
you
actually
get
a
smaller
package
result.
So
for
those
you
you
just
say
well,
this
is
a.
This
is
just
a
constant
object
rather
than
an
enum
and
for
the
other
ones
you
make
them
constant
enums.
C
F
C
F
B
So
I
mean
I
am,
I
would
be
fine
changing
some
of
them
to
be
constant
objects.
I
mean
that's
sort
of
the
way
that
they're
used
most
of
the
time
anyways.
It
is
a
little
bit.
You
know
slightly
more
dangerous,
because
then
that
object
is
like
modifiable,
and
I
know
that
there's
ways
to
freeze
them
and
stuff,
but
those
are
never
perfect.
B
Yeah
yeah,
I'm
not
against
that.
This
was
the
issue
that
I
had
been
thinking
of,
so
that
roll
up
at
the
time
at
least
you
know
december
of
2019,
didn't
understand
like
const
enums,
so.
B
C
C
My
team,
but
well
he
was
on
my
team,
he's
actually
now
left
microsoft,
he's
working
for
robin
hood
now
and
probably
won't
be
involved
here
anymore.
One
of
the
reasons
for
me
getting
involved
for
app
insights.
We
use
trying
to
change
things
to
use
a
constant
number
he's
never
raised
this
one
with
me
previously.
So,
okay
I'd
be
very
intrigued
to
figure
out
what
what
this
is,
because
we
use
roll
up
for
app
insights.
We
don't
have
any
issues
with
constant
emails.
B
G
B
And
you
know
trying
to
summarize
what
the
what
the
issues
might
be.
It
could
be
entirely
possible
that
I'm
just
misunderstanding:
what
happened.
C
That's
probably
the
biggest
one,
so
the
second
one
came
from.
I
was
reviewing
this
one
yeah.
E
C
Was
reviewing,
I
think
it
was
florner's
pr,
and
I
just
had
an
observation
that
it
was
affected.
There's
a
bunch
of
boilerplate
code
which
I've
got
there.
So
you
know
local
config
logo
or
uapi
logger.
C
If
we
added
a
helper
function,
we
can
actually
get
rid
of
that
boilerplate
code,
and
it
overall
would
actually
make
it
a
smaller
minified
code
and
then
you
can
actually
get
rid
of
the
no
op
logo
class
completely
because
you
just
have
to
put
in
the
interface.
B
C
Well
effectively,
the
the
get
logger
implementation
I've
got
there
is
is
the
entire
class.
So
oh.
B
B
A
But
what's
really
the
benefit,
because
here?
Okay,
you
have
the
the
function,
but
you
don't
have
here
any
types
get
here,
because
that
no
blogger
is
correct.
B
C
No,
what
I'm
suggesting
here
is
we
just
get
rid
of
the
no
the
art,
blogger
class
so
affected
by
having
the
class
definition
and
then
because
the
because
it's
a
class
you've
got
the
debug
error,
worn
info.
You
end
up
with
a
whole
bunch
of
extra
javascript.
That
says
like
no
blogger.prototype.debug,
which
just
can't
be
minified.
So
really.
This
is
just
completely
removing
the
need
for
that
class
entirely,
but
still
providing
the
same
functionality.
C
That
class
has
and
then
on
the
usage
when,
instead
of
having
to
say
always
localconfig.logger
or
go
off
and
create
a
new
one,
it
just
becomes
a
the
line
below
which
is
just
api.getlogger.
C
So
therefore
it
just
simplifies
the
code,
so
you
don't
have
to
effect.
You
have
the
same
boilerplate
code
throughout
everywhere,
so
your
net
effect
is
overall,
a
smaller
code
for
both
us
as
the
sdk
and
anyone
implementing
it
or
using
it.
B
Got
it?
Okay,
if
that's
the
case,
then
I
think
that
the
api
is
probably
not
the
right
place
for
this.
It
should
probably
live
in
the
sdk
yep.
Just
you
know,
it
seems.
B
Logging
is
more
of
an
sdk
concern
and
being
able
to
this.
If
we
implement
this
in
the
sdk,
we
may
be
able
to
remove
all
you
know
references
to
logging
from
the
api
other
than
the
interface
too,
which
I
think
is.
A
A
B
Yeah,
okay,
that's
fine,
but
yeah
in
general.
B
Just
to
be
clear,
when
you
say
it's
a
minification
issue,
you
don't
necessarily
mean
minifying
the
api
itself.
You
mean
minifying
things
that
depend
on
the
api.
C
Yeah,
so
anyone
using
it
so
the
sdk
when
it
goes
to
get
the
get
a
logger.
Anyone
who
wants
to
go
get
a
get
their
own
logger
and
I
guess
in
the
api
as
well,
because
you
have
a
class
there.
The
api
will
be
looking
at
probably
about
two
to
three
hundred
bytes
smaller
by
not
having
the
no
blogger
class
and
just
having
this
function
instead.
In
fact,
maybe
more
than
that.
C
C
C
C
Total
size
aspect
yeah
that
that's
really
what
this
is.
It's
a
it's
a
minification
suggestion
to
try
and
keep
the
api
as
small
as
possible
in
any
implementations.
A
B
What's
different,
I'm
going
to
show
you
an
example
of
what
he's
talking
about
if
we
go
to.
B
Yeah,
I
mean
so,
I
thought
it
was
gonna
set,
show
like
you
know,
logger.prototype
or
whatever
it
doesn't
seem
act
like
it's
actually
an
issue
here
am
I
misunderstanding,
because
this
wouldn't
change.
C
Correct
yeah
so
that
the
the
consumers,
that's
the
reason
for
having
it
as
a
helper
function,
so
really
they're
only
going
to
save
a
few
bites,
because
if
they
really
want
a
logger
and
they
say,
use
this
logo
or
go
and
create
a
new
one
effectively,
they're
just
saying
always:
go
get
the
logger
and
the
get
logger
function.
Name
can't
be
minified,
so
they're,
probably
only
saving
through
10
bytes
or
something
every
time
that
you
they
use.
It.
A
A
A
C
B
C
I
I
don't
recall
I
I
know
for
us,
we
use
253
as
the
base,
but
we're
now
using
3.9
and
some
other
ones,
but
we
get
some
internal
microsoft
teams
that
are
using
really
funky
ones
and
they've
got
to
allow
script
set
to
it's
like
it's
crazy,
yeah
yeah.
So
this
helps,
but
you
still
find
the
prototype
and
the
the
name
can't
be
minified,
so
it's
better
than
it
was
before,
but
it's
still
extraordinary.
C
So
one
of
the
issues
we
you
have
with
typescript
is
when
you
have
private
properties
and
functions,
they're
still
actually
exposed
on
the
on
the
resulting
javascript
object.
So
therefore,
you
can
still
get
people
fiddled
with
them
and
call
them
and
do
whatever
they
like.
C
So
this
is
just
about
making
you
know
the
api
surface
clean.
So
you
say
anything
private
is
completely
private
and
it
results
in
both
a
better
separation
of
concerns.
So
you
don't
end
up
with
people
doing
things
you
don't
expect,
as
well
as
the
resulting
minification.
C
I
link
into
a
project
decorator
called
dynamic,
proto,
microsoft,
slash
dynamic,
photo
there.
I
drill
into
the
rationale
behind
it
and
I
I
do
have
the
complete
breakdown.
C
It's
quite
big,
although
the
resulting
side
is
only
about
2k,
but
I
linked
to
this
mainly
for
the
descriptions
of
what
I've
got
here
rather
than
saying.
We
should
use
this
because
I
don't
know
what
the
policy
is
on
about
using
external
products,
and
it
would
mean
everyone
would
end
up
using
it,
which
is
not
necessarily
what
we
want.
B
Yeah
extremely
conservative
is
the
answer,
especially
with
the
api
package.
You
know
we
were.
We
just
rejected
december
package
that
should
tell
you
sort
of
what
our
thinking
is
on
that
sort
of
thing.
C
Yep
yeah,
so
so
the
link
there
is
is
mainly
for
the
discussion
aspect
in
terms
of
how
we
go
about
implementing
things,
because
there
are
other
ways
to
do
it.
Apart
from
the
dynamic
proto,
it's
but
you
end
up
changing
functions
from
being
prototype
level
to
instance,
level.
C
C
B
Yeah,
I
don't
expect
that
these
api
class
instances
will
be
extended.
In
fact,
I
would
probably
prefer
to
discourage
that
the
sdk.
It's
important
that
it's
expensible,
you
know
any
sdk
classes,
but
for
these
api
instance
classes
I
would
actually
prefer
to
discourage
extending
them.
Anyways.
C
G
C
H
C
Yeah
this
one
can
be
done
after
you're
after
ga,
because
you
can
say
well.
We
defined
it
as
ga
if
you've
taken
a
breaking
dependency
on
an
internal
private
field.
It's
not
our
problem.
B
C
B
Have
very
many
private,
I
mean
only
instance.
Here
is
the
only
private
one.
C
Yeah
on
this,
so
for
this
particular
example
yeah,
it
really
is
a
case
of
it
is
class
dependent.
It
is
you
know
effective.
It's
just
hiding
the
internal
implementation
from
being
fiddled
with.
C
C
So
you
can
see,
there's
the
like
a
normal
class
versus
just
something
using
dynamic
proto
and
it's
about
a
63
compression
difference.
B
C
Yeah
per
class,
so
again
it
depends
on
how
many
functions
there's
a
lot
of
variables.
So
it's,
which
is
why
I
defined
in
the
other
thing
as
a
percentage,
because
it's
like,
like
every
one
of
these
public
classes,
has
dot
prototype
in
the
resulting
javascript
effectively.
That
goes
away.
C
The
the
private
property
and
even
the
the
private
static
can
go
away,
so
they
also
don't
have
a
prototype
on
them,
and
then
they
become
internal
to
the
constructor.
So
they
can
again
get
midified.
So,
instead
of
under
underscore
proxy
tracer
provider,
which,
as
a
property
of
the
class,
can't
be
minified
it
then
as
a
within
the
closure,
it
can
be
circuit
that
could
be
like
minified
to
a
so
you're
saving
like
with
that
15
bytes
or
something
just
there
alone
got.
D
C
And
this
is
you
know
it?
You
can
do
this
as
a
as
a
piecemeal
approach,
not
as
a
big
bang,
which
is
what
I'm
doing
with
application
insights
in
that,
like
I've
been
working
on
this
for
about
eight
months,
just
slowly
chipping
away,
you
know,
remove
height,
removing
all
the
the
private
fields
solely
changing
to
dynamic
proto
for
the
ones
that
we
want
to
extend
classes,
etc.
So
and
you're
just.
B
C
B
B
Or
where's
your
issue:
are
you
like?
Aren't
our
new
way
where
you
define.
B
Within
the
constructor
yeah
yeah,
our
new
user
is
going
to
be
confused.
What's
going
on
here
for,
like
I
understand
for
web,
like
every
bite
counts,
I
have
to
admit.
I
have
significantly
more
experience
with
the
back
end,
where
the
difference
between
tens
of
bytes
is
essentially
negligible,
so
maybe
people
with
more
web
experience
could
weigh
in
here.
B
I
know
bart
has
more
web
experience
than
I
do,
but
I
you
know
I
I
would
say
this
might
be
worth
it
for
things
like
the
api
which
are
used
all
like
by
a
lot
of
you
know.
We
we
don't
want
the
size
of
our
module
to
become
the
reason
that
some
other
module,
which
is
very
size
sensitive,
doesn't
want
to
take
us
as
a
dependency.
So
I
I
totally
understand
that
aspect
of
it,
but
in
the
mdk
I'm
not
sure
that
it
would
be
worth
it.
A
C
C
You
define
so
yeah,
no
it
it
it's
how
you
define
the
functions.
So
if
you
define
them
like
there,
we've
got
the
set
global
context
manager,
that's
a
a
function
of
the
class,
so
typescript
will
create
that
as
a
prototype
level
function.
If
you
define
that
as
I'm
not
seeing
an
example
as
an
instance
level.
C
So
if
you
change
that
and
say
public
set
global
context,
manager,
colon
a
function
that
then
returns
a
context
manager
that
will
then
be
an
instance
level
and
typescript
will
deal
with
that,
which
is
how
you
code
that.
C
So,
for
example,
at
the
highlighted
section
at
the
moment
right
where
we've
got
self
dot,
set
global
context
manager
at
the
top
of
that
class.
You
should
see
what
I'm
talking
about
in
terms
of
defining
it
as
a
instance
level,
but
as
an
instance
level.
You
then
have
to
populate
it,
which
is
why
you
have
to
then
set
it
up
in
the
constructor.
B
Yeah,
instead
of
being
a
function,
it's
an
instance
variable
what
happens
if
we
instead
do
something
like
we
do
something
like
this
public
active
equals.
B
C
In
that
case,
yeah
yeah
yeah
just
just
change
the
signature
to
that
and
that
one
it
would
work.
The
the
only
the
only
caveat
you
have
to
be
aware
of
this
is
now
an
instance
level
property.
So
anyone
extending
this
class
will
have
to
effectively
save
the
previous
value
if
they
want
to
overload
it
so.
B
Yeah
but
again,
and
this
on
this
particular
class,
I
don't
care
in
the
sdk
yeah
it's
it's
important
that
it's
extensible,
because
we
want
vendors
to
be
able
to
create
their
own
custom
sdks
by
using
you
know,
parts
of
ours.
C
Yeah
surprised
like
it
and
on
line
33,
it
should
have
used
underscore
this
for
minification
purposes,
but
anyway,
just
general
comment
of
the
way
typescript
converted
it
for
minification
purposes.
It
should
have
used
the
local
variable
it
created,
so
that
because
this
is
not
non-compressible.
So
if
I
use
the
underscore
this
they
they
could
have
compressed
that
to
a
anyway.
B
C
B
B
You
know
meet
in
the
middle
approach
that
will
be
not
confusing
for
people,
but
will
aid
minification?
Is
that
an
acceptable
yep?
Okay?
So
can
I
also
assign
this
one
to
you,
yep.
E
C
Yep
in
terms
of
time
frame,
I'm
not
sure
when
I'll
get
to
this.
I
get
a
bunch
of
stuff
this
week
so
probably
next
week
before
I
get
to
a
lot
of
these
things,.
B
F
E
B
B
A
So
I
can
simply
assume
that
the
old
style,
where
you
basically
create
a
function-
and
then
you
created
this
active,
is
equal
to
something
with
regards
to
the
minification
would
be
the
smallest
size
possible.
Yeah.
A
C
A
C
Also
doesn't
address
hiding
of
the
private
properties
either
because
you,
you
still
would
expose
on
on
this
for
a
type
script
or
reference
properly,
but
it's
a
definitely
a
step
forward,
and
yet
you
could
say
well
anything
where
we
don't
want
them
to
extend.
We
change
it
to
a
function
instead
of
a
class
anything
we
do
and
extend.
We
keep
it
as
a
class.
That
would
be
another
approach
as
well.
A
A
No,
no,
I
mean
like
because
we
because
you're
talking
about
changing
this,
to
achieve
something
like
a
different
pattern.
This
function
context
with
the
inner
function
context
up
here.
A
If
we
change
all
the
public
method
now
to
be
the
arrow
functions,
to
create
the
context
function
inside
the
context,
yeah
and
assign
everything
to
this
so
and
your
example
from
the
very
beginning
was
just
showing
like
a
pure
javascript,
where
you
basically
return
a
new
function
with
everything
attached
to
to
this
function,
which
is
like
an
old
style
javascript,
and
the
main
question
is:
if
we
cannot
achieve
this
with
the
typescript.
A
C
The
main
reason
that
typescript
uses
when
you
define
the
function
on
the
prototype
is
for
extensibility,
so
they've
effectively
got
the
standard
pattern
so
that
when
you
create
a
subclass,
you
can
then
say
super
dot
to
get
back
to
the
previous
one,
and
at
compile
time
it
knows
that
super
is
the
base
class.
So
it
actually
replaces
that
with
the
base
class
name
dot
prototype.
So
it
calls
it
directly
because
it's
not
on
the
instance.
A
A
B
B
A
B
Let's
see
if
we
do
make
this
change,
then
you
have
class
b,
extends
what
is
that
context
api
instructor?
Can
you
call.
D
C
G
C
G
A
B
C
B
H
B
Yeah,
I
I
among
others
that
this
is
an
issue
that
people
have
attempted
to
fix
a
few
times
and
it's
just
kind
of
thorny,
partially
because
it's
difficult
to
reproduce
partially,
because
different
browsers
act
differently
and
node
x
differently
than
the
browsers.
B
I
think
the
most
recent
suggestion
was
to
add.
Like
a
time
provider
interface
looks
like
farna's
suggesting
we
add
that
to
the
api.
I
would
want
to
check
with
the
you
know
the
maintainers
group
before
making
a
change
like
that
in
the
api,
but
it's
a
fairly
javascript
specific
issue.
I
don't
think
other
languages
really
have
this
problem.
B
I
mean
the
short
answer
is
that
I
I
think
that
this
is
a
difficult
problem
to
solve.
We
probably
have
to
solve
it,
it's
not
something
we
can
just
ignore,
but
I
am
unsure
what
the
correct
way
to
go
about.
This
is.
H
Yeah,
that's
fine!
That's
the
impression
that
I
had
is
that
it's
a
a
tough
and
challenging
problem
with
no
clear
way
out,
but
something
that
probably
does
need
to
be
solved
at
some
point
yeah,
because
if
I'm
not
mistaken,
this
can
generally
just
be
like
you.
Don't
necessarily
need
to
put
your
computer
to
sleep
to
get
this
problem
like
it
can
just
be
a
difference
in
clock
between,
like
browser
and
back
end,
causing.
B
This
right
yeah,
but
if
that's
the
case,
then
yeah
there's
very
little.
We
could
do
about
that.
One
thing
that
florina
suggested
was
adding
to
the
api:
a
global
like
time
provider
instance
where
you
would
be
able
to
register
your
own
time
provider
and
then,
if
you
have
a
back
end
that
supports
time
synchronization
like
dinosaurs,
for
instance,
we
do
you
could,
then
you
know
your
your
custom.
B
Sdk
could
register
a
time
provider
with
synchronized,
timestamps
and
stuff
like
that
that
all
the
api
consumers
would
be
able
to
take
advantage
of.
B
B
I'm
not
incredibly
familiar
with
it
honestly,
but
the
short
version
is
that
it
makes
a
request
to
the
back
end
like
it
makes
a
request
to
the
dynatrace
server
to
get
whatever
the
server
timestamp
is
and
correct.
Sku
based
on
that,
it's
not
as
accurate
as
anything
like
ntp
would
be,
and
if
the
time
is
very
close,
then
I
believe
we
actually
don't
do
anything.
B
It's
really
just
to
fix
to
correct
large
issues
with
times
or
we
have
like
a
server.
That's
not
ntp,
synced
or
something
like
that,
or
you
know
a
case
like
this,
where
the
browser,
because
of
the
semantics
of
the
sleep
you
know
sleeping
the
time,
is
incorrect.
C
Yeah,
you
also
get
devices
that
that
clock
drift
so
yeah.
E
C
Used
to
be
on
windows
phone
before
I
move
to
identity
before
I
move
to
this
team
and
it's
a
case
of
for
the
authenticator
app,
because
you
get
like
a
it's
a
time
based
token
effectively
when
they
start
up,
it
does
the
same
thing
that
daniel
just
said
it
sends
a
request
out
to
the
the
server
to
get
back
effectively
a
a
good
down
time,
because
you
know
especially
mobile
devices
they
can
drift
up
to,
like.
C
I
think,
that's
like
120
seconds
between
synchronizations
it
was,
it
was
painful
and
the
same
happens
in
appian
sites
effectively.
The
first
request
hits
the
server
and
we
get
an
offset
and
that
offsets
just
remembered
and
sent
to
adjust
the
time
every
every
every
request.
B
Yeah
and
one
of
the
limitations
of
open
telemetry
is
that
we
don't
have
like
a
you
know,
canonical
server
implementation
that
everybody.
You
know
we
don't
have
a
server
that
we
can
synchronize
time
with.
But
vendors
might
you
know,
exporter,
implementations
might
and
things
like
that.
Yeah.
E
Of
the
the
provider
is
the
way
yeah
this
whole
thing
and.
B
And
that
would
allow
us
to
then
treat
the
browser
in
node
differently,
because
node
doesn't
have
the
sleeping
issue,
which
is
like
the
the
real
motivation
here,
but
I
know
that
we
have
all
the
time
we
have
hosts
that
are
not.
B
You
know
that
the
time
is
not
accurate
on,
even
when
the
people
that
are
in
charge
of
maintaining
them
are
very
sure
that,
oh
yes,
we
have
ntp,
everything
is
synchronized
and
you
know
you
look
at
the
times
and
they
don't
match.
So
you
know
there's
not
much
to
do
about
it,
so
yeah
that
that's
why
we
do
that
to
sort
of
time
synchronization.
But
it's
not
anything
like
you
know
it's
not
a
full
ntp
into
implementation
or
anything
like.
C
B
F
I
might
be
half
making
stuff
up
here,
but
if
you're
in
containers,
for
example,
kubernetes
it
might
sleep
depending
on
how
much
cpu
you've
given
your
service.
B
C
B
Yeah
I
I
know
that
we
don't.
We
were
not
able
to
reproduce
this
in
lambda,
but
I
yeah,
I
wouldn't
be
surprised
if
there
are
runtimes
that
do
have
issues
like
this.
I
just
haven't
seen
them
yet
the
the
issue
is
that
we
don't
use
for
for
timestamps.
We
don't
use
like
date.now.
B
We
use
the
performance
time,
origin
and
performance.now,
which
is
like
a
monotonic
clock.
If
you
change
your
system
time,
it
doesn't
affect
that
after
the
process
has
already
started,
which
is
important
for
collecting
durations
and
things
like
that.
But
it
does
mean
that
you
know
date.now
is
correct
after
asleep,
but
the
time
origin
and
the
performance.now
shift
then
becoming
correct.
A
A
B
B
B
B
But
I
actually
have
to
go
so
if
somebody
wants
has
anything
that
it's
important,
that
they
bring
up
now
now's
the
time
I
have
two
minutes.
G
B
So
hopefully,
next
week
will
be
a
little
easier
but
happy
new
year,
everybody
and
I'll
talk
to
you
in
a
week.