►
From YouTube: 2022-02-01 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).
B
Sorry,
I
think
it's
late
for
you
so,
but
I
think
this
would
be
hopefully
the
last
time
we'll
be
having
the
meeting
at
this
time.
So
we
had
a
discussion
and
I
think
it's
good
to.
B
I
think
it
was
too
late
before
the
decision
was
made,
so
I
didn't
want
you
to
change
it
today,
so
probably
from
next
week
onwards.
Next
week
anyway,
it's
set
in
morning
time,
inventment
time,
so
I
think,
probably
next
to
next
week
onwards,
we'll
have
a
proper
timing
for
it.
A
B
Let's
start,
let
me
shade
the
screen.
B
B
Matrix
implementation
again
I
mean
I've
been
involving
some
lots
of
other
stuff.
I
did
create
some
block
diagram
based
on
what
current
set
of
changes
we
have
done,
and
probably
that
is
something
which
we
can
use
it
further.
So
I
think
we
can
discuss
it
after.
We
have
discuss
all
the
agenda
items
and
then
I
need
to
add
more
stuff
on
that.
Probably
I
can
add
it
in
couple
of
days
right.
B
It
may
not
look
better,
I
mean
once
we
started
doing
more
implementation,
but
I
think
we're
good
to
have
a
discussion
upfront
on
this.
So
probably
we
will
spend
some
time
on
that
after
this,
after
after
going
to
the
agenda,
I
think
we
have
to
have
a
release
on
this.
C
Yeah
I'm
creating
the
1.2.0
now,
not
only
when
compared
with
previous
release.
I
have
a
question
that
how
can
how
to
how
could
a
way,
declare
the
break
and
change.
C
C
B
Now
we
don't
need
to.
Basically
I
mean
after
you.
How
do
you
think
I'll
probably
have
one
breaking
changes?
Do
we
want
to
segregate
segregated
over
sdk
exporters?
I
don't
think
we
should
do
it
just
mention
it.
I
mean
whatever
making
changes
are
there
and
then
we
can
continue
more
detailed
changes
which
we
are
doing
afterwards.
B
C
Okay,
I
should
upload
the
pr
version
soon
and
yeah
hope
we
can
complete
this
today.
B
Yeah
I
just
had
one
the
pr
which
is
raised
right
did
start
looking
into
that.
I
had
some
confusion.
So
probably
let's
discuss
that.
Also
today
I
mean
when
we
start
discussing
all
the
https
and
we.
B
We
can
take
that
also
in
this
release.
B
B
B
B
Of
the
projects
internally
in
microsoft,
where
they
wanted
to
use
open,
telemetry
and
one
of
our
proprietary
exporters-
and
that
was
more
of
they
wanted
to
use
it
for
both
32-bit
64-bit
intel
and
also
they
wanted
to
put
it
for
year,
and
so
I
think
it's
spent
substantial
time
working
with
them.
But,
finally,
I
think
for
open
telemetry.
I
think
it
was
seamless
to
we
could
deploy
it
on
all
these
three
platforms
and
it
was
working
fine.
B
B
So
the
actual
deployment
route
was
all
changed
to
some
other
path,
which
was
mostly
erm
based.
So
all
the
builds
were
happening
on
64-bit
intel,
but
actual
the
the
all
the
artifacts
which
were
created
was
basically
here,
and
I
think
somehow
some
of
the
build
script
was
not
working
as
well
expected,
but
I
think
it.
Finally,
eventually
we
were
able
to
deploy
it
I'll
have
a
look
into
that.
I
will,
if
I,
if
I'm
not,
if
I
remember
correctly
at
least
the
low
man
json
installation,
it
was.
B
I
mean
correct
me,
I'm
wrong,
but
it
does
the
installation
by
default
right
as
part
of
the
build.
If
it
is
not
there.
B
Yeah
and
somehow
I
think
we
noticed
that
it
is
installing
it
always
on
user,
local
for
or
the
system
defined
path
default
path
which
may
be
user,
local
or
use
slash
user,
but
through
compiler
we
can
all
I
mean
through
the
compiler
toolkit,
and
we
can
always
change
the
system
root.
B
That's
normally
done
for
the
cross
compiler,
so
we
can
specify.
I
mean
the
dcc.
This
is
a
compiler.
You
can
also
specify
dash
guest
is
root,
and
then
you
can
specify
all
the
arguments
somehow
that
was
not
getting.
B
That
was
not
even
though
we
were
specifying
that
it
was
still
always
installing
on
slash
user,
slash
local,
but
probably
because
of
we
specify
the
installation
people
we
use
that
cmake
install
prefix
for
that,
and
that
is
different
from
what
these
this
root
takes,
but
yeah,
but
that's
something
I
I'll
look
into
that.
Oh
test
it
further
and
look
into
that.
I
mean
as
of
now.
I
think
we
did
the
custom
installation
and
it's
working
fine.
B
B
I
mean
the
download
was
surprisingly
slow.
I
don't
know
why
for
for
json,
it
was
not
that
slow
for
open
telemetry,
so
they
were
using
that
cmake
external,
add
external
direct
command
to
do
the
installation
that
external,
whatever
is
their
add
and
export,
and
using
that
github
repo
which
which
basically
clones
the
complete
open
telemetry,
which
was
very
fast,
but
when
it
goes
to
low
maintenance
on
it
was
very
slow.
I
don't
know
why
it
just
know.
A
C
C
B
B
A
A
A
A
B
B
Okay
looks
good
to
me,
then
let
me
just
probably
do
it
today
and
I
think
I'll.
Surely,
if
I
have
some
comments
I'll
just
post
it
there,
otherwise
I
think
I'll
probably
going
to
improve
it.
B
B
Do
use
something
vc
package
right,
why?
Why
are
we
using
that
for
installation
if
we
already
have
for
bazer,
we.
B
A
B
A
B
B
A
B
B
A
B
B
B
C
B
B
B
B
B
B
B
B
A
Had
had
some
comment
recently
for
logs.
B
B
B
B
B
B
Yeah,
I
think
that's
all
we
have
in
this,
and
I
just
wanted
to
talk
more
about
the
architecture
I
tried
doing.
Something
here
probably
could
not
could
not
do
much
of
the
work,
but
I
probably
you
can
talk
what
what
exactly
was
the
was
the
idea
I
had
so
so
some
of
the
some
of
the
this
is
visible
right.
This
block
diagram,
yeah,
okay,
so
some
of
the
components
are
already
there
existing
and
some
other
things
we
are
going
to
add
it
so
meter,
meter,
provider
and
meter
context.
B
These
three
are
already
existing
and
these
the
functionality
of
these
three
is
very
similar
to
what
we
have
for
traces
and
marks
meter
provider
will
give
us
a
meter
for
for
a
given
instrumentation
library.
B
Meter
context
is
part
of
meter,
it's
a
shared
pointer
for
which
exists
both
in
meter
provider
and
also
with
meter,
which
owns
a
component
like
measurement
processor,
metric
exporter,
metric
reader
and
also
views.
Let
me
see
how
it
didn't
go,
but
this
also
wants
to
yeah.
So
it
wants
view
registry
matrix,
total
metric,
reader
and
measurement
processor
and
view
registry,
your
own
views,
so
there
may
be
multiple
views
which
are
defined
which
may
be
defined
by
a
developer.
B
So
there
would
be
multiple
instrumentation
libraries,
which
would
be
part
of
an
application.
Each
instrumentation
library
will
get
a
meter.
They
will
create
instruments
so
base
that
instruments
based
on
the
kind
kind
of
in
instruments.
It
could
be
asynchronous
instrument
or
a
synchronous
instrument.
They
will
they
will.
These
libraries
will
use
those
instruments
to
log
or
report
any
matrix
information
that
they
want
to
report
from
their
librarian.
B
So
they
will
call
this
record
long
or
record
double
based
on
the
instrument
type,
which
is
it's
a
long
time
instrument
or
recorded
instrument
or
double
time
instrument,
or
they
will
create
asynchronous
instrument,
and
in
that
case,
while
creating
the
instrument
they
will
just
register
a
callback
and
metric
measurement
processor
is,
which
is
something
which
I
have
created
as
part
of
the
current
pr.
B
So
this
is
basically,
I
think
this.
The
complete
block
diagram
is
not
something
which
we
have
invented.
This
is
something
which
I've
gone
through
java,
implementation.net
and
javascript
python.
All
these
are
bit
ahead
of
us.
They
are
already
doing
similar
workflow,
which
with
something
I
have
mentioned
it
here.
B
So
so,
basically,
what
is
going
to
happen
is
like
they
could
be
multiple
instrument
meters,
each
with
a
given
instrumentation
for
a
given
instrumentation
library
and
all
the
flow
for
all.
Those
instruments
will
go
through
measurement
processing,
so
measurement
processor
will
get
slow
for
any
instrument
for
any
meter
type
for
any
instrumentation
library
that
has
to
come
through
this,
and
even
any
collection
which
is
going
to
happen
also
should
flow
to
measurement
processor.
B
Measurement
processor
measurement
processor
will
so
views
there
would
be
views
which
are
created.
This
views
will
define
what
kind
of
aggregation
we
want
to
do
for
for
what
kind
of
meter
type
and
what
kind
of
instrumentation
they
bring.
So
it
has
a
mapping
of
all
the
aggregations
which
are
which
we,
which
an
sdk
want
or
applications
want
to
get
for
a
given
instrumentation
time
in
meter
time.
So
this
contains
that
mapping,
so
so
measurement
processor.
B
B
And
that
will
contain
the
current.
So
so,
basically,
the
record
now
suppose
record
long
is
there
goes
something
instrument
to
measurement
processor.
It
will
go
from
this
measurement
processor.
To
this
view,
aggregation
and
also
to
this
view,
application
based
on
how
these
views
are
defined
and-
and
this
will
do
the
aggregation-
it
could
be
some
aggregation
or
it
can
be
last
value,
aggregation
or
histogram.
B
So,
based
on
any
counter
type,
it
will
aggregation
type
would
be
mapped
in
the
view
and
based
on
that,
this
is
going
to
do
education
and
it
is
going
to
store
the
all
the
metric
points,
the
result
of
that
aggregation
in
this
storage
with
the
timestamp
information,
so
that
that
would
be
stored
in
all
the
aggregation
storage
based
on
what
our
views
are
defined.
B
So
how
many
views
are
there
that
many
view
aggregation
stories
will
be
there
and
it,
and
the
matrix
collector
would
be
something
which
is
going
to
invoke
the
actual
collection
of
the
matrix.
So
this
is
the
flow
of
measurements
like
this,
and
this
is
the
this
would
be.
The
flow
of
the
collection
of
collectors
again
metric
reader
would
be
initialized
as
when
the
sdk
is
initialized,
it
will
have
its
own
metric
exporter,
so
this
has
to
collect
the
matrix.
B
B
So
this
is
very
high
level.
Probably
I
think
once
once
we
add
more.
B
Implementation-
this
is
something
which
is
still
a
gray
area
need
to
have
more
drill
down
here,
how
it
is
going
to
work,
how
the
storage
will
look
like
what
kind
of
mapping
it
could
be,
how
how
this
measurement
processes
will
get
information
of
which
all
storage
has
to
use.
There
has
to
be
some
mapping
between
measurement
processor
to
list
of
storages
for
a
given
aggregation
type
so
that
that's
something
it's
the
gray
area.
Probably
you
can
add
it
going
forward,
and
let
me
write
some
some
write
up
for
this.
B
I
mean
for
the
flow
for
both
the
measurements
and
for
the
collection.
I
think,
if
that
will
make
sense,
once
we
discuss
further
so
so
something
like
if
we
see
that
specie
specification.
B
B
Based
on
the
instrument
type
which
we
are
getting,
which
allocation
should
be
used,
so
that
would
be
defined
in
the
views
and
it
has
to
be
defined.
Based
on
this
mapping
between
the
instrument
I
mean
like
for
counter,
we
can
have
some
aggregation
for
after
control,
so
we
can
have
some
regulation
for
asynchronous
gauze.
B
We
just
need
last
value
waste
influence.
Gauss
could
be
something
like
temperature
after
every
few
few
minutes,
so
we're
not
worried.
We
may
not
be
worried
about
what
was
the
temperature
earlier.
We
may
be
just
worried
about
last
value
of
the
temperature,
or
we
may
be
worried
about
here.
We
don't
need
to
do
some
aggregation
so
based
on
that
type,
the
aggregation
would
be
defined
and
that
aggregation
will
be
done
so
so
this
is
basically
doing.
The
aggregate
call
which
does
the
aggregation
and
the
result
of
aggregation
would
be
stored
in
the
storage
here.
B
It
has
got
from
the
last
stretch
of
that
time,
step
of
the
last
red
timeframe,
and
then
we
have
to
again
create
the
timestamp
windows,
so
I
mean
it
looks
bit
complicated
right
now.
Probably
this
is
something
which
we
have
to
drill
down
further,
but
I
think,
once
we
add
start
implementing
more,
I
think
we'll
get
more
clarity.
B
Yes,
each
box
is
a
class
right
now,
so
sync
instrument
is
abstract.
Class
async
instrument
is
abstract
class
sync
instrument
will
the
actual
classes
would
be
counted
like
these
are
for
sync
instrument.
We
have
a
counter
up
down
counter
histogram
for
async
instrument
will
have
these
again.
Aggregation
is
actually,
if
you
see
here,
aggregation
is
a
class
is
extract
class.
The
actual
actual
implementation
would
be
any
one
of
these
three.
Some
aggregation
last
value
aggregation
in
instagram,
and
this
is
already
in
my
one
of
the
prs.
If
you
see
this
one.
B
So
so
the
view
is
already
there.
We
already
have
the
implementation
for
views.
View
registry
views.
This
is
already
in
place.
We
may
have
to
do
the
changes
once
we
dig
further
into
this,
but
this
part
is
already
existing
view.
Registry
views.
B
Sync
instrument,
async
instrument
is
apis,
are
already
there.
We
have
to
add
the
sdk,
so
I
just
created
one
pr
for
that.
That's
very
straightforward
measurement
processes
also,
I
have
added
a
pr
to
add,
add
this
class
and
how
it
is
going
to
be
called
from
network
reader.
This
I've
just
kept
it
as
a
placeholder
in
my
in
this
implemented
in
this
vr.
B
Javascript
python
all
are
using
kind
of
similar
approaches.
So
probably
it's
already
tried
and
tested-
and
I
didn't
try
to
reinvent
the
wheel
here.
B
B
It
has
lots
of
information
not
not
how
to
implement,
but
it
has
lots
of
recommendation
what
we
can
do,
how
to
how
to
how
how
how
can
we
really
implement
it
in
terms
of
recommendation,
but
it
does
not.
So
it
talks
about
like
if
we
see
here.
B
Yeah,
if
you
see
here
it
talks
about
the
in
memory
state,
it's
it
will
know,
it
will
not
tell
us
how.
How
should
our
writable
source
should
look
like
this
would
be
something
which
will
maintain
the
aggregated
matrix
and
exporter
and
reader
are
going
to
pull.
So
exporter
is
going
to
periodically
pull
the
matrix
from
this
and
it
is
going
to
push
it
to
exporter.
It
is
going
to
send
it
to
exporter,
and
exporter
is
going
to
push
it.
B
B
B
I
mean
they
are
trying
to
create
a
wrappers
on
top
of
world
implementation
to
support
the
new
api,
but
I
haven't
seen
check
that
lately.
The
reason
I
didn't
see
was
because
these
dotnet
java
and
python
these
three
were
the
early
adopters.
I
mean
they
were
selected
as
the
early
adopters
for
matrix
and
I
probably
felt
that
these
are
some
some.
These
are
the.
B
B
I
think
this
is
something
very
open
right
now.
I
was
just
thinking
that
if
we
can
have
one
end
to
end
prototype
running
probably
we
should
be
open
for
any
changes.
We
can
figure
out
the
bottlenecks
and
the
performance
issue
only
once
we
have
something
up
and
running.
So
that
was
my
idea.
B
B
B
B
B
Yeah,
so
periodic
exporting
metric
reader
will
be
something
which
would
be
periodically
periodically
reading
the
matrix
of
data
from
the
memory,
and
it
is
going
to
push
it
to
the
matrix
exporter,
which
would
be
configured
and
matrix
exporter.
We
can
have
some
console
exporter
to
start
with,
which
will
just
print
the
matrix
on
the
console.
B
B
Okay,
now
that
would
be
good
yeah.
It
would
be
good
yeah.
I
can.
I
can
focus
on
this
part
measurement
processor
and
this
one
aggregation.
Probably,
I
think
if
we
have
something
to
fetch-
and
that
would
be
that
this
would
be
a
good
good
use
case
for
us.
C
C
B
I
mean
like,
like
this
one:
a
push
matrix
exporter
have
a
very
basic
console,
matrix
exporter
and
a
periodic
exporting
metric
leader.
So
basically,
this
this
use
case
would
be
good
to
show
a
periodic
exporting
metric
reader,
which
is
going
to
read
the
metric
information.
B
C
B
We
can
do
that,
but
my
only
concern
was
that
this
was
not
something
we
were
inventing
it.
I
mean
people
have
already
implemented.
Based
on
that,
we
have
kind
of,
I
mean
fair
enough.
We
have
kind
of
taken
mix
of
stuff
from
multiple,
multiple
6
and
created
block
diagram.
For
that
we
can
do
that,
saying
that
we
have
kind
of
collected
all
the
information
from
the
existing
implementation
and
trying
to
come
up
with
a
with
this.
We
can
do
that
yeah.
Now.
How
am
I
doing
it?
B
B
B
B
B
Yeah,
let's
discuss
I
mean
I
just
kept
it
separate
for
each
of
the
aggregation
types
mixing.
It
probably
would
be
a
single
point
of
failure
or
single
more
of
a
bottleneck.
I
just
felt
that
and
probably
but
yeah,
let's
discuss.
Let's
see,
let
me
come
up
with
some
implementation
here
and
let's
discuss
it
over
there,
but
yeah
I
mean
I
thought
lots
of
things.
I
was
thinking
if
you
can
use
sqlite
in
memory
db
for
storing
these
instead
of
having
some.
B
That
would
be
a
quick
lookup
instead
of
having
a
flat
file
with
all
the
matrix
information.
If
we
can
have
something
in
the
in
memory
sqlite
storing
in
a
table
of
form.
That
would
be
good,
too
may
be
good
for
queries.
For
collections,
I
mean
I
was
thinking
lots
of
things,
but
probably
that
will
come
afterwards.
A
A
B
Yes,
yes,
we
don't
need
persistence,
so
I
was
talking
about
yeah.
I
was
talking
about
sql
sqlite
in
memory,
not
sqlite
file
system,
yeah,
yeah
yeah,
so
not
persistent
that
we
don't
want
to
support
it
and
yeah,
but
that's
just
a
thought.
I
think,
let's,
let's
go
for
something
simple
and
let's
probably
take
it
further
from
there.
We
want
to
really
optimize
it.
A
B
Let's
it
would
be
good
to
have
here
something
something
more
abstracting.
I
try
to
do
that
not
giving
much
much
much
of
the
strict
matter
our
public
facing
apis
would
be
meter.
B
This
meter
sync
instrument,
async
instrument,
meter
provider,
meter,
context,
meter,
reader
view
registry,
meter,
metric
exporter,
sorry,
metric
reader,
metric
exporter
and
views,
and
I
think
all
this
stuff
would
be
internal
measurement,
processor
view,
aggregation,
storage
and
aggregations.
All
this
would
be
internal.
Nobody
would
be
knowing
how
we
are
implementing
it.
So
probably
I
mean
as
much
as
functionality
we
can
add
internally.
B
Keeping
all
the
public
facing
apis
as
abstract
as
possible
would
be
good
to
have
so
I
tried
to
do
it
when
I
was
trying
to
implement
this
measurement
processor
instead
of
having
metric
reader
having
information
of
what
all
what
all
storage
it
should
be
broadcasting
to.
Let's
let
measurement
processor
have
that
information
so
that
later,
if
you
want
to
change
this
functionality,
we
don't
need
to
change
metric
reader.
Metric
leaders
has
to
do
a
collect
call.
It
does
not
need
to
worry
that
internally,
how
the
actual
collect
would
be
running
inside.
B
Here
so
so
I
mean,
as
of
now,
if
you
see
metric
treated,
I
purposefully.
I
added
lots
of
things
here
so
that
we
don't
need
to
do
much
changes
for
internals
in
metric
reader,
so
metric
reader
just
to
need
to
worry
about
how
frequently
to
read
whether
it's
the
push
leader
or
the
pull
reader.
B
B
Okay,
probably
I
need
to
see
once
again,
but
yeah
metric
reader
has
to
have
idea
about
it.
Just
should
be
doing
collect
and
should
be
more
bound
to
how
frequently
to
read
and
get
the
data
and
transform
it
to
the
format
or
directly
send
it
to
exporter,
and
that
exporter
need
to
format
it.
How
you
want
to
do
it
so
yeah,
let's
see
nothing
yeah,
cumulative
and
delta.