►
From YouTube: 2021-06-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
Yes,
so
I
I'm
confused
about
the
the
so
that
I
was
just
and
second
ago
I
was
in
the
right
meeting
correct.
B
Because
I
have
two
different
links
and
I
was
thinking
that
the
meeting
has
changed
but
because
one
link
actually
requires
a
passcode
and
the
other
does
not.
B
But
now
that
I
know
that
both
lead
to
the
same
meeting.
It's
great.
I
can
use
the
link
without
the
passcode.
A
Yeah
yeah
the
the
unfortunately
zoom
bombing
that
happened
with.
I
was
in
a
meeting
that
happened
that
lambda
some
time
ago,
and
then
we
have
to
put
passcodes
you
know
so.
A
Yeah,
but
you
know
bots,
because
these
meetings
are
public
and
they
didn't
have
any
passcode,
so
bots
come
and
they
start
to
to
post
a
lot
of
stuff.
You
know
music,
porn
videos,
everything
you
know
so.
B
Really
like
in
a
meeting
a
zoom
board,
that
is
so
that
is
cool.
I
didn't
realize
it
existed.
No,
you
literally
have
a
conversation
on
zoom
about
whatever
it
is,
could
be
anything
right.
It
could
be
whatever
like.
We
have
a
work
conversation,
but
could
be
anything
and
suddenly
a
virtual
person
appears
in
that
meeting
and
it
goes
like
hey.
Why
don't
you
buy
some
whatever
really
like
that?
Yes,
yes,
that
is
so
cool
like
wow.
B
A
Yeah,
I
would
experience
it
the
public
zoom
meetings.
I
think
people
can
just
write
about
and
guess,
the
the
code
and
once
they
get
one
that
they
are,
if
they
they
are
allowed
to
share
and
post
stuff.
The
bot
starts
sending
stuff
like
crazy
and
also
I'm.
B
B
Yeah
but
they
do
do
they
post
so
bad
things.
A
B
Wow
you
you
know,
but
whatever
it
is.
I
like
just
the
the
phenomenon
of
actually
this
happening.
I
I
I
realized
that
maybe
not
the
the
kind
of
things
I
would
like
to
be
advertised,
get
advertised
and
shown,
but
still
you
know
it's
okay,
it's
like
if
you've
never
seen
spam.
Yes,
the
contents
of
spam
are
annoying,
but
you
know
if
you
actually
want
to
experience
a
phenomenon
you
can
deal
with
it.
A
Okay,
so
greg
since
you
you
had
your
pto
we've
been
doing
experimenting
with
the
sdk.
We
did
a
poc
branch.
We
think
we
found
a
workaround
for
the
majority
of
the
issues
that
we
we
are
aware
about
conflicting
versions,
and
things
like
this
so
just
to
be
very
briefly,
4.net
core.
A
A
A
I
think
no,
that
was
binding,
redirects
no.
C
I
think
this
scenario
was
that
some
library
was
using
different
version
of
of
some
package
of
some
reference
and
if
and
we
are
able
to
like
force
different
version
of
the
assembly
just
by
giving
the
newest
version
to
the
application
and
by
default,
the
fighting
crew
directs
are
not
needed.
Like
there's,
you
said
that
there's
some
default
of
callback.
I
think
it's
even
described
in
dpr.
You
were
reviewing.
I
don't
know
this
week
or
last
week.
Chris,
you
remember.
C
A
Yeah,
but
the
important
thing
is
that.
A
We
think
that
we
have
workarounds
and
recipes
and
there
will
be
limitations
with
that.
One,
like
chris
pointed,
for
instance,
in
certain
scenarios
that
devops
don't
have
debuted
access
to
the
the
application.
Then
we
can't
do
this
stuff,
but
it
seems
that
is
a
is
a
path
that
we
can
take
to
start
to
get
some
synergy
with
the
sdk.
A
So
we
can
try
to
move
the
project
a
bit
faster,
because
I
think
the
challenge
that
we
are
facing
is
that
no
one,
no
one
of
us,
can
take
a
dependency
on
the
project
right
now,
because
the
project
is
not
ready,
and
so
we
keep
being
pulled
for
stuff
that
end
up
taking
a
higher
priority,
because
the
project's
not
being
used
right
now.
A
So
this
will
be
kind
of
a
tentative
to
accelerate
stuff
and
gets
us
to
the
point
that
we
can
start
to
really
use
it.
A
B
And
in
a
high
level
in
a
nutshell,
so
it's
about
referencing,
the
sdk
libraries
or
is
it
what
what
is
it
specifically.
A
We
we
know
these
problems
and
limitations
about
the
versions.
We
know
that
requires
business.
B
But
when
we
say
using
the
sdk
the
trace,
I
didn't,
I
don't
quite.
A
Understand,
instead
of
injecting
the
when
we
do
the
startup
instead
of
starting
the
datadog
tracer,
we
start
the
sdk
okay
and
we
listen
the
activities
we
generate
activities
instead
of
generating
the
internal
spend
type.
You
know.
B
Got
it
so,
but
so
we
we
do
still
do
a.
I
have
an
instrumentation.
B
Gorgeous
so
so,
whenever
it's
activities,
then
of
course
it
doesn't
need
to
do
anything
and
then
instrumentation
injects
activities.
B
A
An
example
in
the
plc
branch
like
the
mongodb
is
io
instrumentation,
bytecode
instrumentation.
D
A
As
chris
mentioned,
for
instance,
the
asp.net
core
comes
from-
let's,
let's
let
me
call
source
instrumentation
that
uses
diagnostic
listener,
but
that
the
fact
that
diagnostics
doesn't
matter
whatever
the
source
produces
the
activity.
We
listen
to
that.
You
know
yes,.
B
B
So
let
let
me
please
repeat
what
I
understood
and
let
me
know
if
it's
correct,
so
we
use
io
instrumentation
to
generate
to
emit
activities,
and
then
we
can
use
the
part
of
the
sdk
that
collects
activities
and
sends
them
to
do
exactly
that.
B
Got
it.
We
just
need
to
load
that
part
of
and
like
make
sure
that
that
part
of
the
sdk
is
actually
loaded.
Yes,
okay,
and
we
do
that.
A
By
doing
what
we
we,
basically,
if
you
look
at
the
code
of
the
the
sdk,
basically
has
a
bootstrap
section
and
we
use
the
loader
code.
But
instead
of
calling
the
the
tracer,
we
call
the
the
bootstrap
code
from
the
hotel,
sdk.
B
But
and
then
there
is
the
versioning
problem:
if
the
application
is
already
using
the
sdk,
then.
A
We
we
the
the
way
that
we
handle,
that
is
the
falling,
because
the
sdk
is
for
producing
the
traces
not
to
lock
the
activity.
We
have
the
open,
telemetry
api
to
instrument,
libraries
and
applications
use
the
sdk
to
actually
produce
to
need
the
activities
capture
and
actually
export
them.
Yes,.
D
B
A
Okay,
sorry,
I
I
mean
I'm
in
my
house
when
I
do
it's
bad,
so.
E
C
D
So
greg
to
answer
your
question
while
we're
getting
that
sorted
out,
I
I
believe,
what's
being
said,
is
that
the
application
so
what's
been
proved
out
so
far
is
when
the
application
is
not
directly
referencing
the
sdk
itself
and
instead.
D
So
so
that
way,
we
don't
have
multiple
instances
of
the
sdk
being
loaded
into
memory,
and
so
any
instrumentation
is
done
through
the
api,
which
is
through
diagnostic
source
and
there's
a
set
of
plug-ins
that
the
groups
proved
out
to
where,
if
you
want
to
do
some
customizations
or
some
vendor-specific
things,
there's
a
way
to
execute
certain
code
within
the
application.
B
So
telemetry
is
emitted
through
sdk
through
the
hotel
api,
which
is
a
one
small
nougat
now,
if
the,
but
that
api
goes
through
to
essentially
diagnostic
source
right.
So
that
means,
if
we
do
ions,
if,
if
a
library
like
a
sdk-
for
I
don't
know
some
some
remote
invocation
right,
if
it's
emits
its
own
temperature,
then
we're
good.
We,
it
already
sends
activities
or
diagnostic
source
events.
We
can
just
collect
them
no
problem.
B
B
So
so
that's
good
and
now,
in
terms
of
collecting
and
sending
that
telemetry
like
exporting
it,
I
should
say
if
the
application
does
not
use
or
reference
the
hotel
sdk,
no
problem.
We
can
have
a
our
own
kind
of
vendor
inversion
and,
if
it
does
that,
so
the
the
the
two
interesting
parts
are
what
happens
when
an
application
already
references
diagnostic
source,
because
we
need
to
ship
our
own
version
of
diagnostic
source
and
there
could
be
a
virgin
conflict
there,
which
we
need
to
like.
B
There
is
a
solution
for
it,
just
that
we
need
one
and
the
second
one
is
when
an
application
already
has
reference
to
the
hotel
sdk.
B
B
C
Solution
is
just
to
ask
like
force.
Like
you
know,
troubleshooting
is
like
please
use
the
same
version
like
include
the
same
versions
so
for
like
just
to
speed
up,
but
in
future
we
can.
Just
you
know,
instrument
bite
like
instrument
the
code
to
the
sdk
into
the
diagnostic
source,
so
everything
goes
to
the
vendor
version
correct.
I
think
that's
what.
D
F
B
So
so
so
for
for
send
for
exporting
for
collecting
and
exporting
exactly
like
you
say,
because
the
sdk
there
is
it's
not
an
exchange
type,
it's
it's
it's
a
worker
type,
so
we
can
essentially
just
instrument
to
use
the
rendered
version.
The
complicated
challenge
is
for
the
diagnostic
source
library
itself,
because
that's
an
exchange
type.
We
can't
make
it
use
the
vendor
inversion.
Just
we'll.
We
will
have
to
rewrite
a
lot
of
things,
and
for
that
I
just
sent
a
link.
B
In
in
the
chat,
so
that's
that's
that
basically,
is
a
working
thing
for
not
activities.
I
think
I
mentioned
this
in
the
past.
I'm
not
sure
whether
I
ever
run
a
demo,
but
it's
it's
open
source
now,
so
it
it
creates
a
wrapper
around
diagnostic
stores
and
the
same
way
so
it
loads
the
library,
dynamically
and
the
it
exposes
oil
apis
for
diagnostic
source.
We
can
add
more
apis
for
activities
as
we
need
them,
so
what
it
does
it
allows
the
il
instrumentation
to
always
use.
B
So
the
wrapper
does
the
following:
if
the
application
references
diagnostic
source,
so
it's
loaded,
then
it
forwards
all
calls
to
the
part
to
the
diagnostic
source
that
came
to
the
application,
and
if
the
application
doesn't
reference
diagnostic
source,
then
it
forwards
all
calls
to
the
rendered
version,
and
then
it
does.
It
watches
libraries
being
loaded.
So
if
something
is
loaded
late,
it
dynamically
switches
from
one
to
the
other.
B
The
result
of
it
is
that,
if
anything
that
emits
il,
if
all
our
instrumentation
uses
the
light
this
this
wrapper
instead
of
diagnostic
source
directly,
it
will
all
just
work
with
diagnostic
source
and
activities
as
well
right.
So
it
will
glue
together
in
in
in
common
stacks,.
A
I
I
I
think
I
you
you,
you
showed
the
damage
to
us
some
time
ago,
yeah.
I.
A
Yeah
yeah,
no!
No!
No!
No,
I
I
do
remember,
but
it's
good
to
to
revisit,
but
what
we've
been
kind
of
leaning,
at
least
in
the
short
term,
is
to
kind
of
using
these
either.
The
project
is
specifying
a
specific
new
get
pi
active
version
or
the
binding
redirects.
We
kind
of
work
around
this
version
problem.
You
know,
because
the
application
is
then
deployed
with
the
version
that
we
need.
B
B
A
And
if
the
application
has
and
conflicts
version,
what
we
can
do
that
there
are
depends
on
the
scenario,
but
typically,
for
instance,
you
can
add
the
reference
for
net
core.
If
you
add
a
reference
to
the
nuget
package,
even
if
it's
a
library,
a
third-party
library
down
in
the
chain,
the
version
resolution
is
going
to
do
the
following:
hey
I
have
the
this
is
my
first
reference
to
the
diagnostic
source.
I'm
going
to
pick
up
the
application.
A
B
A
Okay-
and
I
would
say
that
most
of
the
scenarios
with
open
telemetry
people
have
been
kind
of
building
from
the
sources
you
know
they
have
access
to
the
building.
What
scenario
doesn't
have?
I
think,
chris
that
brought
that
up
some
time
ago,
it's
kind
of
their
devops
scenario
that
they
do
deployments
and
they
don't
have
access
to
the
project
itself
to
build.
In
that
case,
this
workaround
proposed
doesn't
work
out
of
the
box.
You
know
I've.
B
Seen
that
scenario
actually
super
often
because
if,
if,
if
you,
if
you
have
access
to
the
application,
you
can
sort
of
do
what
application
insights
does,
which.
E
Yeah,
if
you
you,
you
know
sorry,
never
mind
it's
just
a
matter
of
deployment,
then
never.
A
Mind
so
so,
when
we
have
the
project,
I
think
we
have
the
arc
the
workarounds.
We
understand
that
we
don't
have
the
workarounds
for
the
case
that
you
are
getting
the
let's
say
a
package
with
the
application.
You
are
not
building,
we
don't
have
the
solution,
then
we
need
something
like
the
stuff
that
you
did,
but
I
think
that
for
us
to
get
start
and
get
the
moment
to
get
some
people
to
use,
we
should
take
this
route,
because
that
allows
us
to
kind
of
gain
some
dependence
on
the
project.
F
B
So
yeah,
I
think
it
should
be
possible
because
so,
with
this
plan
we
are
rewriting
il
instrumentations,
not
the
engine
for
our
instrumentations,
but
the
actual
instrumentations
right,
like
the
integration
code,
because
they
used
to
the
the
the
one
that
previously
emitted
like
spans,
would
now
emit
a
diagnostic
source
event
or
activities
right.
B
B
That
work
needs
to
happen
anyway,
correct
when,
as
we
do
this
and
I'm
guessing,
please
let
me
know
that
we
want
to
emit
activities,
not
diagnostics
events,
yes
activities,
yes,
that
that
makes
sense.
B
So
the
the
the
challenge
of
of
of
so
basically
the
plan
makes
session.
It's
just
this
aspect,
because
the
the
the
story
at
microsoft
that
happened
is
that
essentially
initially
the
bet
was
that
enough
people
touched
the
application
and
then
the
big.
The
big
kind
of
issue
was
that
the
learning
was
known.
There
is
the
market
for,
like
the
devops
scenario,
is
essentially
almost
bigger
and
like
in
in
a
very
long
term,
people
will
of
course,
touch
every
application,
but
by
the
time
it
happened.
B
Vendors
who
support
the
like
the
non-touch
application
scenario
will
have
will
be
controlling
the
market.
Essentially,
so
it
may
be
a
matter
of
time
estimation
because
you're
right
if
we
can
move
the
project
forward
by
doing
what
you
described,
that
may
be
just
a
good
compromise.
C
Want
one
question:
this
is
something
that
I
do
not
know
it's
possible,
but
probably
you
know:
is
it
possible
to
do
another
approach
that
just
doing
the
il
rewrite
to
use
different
reference
of
a
library?
So
we
will
just
you
know,
force
the
application
to
load
the
one,
the
the
diagnostic
source,
that
we
want,
that
we
ship.
B
C
D
B
Api,
so
what
the
rapper
does,
so
microsoft
won't
break
backward
compatibility,
so
the
rapper
notices
that
there
is
a
more
forward
version
forward
forward
that
forwards
all
costs.
To
that
I
see
so
so.
If
we
wanted
to
do
diagnostics
tools,
not
activities,
then
the
rep
is
ready.
We
can
use
it
today
with
essentially
as
we're
rewriting
the
il
integrations.
B
It's
same
effort,
doing
it
via
the
wrapper
or
directly
calling
diagnostic
students.
It's
ready.
It's
and
all
the
all
the
right
apis
are
there,
and
there
are
actually
examples
of
how
to
do
this.
I
also
linked
them
for
activities.
B
B
I
don't
know
how
many
of
the
activity
apis
actually
need
to
have
a
wrapper.
It
could
be
that
it's
literally
two
or
three
or
five
or
no
in
that
case
it
could
be
a
an
effort
of
like
one
sprint
to
add
those.
By
simply
doing,
you
know
copying
the
same
stuff
that
we
do
for
diagnostic
source,
just
co-interactivity.
Instead.
B
Up
to
you
guys,
because
you're
working
on
it
more,
but
I
would
encourage
you
to
spend
a
couple
of
days
and
days
just
investigating,
because
if,
if
it's
viable,
then
it
could
be.
Essentially
you
like
avoid
this
problem,
and
you
immediately
address
the
the
devops
people
as
well,
and
if
not,
then
you
know
that
it's
then
you
have
just
gained
some
some
clarity.
A
There
just
for
me
to
understand
the
trade-off
here,
because
on
that
path
there
the
main
difference.
Basically,
you
change
the
reference,
because
the
thing
you
look
and
behave
as
an
activity
right,
so
the
instrumentation
basically
looks
the
same.
It
doesn't
look
different
mine
or
some
using
statement
somewhere,
but
please.
B
Several
months
ago,
probably
so
I
hope
I
can,
but
let
me
share
my
screen,
which
is
which
what
is
the
right
one?
Second,
that's
right
here.
E
Do
you
see
my
browser
window
now.
A
E
E
B
B
No,
I
I
I
don't
want
to
waste
the
time
now,
so
I
I
can
I
can
send.
I
can
find
the
the
method
after
the
meeting
and
send
a
point
to
the
to
the
chat,
but
it's
essentially
the
same
structure.
It's
equivalent.
Every
api
has
a
different
name,
but
it's
a
similar
name.
It's
like
has
a
stub
in
it
or
something.
So
if
your
question
is,
can
we
write
it
for
the
one
and
then
change
it
and
whether
it's
easy?
Yes,
it
is
easy,
but
it's
not.
D
So
I
think
that
segues
into
a
question
that
that
I
was
going
to
bring
up,
which
is
related
to
a
document
that
robert
shared
a
couple
weeks
ago,
where
the
it
talks
about
how
we
can
use
a
similar
api
within
the
il
instrumentation
and
source
based
instrumentation
to
do
instrumentation.
D
And
I
think
what
this
leads
to
is
that,
when
we're
doing
il
based
instrumentation
we'll
likely
want
to
have
a
an
api
layer,
an
abstraction
layer
in
there
where
we
can
then
handle
any
mapping,
logic
or
future
changes
to
how
we
need
to
manage
these
different
dependencies.
Whether
we're
using
the
forwarding
stub
that
greg's
talking
about
or
whether
we're
using
the
the
activity
api
directly.
B
So
the
thing
is,
the
forwarding.
Stub
is
sort
of
already
delay.
You
could
have
an
additional
layer
of
interaction
or
you
can
to
simplify.
B
But
designing
that
api
is
essentially
also
time,
so
you
could,
you
could
take
the
thing
design
the
api,
but
but
like,
for
example,
the
way
this
is
written
right.
First,
there
was
this
api
and
I
was
statically
referencing
diagnostic
source
and
calling
directly
into
it,
and
then
you
sort
of
swap
the
the
for
example.
If
you
may,
if
you
already
create
this
api,
then
you
have
to
think
about
how
the
cpi
looks
like
so
that
it
can
do
be
generic
so,
for
example,
the
the
the
vendored
versions
already
baked
into
this
library
right.
B
You
remember
apollo.
We
did
this
together,
so
so
you
could
do
the
activities
right
now,
like
exactly
what
you
say
you
create
this.
You
create
this
layer,
but
for
for
the
activities,
it
always
uses
the
the
vendored
inversion
or
you
can
statically
reference
and
always
use
the
the
latest
version,
whatever
you
prefer
and
then
later
you
swap
it
for
dynamic
loading.
B
D
Yeah
I
I
would
think
that
the
api
design
is
already
in
place,
given
what
the
activity
api
is,
and
so,
which
is
basically
what
what
you
did
you
you
took
the
existing
api,
shape
and
reused
it,
and
then
you
eventually
just
swapped
out
which
version
of
it
you
were
using.
Ultimately.
B
Yeah,
it's
just
you
you,
the
the.
B
Exactly
it's
it's
it's
it's
very
very
similar.
It
follows
exactly
the
same
structure
as
the
original
api,
but
it
can't
be
the
same
because
you
need
to
say,
dear
dear,
stop,
give
me
an
activity
and
then
so
give
me
an
activity
wrapper.
You
can't
just
go
and
you
have
an
activity.
You
should
see
what
I
mean
right.
B
It
follows
the
pattern,
but
it's
not
exactly
the
same.
So
there
is
api
design
in
it
and
if
you
do
another
layer,
then
essentially
go
like
dear
dear
rapper
of
the
of
the
generic
thing.
Give
me
the
generic
thing
so
essentially
do
exactly
the
same
logic,
just
one
more
layer
and
then
what
I'm
saying
is
because
stub
is
already
as
a
wrapper.
Just
do
the
api
but
delay
the
implementation
implementing
of
the
dynamic
part
of
it
and
have
the
stub
just
always
give
you
the
static
thing.
B
A
So
I
think,
for
for
the
short
term,
this
is
a
is
an
important
question
about
who
you
wanna
what
we
wanna
do
down
the
road
for
this
scenario,
but
I
think.
A
I
think
I
before
we
tackle
that,
but
as
long
as
we
don't
start
to
tackle
a
bunch
of
io
instrumentations,
I
would
like
kind
of
to
wrap
up
the
poc
with
the
two
things
that
I
mentioned
before
and
seems
that
one
is
done
and
collect
that
information.
A
A
I
didn't
encounter
that
scenario
as
much,
but
I
know
chris
already
mentioned
so
we
already
encounter
gregor
had
mentioned
he
already
in
contact.
So
I
I
I
would
like
us
to
to
think
about
and
try
to
to
dig
if
this
is
kind
of
a
legacy
scenario
that
still
exists
and
it's
worth
the
investment
or
not.
A
And
once
more
I'm
saying
this
based
on
my
experience,
but
I
I
don't
encounter
that
recently
yen
scenario,
you
know,
so
the
cases
that
I
encounter
people
do
have
access
to
the
project,
and
I
I
want
to
avoid
us
taking
a
costly
path.
A
Perhaps
for
and
we
to
be
fair,
we
probably
don't
have
a
good
way
to
measure
that,
but
I
would
like
to
kind
of
think
if
it's
really
a
scenario
that
we
must
support,
you
know
or
if
it's
something
that
perhaps
look
something
that
happened
in
the
past.
But
if
you
take
an
approach
that
let's
look
to
the
future
in
especially
that
activities
part
of
the
runtime
kind
of
what
makes
sense
for
us
to
invest
on
that.
A
B
Yeah
that
works
good,
just
to
add
a
little
bit
on
top,
because
there
are.
There
are
separate
questions
that
that
you
you
touched
on.
I
think
it
would
be
good
to
kind
of
underline
the
the
difference
here.
So
the
the
what
we
call
devops
scenario
right-
and
I
I
don't
have
numbers
to
to
to
to
show
right
now,
but
just
I'm
just
sharing
experience.
B
We
will
be
able
to
address
a
significant
market,
ignoring
this
issue
and
saying
it's
not
supported.
Yes,
we
will,
however,
which
market
is
bigger,
the
one
that
that
devops
scenario
market
or
the
the
touched
application
market.
I
think
there
may
maybe
either
roughly
the
same
size
or
the
devops
market
is
bigger.
B
Both
people
people
go,
we
want
open
telemetry
and
they
don't
want
to
touch
the
applications
they
they
want
to
install
open,
telemetry
tools,
they
go
like.
Oh,
we
have
like
they.
They
don't
understand
this
as
deeply
as
we
do
they
go
like
we
want
standardization.
We
don't
want
to
commit
to
some
sort
of
vendor
specific
thing,
but
we
just
can't
touch
our
application.
D
Yes,
but
at
the
same
time,
open
telemetry
is
in
a
state
of
where
some
things
are
pre-release
and
some
things
are
ga,
and
so
that's
where
I
I
I
I've
seen
hesitancy
between
between
different
segments
and
so
that
that's
where
I
don't
have
a
good
answer.
Yeah.
B
B
There
is
a
couple
of
things
that
are
all
important,
but
very
distinct,
and
we
should
not
mix
them
up.
One
is
some
libraries
just
are
not
producing
telemetry
and
that's
a
big
problem
and
in
some
long-term
future
it
might
go
away,
but
it's
gonna
be
a
long
time
until
then,
and
then
there
is
another
distinct
problem
that
is
also
huge
and
that's
the
devops
scenario
program
right.
People
want
to
take
the
application,
do
some
magic
to
the
infrastructure
and
have
telemetry
and
the
market,
for
this
is
gigantic,
and
especially
large
corporations.
B
A
Yeah
one
thing
I
that's,
perhaps
a
a
little
bit
of
confusion
with
the
term,
but
I
see
people
claiming
claiming
teams
that
I
worked
with
saying:
hey,
I'm
not
touching
the
code
at
all,
but
they
really
mean
source
code.
You
know,
and
I
think
what
I'm
calling
devops
scenario
just
to
be
sure
is
people
that
are
not
even
talk
about
touching
their
build.
You
know.
A
Yeah
no,
but
I
I
think
it
I
think
it's
good
to
to
make
the
district
you
know,
because
I
I
think
they
are
all
the
the
the
the
true
case.
I
I,
as
I
said,
I
don't
have
a
clue
about
numbers.
I
can
tell
that
the
experienced
person
that
I
have
is
people
that
okay,
I
don't
want
to
touch
code.
They
are
very
vocal
about
it,
but
if
I
tell
to
them
to
change
stuff
in
the
build
or
their
deployment,
they
they
take
it.
A
You
know,
but
it's
a
different
scenario
that
somebody
that
is
not
gonna
touch
the
building
you
know,
so
I
think
we
wanna
cover
the
zero
touch
source
code,
in
any
case,
the
build
case
that
I'm
calling
that
I
don't
wanna
touch
even
the
build.
Is
that
special
case
that
we
need
to
come
to
kind
of
a
decision
about
how
we
are
going
to
approach
that?
A
Are
we
gonna
go
there
out
of
having
this
stud
and
handle
that
case
too,
or
are
we
gonna
kind
of
say
that
that's
not
a
scenario
that
we
cover?
I
don't
know.
B
I
think,
because
we
can
there's
a
difference
of
saying
we
want
to
get
to
some
market
soon,
so
we
do
want
to
cover
the
devops
scenario.
But
later
that's
one
thing
or
we
can
say:
actually
we
not
part
of
like
not
not
at
all,
because
if
we
do
that,
we
will-
and
I
know
we
don't
have
numbers.
So
it's
just
a
matter
of
perspective
like
again.
D
B
Me
to
me
this:
we
will
significantly
reduce
addressable
number
of
people
because,
like
touching
the
build,
but
not
touching
the
code,
that
means
you
touch
your
build
scripts.
That
means
like
really
you're
touching
your
code.
Like
blah,
we
don't
have
data,
so
let's
leave
it
there
but
clear
that
we're
not
don't
fully
understand
the
the
amount
of
people
there,
but
the
thing
is,
if
we
explicitly
say
no
devops,
we
suddenly
offer
ourselves
a
lot
of
new
options
for
for
designs
right.
B
We
can
say
well
now
that
we
can
touch
our
build,
that
we
must
touch
our
build.
We
don't
do.
We
really
need
runtime
instrumentation.
Why
don't
we
take
the
library
being
referenced
by
the
application,
rewrite
the
il
in
place
like
of
that
library
make
it
emit
telemetry
we
can
inspect
what
is
being
referenced.
B
We
can
we
can
make
it
reference
new
things
and
rewrite
the
l
repackage
the
application
done
like
nothing
being
touched
at
runtime.
That's
neat
probably
comes
to
some
disadvantages
as
well,
but
in
the
scenario
where
we
know
that
that
application
must
be
touched
like
the
build
of
the
application
must
be
touched.
Suddenly
we
have
lots
of
options,
and
just
this
is
just
an
example
right
yeah,
so.
C
Yes,
so
can
I
just
interrupt,
I
think
that
we
together,
like
as
a
whole,
see
we
should
not
be
against
against
greg
your
proposition.
Personally,
I
was
not
even
against.
I
just
think
that
it's
something
that
should
be
in
plan,
but
should
we
should
not
focus
like
as
immediate
step,
because
it
would
just
you
know,
we'll
lose
a
lot
of
velocity
to
get
any
any
feedback
even
from
ourselves
touching
with
the
bit
scenario,
but
in
my
opinion
we
should
address
this
devops
scenario.
C
C
B
Yeah
yeah
yeah.
I
I
just
want
to
make
sure
that
we
don't
lose
the
strategy
for
the
for
for
the
tactics
as
but.
A
No,
I
I
agree.
I
I
think
I
was
mentioned
kind
of
the
most
extreme
case
kind
of
we
support
or
not
support,
but
also
there
is
the
kind
of
in
between
kind
of
we
are
enabling
this
for
this
scenario
right
now,
but
then
we
address
the
other
scenario
in
the
next
step.
I
I
just
want
to
be
sure
that
we
need
to
solve
that.
A
When
we
get
to
the
step
of
touching
the
the
il
instrumentations
you
know
we
are
going
to
make
those
to,
depending
on
activity
we
are
going
to
make
this
depend
on.
Let
me
call
stub
if
you
don't,
like
the
name
greg,
I'm
gonna
for
now.
I'm
gonna
use
this
stub,
but
you.
A
They
they
stub,
so
how
we
are
gonna.
Do
that
part?
You
know
so
for
the
plc
right
now
we
just
wrote
one.
It's
fine,
it's
just
to
prove
the
concept
really.
So
it's
it's
totally
fine,
but
the
question:
when
we
get
to
that
point,
then
we
need
to
to
have
a
clear
picture
about
what
we
want
to
go,
even
perhaps,
if
even
if
we
are
not
doing
at
first,
then
we
are.
We
are
writing
it,
prepared
to
eventually
have
these
stubs
in
place.
A
You
know
so,
even
if
the
first
stub
version
that
we
ship
actually
uses
activity,
but
then
we
have.
C
B
Yes,
if
you,
if
you
do,
if
you
do
an
adapter
so
up
to
you,
I
think
it
makes
sense.
You
don't
want
to
over
engineer
it
now.
You
want
to
do
it
step
by
step.
My
recommendation-
and
it's
very
soft
recommendation,
please
feel
free
to
do
it
in
any
other
way,
is
to
look
closely
at
the
existing
start
api.
It's
it's
all
done
for
everything
that
is
diagnostic
source
directly
rather
than
activity.
It's
done,
tested
and
ready
to
go
right
now.
B
So,
if
you
wanted
to
emit
diagnostic
source
telemetry
rather
than
activity
telemetry,
you
could
start
doing
it
full-on
today
dynamically
with
the
study.
If
you
look
at
the
how
they
I
I
sent
after
the
meeting
some
some
links
to
the
to
the
to
the
chat,
I
would
look
at
it.
B
B
The
thing
is,
as
you
do,
this
use
as
few
activity
apis
as
possible,
but
as
many
as
necessary
whenever
you
feel
like
you
could
actually
avoid
using
an
activity
api.
Maybe
it's
slightly
less
need,
but
you
can
avoid
using
it
do
avoid
it,
don't
stop
it
and
then,
by
the
time
you're
finished,
you
know
exactly
which
activity
apis
need
to
be
stopped
and
which
don't
and
then
this
whole
complexity
that
we
chatted
a
while
back
about
ids.
Do
we
need
to
like
map
all
the
addition?
B
New
ideas,
like
the
all
of
the
stuff
may
not
even
be
a
thing
because
we
get
away
without
it
or
maybe
not.
I
don't
know,
but
by
doing
this
way
we
know
exactly
what
needs
to
be
stopped
and
what
doesn't
and
then
the
whole
stabbing
effort
is
much
better
defined.
A
Yeah,
so,
okay,
I
think
we
had
a
bug
about
something:
that's
not
building,
I'm
I'm
changing
the
topic
right,
but
we
had
a
a
bug.
It
was
the
only
new
issue
that
we
we
had
and
the
the
build
is
falling.
I
have
to
look.
A
G
D
A
Yeah,
so
let's
update
the
branch
and
merge
them,
so
we
got
rid
of
that.
A
So
all
right
so
gonna
try
to,
as
I
said,
try
to
wrap
up
the
stuff
for
the
plc
before
next
meeting,
and
then
we
can
perhaps
continue
the
the
discussion
or
start
a
more
basic
discussion
about
what
happens
next.
Regarding
the
io
instrumentation
itself,.
A
Yeah,
by
the
way,
I
I'm
not
a
scribe,
so
I
like
to
take
very
short
notes
and
link
his
stuff.
If
you
have
a
chance
like
guys
later,
take
a
look
at
the
dog
and
add
any
notes
that
you
guys
think
it's
relevant.
You
know
I
pay
attention
to
the
conversation
I
can
type.
While
I
pay
attention
to
the
conversation
so.