►
From YouTube: 2022-05-25 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
C
D
D
Should
we
be
adding
the
span
context
into
the
logs,
you
know
by
default,
and
you
know
if
you
look
at
the
tracer
when
you
create
a
new
span,
the
spec
clearly
says
that
you
know
it
should
not.
D
D
A
A
What
probably
you
want
to
have
is
the
ability
to
say
whether
the
context
should
or
should
not
be
included
when
you're
setting
up
either
when
you're
setting
up
the
loader
or
when
you're
emitting
the
particular
log
record.
I
think
last
time
we
discussed
this,
you
you,
the
conclusion
was
that
you
will
think
about
how
you
add
this
ability
to
make
this
choice
in
the
api
right
so
once
it
is
there.
I
think
we
can
then
then
see
what
does
what
which
default
behavior
makes
the
most
sense
we
should
be
able
to.
A
A
D
A
So
it's
it's
another
option
for
the
logger.
Let's
say
we
decide
it's
an
option
for
the
logger,
so
you
set
it
in
the
scope
of
the
logger
not
per
record
okay,
which
probably
I
guess,
means
yeah.
I
guess
that
makes
sense
makes
most
sense
to
me.
I
don't
know,
maybe
I'm
wrong
and
with
the
options
I
guess
we
are
most
of
the.
A
So
all
the
the
the
caterers
that
you
you
get
a
tracer
meter
logger
now,
there's
so
many
options
that
adding
yet
another
option
should
be
not
not
a
problem
at
all.
From
what
I
understand
you
either
have
this
builder
pattern
in
some
languages
somewhere
else
you
have
maybe
named
parameters
or
whatever
works
in
particular
language,
so
that
that
probably
can
become
another
option
where
you
say
whether
the
trace
context
should
be
should
be
or
should
not
be,
the
span
context
should
be
populated
or
not
by
should
be
populated
or
no
and
then
the
default.
A
If
you
don't
specify
the
option,
I
mean
we
can
decide
on
that.
So
maybe
what
what
you
can
do
is
just
say
that
that's
another
option,
the
tracer
sorry
yeah
in
the
logger
can
be
a
little
setter
in
the
logger
as
well,
but
I
don't
see
how
that
yeah.
Why
do
we
need
to
deviate
from
the
concept
of
specifying
all
the
parameters
when
you're
obtaining
it?
The
difference
is
going
to
be
that.
D
A
E
D
Not
not
the
domain
we're
talking
about
whether
we
should
have
the
span
context
automatically
added
to
the
to
the
last
yeah.
A
There's
a
trace
id
and
span
id
in
log
records
right
and
with
the
current
specification
for
logging
libraries,
respect
says
that
they
should
be
automatically
populated.
If
there
is
a
current
active
spam
and
santosh
is
saying
that
for
in
some
cases
you
probably
don't
want
that
behavior,
maybe
you
don't
want
the
spam
context
to
be
there
so
a
way
to
way
to
say
that
no,
don't
don't
put
the
spam
context
there
or
the
opposite.
If
the
default
is
not
to
do
that,
then
you
want
to
say:
yes
do.
A
D
Okay,
cool
and
you're
saying
that
the
defaults
can,
you
know,
can
evolve
right.
I
think
we
don't
need
to
respect
that.
A
I
think
I'm
in
favor
of
what
we
have
right
now,
because
it
seems
like
a
valid
choice,
for
I
guess
for
for
the
cases
that
are
unknown
to
me.
I
would
expect
that
it's
valuable
to
include
the
context
and
for
the
cases
where
you
know
in
with
you,
with
your
example
that
you
had
for
javascript
event
that
spawned
context
should
not
be
there.
I
mean
yes,
you
know
so
explicitly
say
that
we
don't
want
it
there
right.
Okay,.
C
Yeah
and
I
think
that
spun
context
also
includes
spawn
id
and
trace
id
which,
in
case
of
logs,
like
additional
attributes
with
spans.
Obviously
this
is
like
part
of
the
of
the
model,
and
I
I
see
very
very
few
cases
when
you
don't
want
that
information
included
in
the
interlock
like
it's.
It's
so
so
useful
that
I
think
we
should
by
default,
have
it
available.
E
Probably
a
good
case
that
you
don't
want.
It
is,
if
you've
actually
got
an
application,
which
has
multiple
components
and
those
components
are
effectively
using
the
same
sdk,
but
they
want
different
values.
E
D
Yeah,
I
think,
in
the
back
end,
it
is
unlikely
this
is
ever.
You
know
required,
because
in
the
in
the
front
end,
I
think
you
often
have
external
environmental
behavior.
Like
you
know,
you
are
on
a
mobile
application.
You
are
doing
something
your
network
changes
or
you
know
user
clicks
a
button,
you
don't
want
that
click
event
or
a
network
change
event
to
be
associated
with
the
span
in
progress
because
they
are
not
related,
whereas
in
the
back
end
it's
mostly
reactive
right.
D
I
think
I
don't
know
unless
you
know,
there's
a
there's,
a
signal
handler
which
is
reacting
to
a
linux
signal
and
then
that
signal
handler
you
know,
do
you
want
the
locks
in
that
signal
handler
to
include
the
current
spans
context
in
a
in
a
single
threaded
environment.
C
Yeah
is
this
related
to
like
a
single
page
application,
essentially
and
handling
of
the
of
the
trace
like
when
you
have
like
a
single
page.
It's
like
much
different
from
the
from
the
application
that
the
url
is
being
changed
like,
so
you
go
from
one
page
to
another.
It's
like
it's!
It's
simple,
because
you
can.
D
D
B
A
D
All
right,
so
we
can
go
to
the
second
one
about
the
even
domain.
We
spoke
that
it
is.
This
is
a
more
of
a
you
know,
cross-cutting
concern,
it's
something
a
library
would
choose
and,
and
that
same
event
domain
will
be
applicable,
no
matter
where
the
library
is
used
right,
so
a
library
emits,
let's
say
profiling
events.
D
What
would
be
other
examples
of
like?
How
do
we
standardize
this
attribute
further.
A
I
think
we
need
to
talk,
maybe
about
examples
right.
Profiling
is
one.
The
other
we
have
is
the
the
browser
events
that
you
care
about
right.
That's
that's
two
distinct
domains
for
browser
events.
I
mean
javascript
events
right
when
we
say
browser,
it's
really
the
javascript
events.
I
guess
right,
that's
what
they
are
called.
So
I
don't
know
if
there
is
another
example
ebpf.
I
guess
they.
They
also
intended
to
use
log
records
for
for
representing
ebpf
events.
A
F
In
java,
we
have
been
writing
a
jfr
component
that
that
processes,
java
flight
recorder
events
and
uses
them
to
aggregate
metrics
and
we've
been
wanting
to
some
of
the
data,
doesn't
aggregate
well
into
metrics.
It's
better
represented
as
events
and
myself
and
and
ben
evans
have
been
interested
in
using
the
log
data
model
to
represent
events
from
those
for
a
while.
So
we're
anxiously
awaiting
this.
A
A
D
Yeah,
I
think
we
were
discussing
in
another
meeting,
some
of
us
from
the
client
side
telemetry.
I
think
the
do
we
look
at
this.
As
a
you
know,
one
field
that
will
identify
the
entire
browser
side,
telemetry
or
or
the
browser
instrumentation-
might
include
multiple
domains.
D
D
They
are
not
necessarily
dom
events
themselves,
you
know,
but
they
they
could
be.
They
would
be
a
separate
class.
So
we
could
use
a
and-
and
let's
say
you
know-
there
is
a
library
to
handle
that
and
that
library
is
used
both
on
the
back-end
and
on
the
in
the
in
the
ui.
D
A
Application
events,
they
the
the
exceptions
or
errors
or
whatever
happens
in
the
application.
They
are
not
unique
to
javascript
or
to
browser
applications.
These
are
the
common.
What
what
you
call
logs
right
in
any
application?
So
I
don't
know
if
we
need
a
domain
for
that,
maybe
that's
the
domain.
I.
D
E
Yeah
and
probably
another
one
like,
rather
than
just
saying,
dom
events
and
non-dom
events,
if
you
just
say
well,
I've
got
client
events
where
I
want
to
capture
a
click
where
in
a
browser
it
might
be
a
dom
event.
So
you're
saying
I've
got
the
user
clicked
on
this
thing
or
if
you've
got
a
net
app,
and
you
want
to
capture
the
fact
that
they
clicked
on
a
button
or
a
link
or
whatever
both
of
those
are
click
events
so
from
a
client
perspective.
E
A
So
I
think
we
we
can't
prescribe
it
in
the
specification
in
any
way.
It
needs
to
be
something
that
is
discussed
by
the
particular
work
group.
Let's
say
you
are
the
expert
in
browser
instrumentation,
you
make
a
decision,
whether
it's
one
domain
or
you
want
it
to
be
multiple
domains,
and
maybe
you
can
have
sub
domains
even
right,
maybe
browser.dom
and
browser..
A
Whatever
is
the
other
you
you
give
it
different
different
names
in
that
case
right,
something
like
that,
and
I
don't
think
we
can
prescribe
what
happens
here
on
the
specification
level,
it's
similar
to
what
we
do
to
semantic
conventions.
We
say
that
whoever
are
the
subject
matter,
experts
they
decide
on.
What's
the
appropriate
classification
right,
how
do
you
combine
those?
How
do
you
group
those
events
into
and
give
them
the
names
to
those
groups
right?
That's
essentially
what
we
do
with
semantic
conventions.
E
A
E
I
I
guess
I
I
have
two
different
views
like
one
is:
we
want
to
have
a
standard
set
of
okay,
let's
call
it
client
events
that
otel
supports,
but
we
could
also
have
support
for
vendor
events.
So
I
guess
if
we
said
the
the
domain
could
be
overloaded
by
the
vendor,
and
maybe
we
just
say
the
domain
is
hotel.client
is
what
we
go
define.
Does
that
sound
like
something
that
would
work?
E
What
do
you
mean
by
vendor
domains,
so
the
vendor
domain
might
be
you
know
ms.web
or
ms.custom,
or
something
like
that
or
the
application
might
choose
to
say
your
app
dot
something
and
they
send
it
to
their
own
backend,
because
they've
got
their
own
collector
instance
or
something.
A
E
That,
yes,
so
so
they
provide
their
own
layer
on
top
of
hotel
so
that
if
the
events
are
being
funneled
to
their
back
end,
they
can
do
something
special
in
their
own
visualization.
When
you
say
ms.web.
E
Well,
right
today,
there
are
all
the
all
of
our
events
are
like
your
ms.web
dot,
page
action.
So
I
think
we
just
have
the
name
field,
but
it
sounds
like
we're
going
down
the
path
of
splitting
that
so,
if,
if
it's
not
something
that
hotel
defines,
how
do
we
pass
that
event
through
which
is
which
is
really
where
I'm
going?
Hopefully,
we
can
define
all
the
events,
but
I'm
assuming
there's
going
to
be
some
level
of
events
where
an
application
wants
their
own
or
some
vendor
wants
their
own.
A
So
I
don't
know,
what's
the
answer
to
the
specific
question
you
have,
but
from
organizational
perspective
as
as
an
organization
as
open,
telemetry
organization,
I
think
we
need
to
have
a
way
for
these
decisions
to
be
made
in
a
decentralized
manner
right.
I
don't
see
that
happening
top
down
and
working
efficiently.
A
You
are
the
client
side,
instrumentation
sig
right.
I
think
you
should
be
deciding
what's
the
name
of
your
domain,
what
is
it
one
domain,
multiple
domains?
How
do
you
split
domains?
Are
they
hierarchical
up
to
you
right
and
I
guess
at
the
best
we
can
provide
some
sort
of
guidance
in
the
specification,
but
it's
going
to
be
very,
very
fuzzy.
In
my
opinion,
it's
very
hard
to
put
a
very
exact
definition
of
these
things.
E
E
But
if
you
want
to
extend
it
and
have
your
own,
this
is
how
you'd
go
about
doing
it,
because
I'm
thinking
is,
it
bands
have
the
name
space
for
the
cloud
events
like
aws
and
azure
and
stuff
like
that,
but
prefix
that
that's
sort
of
concrete
is
what
I'm
looking
at,
not
actually
defining
those
events,
just
saying
if
you
want
to
override
and
overload
and
add
your
own,
do
it
this
way.
A
A
E
Yeah,
I'm
just
trying
to
define
how
we
define
what
the
domain
is.
So
if
we
say
if
we
come
up
with
and
we
say,
otol.client
and
then
other
vendors
can
say,
azure
dot
whatever
aws,
whatever,
then
that
uniquely
name
spaces,
the
oto
ones
or
we
just
say
we're,
gonna,
claim,
client
or
we're
gonna
claim
java
or
we're
gonna
claim
dot.
Net
yeah
et
cetera.
F
I
think
prefixing,
the
domain
with
hotel
dot
is
a
good
idea
to
like
avoid
collisions
down
the
road
that
are
unanticipated.
You
know
I
viewed
the
problem
of
domain
like
selecting
a
unique
domain
as
similar
to
the
problem
of
selecting
a
scope.
That
is,
it
needs
to
to
not
collide
with
other
scope
names
that
are
decided,
and
so
you
know
do
what
you
need
to
do
in
order
to
have
a
sufficiently
unique
domain.
F
Do
what
you
need
to
do
to
have
a
sufficiently
unique
scope
name,
and
if
that
means,
I
think,
for
hotel
semantic
inventions.
I
think,
having
that
hotel
prefix
makes
sense
new
relic,
that
my
employer
is
is
interested.
F
We
have
lots
of
customers
that
generate
custom
events,
that's
a
top-level
entity
type
in
our
data
model
and
what
we're
probably
going
to
advocate
for
is
you
know
if
you
want
to
indicate
to
us
that
these
are
custom
events
and
in
new
relics
domain,
then
data
model,
then
you
should
prefix
the
domain
with
new
relic
dot,
something.
D
Actually
it's,
it
could
be
tricky,
but
I
thought
this.
This
custom
data
topic
came
up
in
in
our
discussions
too,
and
I
thought
there
was
a
custom
namespace,
I'm
not
sure,
but
assuming
that
the
whole
philosophy
is
that
the
customers
don't
need
to
rewrite
their
application
when
they
move
vendors,
you
know
you
wouldn't
want
them
to
use
new
relic
for
custom
data.
F
Yeah
I
mean
ideally
that
would
be
the
case,
but
you
know
there's
concepts
in
new
relic
that
are
not
transferable
between
vendors,
okay.
So
for
those
situations
you
know
you
are
kind
of
buying
into
a
new
relic
specific
concept,
and
there
is
going
to
be,
I
guess,
some
sort
of
it.
It's
not
going
to
be
as
seamless
of
a
transition
switch
vendors.
D
A
It's
still
a
best
effort
right.
Somebody
can
use
the
domain
name
correctly,
so
it's
not
like
you're
guaranteeing
something,
but
it's
just
you're,
making
it
more
difficult
to
make
that
mistake
having
the
conflicts.
So
I
don't
know.
Maybe
we
enforce
the
presence
of
the
domain
in
the
in
the
in
the
api.
F
Okay,
it
to
me
that's
similar
to
you
know
you
can
obtain
a
meter
or
a
tracer,
and
you
know
we
say
that
you
have
to
include
a
scope
name
for
when
you're
obtaining
a
meter
or
a
tracer,
but
you
can
you
can
put
noel
or
empty
in
there
and
we
do
something
in
those
situations.
F
In
a
similar
case,
you
know
if
domain
is
a
required
field
when
getting
a
event
logger
or
whatever
we're
calling
the
thing,
but
somebody
puts
null
or
empty
in
there.
We
have
to
decide
what
to
do
in
the
case
of
java.
If
you
try
to
obtain
a
meter
or
tracer
without
a
scope
name,
we
set
the
scope
name
to
be
unknown
and
you
know
like
that's
just
the
scope
name,
that
we
pass.
D
A
Yeah,
so
I
think
I
I
feel
that
that
some
of
the
discussions
that
we're
having
are
something
that
we
already
discussed
in
the
past.
They
have
this
feeling.
So
maybe
we
should
start
capturing
this
in
the
written
form
so
that
we
don't
forget
what
what
has
been
discussed
so,
maybe
so
the
event
domain.
Maybe
it's
a
separator
tab.
A
I
don't
know
so
that
you
don't
make
the
events
api,
that
you
have
much
bigger
or
maybe
it's
the
same
one,
I'm
not
sure
whatever
you
prefer,
but
let's
make
sure
that
this
this
discussions
that
we
have
they
are
captured
somewhere
right,
so
that
and
then
we
can
have
a
broader
group
of
people
also
seeing
what
is
happening
there,
not
just
people
who
attend
this
meeting.
A
A
The
by
the
way,
the
old
tap
that
you
have
do
you
think
it's
it's
ready
for
more.
I
guess
wide
review
by
python.
D
I
I
will
need
to
update
it.
I
I,
I
think
there
is
one
more
topic.
Maybe
let's
discuss
that
and
then
I'll
update
the
whatever
contents.
I
think
it's
the
very
initial
version-
and
we
have
made
a
few
changes
after
that
in
the
last
two
meetings,
so
I'll
need
to
update
that.
A
D
I
think
we
kind
of
went
back
and
forth
on
this,
whether
we
should
have
a
public
log
api
for
application
logs,
and
I
think
in
the
last
meeting
I
think
the
you
know
we
were
at
a
state
where
we
will
will
still
call
it
a
log
api,
but
it
will
be
used
only
to
create
events
and
jack
has
a
point
that
the
log
appender
api
or
log
appender
sdk
are
the
api
that
is
meant
to
be
used
by
the
appenders
they,
that
is,
that
looks
very
similar
to
what
we
already
have
so
instead
of
having
two
separate
apis,
you
know
one
log
api
to
create
events
and
then
the
log
appender
api,
both
of
them
using
the
in
a
log
emitter
sdk.
D
A
F
I
I
talked
to
some
of
the
java
sig
folks,
some
of
the
other
java
maintainers
and
john
watson
expressed
an
opinion
about
you
know
if
he
were
to
do
it,
that
he
would
kind
of
go
this
other
route
of
having
two
different
kind
of
entry
points
into
the
api.
You
know,
I
I
think,
there's
pros
and
cons
of
each.
I
think,
having
two
different
entry
points,
one
for
a
log
of
pender
and
one
for
a
like
an
event.
F
Emitter
type
thing
you
know
the
advantage
of
that
approach
is
that
it
has
more
precise
language,
and
so
you
know
it.
It
may
seem
odd
to
somebody
that's
looking
to
emit
events
to
do
so
through
something
that's
called
a
logger.
F
F
E
I
I
would
concur
with
john
I
I
would
prefer
to
see
them
separate,
especially
when
you
you're
playing
with
like
areas
again
browser
where
there
is
no
appender
or
no
need
for
an
appender
and
effectively
under
the
covers.
I
would
see
that
the
event
api
would
actually
be
using
the
logging
appender
api.
So
if
you
generate
the
log
entries.
F
F
If
you
have
separate
separate
entry
points
into
the
api,
you
can
easily
do
that
without
you
know,
being
prone
to
errors
without
people
accidentally
missing
the
documentation
and
accidentally
omitting.
This
domain.
D
Actually,
it
goes
back
to
the
fundamental
decision
of
calling
logs
and
events
the
same
right.
I
think
I
I
I
I
still
feel
like
you
know
that
you
know
shouldn't
have
been
made,
then
all
of
this
discussion
would
have
been
simply
simpler.
B
D
Even
the
data
model,
we
can
argue
right,
you
know
we
are,
we
have
decided
to
use,
you
know
what
fields
would
use
for
events
and
what,
for
for
logs
in
all
of
them
are
applicable,
but
for
events
we
are
going
to
use
only
some
fields.
F
Well,
you
could,
for
events,
use
all
the
fields
of
logs
there's
just
like
this
requirement
that
you
have
these
two
fields,
in
particular
a
name
in
a
domain,
but
there's
I
think,
riley
has
brought
up
in
the
past
that
you
may
be
interested
in
emitting
an
event
with
the
severity
associated
with
it
for
filtering
purposes.
F
D
It's
you
know,
I'm
only
saying
that,
because
of
that
you
know
we,
you
know
that
that
gives
one
basis
to
continue
to
keep
them
together.
Even
at
the
api
level.
A
A
I
don't
see
the
point
of
kind
of
trying
to
reverse
this
decision.
It's
it's
too
late.
In
my
opinion,
whether
in
the
api,
they
can
be
different.
I
think
that's
the
option
we
we're
open
to
that,
and
maybe
we
soften
the
language
which
says
they
are
the
same
thing
everywhere
in
the
specification.
Instead,
we
say
that
they
are
the
same
thing
from
data
modeling
perspective,
but
in
the
api
they
we
have
different
ways
to
to
interact
with
this
data.
So
I
think
that's
fine.
D
Sorry,
are
you,
okay,
with
using
different
names
for
the
two.
A
F
A
I
don't
see
a
huge
contradiction
here
right,
so
it's
one
entry
point,
but
you
call
different
methods.
You
get
different
results
and
maybe
you
group
the
the
surface
of
the
api
that
we
expose
it's.
I
guess
not
huge
right.
It's
it's
not
like.
You
have
100
different
methods
and
you're
going
to
be
confused
about
what
is
happening
there.
Maybe
I'm
wrong
right.
I
think.
D
That
I
agree
with
that,
because
I
think
nav's
concern
is
also
not
so
valid,
because
the
the
additional
set
of
methods
you
would
have
for
the
logging
use
application
log
use
cases
is,
is
going
to
be
very
few
and
that's
not
going
to
add
the
you
know.
It's.
A
D
I
think
only
difference
is
for
events.
We
are
mandating
the
the
name
and
therefore
you
know
there
is
one
extra
method
you
know
which
gives
you
a
a
log
record
builder,
with
with
the
name
pre-populated
right.
A
D
D
D
Very
small
addition,
such
might
be
okay,.
A
So
yeah,
it's
again:
let's,
if
you,
when
you
update
the
the
autopsy
that
you
have,
it
will
be
maybe
easier
to
discuss
these
things
on
the
actual
well,
on
the
in
the
form
of
a
code,
I
guess
called
examples
or
something
like
that.
It's
it's
maybe
difficult
to
picture
this.
While
we're
discussing
this
verbally.
F
Okay,
well,
that's
what
I
try
to
do
exactly
so.
I
left
a
comment
that
you
know
I
I
have
two
prototypes
that
indicate
each
of
those
and
you
know
they're
they're.
They
demonstrate
the
same
types
of
examples
of
using
them,
but
using
two
different
kind
of
strategies
in
terms
of
the
api
layout,
and
you
know
I've
written
out
the
pros
and
cons
of
each.
So
I
I
don't
see
a
clear
winner.
F
I
think
each
has
its
merits
and
well,
I'm
not
sure
exactly
how
to
decide
when
each
has
that
has
merits-
and
you
know.
E
A
That's
an
interesting
way
of
thinking
about
it.
I
like
it.
The
slight,
I
guess
complication-
is
that
the
span
events
they
are
not
the
data
models
or
span
events
is
not
exactly
the
same
as
the
data
model
for
the
for
the
log
records
we
have,
which
at
some
point,
I
wanted
to
make
sure
that
they
are
aligned,
but
there
was
some
there
were
some
some
of
the
fields.
A
Yeah
so
essentially,
regardless
of
how
you
obtain
a
logger,
you
could
obtain
a
logger
as
a
top
level
logger
by
using
the
logger
provider,
or
you
could
obtain
a
logger
from
from
the
current
span.
And
then
you
would
once
you
have
the
logger.
You
would
essentially
call
the
same
methods
yeah,
but
one
would
create
top
level
lock
records.
The
other
would
create
spam
events,
something
like
that
right.
That's.
D
What
you
mean,
but
these
span
events
has
to
be
part
of
the
trace
api,
because
there
is
an
impressive
yeah.
A
E
Yeah,
because
that
would
be
an
invalid
situation
as
well.
The
span
has
ended
yeah.
E
A
F
Sorry
so,
okay,
so
there's,
I
have
a
comment
with
a
reply
to
my
own
comment.
Yes,
yes,
I
just
saw
that
and
each
one
of
them
has
a
link
to
a
pr
and
that
pr
contains
the
the
prototype.
For
you
know
the
concept
that
that
comment
is
describing
and.
F
And
there's
a
link
in
each
comment
to
a
test
class
which
you
know
it's
just
like
a
little
unit
test
which
illustrates
usage
of
the
api.
You
know
so
my
goal
was
to
be
able
to
compare
them
on
equal
footings,
so
try
to
do
the
same
thing
with
each
of
the
apis.
A
Yep
yeah
I'll
definitely
have
a
look
at
you
folks,
also,
if,
if
you
haven't,
please
do
because
I
think
this
it's
great
to
to
be
able
to
see
the
shape
of
the
api
in
the
code
right.
We
discussed
this
verbally,
but
it's
never
a
proper
substitute
for
for
the
code.
What
it
looks
like
in
the
code.
A
D
Yeah
I'll
update
the
tip.