►
From YouTube: 2021-06-16 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).
C
C
C
F
F
Wonder
if
greg
will
join
today,
he
just
got
back
from
his
pretty
long
vacation.
So
I
don't
know
if
he
is
gonna
be
catching
up
on
other
things,
but.
B
G
That's
okay.
I've
got
another
one
coming
up
right
away.
C
All
right,
let's
just
give
one
extra.
C
D
C
Okay,
so
I
think
we
didn't
have
much
movement
from
the
last
week.
C
I
think
david
and
erasmus
are
working
on
kind
of
putting
some
sample
apps
with
the
corner
cases
that
we
want
to
kind
of
be
sure
that
we
cover
for
the
poc
to
be
sure
that
that's
really
workable,
so,
basically
just
to
be
sure
that
everyone
is
in
the
same
page
on
the
same
page,
this
should
be
applications
that
use
different
versions
of
system
diagnostic
diagnostic
source.
C
There
will
be
and
different
ways
of
bringing
that
dependence
right.
So,
but
besides
that,
this
is
something
that
prosmos
pointed
in
other
places
is
also
about.
Let's
say
if
the
instrumentations
have
dependence
with
some
library
and
the
application
also
has
other
dependencies
with
different
versions
of
the
library.
So
in
principle,
for
those
we
don't
have
kind
of,
we
are
not
going
to
be
doing
anything
special,
but
in
principle,
the
same
solutions
that
we
are
recommending
for
a
system
diagnosed
diagnostic
source
should
work
for
those
assemblies.
C
A
C
So
the
the
downside
is
kind
of
perhaps
some
of
that
stuff
people
will
just
note
at
runtime.
There
will
be
no
way
of
hitting
the
issues,
perhaps
without
actual
test,
for
the
application.
C
So
I
think
this
is
kind
of
the
the
update.
I
don't
think
we
had
other
stuff
coming
up.
I
I
don't
remember
any
bugs.
I
tried
to
look
at
my
github
notifications
more
closely.
I
didn't
see
any
bugs
or
new
issues
coming
up.
C
We
still
have
the
the
upstream
pool
to
to
get
merged,
so
I
think
last
time
we
talked
it
and
the
the
conclusion
was
that
if,
when
it
was
ready,
exactly
was
gonna,
do
the
merge
right.
F
Yeah
I
want
to
follow
up
on
that,
so
we
can
either
keep
them
from
the
last
meeting.
We
were
saying
that
I
was
fine
with
keeping
the
headers,
as
is,
if
that
would
make
it
easier.
Nikita,
also
responded
and
said
that
if
we
wanted
to
change
them
right
now
that
a
dd
maintainer,
so
myself
could
do
the
merge
and
that
would
be
sort
of
doing
the
giving
the
permission
to
change
those
to
hotel.
F
So
I
didn't
know
what
you
all
wanted
to
do,
because
we,
I
don't
know
what
the
burden,
if
we
you
know
add
more
files
to,
for
example,
say
we
add
more
files
like
on
the
a
datadog
upstream
and
then
we
have
to
modify
those
headers
again.
I
don't
know
if
that's
gonna
be
too
much
overhead
right
now,.
C
So
perhaps
should
we
look
at
tools
to
do
that
kind
of.
D
Because,
at
least
for
right
now,.
C
C
No,
but
after
we
do
the
first,
then,
is
just
what
conflicts
after
the
the
first
school
right.
F
F
Issues,
I
think
if
we
change
some
name
spaces
that
might
introduce
the
merge,
but
I
think
that
would
show
up
pretty
quickly
and
the
well
all
we'd
have
to
do
is
basically
on
import
or
on
upstream
the
maintenance
would
be
adding
add
a
new
step
to
basically
just
rerun,
at
least
in
visual
studio,
there's
an
easy
way
to
change.
It
it'll
throw
a
compiler
error
and
you
can
just
fix
the
headers
across
the
project
or
solution,
but
the
overhead
I'm
thinking
is.
F
D
C
So
stepping
back
here
what's
the
route
that
we
want
to
take
in
the
end
you
know
I
I
have
that
the
attendance
of
of
saying
that
kind
of
let's
look
to
a
tool
that
we
can
run
and
and
update,
even
if
it's
already
changing
the
header
so
every
time
that
we
do
the
upstream
pull,
we
run
the
tool
and
we
keep
that
in
sync.
You
know
the
same
way
that
we
we
have
to
run
the
version
2
when
doing
the
upstream
pull.
C
F
A
C
That
yeah,
okay,
okay,
so
let's
go
with
that
then.
The
next
thing
that
we
we
have
here
is
because
looking
at
the
sdk,
the
story
for
extensibility
that
we
discussed,
if
we
really
go
going,
this
route
changes
a
bit
and
robert
put
together
an
initial
document
with
the
ideas
about
how
to
leverage
the
sdk
and
make
that
thing.
D
D
C
D
I'll
make
it
big
good,
so,
basically,
here's
a
problem
description
which
paolo
asked
me
like
to
use
like
like
as
a
baseline,
so
I
put
it
here
to
have
some
context.
So
basically,
there
are
a
few
like
use
cases
or
like
principles,
context
that
paulo
wanted
to
me
to
focus
on.
So
basically,
there
are
like
stuff,
like
configurability
from
different
perspectives.
D
One
is
like
changing
the
different
different
default
values,
somehow
like
the
hard-coded
ones.
As
far
as
I
understand
having
the
possibility
to
turn
off
turn
on
some
concrete
instrumentation,
for
example,
http
client
instrumentation,
the
other
one
will
be
if
the
accessibility,
even
not
like
in
the
distribution
but
like
in
even
in
a
vanilla
way
that
someone
wants
to,
for
example,
add
some
custom,
auto
instrumentation,
which
is
not
shipped
to
stand
here
like
out
of
the
box,
then
turning
off
basically
turning
off
exporters.
D
D
Okay,
this
is
like
a
context
like
just
like
an
additional,
like,
I
think,
for
those
here
just
to
to
be
sure
that
I'm
not
missing
anything.
So
what
things
need
to
be
like
exported
me
can
look
at
packages
if
we
need
some
additional
public
api
to
that
needs
to
be
exposed
to
make
some
custom
stuff
and
yeah,
basically
how
to
add,
replace
stuff.
And
here
all
I
wanted
to
focus
on
two
stuff.
D
Basically,
if
you
have
any
questions,
anything
is
unclear.
Please
just
interrupt
me,
it's
okay
for
me.
D
So
basically
I
I
made
a
proposal
when
I
tried
to
like
explain
some
properties-
or
I
don't
know
like
features
functionalities-
that
if
you
sum
them
up
in
theory,
should
cover
all
of
these
things,
so
the
first
like
basic
thing,
is
having
a
config
file.
So,
basically,
right
now
the
data
datadog
instrumentation
has
the
data.json
file
correct.
D
But
I
thought
that
maybe
json
is
not
a
perfect
match,
because
json
has
a
more
complex
structure
and
also,
I
feel
that
it
will
be
easier
to
have
like
something
like
a
dot
end
file
which
would
match
the
environmental
settings.
Then
it
will
be
like
sure
that
will
not
make
you
know
some
configuration,
which
will,
for
example,
be
easy
to
edit
on
the
json
stuff,
but
it
would
be
almost
impossible,
for
example,
to
set
by
environmental
variables.
C
D
D
G
C
Is
it
specified,
via
the
environment
variable
when
you
are
launched,
the
application
set,
the
environment
variable
to
the
file
that
you
want,
so
it
becomes
per
application,
becomes
per
process
right.
D
Yes,
so
that's
one
thing
and
in
theory,
if
we
have
a
use
case,
we
could
it
could
even
support
multiple
files
that
it
will
be
like
overridden.
I
don't
know,
for
example,
the
last
one
specified
has
the
highest
priority
that
first,
you
know
load
one
file,
then
you
overwrite
overwrite,
overwrite,
etc
the
settings
for
then,
for
example,
there
could
be
a
root
file
in
the
in
the
tracer
pro.
D
So
oh
it's
I
I
said
it
here
so
basically
for
each
environmental
variable
that
contains
path.
We
could
support
that.
We
can
just
add
something.
You
know
additional
paths
using
separator
this
one
for
windows
and
this
one
for
and
it's
like
my
mac,
os
linux
systems,
etc
and
yeah.
D
Next
thing
is
about
select
instrumentations,
so
I
only
said
that
we
could
have
two
environmental
variables
that
can
be
used
to
as
bo
or
a
low
list
or
a
set
deny
list.
D
Because
from
my
experience
there
are
some
you
know:
custom,
maybe
not
customers,
because
I'm
a
developer,
even
developers.
There
are
one
kind
of
developers
that
prefer
to
have
street
control
when
they
just
you
know,
allow
something,
because
you
know
some
concrete
instrumentations
and
they
want
to
be
sure
that
whenever
they
bump
something
you
know
the
version,
they
do
not
get
any
new
instrumentation
out
of
their
control
and
there's
a
separate
like
set
of
developers
that
simply
disable
what
is
slow
for
them
and
what
they
do
not
want
to
have.
C
So
one
question
here
just
to
to
clarify-
and
I
think
down
the
document-
that's
that,
but
here
instrumentations
will
refer
both
to
let
let's
say,
source
instrumentations
and
distributions
correct
yeah.
D
I
think
it
will
be
simpler
for,
for
you
know,
for
the
customers
and.
C
C
Yeah
so,
and
just
just
to
something
that
you
already
mentioned
before,
that's
why
I'm
start
to
call
this
thing
trying
to
call
this
thing:
bite,
cool,
instrumentation
and
source
instrumentations,
because
they
are
different
and
I
don't
have
a
a
better
term
that
people
can
understand
outside
you
know
people
don't
seem
to
like
auto
instrumentation
so
much
because
we
are
also
injecting
the
sdk.
So
in
that
sense
is
auto
and
if
I
say
ial
or
something
people
that
are
not
familiar
with
dotnet,
they
don't
know
what's
about.
C
Source
instrumentation,
but
I
diagnostic.
C
D
D
Okay,
going
further
so
so
next
thing
which
I
started
to
think
about
is
about
extensibility,
because
this
these
three
things
were
like
covering
like
vanilla,
vanilla
configuration
and
now
we
are
getting
to
the
to
the
more
complicated
extensibility
part.
So
the
first
thing
I
think
and
probably
is
the
hardest
one
is
about
adding
additional
assemblies
and
making
sure
that
they
are
correctly
loaded.
D
So
I
I
haven't
done
any
poc,
so
this
is
just
you
know
like
a
lot
of
guessing
here
and
basically
most
of
the
stuff
here.
I
think
I
should
make
a
poc,
but
I
hadn't
got
time
so
I
saw
I
looked
at
the
manage
loader
and
I
right
now
it
just
looks
it's
as
just
the
assembly
resolver
to
a
particular
structure
right-
and
I
was
just
thinking
that
maybe
it
could
take
a
look
at
more
directories
following
the
same
structure.
F
D
F
Like
net
core
f31
or
net
standard
2o
and
then
it'll,
basically,
when
you
try
to
resolve
one
it'll,
we'll
pre-calculate,
what
build
we're
on
and
then
look
into
the
correct
subdirectory,
so
yeah
you're,
saying
basically
add
additional
like
root
directories.
D
F
Looking,
I
suppose,
to
make
easier,
it's
easier
right,
yeah
so
like
we
would.
We
would
start
our
search
if
we
have
our
netcraft
31
build
of
the
auto
instrumentation.
Look
in
that
subfolder
first
and
then,
if
it
doesn't
find
it
there,
then
look
in
the
standard,
2o.
C
Yeah,
this
idea
of
kind
of
having
a
preferred
dfm
and
then
have
us
all
back
if
it
makes
sense
like
like
zach
described.
I
think
it's
very.
D
D
So
next
thing
here
I
feel,
but.
D
D
I
don't
imagine
that
regular
users
will
be
able
to
do
such
stuff,
so
I
think
that
even
keeping
the
what
we
have
right
now
just
this
integration
json-
should
be
good
enough,
but
we
probably
would
need
to
have
some
nougat
package
or
or
at
least
assembly
that
will
have
the
common
stuff
that
are
needed
to
just
create
another
bytecode
instrumentation.
G
C
No,
I
I
think
the
the
only
thing
that
we
need
is
because
those
things
can
have
not.
I
actually
not
the
byte
code
instrumentation,
but
the
thing
is
about
dependencies
that
people
need
to
be
very
careful
about.
You
know.
So,
probably
we
need
kind
of
to
have
a
a
set
of
rules
and
things
that
I
did
a
break
for
them
at
build
time.
C
If
they
are
bringing
some
dependence
or
if
they
are
bringing
some
dependence,
then
perhaps
we
have
to
point
into
how
to
update
those
folders
that
we
talked
prior
that
have
those
dependents,
but
preferences
is
not
to
bring
independence
when
doing
this
kind
of
instrumentation.
C
One
thing
that
I
think
it's
worth
mentioning
this
kind
of.
Why
these,
I
think
the
other
especially
java,
that's
working
without
instrumentation
has
this
kind
of
approach,
and
I
think
this
actually
helps
adoption,
because
there
are
a
few
cases
that
people
want
to
open
telemetry.
C
They
want
to
add
something
on
top,
but
they
don't
want
to
share
as
open
source
so
having
these
extensibilities
kind
of
we
get
more
traction
for
the
project
while
allowing
people
to
still
have
their
own
way
to
kind
of
they
just
want
to
add
an
instrumentation
for
some
library,
that's
internal,
that
they
don't
plan
to
open
source
that
slag
or
something
like
that.
C
One
good
argument
that
they
could
do
on
the
source
code,
but
sometimes
that's
what
they
want
so
with
having
this
extensibility,
is
also
attempted
to
kind
of
make
it
easier.
The
adoption
of
the
open
telemetry
itself
for
these
people,
and
they
can
also
do
their
specific
kids.
G
Yeah
to
follow
up
on
that
paulo,
I
have
worked
with
customers
where,
based
on
their
rules,
they
will
not
change
any
of
their
code
to
use
any
other
api
or
anything
like
that
and
as
a
result,
we've
had
teams
build
specific
instrumentation
for
their
own
internal
libraries
that
get
shipped
separately
from
the
from
the
product.
A
C
F
We
also
consider
basically
taking
in
multiple
json
files
and
reading
all
those
in
to
compile
the
list
of
like
integrations
that
the
profiler
will
be
right.
A
F
D
Okay
going
further,
so
the
next
stuff
here
is
basically
about
extensibility.
I'm
just
not
do
not
remember
it
right
now,
because
it
was
writing
like
two
weeks
ago,
so
basically
at
the
about
adding
a
custom
configuration
code
on
top
of
the
one.
What
is
out
of
the
box,
so
maybe
I'll
show
the
code
here.
D
So
basically,
I
think
there
zoom
in
please
yeah.
C
With
it,
so
so
so,
basically,
you
are
saying
that
in
that
chain
we
get
something
that
supports
the
builder
in
the
chain.
We
have
a
specific
point
to
inject
the
calls
to
shoot
that
that
one.
So
then,
if
if
they
have
some
source
instrumentation
similar
to
the
case
that
we
were
talking
about
before,
but
for
byte
code,
if
you
have
some
source
instrumentation,
they
can
use
this
mechanism
to
inject.
D
C
Yeah-
and
this
is
kind
of
I
don't-
there-
is
a
spec
for
some
aspects
of
this-
took
over
some
exporters-
the
batch
spam
processor,
but
I
think
then
it
becomes
a
matter
of
people
implementing
these
things
to
follow
a
convention
with
environment
variables.
Then
all
the
other
stuff
that
we
did
before
red
works
for
these
configurations.
C
C
H
C
By
the
way,
I
think
soon,
if
this
thing
keeps
going
progressing,
the
way
that's
progressing.
We
start
to
do
some
work
on
the
sdk
to
get
some
support
from
environment
variables.
There.
D
I
just
wanted
to
call
it
out
that
we
need
some.
We
need
some
methods
that
basically
load
stuff
from
the
environmental
valuables,
because
right
now
the
sdk
is
like
hard
coded.
So
I
imagine
that
if
someone
in
code
just
calls
add
zipkin
exporter,
it
will
be
always
added
whatever
you
know
the
environmentals
will
be
set,
and
I
think
that
I
looked
at
the
python
sdk
and
they
have
like
also
the
notion
of
registering
like
yeah
like
environmental
variables.
D
Callbacks
or
I
don't
know,
you
know
that,
for
example,
I
am
registering
you
know
a
zipkin
and
verm
to
variable
that
if
someone
configures
it,
then
it
will
be
loaded
just
to
have
you
know
this
not
not
tightly
coupling
in
the
sdk
code,
so
they
have.
You
know
something
like
I
have.
Basically,
I
have
mentioned
the
other
issue,
but
since
perhaps
I'm
thinking
too.
C
Too
hacky
here,
but
wouldn't
be
simply
like.
We
have
the
environment
variables
right.
C
C
So
so
what
I'm
saying
is
that
if
the
code
reads
the
environment
variable
when
is
instantiating
their
defaults,
perhaps
there
will
be
something
that
is
not
amendable
to
environment
variables.
That
is
a
separate
issue,
but
most
of
them
are
most
are
extreme
boards.
Things
like
that.
So
what
I'm
saying
that
a
very
kind
of
simple,
perhaps
hack,
way
of
doing
but
simple,
is
the
following:
if
every
component
follow
the
practice
of
okay,
my
default
is
if
the
environment
value
is
not
defined.
C
D
Yes,
so
basically,
I
think
that
for
use
cases
like
settings
for
the
exporter
concrete,
it
will
work
like
you
say,
because
it's
a
simple
use
case,
but
I
think
the
problem
will
be
the
environmental
variables
which
set
something
which
is
like
cross
component
because,
for
example,
if
you
have
you
know
exporters,
you
need
to
also
have
a
mechanism
to
you
know
plug
in,
like
you
know,
some
exporters,
which
are
right
not
out
of
the
box.
D
I
don't
know
if
you
are
talking
about
the
same.
I
hope
so
so.
For
instance,
if
we
have
the
zip
king,
if
we
have
the
zipping
exporter
configuration
here
like
that,
it's
very
easy
with
the
defaults
and
have
you
know
the
the
nougat
package
for
the
zip
king
to
just
read
them
and
put
the
defaults
if
there's
nothing,
but
if
we
have
an
environmental
variable,
for
example,
for
something
extremely
generic
like
author
traces
exporter,
then
you
know
it
could
be
otlp
jaeger
zikin.
D
I
don't
know
data
agent
and
here
is
being
more
complicated
and
I'm
more
worried
about
this
thing,
and
I
think
we
just
need
to
consult
with
with
cjo
or
with
other
guys
from
the
hotel
sdk
how
the
api
will
look
like.
D
C
Yeah
that's
easy,
but
requires
people
to
implement
the
components
following
that
practice.
What
I
think
is
not
the
case
right
now.
You
know.
So
perhaps
we
go
through
the
you
can
do
this
through
a
bunch
of
components
there
and
people
start
to
get
that.
You
know.
C
And
then
the
dot
net
sig
start
also
two
monitor
components
for
that,
and
then
you
are
right
for
this
other
kind
of
generic
kind
of
selection.
We
need
something,
a
bit
different
and
then
even
exported.
I
there
is
another
case
that
could
be
extension.
Point.
Can
somebody
add
export
their
customer
exporter,
so
we
don't,
we
don't
know
the
name.
Then
we
check
some
file
or
something
to
find
the
components.
D
Okay,
so
basically
he
was
just
example
like
I
try
to
even
spec
out
the
like
or
seldo
cellular
code,
or
even
maybe
code
that
will
be
working
for
for
this
plugin
mechanism.
D
D
G
Rubber,
before
you
get
into
the
distribution
part
of
it
sure.
H
G
That
plug-in
approach
that
you
just
mentioned
for
configuring
things
via
code,
it
seems
like
there's
two
approaches
that
we
could
take
for
there.
One
is
where
this
library
is
kind
of
deployed
independently
from
the
application
and
then
the.
G
D
D
B
D
G
G
And
then
the
other
thing
that
that
I'm
thinking
of
related
to
this-
and
it
may
be
more
complexity
than
than
we
need
right
now-
is
I'm
thinking
of
the
redis
instrumentation
case,
where
you
have
to
have
a
reference
to
some
redis
object
in
order
to
register
the
auto
instrumentation
from
the
sdk,
and
that
often
happens
in
a
different
spot,
especially
with
an
asp.net
core
app.
D
What
do
you
think
yeah,
because
I
imagine
it
could
be
done
in
a
very
hacky
way,
but
probably
it
could
be
done,
as
you
know,
as
you
told,
as
a
separate
accessibility
point
like
adding
some
kind
of
property
back
which
can
be
accessed
but
just
not
sure,
probably
I'll
need
to
sleep
and
think
about
it.
C
G
C
Thinking
about
this
in
the
sense
of
just
to
brainstorm,
really,
I
actually
start
to
not
like
this,
but
just
to
mention,
because
the
idea
came
to
my
mind
is
that
we
could
have
the
location
that
we
kind
of
describe
the
assemblies
for
a
specific
interface
or
type
and
kind
of
do
the
load
the
automatic
there.
But
I
kind
of
start
to
think
that
the
fire
is
a
better,
more
controlled
approach.
C
G
C
D
C
D
D
C
D
D
D
D
Okay,
so
basically
I
was
thinking
that
distribution.
It
was
something
that
I
saw
that
the
java
sdk
basically
does
everything
almost
by
overwriting
stuff,
that
almost
everything
in
there
in
the
repo
is
like
pub
public
and
they
can
override
like
public
mutual,
which
is
like,
which
is
by
default
like
in
java
and
basically
when
someone
wants
to
them
something
specific.
D
They
are
just
oh
they're,
just
inheriting
from
the
base
class
and
replacing
what
they
want.
So
I
think
I
thought
that
personally
I
didn't
like
that
much
that
approach
and
I
think
I
think,
but
probably
it
should
be
tested
in
the
battery
field.
That
probably
I
hope
that
this
section
here
like
the
default
one
should
not
be
very
big.
D
It
should
be
like
you
know.
I've
hoped
that
the
sdk
after
some
time
we'll
have
a
lot
of
stuff
out
of
the
box.
So
we'll
have
just
I
don't
know,
register
zipkin.
You
know
just
register
some
out
of
the
box
stuff
from
the
from
the
sdk,
but
I
don't
think
it
will
have
like
more
than
10
or
15
lines,
something
like
that
this
list-
and
I
was
thinking
that
we
just
need
a
next
like
a
extensive,
bleed
point
when
we
can
change
this
whole
code.
D
G
I
think
some
of
the
other
extensibility
options
that
you
mentioned
might
play
into
that
as
well,
so
with
the
alas
and
and
denialist
I
I
think,
can
help
whittle
down
the
the
defense.
D
D
You're
correct
but
yeah
you're
correct,
so
probably
a
lot
of
stuff
will
be
done
without
you
in
this
distribution.
That's
using
just
these
plugins
and
allow
a
deny
list
right.
That's
what
you
mentioned.
G
C
Can
can
we
kind
of
if
needed?
Can
we
just
have
something
very
simple
kind
of
say:
hey,
because
basically
we
set
up
the
sdk
and
then
the
work's
done
right,
so
we
don't
interact
with
the
sdk.
From
this
point
on
right,
we
set
up
the
pipelines,
we
started
the
quite
cool
the
source
instrumentation,
but
after
the
sdk
is
set,
there
is
no
interaction
with
the
sdk
directly
by
the
code,
it's
indirect
via
the
instrumentation
submit
activities.
C
So
perhaps
we
have
our
default
implementation
on
doing
this,
and
if
somebody
wants
to
really
have
control
full
control
of
this,
we
do
the
thing
about
the
loader.
Actually
right.
You
just
point
the
loader
to
something
that
does
the
initial
initialization
of
the
sdk.
C
Yeah
exactly
yeah,
so
I
I
I
don't
think
if
we
provide
that,
I
don't
think
we
need
to
provide
inheritance
or
other
mechanisms.
You
know
they
could
do
whatever
they
they
doing
there
and
inside
yeah.
C
Yeah
yeah,
I
think
I
think
that
that's
it
by
the
way.
I
think
it's
worth
to
mention
that,
although
we
are
very
on
the
beginning
of
this,
we
we
saw
on
the
plc
the
they
needed
to
kind
of
delegate
the
application
both
in
the
sdk
and
some
folks
from
the
java,
auto
instrumentation
saw
that
and
they
liked
the
idea
they
are
thinking
in
adopting
the
same
idea
too.
D
Okay,
so
here
I
put
an
example-
and
I
don't
know
so-
here's
an
example
for
like
this
thing,
which
was
specified
sooner,
but
I
had
a
discussion
with
rasmus.
Basically,
it
was
something
that
I
was
complaining
before
when
doing
his
review.
D
So
right
now,
I
have
like
I
have
specified
everything
using
elevator
variables
and
the
question
was
what
about
like
future
compatibility
for
such
stuff.
So,
for
example,
if
there
will
be
some
use
cases
that
we'll
need
to,
I
don't
know,
add
some
more
integrity
checks
to
the
plugins
that,
for
example,
someone
would
require
to
to,
for
example,
check
the
signatures
of
ddl
like
digital
signatures
of
of
dds,
or
I
don't
know,
hardcode
the
sh
essay,
the
checksums
or
stuff
like
that.
D
So
here
was
another
idea
like
here's,
like,
I
tried
to
put
the
question
here
and
possible
solution
that
instead
of
having
this,
for
example,
free
environmental
variables,
we
could
simply
have
a
configuration
configuration
file.
Instead,
when
we
specify
all
the
extensibility
configuration
like
accessibility
means
the
loader
stuff,
the
distribution
and
this
plugin
stuff.
D
D
G
A
A
G
C
Yeah,
I
know
that's
a
good
point
as
much
as
I
I
don't
like
json
files,
depending
on
what
you
are
doing.
Maybe
it's
the
best
like
like,
for
instance,
the
integrations
they
draw
actually
is
a
good
fit
for
the
result.
There
is
a
bunch
of
information
there,
that's
kind
of
hard
to
put
in
other
form,
not
not
other
form,
but
new
data
structure.
The
form.
C
Just
a
quick
comment
on
the
format
additional
assemblies,
but
this
you
just
mean
that
the
loader
will
look
at
these
folders,
but
shouldn't
we
be
doing
this
per
assembly
instead
of
having
a
bunch
of
paths.
Should
we
have
these
per
plugin
providers.
D
Just
just
close
in
my
mind,
you
know
the
one
thing
which,
like
from
the
usability
perspective,
is
that
maybe
a
few
comments,
it's
easier
to
see
and
understand
when
you
have
an
array
of
json
than
have
something
like
that,
for
example,
I
don't
know
if
you
see
here
we
have
two
plugins
yeah.
C
D
But
I
can
even
it's
so
easy
that
I
can
talk
in
parallel
and
basically
mer.
I
think
that
merging
you
know,
for
example,
doing
something
like
for
path.
If
you
have,
for
example,
you
know
something
default,
it's
easy
to
do
something
like.
D
D
I
don't
think
it
will
be
that
easy.
For
example,
you
know
to
edit
additional
directories.
So
probably
there
will
be
more
logic
inside.
I
don't
know,
merging
multiple
config
files
that
it
you
know,
gets
all
together
and
merges
multiple
json
files
into
one
single
structure.
So
that's
only
one
thing
which
was
coming
to
my
mind.
C
Easier
yeah,
I
think
I
think
the
point
is
is
now
after
you,
you
presented
the
dog.
We
take
a
second
look
to
a
quick
pass
and
put
comments
and
review,
and
then
we
try
to
have
some
similar
validation
of
these
ideas
on
the
plc.
Branch
doesn't
need
to
be
something
that
we
perhaps
merge
the
code,
but
just
validate
the
ideas
that
things
for
things
that
we
have
questions.
If
they
work
or
not,
we
we
should
do
a
quick
validation
on
top
of
the
plc
branch.
C
So
thanks
robert,
I
think
we
are
already
kind
of
one
hour.
I
I
I
think
it
starts
to
be
unproductive
if
we
keep
going
much
more.
B
F
F
Yeah,
I
I
had
to
run
to
another
meeting,
really
quick.
I
did
add
another
item
to
our
agenda
notes.
While
we
were
speaking-
and
I
mean
we
don't
have
too
much
time
to
talk
about
it,
but
I
want
to
throw
this
on
your
radar
and
see
if
you
have
any
concerns,
we
are
planning
to
move
sort
of
most
of
our
products
into
like
a
tracer
subdirectory,
and
so
we
can
just
live.
F
We
put
all
of
our
tracer
stuff
in
there
that
way
we
can
expand
with
other
other
products,
and
so
I
want
to
bring
that
to
your
attention.
F
Besides,
I
think
there'll
be
some
changes,
maybe
on
your
ci
to
like
adjust
the
path,
but
I
don't
think
there's
going
to
be
any
disruption
other
than
that.
C
C
Okay,
no
no
check
the
dashboard,
but
I
think
there
was
nothing
new.
I
was
checking
the
notifications
this
week
and
I
didn't
see
any
new
issues,
so
I
think
we're
good
there
all
right.
Everyone.