►
From YouTube: 2023-04-04 meeting
Description
Instrumentation: Messaging
B
C
Hello
yeah,
so
I
guess:
I'll
wait
until
other
folks
arrive
and
we
actually
get
started.
I,
don't
want
to
repeat
myself.
A
Okay,
we
can
start.
We
can
start
with
your
topic
first,
because
for
the
other
one
I
am
expecting
one
more
member.
So
we
could
do
that
after
yours,.
C
Right
so
I
spent
some
time
going
over
a
lot
of
the
material
that
relates
to
the
ephemeral
resource
conversation
I
read
through
the
otab
I
read
through
the
you
know,
one
of
the
original
design
documents
that
described
why
session
IDs
you
know,
belong
as
a
resource
and
attribute,
and
you
know,
there's
a
lot
of
material
out
there.
There's
a
lot
of
conversations
and
opinions
and
so
and.
C
I
have
all
the
contacts,
but
I
think
I
have
enough
enough
to
form
an
opinion
and
kind
of
one
thing
that
occurred
to
me
last
night
is
I.
Was
thinking
about
this
problem?
Was
that
I
think
you
all
have
all
the
tools
you
need
to
move
forward
this
with
this
right
now,
so
you
know
the
place
and
the
specification
where
it
says
that
resources
are
immutable
is
let
me
pull
up
the
specific
document.
B
C
Right
so
the
place
that
it
says
that
okay,
let's
let's
just
back
up
for
a
second,
so
okay,
this
is
the
resource,
SDK
document
and
the
specification-
and
it
says
you
know
this
is
this-
is
what
a
resource
means
from
an
sdk's
perspective.
This
is
different
than
what
a
resource
means
from
a
data
model
perspective.
C
If
we
want
to
find
that
we
need
to
actually
go
over
to
the
Proto
repository,
but
from
the
sdks
perspective,
the
resource
is
the
thing
that
you
associate
with
the
Tracer
provider
or
a
meter
provider,
and
it's
very
clearly
immutable,
and
this
is
the
whole
like
kind
of
Crux
of
the
conversation.
Is
it
a
breaking
change
to
revise
this?
Where
this
this
one
line?
Here,
we
don't
say
much
about
what
a
resource
is,
but
we
say
very
clearly
that
it's
immutable,
but
we
don't
actually
listen
to
this.
C
You
know
if,
if
you
think
about
you,
know
the
broader
data
model,
the
collector
in
particular,
has
all
sorts
of
capabilities
for
mutating
resources
and
enriching
them
with
additional
attributes
related
to
the
environment
that
an
entity
is
running
in
and
there's
nothing
stopping
those
those
processors
that
are
running
in
the
collector,
from
not
just
like
enriching
the
data
in
a
way
that
is
stable
and
predictable.
But,
like
you,
know,
mutating
it
in
a
way
that
is
like
every
single
piece
of
data
that
flows
through
gets
a
a
different
resource
attached
to
it.
C
So
going
back
to
the
trace
SDK,
what
are
the
tools
that
we
have
in
the
trace?
Sdk
that
would
might
allow
you
to
you
know,
change
a
resource,
so
a
trade,
a
tracer
provider.
It's
got
to
be
configured
with
all
sorts
of
things,
so
you
know
we
list
here.
The
span
processor,
the
ID
generator.
C
The
span
limits-
weirdly,
what's
not
mentioned
here,
but
it
has
to
be
implied-
is
that
it
has
to
be
configured
with
a
resource
as
well
that
resource
has
to
get
attached
to
all
the
the
data
that
gets
emitted
from
this
Tracer
provider.
Although
it's
not
explicitly
said
here
and
then
we
have
these
span,
processors
span,
processors
are
strange,
contrary
to
their
name.
C
They
don't
actually
allow
you
to
process
data
in
the
way
that
you
would
expect
you
can
only
mutate
data
in
this
on
start
section
of
a
span
processor,
you
can't
mutate
data
in
on
end
at
all.
That's
strange
and
the
things
that
you
can
mutate
on
a
span
on
the
onstart
phase
are
is
pretty
limited.
You
can
only
you
know
mutate,
a
handful
of
fields
that
are
like
you
can
you
can
change
the
name
of
the
span
and
you
can
set
attributes
you
don't
have
full
access
to
mutate.
C
Every
bit
of
data
on
the
span.
You
can't
change
its
scope,
you
can't
change
its
resource
and
so
span.
Processor
is
a
limited
interface
in
that
way,
and
the
other
thing
that
you
can't
do
in
a
span
processor
that
you
might
expect
to
do
is
you
might
expect
to
filter
your
data,
and
you
can't
do
that
here.
C
So
that's
strange,
but
span
processors,
there's
there's
a
couple
that
are
built
in
right.
You
have
the
simple
span:
processor
and
the
batching
span.
Processor,
the
one
that's
most
popularly
used
is
the
batching
span
processor,
which
you
know
when
spans
end.
It
batches
them
up
into
a
queue
and
passes
them
to
a
configured
span,
exporter
to
export
out
of
the
application,
and
so
that
leads
us
to
the
next
portion
of
the
trace
SDK,
which
is
like
span
exporter
span.
C
Exporters
interface
is
pretty
simple:
it
has
an
export
method
and
then
a
shutdown
and
a
flush,
but
we
won't
talk
about
those
export
accepts
a
batch
of
readable
spans
and
if
you
actually
think
about
it,
the
span
exporter
is
the
only
place
where
you
can
do
real
processing
on
data.
You
have
access
to
the
full
readable
span,
including
its
including
its
scope
and
its
resource
and
all
of
its
fields
that
are
needed
to
export
it.
C
Out
of
the
application
you
can
chain
together,
exporters
if
you
choose
to
filter
data
or
enrich
those
spans
with
whatever
you
see
fit
before
passing
on
passing
that
batch
on
down
the
chain,
and
so
you
know,
despite
its
name
span
exporter,
really
the
only
it's
really
the
only
tool
in
the
the
tool
belt
of
it
of
an
SDK.
You
know
operator
for
doing
real
processing
like
on
the
data
like
you
might
expect
in
The,
Collector
and
so
I
guess.
What
I'm
advocating
for
is
just
build
a
span
exporter
which
wraps
you
know.
C
It
accepts
a
delegate
span
exporter
as
an
argument,
and
it
accepts
A
supplier
of
a
resource
as
another
argument
and
that
resource
that
it's
this
supplier
can
change
as
a
function
of
time.
And
so
every
time
a
batch
of
spans
comes
through.
It
evaluates
what
the
current
resources,
according
to
its
provider
or
its
supplier,
and
merges
that
resource
with
the
resources
that
are
attached
to
the
spans,
which
are
you,
know,
static
and
immutable.
C
And
then
you
know,
passes
those
spans
onto
the
delegate
exporter
to
to
get
out
of
the
application
and
that
supplier
of
resources
is.
The
thing
is
the
place
where
you
could
have
you
know
the
session
ID
and
the
you
know
the
the
page
or
the
the
browser
height
and
width
and
all
the
immutable
attributes
be
subject
to
change.
B
Okay,
there's
a
couple
of
problems:
I
see
with
that.
What
do
you
got?
The
the
first
one
is
we're
using
logs,
not
spans
so.
B
But
apart
from
that,
it's
effectively
yes,
the
the
you
know
the
batching
is
important,
but
within
that
batch
that
batch
may
actually
have
a
mixture
of
session
IDs
page
widths.
It's
not
just
a
case
of
okay.
Now
now
I'm
in
the
exporter,
I've
got
this
batch
of
things.
I
want
to
stamp
the
same
thing
on
every
single
event.
That's
not
how
it's
going
to
work.
C
I
was
under
the
impression
that
session
ID
was
shared
amongst
all
its
data,
all
of
its
all
the
spans
and
logs
emitted
by
an
application
actually.
A
Let
me
clarify
I,
think
Jack,
correct
me:
if
I'm
wrong
I
think
you
are
like
I
think
about
a
year
ago,
when
Ted
we
were
discussing
with
Ted,
he
actually
suggested
exact
same
thing.
I
I
think
it
is
the
same
thing
and
we
in
fact
prototyped
where
the
resource
that
you
attach
with
the
spans.
A
You
know
you
could
always
you
know,
change
and
the
JavaScript
SDK.
We
noticed
you
know
with
one
small
change
in
the
SDK
code.
You
know
we
were
able
to
get.
That.
Is
that
the
same
thing
you
are
suggesting
and
not
that
you
you
know
attach
you
know
the
you
know
some
of
these
attributes
as
part
of
each
span.
C
No
I
think
it's
a
little
bit
different
okay
and
what
I'm
suggesting
so
I
found
this
document
that
goes
back
a
while,
and
it
I
think
it
was
some
of
the
thinking
behind
Ted's
otab
and
it
talks
about
why
session
ID
is
important
to
include
as
a
resource
attribute
it's
attached
to
every
piece
of
data,
that's
emitted
from
an
application,
and
so
it
kind
of
meets
the
criteria
of
a
resource.
It's
part
of
the
Telemetry
source
and
if
you
scroll
down
in
here,
there's
a
couple
of
other
ideas
suggested
behind.
C
D
A
On
The
Wire,
where
do
these
attributes
go?
Is
it
on
the
resource
or
is
it
inside.
C
A
Resource
on
the
resource,
only
right,
okay,
so
it's
just
that
you're
you're,
suggesting
that
during
the
export
time
you
alter.
You
know
what
resource
you
send
for
that
in
sense
of
export,
yep.
C
Okay,
all
right
here,
here's
here's,
okay!
So
this
this
is
kind
of
the
idea
here
so
record
session,
ID
as
a
resource
or
scope
attribute
on
the
fly.
So
this
is
that,
but
this
is
the
same
idea,
but
what
Ted
suggests
or
whoever
wrote
this
suggests
is
doing
it
in
a
span
processor
and
the
problem
is,
is
that
is
that
requires
log
and
Metric
processors
to
be
able
to
modify
resources
and
span
processors
span?
C
Processors
cannot
modify
resources
today,
right
span,
processors
are
super
limited,
and
so
the
only
change
that
I
have
from
this
is
to
not
do
it
in
a
span
processor,
but
to
do
it
in
an
exporter
that
delegates
to
whatever
ultimate
Target
exporter
you
want
and
exporters
do
have
the
full
ability
to
you
know
access
to
all
bits
of
data
on
the
span-
and
you
know
by
extension
of
that
they
can.
They
can
modify
any
bit
of
that
data
before
they
pass
it
on
to
some
delegate.
B
Yeah,
okay,
so
do
you
have
a
reason
why
it
may
not
work
so
there
are.
There
are
cases
where?
Yes,
it
would
be
perfectly
fine,
because
it's
not
going
to
change
within
that
batch,
but
there
are
edge
cases
where,
if
you've
got
like
a
spa
application,
so
a
single
page
app
in
the
browser
where
the
user
says:
okay,
I'm
going
to
sign
up
and
then
sign
back
in
which
would
cause
a
session
ID
to
change.
C
You
can
imagine
a
situation
where
the
code
that
is
responsible
for
handling
the
session
IDs
before
it
updates
its
mutable
resource
it
flushes
this
the
Tracer
provider
and
causes
all
export
all
exports
to
be
done.
All
those
spans
are
exported
out
of
the
application,
and
then
it
updates
the
session
ID
to
be
the
new
one,
and
you
know
from
from
that
point
forward.
All
additional
spans
that
are
exported
would
have
the
new
session
ID
and.
B
And
that
would
work
for
a
session
ID,
except
in
network
intensive
applications,
so
like
for
teams
like
add
a
default
flushing
time
for
the
in,
for
our
internal
version
is
every
two
seconds
for
teams.
They
they
push
that
out
to
every
30
seconds,
because
when
you're
doing
video
calls,
you
don't
want
a
browser
to
create
lots
and
lots
of
Network
requests.
B
So
in
the
in
the
and
in
the
case
of
signing
out
and
signing
in
that's
a
very
intensive
set
of
network
requests.
They
actually
don't
want
that
to
happen
at
that
point,
either.
B
Because,
at
the
you
know,
effectively
everything
can
be
batched
and,
as
part
of
the
the
the
the
batch
an
event
has
a
link
to
it
to
firmative
a
set
of
ephemeral
resources,
so
I
can
then
pull
it
out.
So
the
batch
could
then
be
a
mixture
of
different
sets
of
resources,
which
is
not
the
case
today,
because
the
other
way
to
do
it
is,
you
could
say:
okay,
I'm,
going
to
create
a
new
resource
and
go
and
set
the
new
resource
for
everything.
Everything
but
you're
always
going
to
miss
something
yeah.
B
Time
it
would
work,
but
there
are
edge
cases
where
it.
A
Wouldn't
so
I'm
not
following
on
the
wire
nav
on
The
Wire?
Are
they
not
equivalent,
like
you
know,
let's
say
for
the
duration
of
the
time
when
you
know
the
the
state
of
you
know
those
mutating
resources,
mutating
attributes.
You
know
if,
let's
say
it's
in
state
one,
you
know
they
get
Associated
for
for
all
the
signals
emitted
thus
far
and
anytime.
They
change
for
that
duration
of
the
period
in
the
next
state
they
get
associated
with
the
span
submitted
during
that
duration.
A
So
in
either
approaches
it's
just
like
I
I
didn't
follow
the
difference.
B
A
Is
that
true
I?
Is
that
a
requirement.
B
I
believe
so
that
has
been
talked
about
in
the
JS,
Sig
and
I.
Think
the
spec
sing
a
couple
of
times
because.
A
That
is
exactly
the
argument.
Jack
is
pointing
out
that
you
know
we
are
already
violating
in
in
the
let's
say
in
the
collector,
like
you,
may
you
may
confirm
to
that
statement
in
in
the
in
the
SDK,
but
in
the
collector
you
might,
you
know,
always
change
it.
So,
at
the.
B
End
yeah
collect
is
further
Downstream
I'm
talking
about
you
know,
you
got
the
span,
you
then
it
hits
the
the
batch
span
processor
and
then
once
it
passes
it
on
it
gets
hit,
hits
the
exporter
and
then
everything
Downstream
can
make.
It
can
change
it.
It's
that
batching
portion
that
that
causes
it
to
so.
A
One
specific
scenario
that
Bogdan
pointed
out
was,
you
know
where
you
know
this.
Could
you
know
lead
to
a
problem?
Is
let's
say
in
a
given
Trace
same
browser?
Sdk
itself
is
exporting,
let's
say
two
spans
in
the
same
trace
and
it's
possible
that
you
know
one
span
might
be
associated
with
one
resource.
A
Another
span
could
be
associated
with
another
resource,
so
that
could
be
some
confusion,
but
other
than
that
scenario,
like
I,
think
I
I
think
there
has
to
be
more
reasoning
as
to
why
a
given
export
a
batch,
you
know
needs
to
have
the
same
resource
like
where
all
does
it
lead
to
problems.
B
A
Because
if
you
point
that
out,
then
we
could
make
a
case
that
what
the
collector
is
doing
collector
is,
enabling
you
know,
may
lead
to
you
know
the
same
problems.
B
A
Okay,
so
this
is
one
one
proposal
for
sure:
I
think
we
we
did
consider
now.
If
you
remember
you
know
we,
we
did
I
think
Martin
had
prototyped
this
to
so
we
did
consider
yeah.
You
are
actually
pointing
out
to
text
document
I.
Think
during
that
discussion
was
the.
C
A
B
D
B
D
B
Yeah,
if
it's
before
batching
it's
fine
but
Jack's,
talking
about
after
batching
right.
C
B
One
of
the
other
things
I
need
to
do
is
I
need
to
be
able
to
support
having
multiple
sdks
running
in
memory.
So
how
would
you
have
that
so.
A
I
think,
last
time
there
was
a
concept
of
a
resource
provider
that
was
introduced.
So
you
would,
you
would
configure
your
SDK
with
the
resource
provider
and
then
your
exporter
will
will
call
resource
provider.get
to
get
you
know
the
the
resource
you
know
at
the
time
of
that
call
and
the
name
of
that
export.
So
in
your
in
your
case
you
know:
if
there
are
multiple
sdks
live,
then
they
would
each
be
configured
with
a
separate
resource
provider.
A
Well,
I
think
the
bigger
point
is
you
know
if
the
if
the
spec
allows
it
or
not,
is
this
a
good
practice
or
not
I
think
if,
if
that
is
answered,
then
we
can,
we
can
make
it
work.
I
think
I.
C
B
In
the
case
of
your
resource
modifiers,
pointing
to
the
same
resource
provider,
that
would
actually
have
to
point
to
different
ones.
But
if.
B
C
Anyways,
that's
that's
my
thought
on
this.
You
know.
A
E
A
Go
ahead,
Scotty,
so
yeah
one
I
I
also
want
to
quickly
revisit
one
question
that
you
asked
last
week,
which
is
like:
do
they
fit
into
a
resource
and
on
on
that
topic?
I
have
one
question
so
on
the
in
the
in
kubernetes,
you
know
your
your
pods
can
have
States
right.
Your
part
could
be
starting
running
terminating
and
in
each
of
those
States
you
could
be
emitting
spans
right.
So
do
you
have
a
mechanism
to
represent
the
state
of
your
resource,
like
is
that
handled
today?
In
some
ways.
C
Represent
the
state
of
your
resource,
like
this,
you
know
represent
the
state
of
a
pod
in
a
resource,
yeah
I.
Don't
think
so,
and
you
know
I
think
I
get
where
you're
coming
from
Santosh
I
think
you're
trying
to
essentially
establish
like
are
there
situations
for
traditional
applications
where
a
resource
attribute
would
change
correct,
yeah
and
you
know
I
I
think
that
could
be
a
decent
example.
I
haven't
seen
anybody
try
to
capture
that
in
a
resource
attribute.
C
C
A
Basically,
the
point
is
there
could
be
a
state
which
could
be
changing.
Apart
from
the
immutable
aspect
of
a
resource,
there
could
be
a
state
that
you
know
you
might
need
to
track
right.
C
It
does
most
almost
all
the
enriching
with
you
know,
kubernetes
related
attributes
on
the
resource.
I,
don't
know
that
it
does
that
one
I
would
I
would
be
surprised
because
I
think
it
tries
to
cache
data.
You
know
if
it
looks
up
what
attributes
it
should
enrich
Resources
with
related
to
a
pod
I,
don't
think
it
tries
to
like
constantly
look
up
its
state
with
every
you
know
record
that
it
comes
across.
It
tries
to
look
it
up
once
and
then
you
know
cache
that
result.
C
It
is
it's
it's
a
good
example
to
bring
up,
though
in
conversations
and
the
specification
like
so
you
know,
I
think
that's
more
reason
why
folks
shouldn't
over
analyze
this
client
instrumentation
group
wanting
to
mutate
its
attributes.
You
know
if
there's
other
examples
where
it's
not
just
client
instrumentation,
but
you
know
other
domains
where
it
makes
sense
to
do
that.
Well,
that
strengthens
the
case.
A
Yeah
one
one
thing:
I'm
thinking
is
that
you
know
if,
at
the
end,
what
gets
on
the
wire
in
in
either
of
these
cases
is
the
same.
Like
you
know,
in
your
proposal
and
that's
original
proposal,
you
know
it's
it's.
It's
only
a
matter
of
how
we,
you
know,
enable
the
resource
attributes
to
change,
but
you
know
they
are
still
on
the
resource
and
not
on
the
individual.
A
You
know
signals,
so
we
could
change
from
one
mechanism
to
another
over
time,
but
if
at
a
high
level,
if
you
agree
that
you
know
it's
it's
okay
to
put
these
things
on
a
resource,
then
then
we
can
get
started
with.
You
know
what
you're
suggesting
and
and
then
evolve
later
right.
C
And
I
I
think
what
I
still
don't
have
a
good
answer
for
is
is
when
is
it
appropriate
to
include
a
particular
attribute
on
a
resource?
Like
you
know,
I'm.
C
Through
your
list
of
the
attributes
that
you
all
want
to
include
on
the
resource,
so
there's
things
like
screen,
width
and
Screen
height
and
Page,
impression,
ID
and
end
user
ID
and
session
ID
and
I,
don't
have
good
intuition
about
whether
some
or
all
of
those
are
appropriate
as
a
resource.
There's,
not
good
language
in
the
specification
that
tries
to
Define
like
what
appropriate
resource
attributes
actually
are.
It's
the
language
is
pretty
vague.
C
A
A
The
term
State,
if
we
introduce,
then
that
answers
your
question
that
you
know
these
could
be.
You
know
this
could
represent
the
state
of
your
resource.
C
Yeah
I
guess
I
what
I?
What
I
don't
want
to
happen
is
I.
Don't
want
the
client
instrumentation
group
to
put
everything
into
a
resource
attribute
just
for
the
sake
of
reducing
the
payload
size
over
the
network.
I
think
that
should
be
separately
addressed.
Somehow
we
have
to
Define.
You
know
whether
or
not
it
actually
is
appropriate
to
based
on
like
the
data
model,
to
include
stuff
as
resource
attributes
and
I
I'm,
not
really
sure
how
to
make
those
decisions
right
now.
B
The
screen
within
height
definitely
there's
arguments
multiple
ways
for
that.
One,
like
there's
arguments
to
say
when
you're
performing
at
you're
recording
a
page
action
you
know
having
the
screen
within
hype
is
useful.
The
other
one
is
yeah
when
they
resize
the
the
screen.
That's
useful
so
yeah
that
one
that's
a
gray
area
but
yeah
session,
ID
user,
ID,
impression,
ID
I,
think
Are
all
valid.
What.
B
Page
view
effectively,
so
it's
not
the
session
which,
which
is
multiple,
page
requests.
It's
it's
that
particular
page
view.
So
everything
happens
on
that
particular
Page.
Look
if
you
like,
and
the
user
is
for
as
long
as
that
user
is
active,.
A
B
A
Visit,
it
I
think
it's
meant
for
analytics
where
you
want
to
see
how
many
visits
a
page
is
getting.
So
it's
like.
B
C
B
B
Because
they
could
load
the
page
and
sit
there
and
nothing
happens
with
the
span
until
you
actually
close
the
page
to
enter
the
spans.
So
you
don't
want
to
keep
bringing
out
of
memory
actually
thinking
about
it
from
what
you're
provider
here
with
the
resource
provider
and
the
the
modifier
that's
effectively
saying
we're
going
to
go
off
and
Implement
our
own
ephemeral
resources
set
of
things.
B
C
B
C
E
C
B
Yeah
it,
it
just
adds
more
onus
on
the
application
developer
when
they're
initializing
the
system
to
make
sure
they
put
that
in
place,
as
opposed
to
just
being
supported,
because
it
means
you
can't
have
a
an
instrumentation
that
effectively
cracks
this
for
you
automatically
it's
but
yeah.
We
can
stop
there.
C
Wait:
I'm
I'm,
not
I,
I,
don't
follow
that
line
of
reasoning.
So,
regardless
of
whether
you
have
an
ephemeral
resource,
that's
Tad
proposed
or
this
you
need
to
do
special
things
when
you're
configuring,
your
SDK,
you
need
to
like
have
the
application
and
whatever
part
of
the
application
is
responsible
for
managing
session
ID
State.
You
need
to
have
that
have
access
to
the
the
Tracer
provider
and
it's
a
femoral
resource
or
this
resource
provider
in
some
ways
that
it
can
mutate
that
state
there's
always
additional
setup
steps
required
in
this
approach
or
tides.
B
Yeah
look
like
in
t2's
second
example
here
with
the
log
processor,
like
these
additional
ephemeral
resources.
It's
there's
multiple
arguments
here
of.
Do
we
want
to
stamp
it
on
every
single
log
event
or
only
our
events?
B
Originally,
you
know
we
were
looking
at
just
our
events.
This
approach
here
would
actually
stamp
it
on
absolutely
everything.
I.
E
B
So
you
could
end
up
with
resources
that
aren't
required
for
something
I
can't
think
of
what
that
something
would
be
an
exception.
The
exception
would
have
the
screen
size
stamped
on
it
for
some
reason.
Well,.
C
B
It's
to
be
attached
to
every
particular
type
of
thing,
going
out
the
door
I.E
an
event.
What
was
the
plan
and
some
of
it
some
spans.
F
C
B
B
C
And
you
can
you
know
as
you're
building
this
you
know.
Obviously
this
should
be
configurable
for
the
user
like
so
while
session,
ID
and
Page
impression.
Id
may
be
important
in
some
situations.
Maybe
people
don't
want
to
pay
the
tax
for
including
screen
width
and
Screen
height
on
every
single
payload.
That's
exported
so.
B
Yeah
we
could
move
forward
with
that,
I
think
and
prototype
it
and
then
once
it's
up
and
running
yeah
the
the
fund's
going
to
be
when
other
languages
have
to
implement
it.
I
guess
Java
was
probably
going
to
be
one
of
them
for
Android
environments.
C
Java
has
an
Android
donation
coming.
It.
C
E
A
A
Okay,
maybe
I
think
we
can
think
over
this
idea
and
and
see.
Maybe
we
could
push
a
type
pen
and
then
it's.
B
Completely
separate
to
the
event
stuff,
this
is
just
yeah
we're
going
to
have
effectively
an
ephemeral,
resourcy
thing.
Okay
naming
is
not
my
substitute
either,
which
effectively
does
this
and
would
link
to
the
session
manager
and
whatever
else
we
want
to.
D
B
A
I
had
yeah
I
added
that
yeah,
so
I've
been
at
and
I.
We
were
chatting
yesterday
and
there
are
a
couple
of
questions.
I
I
think
one
is
I
think
he
asked
already
asked
you
on
slack,
which
is
about
the
examples
or
how
do
you?
How
does
one
test
the
changes
we
make
there
and
second,
we
also
wanted
to
know
that
you
know
is
like
what
would
be
the
difference
between
development
in
the
jsripo
versus
development
in
the
sandbox.
A
If,
if
we
like,
can
the
same
thing
be
moved
without
any
changes
or
will
there
be
some
changes?
You.
B
Know
where
we
come
yeah
so
so
the
intent
is,
the
effect
of
the
main
branch
of
sandbox
is
effectively
just
a
copy
of
both
JS
and
contrib.
Combined
with
the
web
components,
you
know,
I
think
to
be
built.
B
Any
changes
that
you
want
to
make
to
JS
and
contribute
should
be
made
to
adjacent
contrib.
So
if
we
find
bugs
in
the
sandbox
because
you're
doing
a
development
branch-
and
you
want
to
do
something
once
you've
proved
it
you're
going
to
go
back
and
make
the
the
pr
on
on
either
one
okay,
the
the
primary
advantage
of
the
sandbox,
it's
a
little
bit
less
than
what
it
was
because
originally
we
had
the
API,
it
was
separate,
so
it
was
going
to
be
combining
the
three
repos.
B
Is
there
all
here
together
we
don't
have
to
publish
you
know
a
JS
build
to
have
something
in
contribute
to
go
and
build
it.
Okay,
so.
A
Ideally,
the
the
same
package
could
be
blindly
put
in
the
JS
reporter
right.
I
think
there
are.
F
B
Yeah
yeah
like
if,
if
you
only
rely
on
stuff
in
the
JS
repo,
you
can
go
drop
it
yeah
go
build
it
in
there
experimental
folder
in
the
JS
repo
there's
no
real
Advantage
for
the
sandbox.
For
that.
Okay,.
A
Then
then,
in
that
case,
what
we
could
do
is
I've
been
at,
you
could
proceed
with
sandbox
and
then
once
we
it
reaches
some
stage.
You
know
you
could
raise
a
PR
on
adjustable
yeah.
B
Yeah
so
the
example
I
haven't,
bought
them
over
effectively.
If
you
go,
have
a
look
at
the
config.ts
folder
there's
a
map
in
that
that
effectively
says
bring.
You
know
this
package
from
this
folder,
which
is
the
affect
the
the
auto
merge
version,
which
has
both
the
branch
that
has
JS
and
contrib.
You
know
grab
it
from
that
folder
and
put
it
into
this
folder.
So
it
should
just
work.
B
I
have
had
issues
in
the
past,
which
is
why
it
took
so
long
where
not
everything,
especially
between
API
JS
and
control,
was
following
the
same
pattern
for
its
TS
config.
It's
lints
and
it's
you
know
running
of
the
thing
at
the
webpack
definitions
for
the
karma.
B
F
I'm
not
sure
about
I
mean
if
it
just
works.
If
we
just
bring
the
examples
from
like
the
country
or
the
JS,
so
I
just
want
to
know,
I
mean
if,
if
you
are
planning
to
do
it
the
domain,
so
we
can.
B
Not
at
this
point,
no,
my
main
goal
was
to
effectively
start
on
the
minification
and
it's
part
of
the
minification,
like
one
of
the
reasons
the
sandbox
generates.
Bundles
is
so
that
I've
got
Baseline
in
Maine
for
the
minification,
because
I
was
primarily
concentrating
on
the
the
overall
functionality.
Once
I
got
the
functionality
under
control,
then
I
was
going
to
look
at
the
examples.
So
I
don't
have
a
need
at
this
point
in
time
doesn't
mean
to
say
there
won't
be.
If
you
have
a
need,
we
can
try
doing
that.
B
In
fact,
you
know
you
could
even
try
doing
that
yourself
because
I
said
maybe
see
if
I
can
find
a
PR.
To
give
you
an
example
of
the
changes
you
need
to
make.
You
can
run
some
I
think
updated
the
readme
in
terms
of
running
the
scripts
locally,
it's
wrong
with
the
test
flag.
E
F
B
Well,
that's
what
the
script
are.
The
script
goes
and
renames
them
all.
So,
if
you
can,
if
we
can
just
add
the
the
definition
to
the
config
TS,
it
does
all
the
renaming
for
you
and
it
it
just
it's
just
like
magic.
F
B
Yeah,
so
in
the
auto,
merge
folder
you've
actually
got
access
to
everything.
Anyway,
you
can
actually
do
a
git
merge.
Oh
sorry,
git
move!
If
you
wanted
to
in
your
own
local
branch.
B
The
only
other
changes
you
need
to
do
is
effectively
prefix
every
package
name
with
sandbox
Dash,
because
every
package
gets
renamed
as
sandbox
Dash.
Assuming
you
want
the
local
packages,
not
the
public
ones.
B
There
are
a
couple
of
changes
that
happen
in
the
in
the
definition,
but
yeah
so
anyway,
I
I
just
dropped
a
link
to
the
pr
that
I
had
apart
from
I've
updated
the
readme.
The
config
TS
is
the
main
bits
like
a
lines:
30
132,
133
134,
in
fact
133
134.
This
is
how
I
brought
in
API
logs
and
API
events.
B
The
other
changes
were
actually
bug
fixes
to
fix
issues.
So
really
it's
just
that
conflict
yes
like,
if
you
just
add
an
entry
there
and
then
the
readme
I
think
I
talked
about
how
to
test
it
locally.
B
Yes
and
there
it
is
so
on
line
55
of
the
readme.
It's
got
this
magic
little
script,
which
you
run
from
the
root,
which
is
the
same
script,
that
the
action
runs,
which
is
the
do
sandbox
staging
merge.
It
just
does
it
without
the
dash
test
and
no
PR.
If
you
drop
the
no
PR,
we'll
actually
create
a
real
PR
up
on
the
sandbox
and
it'll
go
through
the
CI.
So
that's.
If
you
don't
want
to
test
it
locally,
you
can
do
that.
B
The
dash
test,
effectively
prefixes
the
pr
with
test
and
also
goes
changes
the
location
that
it
does
all
the
merging
back.
One
level
from
your
repo
route
I
had
to
do
that,
because
I
run
on
Windows
and
vs
code
and
vs
Visual
Studio
keep
files
open
once
you
modify
the
existing
one,
so
by
moving
it
outside
of
my
repo,
it
meant
I
could
blow
it
away
and
run
it
again
without
having
to
shut
down
BS
code
and
visual
studio.
F
B
Yeah,
so
really
all
you
do
is
in
that
config
TS
is
add
the
examples
so
like
in
the
name
it
would
be
whatever
the
name
is
in
the
package.
Json
that
you're
copying
from
the
destination
path
is
where
we
end
up
putting
it
into
the
merge.
So
we
could
create
an
examples
folder.
So
we
double
the
examples
into
into
an
examples.
Folder
Source
path
is
like
Auto,
merge,
Dash
yeah,
so
Auto
Dash
merge
slash
and
if
it's
coming
from
the
JS
repo,
it's
JS,
that's
chemical
contribute
reports,
contrib
and
then
it's
wherever
it
lives.
B
In
those
the
bundle
name,
bundle
name,
space
are
used
for
creating
the
UMD
and
the
resulting
JavaScript
bundle
names.
So
bundle
name
is
the
JS
file.
Name,
bundle
name
spaces,
the
namespace
it
uses
within
the
UMD
for
that
and
then,
if
it
doesn't
work
with
all
tests,
I've
got
switches
there
to
say
you
can
say
no
worker
tests,
no
node
tests.
No,
you
know
no
tests.
If
you
don't
want
to
bring
any
tests
at
all
and
that
drives
how
it
creates
the
and
the
karma
definitions.
B
B
A
Okay,
all
right,
we
can
end
here.