►
From YouTube: 2016-06-01 Node.js Tracing/Diag WG Meeting
Description
Begins with intros, actual meeting at 4:16
GH Issue: https://github.com/nodejs/tracing-wg/issues/49
Notes: https://docs.google.com/document/d/13kzR1TPPKZpn7seUuGZlOaM3wU8kCpgxqW1WdUaSaWU
A
A
A
B
D
E
D
G
Okay,
I
guess:
I'll
jump
in
on
I'm
Michael
Dawson
I'm,
with
IBM
I
been
participating
a
bit
with
Richard
and
some
other
team
members
and
post-mortem
work
group,
and
you
know,
tracing
and
so
forth,
relates
to
that
as
well
as
bunch
of
the
other
discussions
going
on
today.
So
that's
why
I'm
here
and
interested
in
participating.
K
L
A
No
problem
so
I'm
Josh
I
am
with
developer
division
of
Microsoft,
representing
Microsoft,
with
the
nude
open
source
project,
but
I
work
with
the
chopper
team,
the
visual
studio
team,
winters
team,
American
team.
So
let's
go
ahead
and
jump
in
to
the
agenda.
So
the
quarrel
depending
bugging
protocol
stuff
came
up.
We
were
going
to
talk
about
trace
event
and
that
I
asked
Ali
to
give
us
an
update.
A
I
wanted
to
discuss
a
little
bit
about
my
trace
module
which
I've
been
working
on
and
then
we'll
talk
about
the
chrome,
debugging
protocol,
a
sing
crab
get
an
update,
Trevor's!
Not
here!
Maybe
andreas
can
talk
to
us,
and
then
we
can
finish
by
talking
about
the
Diagnostics
work.
How
that
relates
to
this
group?
A
C
In
fact,
we
have
all
the
experts
on
the
call
as
well
so
I'll.
Let
them
do
lot
most
of
the
talking,
so
in
fact,
I
think
trace
event
and
chrome
debug
to
protocol.
They
may
have
some
synergies
that
might
make
sense
to
cover
those
two
first
and
then
we
can
go
into
your
trace,
module
and
I
think
to
start
off,
I,
think,
Bobby
and
and
Powell
wanted
to
take
you
through
an
overview
of
trace
event
and
chrome
debug
protocol
and
how
everything
fits
together.
L
So,
first
of
all,
I'm
going
to
give
a
very
quick
introduction
about
tracing
so
and
the
current
state
of
tracing
and
VA,
so
tracing
is
basically
a
way
so
that
you
can
specify
trace
events
trace
events
or
events
that
have
begin
and
end
times.
You
specify
can
usually
in
the
native
code
and
the
C++
code,
and
there
is
other
ways
where
we
can
actually
specify
them
through
JavaScript
as
well.
That
Bob
will
we'll
talk
about
in
a
second
traces,
are
collected
using
something
called
tracing
controller.
L
The
tracing
controller
is
basically
a
buffer
and
a
set
of
configuration.
So
you
say:
okay
I
want
to
collect
the
events
in
a
subset
of
categories,
and
then
you
say
start
that
will
collect
these
events
and
put
them
in
a
buffer.
And
then,
when
you
press
stop
these
events
gets
them
the
way
we
use
trace
events
in
general
or
we
don't
stream
them.
We
just
get
a
dump
at
the
end
in
general.
I
know
that
note
has
a
use
case
where
this
might
not
be
the
case,
but
this
is
a
current
state.
L
E
L
Can
everybody
click
on
my
name
and
see
my
screen,
and
if
you
do
that,
you
will
see
that
this
is
an
example
of
a
trace
for
the
verge,
and
this
is
the
level
of
details
we
get
into
when
we,
when
we
profile
a
website
using
trace
events.
Basically,
we
captures
a
render
in
chrome
message
loop
at
the
top
here
and
then
inside
of
it
we
have.
We
can
jump,
for
example,
all
the
way
to
a
v8,
cold
function
and
then
inside
the
full
function.
L
L
We
provide
to
informations
about
it,
the
alteration
and
the
CP
duration,
and
one
of
the
strongest
things
that
we
found
ourselves
off
with
tracing
is
that
we
also
click
capture
the
CP
duration
of
the
events
which,
because
they
give
them
much
more
meaningful
time
of
what's
going
on,
since
this
is
a
GC
events.
Specifically,
we
also
have
as
an
ape
size
before
some
some
more
information
and
a
context
about
what
happened.
L
We
can
also
have
something
called
overlapping
samples,
so
we
also
collect
the
runtime
samples
that
show
up
in
devtools
and
we'll
show
you
in
a
second
and
then
we
can
show
them
here.
So
when
we
click
on
them.
Actually
you
can
see
that
there
is
no
meaningful
sample
day,
because
this
was
basically
GC,
so
nothing
actually
got
executed.
L
But
if
we
click
and
actually
execute
no
click
here,
then
apparently,
this
is
like
a
biscuit
of
code,
but
we
know
that
we
have
here
a
top-down
tree
and
then
we
can
associate
this
specific
top-down
tree
with
this
v8
execute
event
that
I
originally
selected
when
I,
when
I
ate
when
I
display
this
tree.
As
you
can
see
here
that
what
I'm
showing
you
guys
here
is
a
chrome
tracing
interface,
it's
intended
mostly
for
the
platform
developers
or
like
chrome
developers,
no
developers,
v8
developers
and
not
the
actual
user
base.
L
D
Alive
so
yeah,
just
briefly
so
I'm
just
going
to
show
kind
of
like
the
same
thing
up
in
doubles,
so
we'll
record
a
similar
kind
of
a
capture.
So
what
is
coming
in
here
at
this
point
I'm
just
loading
timeline.
It
is
the
same
thing:
it's
a
trace.
The
Delta
between
kind
of
the
data
that
powers
this
view
and
trace
viewer
versus
what
comes
into
here
is
pretty
much
a
change
in
the
categories
here
that
are
being
recorded,
and
so
generally
this
parent
race
viewer.
D
But
in
nodes
case
you
can
imagine
that
we
would
have
the
JavaScript
functions
and
the
user
line
javascript.
In
addition
to
the
native
data
native
trace
data,
coming
from
note
and
so
yeah
I
guess
that's
kind
of
a
quick
summary
the
just.
So
we
have
an
idea
on
kind
of
what
this
looks
like
see.
If
I
can
open
that
up
real
quick.
F
D
D
Yeah,
so
this
is
kind
of
a
what
are
the
trace
looks
like
in
both
cases,
a
big
JSON
blob
of
individual
trace
events
tagged
with
their
category.
In
this
case
you
know
top-level
their
name
and
then
any
arguments
and
extra
data
kind
of
attached
to
the
trace
event,
and
so
this
is
kind
of
the
standard
base
layer
of
the
trace
serialization
that
powers
both
UI
views.
L
L
This
is
the
sampling
information
they
were
collecting
and
the
sampling
information
currently
are
not
part
of
the
trees
trace
file
that
we
were
getting,
but
we're
working
on
actually
making
it
as
part
of
the
trace
file
and
we're
sampling
at
intervals
that
you
can
define.
So
if
node
wants
to
sample
at
a
lower
interfere
or
higher
intervals,
they
can
do
that.
L
M
Don't
have
to
look
especially
remote
debugging
to
the
API,
so
listen
and
I
can
take
over
I.
Don't
need
to
show
much
is
almost
speaking
about
how
this
ties
into
remote
debugging,
and
so
we
have.
We
now
have
a
v8
inspector
as
a
standalone
project
that
is
on
its
way
to
v8
and
then
deviate.
We'd
like
to
have
sort
of
a
tooling
library,
tooling
associated
with
Eve,
is
going
to
power.
It
all
is
going
to
power,
run
time,
debugging
and
performance
features
and
the
way,
similarly
to
how
it
works.
M
In
chrome,
we
like
the
same
remote,
debugging
api
to
control,
enabling
and
disabling
this
chasing
and
configuring
the
categories
being
captured.
So
that's
pretty
much.
The
story
would
like
to
receive
it
as
a
box
product
where
you
have
an
API
that
you
could
automate
and
instrument
linode
instance
with,
and
you
can
consume
the
traces
in
by
both
of
these
tools.
One
is
starting
targeting
internal
developers.
It
operates
a
native
method
calls
levels
as
you've
seen
in
the
chase.
There
were
things
like
the
names
of
the
chase
events
that
we
have
seen
in
the
chase
viewer.
M
Those
were
actual
names
of
the
methods
in
chrome,
so
that's
the
level
of
detail
there
and
at
the
same
time
and
I
would
imagine
that
you
would
be
using
that
for
tuning
note
performance
at
some
point
in
time.
You
would
think
about
the
user
facing
the
developer,
facing
consumer-facing
interface,
for
that
and
I
would
imagine
that
you
would
turn
to
something
similar
that
to
what
we
have
in
timeline,
except
for,
instead
of
focusing,
instead
of
exposing
the
browser
related
terms
such
as
frames
and
navigations
and
loads.
M
M
The
information
exposed
needs
to
be
actionable,
so
you
can
see
samples
you
own
the
source
you
can
tweak
the
source
and
you'll
get
it
I'm
working
and
the
the
API
is
wired
similarly
to
v8
inspector
there's
a
tracing
domain
that
has
methods
start
and
stop,
and
they
will
notify
you
with
the
event
containing
the
buffer.
With
the
actual
and
chase
payload,
that's
all
I
wanted
to
say.
D
Yeah
and
I
guess
I
was
just
going
to
briefly
at
the
the
both
the
Timeline
view.
Trace
viewer,
you
I.
These
are
existing
consumers,
you
know
which
are
consumers
of
the
traces
and
format,
but
we've
seen
other
people
build
tools.
On
top
of
this
format.
You
know
walking
through
the
data
and
pulling
out
interesting
things.
So
I
think
this
there's
also
plenty
of
opportunity
for,
for
that
of
just
more
automated
data
data
processing.
L
Of
those
traces
so
currently
the
way
we
we
want
to
instrument
JavaScript
code,
so
you
can
always
do
the
sampling,
get
the
profile
and
get
the
sample
data
and
if
you
actually
have
more
meaningful
information
or
you
wanna
instrument
your
code.
So
what
we
currently
do
in
chrome
is
that
we
console
the
time
and
time
end.
So
when
you
consult
of
time
and
time
ends,
they
show
up
in
the
tracing
format
as
normal
trace
events,
so
that
you
can
associate
them
with
everything
else
going
around
them.
M
Right
to
I
can
give
you
an
update
on
what's
happening
on
tracing
like
a
brief
update
of
we
are
ought
to
currently
I
mentioned
that
we
want
samples
to
be
a
part
of
trace.
Well,
in
fact,
we
have
them
as
a
part
of
trace
for
about
a
year,
but
we're
not
satisfied
with
the
footprint
that
we're
getting
and
we're
consuming
a
lot
of
memory
hitting
a
lot
of
limitations
there.
M
So
we
are
iterating
on
that
to
make
sure
that
we
get
best
of
both
worlds
and
we
get
lean
nice
sampling
data
as
a
part
of
chase.
That's
one
of
the
things
that
is
currently
happening.
The
other
thing
that
is
currently
happening
is
that
we
are
looking
at
the
chase
format
and
we're
looking
at
a
ways
to
optimize
it
and
there's
an
active
project
on
bringing
it
into
a
binary
format
driven
by
protos
for
the
sake
of
efficiency.
B
L
K
L
L
That
trace
format
is
a
format
that
we
all
agree
on
to
generate
files
into
that
format,
so
that
chrome,
tracing
and
the
dev
tools
can
be
able
to
read
it
right.
So
if
you
so
as
a
tracing
controller
currently
generates
that
format,
because
this
is
the
one
is
being
consumed
by
the
viewers.
But
if
you
decide
to
write
your
own
format,
nothing
will
stop
you,
and
also
that
phrase
view
or
not
the
dev
tools.
You
can
write
an
importer
to
import
any
format
into
the
trees,
your
model,
so
it's
kind
of
an
agreement.
L
It's
not
something
set
in
stone,
and
then
we
have
this
document
that
is
on
the
screen.
Now
that
actually
defines
this
format
very
well
and
we're
going
to
keep
supporting
this
format
for
a
while,
but
we're
also
working
on
as
bubble
mentioned
and
much
more
binary,
more
concise,
more
efficient
formats.
B
L
Yeah,
so
basically,
what
we
do
is
that
we
write
everything
into
a
buffer
and
then
then
we
have
the
trace
writer
that
basically
takes
us
buffer
and
writes
it
down,
so
that
writer
can
be
configured
by
the
client.
So
chrome
currently
takes
the
name,
servers
I,
you
I,
and
you
give
it
a
name
and
it
dumps
it.
So
it
takes
a
buffer
transform
it
into
the
trees
format
that
you're
seeing
on
the
screen,
and
then
you
give
it
the
file
name
and
then
it
will
put
the
file
name
on
it
at
four.
L
Currently
I
have
an
implementation
prototype
for
v8
that
d8
uses,
and
this
one
just
uses
v8
underscore
trace,
but
Jason
similar
to
the
via
the
flog
that
they
use
just
a
fixed,
named
Frieda
plan.
What
back
to
your
question,
there
is
an
important
part:
there
is
that
we
have
to
predefine
the
categories
that
gets
recorded
and
predefined,
whether
we
want
sampling
being
able
door
not
and
predefined
everything,
so
you
have
to
so.
We
have
also
another
format
that
is
called
the
trace
conflict
formats.
That
basically
says
what
recording
mode
do
you
want?
L
You
want,
for
example,
a
cyclic
buffers
that
keeps
going
or
the
monaco
down
to
the
buffer
is
full
and
stop,
or
and
so
forth,
and
also
as
Paul
mentioned,
there's
set
of
categories.
So
we
also
define
which
categories
you
want
enabled
for
recording
as
well,
and
these
are
defined
in
the
trace.
Config
file
that
gets
read
before
tracing
starts
once
it
starts.
It
keeps
racing
with
this
configuration
and
then
you
stop
it
off
with
and
then
as
a
fixed
in
warm
whatever.
N
C
C
L
C
This
would
be,
and
a
tracing
controller
for
node
needs
to
be
written,
so
it
would
be
up
to
us
on
how
we
want
to
design
it.
What
kind
of
a
trade-off
you
want
to
make?
What
kind
of
buffers
you
want
to
keep?
How
much
of
a
memory
footprint
we
want
and
how
frequently
we
flush
this
buffer
out
to
the
network
or
to
the
disk
or
whatever
sink
we've
attached
to
this
buffer
and.
L
M
M
I
can
give
you
an
example
of
one
of
them,
for
example,
there's
a
note
instance
running
in
a
while,
and
we
are
interested
in
collecting
performance
data
on
it,
and
we
cannot
start
chasing
up
front
with
all
the
categories
because
it
will
blow
it
out
of
memory.
So
what
we
do
is
we
sample
performance,
which
means
that,
for
example,
we
agree
to
enable
gathering
the
formal
snapshot,
including
the
sampling,
for
each
hundreds
network
request.
That
hits
this
instance,
and
then
we
write
a
script.
M
That
intercepts
is
never
request,
use
word,
protocol
to
start
and
stop
chasing
before
and
after
it
and
dumps
it
into
the
buffer
that
layer
B
is
being
collected
and
processed.
So
it's
not
really
a
big
deal
of
whether
the
API
is
native
or
wired
is
just
kind
of
our
recommendation
to
go
wire
for
backwards,
compatibility
and
consistency.
But
it's
entirely
up
to
note
how
to
define
strategies
of
collecting
that
information.
The
buffers
being
used
categories
being
used
as
a
and
timing
when
it's
initiated.
A
M
M
What
our
strategy
tours
tumors
analyzing
GS
performance
is
sampling,
because
sampling
covers
everything,
it
doesn't
require
additional
instrumentation
and-
and
you
get
it
with
a
very
high
precision
with
we
found
simply
to
be
very
impactful
and
actionable,
and
it
doesn't
matter
whether
it's
a
user
code
or
module
code
or
any
JavaScript
code.
Any
JavaScript
samples
will
get
there.
If
you
want
to
add
structural
GS
profiling,
where
you
want
to
maintain
higher
level
structure
events,
we
currently
have
a
way
of
doing
it
through
the
console
API.
M
So
you
say
console
time
and
I
started
process,
something
that
is
a
console
time
and
you
start
processing
something
you
will
get
a
nice
bar
in
the
chasing
in
the
timeline
for
it
and
you'll
get
the
entire
hierarchy
of
samples
honor
it.
So
you
kind
of
mark
up
your
source
code
with
the
with
the
augmented,
with
the
semantics
of
your
app.
F
So
I
could
not
recommend
him
that
we
currently
have
pretty
high
expectations
on
the
trace
format,
consistence,
basically,
the
matching
of
forming
and
closing
events,
and
this
is
ensured
most
of
the
time
five
markers
on
the
ballot
is
both
class
code
and
in
case
this
gets
exposed
the
models
in
a
manner
that
allows
like
generating
opening
events
without
much
enclosing
events,
some
may
break
on
the
client
side.
So
we
have
a
special
case
when
this
is
supported,
which
is
simply
no
serious
and
with
trade
say.
F
M
Think
what
what
Amon
is
that
by
default?
You
should
maintain
a
contract
of
our
balancing
the
start
and
end
events
for
instrumentation.
But
if
you
cannot
enforce
it
and,
for
example,
we
are,
if
you're
dealing
with
a
synchronous,
JavaScript
code,
where
you
still
want
to
augment
the
disciples
with
the
logic
of
the
app.
There
is
a
the
notion
of
a
synchronous
event
not
require
the
balancing
and
the
visualizing
tools
are
doing
a
best
effort
at
aligning
things
and
then
lining
them
up
on
a
same
timeline.
A
M
Imagine
that
the
council
object
that
we
have
in
chrome
was
a
part
of
node
and
it
exposed
the
time
and
time
admat
bindings
as
it
currently
doesn't,
in
node
and
and
by
the
way,
there's
nothing
preventing
us
from
wiring.
Those
calls
to
the
inspector,
in
this
case
those
bars
increase
on
to
user
land
events,
will
show
up
as
a
part
of
a
chase.
D
Yeah
so
consult
I'm
in
time
and
is
just
a
way
of
identified
at
market
up
a
time
span.
This
is
implemented
in
the
end
nodes.
Existing
console
object
in
Chrome's
Council
object,
which
at
this
point
are
there
is
a
difference
in
addition
to
like
exporting
how
long
time
took
to
the
console.
It
also
creates
a
trace
event,
and
so
that
is
like
that
is
currently
a
good
mechanism
for
allowing
JavaScript
to
inject
trace
events
into
the
recording
performance.
D
M
M
It
is
not
yet
integrated
with
note,
because
we
would
need
to
wire
it
with
the
terminal
and
we
would
need
to
wear
it
in
a
way
that
is
sort
of
backwards
compatible
so
that
all
the
terminal
output
that
node
is
generating
was
consistent
with
what
it
did,
but
as
a
part
of
this
effort,
once
we
generated
once
we
let
V
AIDS
Council
object
to
be
note,
console
object.
You
are
pretty
much
getting
this
for
free.
A
M
A
B
A
M
M
L
M
A
Okay,
yeah,
that
makes
sense.
I
was
exactly
what
I
thought,
so
you
basically
wrapping
some
of
the
trace
event
macros,
so
just
quickly
because
we're
we're
getting
out
of
time-
and
we
wanted
me
to
move
on.
But
let
me
just
quickly
describe
what
I
was
looking
at
and
and
understand
just
fits
together.
So
they
think
that
have
been
investigating.
Oh.
A
Right
now,
there's
no
unified
trace
system
really
in
node
that
could
be
used
by
the
node
core
components
by
native
modules,
by
ecosystem
modules.
I
console
dot
log,
maybe
a
little
bit,
but
that's
it's
not
really
an
easy
way
to
hook
into
it.
So
I've
been
looking
at
just
a
basic
pub
sub
set
up
that
would
allow
javascript
or
native
or
core
components
to
emit
traces,
just
to
publish
a
trace
by
calling
something
on
a
broker,
and
then
the
broker
would
publish
them
out
to
register
JavaScript
functions
or
native
function.
A
Pointers
in
really
what
I
was
gonna
break
up
in
this
call,
but
we
don't
have
a
ton
of
time
enough
to
just
discuss
him
and
get
up,
but
do
we
I
wanted
to
find
out
how
we
can
make
everything
go
into
that
into
some
unified
system?
And
that's
what
I
was
kind
of
wondering
about
trace
event?
Is
it
just
going
to
be?
You
know
something
that's
for
the
platform
and
for
the
core,
or
can
we
use
that
for
everything?
A
And
it
sounds
like
you
guys
are
saying:
let's
use
the
tracing
controller,
which
would
you
know
that's
kind
of
equivalent
to
in
my
side
what
I
call
the
broker
in,
but
you
I
think
you
guys
would
say,
use
the
tracing
controller
and
have
and
then
wrap
the
trace
event
stuff
in
loser,
expose
to
JavaScript.
So.
L
Just
to
be
clear,
chasing
controller
is
the
place
where
it
actually
collect
the
buffers
dump,
the
thumb
of
the
traces
and
so
forth.
What
we
have
is
actually
what
you
want
is
a
creative
wrapper
on
top
of
like
a
JavaScript
coal
into
a
C++
pole
and
then
transform
that
it's
in
a
trace
event,
and
this
can
happen
anywhere
and
applies
to
any
tracing
controller.
It
doesn't
have
to
apply
to
a
specific
one.
Like
the
example,
we
showed
you
in
chrome,
it
actually
is
being
used
by
the
traffic
controller
and
other
traceable
tropism.
M
But
on
a
broader
sort
of
a
broader
topic,
the
chasing
offer,
the
chasing
controller
or
bracelet
we
can
buffer
and
all
the
performance
information.
Our
vision
for
chrome
is
that
all
the
performance
information
be
internal
or
be
the
user
land
ends
up
in
the
same
buffer.
You
have
control
over
what
you're
collecting
but
there's
a
single
buffer,
and
this
buffer
is
extremely
efficient.
M
We're
looking
at
a
zero
overhead,
we're
not
doing
anything
streaming
because
we're
only
concerned
about
getting
up
this
buffer
without
doing
any
extra
work
at
all,
and
you
mentioned
the
the
callbacks
and
JavaScript
fallbacks
and
diesel
would
raise
concerns
as
as
far
as
ill
overhead
and
side
attacks
are
concerned.
So
we
don't
like
skewing
profiles
at
all.
So
this
is
a
zero
overhead
buffer.
You
grow
it.
M
Everything
goes
there
and,
and
then
we
sort
of
discussed
the
means
of
delivering
this
buffer
to
the
viewing
systems
and
it
could
be
a
remote
debugging
protocol
or
some
serialization
persistence,
and
we
also
discuss
the
means
of
alkylating
this
buffer.
And
today
this
is
native
chase
events
or
the
RGS
wrappers.
A
I
A
Guess
we'll
okay
I
want
to
I,
it
seems
like
when
it
seems
like
you're
saying:
is
the
foundation
can
be
the
foundation
for
all
trace
in
node
is
if
we
need
it
to
stream
out
the
buffer?
Somehow,
then,
we'll
figure
that
out,
but
like
we
can
figure
out
those
concerns
later
that
central
implementation
would
make
sense
to
use
yeah.
L
The
trick
is
that
we've
trying
to
keep
the
overhead
if
you
are
an
off
categories.
That
means
that
you're
not
collecting
this
category,
which
is
what
the
user
will
be
facing
most
of
the
time,
is
to
be
as
minimal
as
possible.
So
actually
we
try
to
push
it
to
one
branch
on
a
static
variable,
and
this
is
the
overhead
of
mist
like
a
category
that
you
would
not
record
if
you
are
going
to
record.
L
L
G
L
Are
talking
between
three
to
ten
percent
overheads
if
all
of
the
categories
are
enabled,
but
the
trick
is
that
you
enable
a
very
small
subset
of
categories
that
gives
you
the
information
that
you're
looking
for
without
affecting
the
overhead,
and
then
we
control
using
the
categories
when
to
exactly
trace
more
versus
traceless.
So.
L
M
For
the
sampling
we,
the
stats
are
a
bit
different
depending
on
the
resolution
of
the
same
thing,
and
we
support
a
thousand
samples
per
second
and
ten
thousand
samples
per
second
resolutions.
You
get
from
ten
percent
of
an
overhead
on
the
desktop
devices
to
up
to
fifty
percent
on
arm
and
mobile
devices
when
assembling
is
an
high
resolution.
Sampling
is
enabled.
A
B
Up
you
know
I
actually
have
at
least
one
question.
Maybe
I
can
ask
that
first
to
help
target,
so
at
first
I
wasn't
quite
sure
why
something
was
replacing
the
existing
d8
debug
protocol,
which
has
been
documented
on
a
single
wiki
page.
So
it's
it's
been
around.
I
guess
not
documented
well,
and
you
know,
I
know
that
the
chrome
devtools
protocol
is
very
well
documented.
B
You
know
described
very
strictly
and
whatnot,
so
that
in
itself
is
good,
but
I,
guess
I'm.
My
understanding
is
the
current
v8
debug
agent
that
some
node
is
just
no
longer
supported
and
that
feud
or
maybe
had
work
to
get
it
back
working
after
it
kind
of
came
out
of
v8
directly
and
so
that
this
chrome
devtools
is
really
kind
of
the
replacement
for
bat
protocol.
Is
that
understanding,
correct.
M
Pretty
much
so
the
history
on
the
topic
is
that
we
started
working
on
chrome
devtools
in
on
webkit
web
inspector,
obviously
in
2009,
and
we
click
quickly
ran
out
of
v8's
protocol
capacity
and
efficiency.
It
didn't
operate,
object
mirrors
in
an
efficient
manner.
For
example,
we
couldn't
get
properties
of
an
object
without
getting
the
values
of
those
properties
and
the
many
things
alike,
and
it
was
also
based
on
the
mirror
objects
in
the
eight
that
were
adding
quite
a
bit
of
the
overhead.
M
Now
at
some
point
in
time,
the
maintenance
of
the
old
protocol
became
so
bad
that
we
decided
to
basically
drop
it
and
put
it
into
the
non
maintainable
node,
where
the
remote
debugging
protocol
was
replacing
a
defective
in
chrome
past
forward
for
two
today,
the
agreement
between
death
tolls
and
v.
Eight
teams
is
that
the
lead
inspector
api
becomes
the
debugging
api
for
v8.
This
allows
league
team
to
drop
the
mirrors
and
drop
support
for
the
chrome.
Debugging
live
for
VA
doing
protocol
altogether.
M
It's
not
that
they
were
doing
much
about
it,
but
they
maintain
this
infrastructure
of
mayor
of
newer
objects.
That
was
simply
an
overhead
and
was
sitting
in
their
source
base,
so
for
them
this
means
that
we
are
going
towards
something
more
and
maintainable.
For
us,
it
means
that
we
are
aligning
on
a
chronicle,
that
is,
that
operates
in
a
more
standard
way
that
operates
in
a
more
efficient
way.
So
this
is
really
nothing
bad
about
this,
which
is
only
getting
rid
of
the
old
chunk
of
code.
So
we.
B
A
Well,
this
I
I
mean
I'm
in
agreement
and
I.
Think
most
of
us
are
like
the
chrome
debugging
protocol
it
has
like
I
could
defend
some
parts
of
it.
It's
got
a
lot
all
of
the
domains
and
things
that
go
beyond
VA.
That's
kind
of
like
like
to
justify
us
in
node.
Switching
over
I
mean
I
think
we
want
to,
but
it
was
hoping
that
would
be
the
conversation
here
like,
let's
just
all
be
on
the
same
page
with
that
I
mean.
Is
there
anyone
here?
A
B
So,
but
you
know
I
doesn't
work
in
Microsoft
where
most
a
lot
so
I'm,
not
the
person
thats
can
can
say
that
that's
doable
or
not,
but
that's
I
think
it's
great
to
hear
the
basically
positive
reactions.
I
think
we
do
Josh.
Did
you
have
a
new
up
and
I
know
you
had
like
a
couple
of
issues
like
what's
the
governance
of
the
API,
and
you
know
how
long
is
a
particular
version
of
the
API
supported
by
I,
guess,
chrome
and
it
was
going
to
support
this
code
and
their
work
up.
A
M
Well,
of
course,
yes,
I
think
the
two
to
adjust
the
support
and
maintenance
concerns.
I
think
we
have
a
very
good
track
record
history.
Wise
we've
only
been
adding
to
the
prodigal.
We
haven't
been
breaking
backwards,
compatibility
everything
is
developed
in
the
open.
The
the
prodigal
is
documented,
our
front
end,
which
is
the
reference
implementation
for
the
client
of
this
protocol.
For
us,
because
we
are
def
will
steam.
It
is
an
open
source.
M
We
have
it
open
in
the
chromium
repository
as
well
as
we
have
a
get
up
mirror
the
source
code
there
is
modular,
and
one
of
the
modules
that
it
contains
is
called
SDK
and
I,
for
example,
know
that
all
was
able
to
reuse
the
SDK
for
his
own
CLI
to
that
he
was
building
for
quite
some
time
and
it
was
pretty
much
a
box
out-of-the-box
solution
getting
the
headless
SDK
it
wires
over
their
own
debugging
protocol.
It
introduces
higher
level
abstractions
for
scripts
requests.
M
Those
are
all,
of
course,
browser
terms
but
scripts
and
break
points
or
not,
and
you
could
right
away.
You
could
hack
from
there.
So
it's
a
hack
ability
of
the
protocol
is
Jason
nature.
It's
open,
as
it
is
very
good
and
we've
seen
a
great
adoption
there.
So
wouldn't
we
don't
see
why
everybody
else
wouldn't
try
and
do
something
there.
M
M
A
M
Way
we
deal
with
it
in
plum
and
I'm
currently
a
splitting.
We
have
a
bunch
of
properties
that
are
using
remote,
debugging
protocol
infrastructure.
What
I'm
currently
doing
is
I'm
splitting
the
v8's
domains
from
the
chrome,
still
means
and
seating
them
in
different
places
so
that
we
could
move
the
thing
in
TV
and
the
way
it
works.
Is
you
get
this
JSON
description
of
your
domains
we
have
here?
Is
that
generate
strong
type?
M
Ap
is
and
wire
dispatchers
for
those
domains,
and
then
you
implement
the
handlers
for
read
in
v8
and
the
handlers
for
node
a
node,
and
then
you've
got
the
the
uber
dispatcher
that
basically
pumps
all
the
messages
and
just
figures
out
into
which
dispatcher
to
send
that
wire
message
and
currently
for
Chrome.
It
processes
most
of
the
things
in
chrome.
Some
of
the
message
didn't
blink,
and
eventually
we
go
indeed,
and
you
could
imagine
that
in
node
a
similar
thing
will
happen.
M
M
We
can
talk
about
reusing
the
utilities
that
we
use,
that
we
employ
for
generating
those
dispatchers.
For
example,
if
you
have,
if
you've
looked
at
me
in
inspector,
it
was
pulling
it
was.
It
consists
of
two
parts
we
even
specter
the
debugger
itself
and
the
inspector
protocol,
which
is
the
harness
for
generating
the
handlers
and
work
dispatchers
and
a
couple
of
bill
time
dependencies
for
a
ginger
that
are
actually
generating
used
for
the
code
jam.
So.
K
M
A
A
B
M
A
Okay,
well,
there's
more
to
talk
about
I
guess,
but
we
got
to
wrap
this
up
so
I
just
wanna
bring
up
at
least
the
one
will
have
the
next
meeting,
which
I
was
gonna
shoot
for
every
other,
the
first
wednesday
of
each
month
so
and
we
can,
if
we
need
something
else
in
between
we'll
figure
it
out.
Otherwise,
let's
chat
on
github
I
know
we
got
to
talk
about
expanding
into
a
diagnostics,
working
group,
I!
Guess,
let's
go
back
to
github
for
that.