►
From YouTube: Open Tracing Monthly Meeting 10.9.17
Description
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
B
Yeah,
oh
definitely
planning
once
the
the
sort
of
context
propagation
API,
stuff
escalate.
The
deck
I
would
love
to
putting
a
lot
more
focus
on
documentation,
onboarding
and
then
local
meetups
people
who
are
specifically
interested
in
tracing,
getting
together
having
birds
of
a
feather
session
and
doing
these
workshops.
I
think
that'd
be
really
great,
especially
since
we've
got
such
a
great
community.
That's
kind
of
spread
out
we're
not
just
in
the
bay
right
where
you
know
all
over
the
world.
So
there's
a
lot
of
opportunity
to
start
running
some
meetups
and
things.
B
C
Sorry,
I
missed
the
update,
I
mean
I,
think
it
went
well,
I
mean
people
were
engaged,
but
many
people
were
not.
Experts
and
tracing
like
like
I
think
two-thirds
have
never
heard
that
workshop.
So
I'm
happy
that
we
finished
a
tutorials
like
there's
one
language
technologies,
steel
painting,
there
is
a
PR
but
yeah
going
forward.
I
think
this
this
the
set
of
tutorials
gives
us
a
good
like
foundation
to
actually
run
this
and
like
we
can.
We
can
have
a
lot
more
people
running
them.
Awesome.
B
C
Yeah,
that's
why
I
think
you
know
after
OS
con
when
we
we
had
this
like
a
list
of
things,
people
can
do
from
easy
to
advanced
and
we
realized
that
most
of
them
are
going
to
be
very
new
to
that.
So
my
tutorials
are
very
basic.
There's
like
it's
essentially
world,
which,
instead
in
tutorial
three
splits
it
into
like
microservices
but
one-line
microservices.
So
it
is
just
pure
illustration
of
some
of
the
most
basic
topics.
B
B
Alright,
going
down
the
list
spins
from
light
step,
gave
a
talk.
It's
strange
loop,
pretty
good
to
talk,
not
super
specifically
open
tracing,
but
some
discussion
about
sampling
and
things
that
I
think
people
might
find
interesting,
so
threw
it
on
the
list
and
then
I
think
the
next
a
big
a
coming
conference
tonight.
No,
that
is
a
good
con
answer,
definite
right
to
have
a
strong
presence
there
and
will
be
definitely
giving
another
workshop
and
I
forget.
Where
is
that
kook
on?
Do
you
remember
been
in
December
yeah.
A
A
So
yesterday,
like
orbits
and
I,
don't
know
I
can't
even
remember
but
they're
like
six
or
seven
travel
related
brands
that
are
part
of
the
Expedia
and
they
have
an
internal
like
international
conference
for
their
own
company,
that's
also
in
Austin
and
on
November
1st.
They
were
asking
for
like
a
keynote
about
racing
I.
Just
can't
do
it
completely,
but
if
someone
here
thinks
that
sounds
like
a
great
opportunity
to
send
me
a
note
or
something
I
think
it
would
be
cool
to
kind
of
spread.
A
B
B
B
D
We
have
quite
a
large
contingent.
My
name
is
Erica
I'm,
the
person
being
added,
and
that's
back
as
the
representative
to
show
up
on
these
calls
and
chat
with
y'all
we're
pretty
excited
to
participate
I.
We
also
have
Chris,
Wildmon
and
Matt
we're
on
the
line
as
well.
We're
all
really
interested
in
this
project
and
eager
to
learn
what
you're
all
y'all
are
talking
about
and
yeah.
Thanks
for
having
us
no.
B
We
tend
to
try
if
it
starts
to
turn
into
a
date
on
the
call,
rather
than
try
to
debate
things
out
in
this
setting,
because
it's
kind
of
awkward
we
try
to
just
schedule
a
time
or
a
place
for
people
to
continue
that
get
a
github
issue.
So
that's
how
they
tend
to
go
yeah
and
feel
free
to
add
anything
to
the
the
meeting.
Oats
and
there'll
be
chance
to
the
end.
Anything
up.
Do
you
want.
B
B
Alright,
so
the
next
bit
around
stable,
unstable
release,
structure,
so
I
added
this
in
here
I
would
like
to
kind
of
formalize
this
in
a
real
doc
at
some
point.
But
this
is
just
sort
of
an
update
around
the
direction
the
Java
API
has
been
going
so
prior
prior
API
changes,
sort
of
took
the
form
of
a
very
large
PR
and
then
a
very
large
discussion
on
that
PR
and
it
sort
of
felt
with
the
last
version
of
the
API.
B
They're
having
a
tracer
who's
actually
bind
to
the
API
and
then
sort
of
port
the
instrumentation
over
and
really
try
to
exercise
that,
and
so
we
issued
a
release
candidate
for
the
newest,
Java,
API
and
people
started
to
bind
to
that
last
week
and
I
feel
like
already
that's,
that's
made
a
large
difference.
We
very
quickly
encountered
a
bunch
of
different
interesting
pieces
of
instrumentation,
where
we
were
wondering
whether
the
new
simplified
API
was
going
to
be
good
enough.
B
So
so
far
it
seems
to
be
fine
for
the
intended
purposes
that
we
were
looking
for,
so
that
that's
going
well,
but
just
sorry
I
kind
of
drifted
into
talking
about
Java,
but
just
just
to
keep
on
this
sort
of
structure.
Does
anyone
have
any
comments
on
this
at
the
time
or
seen
just
from
what
we've
been
doing
with
Java?
Does
this
feel
like
a
good
or
a
bad
direction
that
we're
going,
because
it
feels
good
to
me,
but
I
would
love
to
hear
feedback
from
other
people
on
moving
to
this
new
approach.
B
E
B
A
My
kind
of
orthodoxy
from
development
software-
just
you
know
internally,
would
be
that
master
should
generally
be
the
place
where
you
know:
you're
not
gonna
commit
stuff,
that's
not
tested,
and
so
on,
but,
like
master,
is
the
place
where
you
see
the
latest
code
and
then
and
then
you
know,
you've
got
release
branches
off
of
that.
When
you
had
a
release
candidate
and
then
you
would
apply
passage
the
release
candidate,
for
instance,
so
there
was
relief
and
then
that
would
be
that
and
then
you
know
now
do
that.
A
A
E
F
B
E
B
E
B
G
B
They're
moving
on
to
Java
we've
got
a
release
candidate
out
for
version
31
very
excited
about
that
excited
to
see
tracers
traces
binding
to
it
light
stuff.
We've
got
over
to
now
bound
to
it
this
week
regarding
to
port
instrumentation
over
and
I've
seen
a
couple.
Other
groups
do
the
same
thing
just
interesting
I.
Can
you
just
kind
of
maybe
go
around?
B
B
H
The
scope,
close
I
think
it's
like.
Maybe
we
should
change
that
to
to
not
close
this
material
span.
I
change
the
default
to
difficult.
Yes,
yeah!
That's
that's
good
feedback.
Yeah
there
are.
There
are
various
reasons
to
I
commented
on
the
issue
for
the
realest
candidate.
So
it
may
be
better
to
read
that.
B
Yeah
so
one
thing
we're
working
on
at
light
step:
Carlos
Alberto
who's
been
working
on
the
Java
API
is
in
the
process
of
trying
to
port
akka
to
create
some
aqua
instrumentation
against
this
API,
because
there's
been
some
concern,
in
particular
about
kind
of
async
frameworks
and
Scala
things
and
whether
they
were
going
to
be
fine
with
this
API
or
whether
they
wanted
something
more
like
continuations.
And
so
we
felt
the
need
to
get
get
more
asynchronous
stuff
instrumented.
Just
to
make
sure
that
we
painted
this
thing
correctly,
but
so
far
so
good.
B
E
B
B
B
A
Mavin
gab
had
mentioned
that
you
know
a
desire
to
capture
state
beyond
the
man
itself
when
you're
creating
a
closure,
like
you
know,
capturing
actually
things
into
a
closure
and
the
you
know
the
the
fact
that
we
don't
have
a
function
call
to
hook
into
you
makes
it
kind
of
impossible
to
do
that,
like
I
personally,
think
that's
like
sort
of
collateral
damage,
I'm
willing
to
live
with
that
if
everything
else
can
go
out
simpler,
but
to
the
best
of
my
knowledge,
like
you
know
the
ref
counting
thing
you
can
always
do
it
yourself,
but
that
piece
is
it's
harder
to
do
in
like
a
consistent
way,
unless
open
tracing
has
a
hook
to
capture
that
kind
of
state.
B
B
Yeah
and
just
to
clarify
what
BHS
is
saying:
the
there
was
an
initial
impetus
to
to
make
open
tracing
and
MDC
kind
of
worked
seamlessly.
I
believe
that's
the
specific
example
mavin
was
was
interested
in,
and
that's
really
where
that
that
capture
call
came
in
handy,
but
yeah
I
do
question
whether
that
that
just
kind
of
represented
and
overreach
like
something
that
would
have
been
great
if
open
tracing
could
come
in
and
it
sold
the
NBC
problem
and
things
like
that.
But
it
seems
like
it.
B
B
E
B
B
I
know,
there's
some
debate
about
like
time
units
and
some
other
stuff
that
maybe
people
want
to
get
in
there
and
I
know
from
talking
to
Matt
her
pick
last
night,
there
was
some
question
about
start
active
and
whether,
like
you
know
that
could
go
back
to
being
start
or
something
like
that.
I
don't
know
if
we
can
tackle
that
or
not,
but
there's
an
opportunity
to
do
a
little
bit
of
cleanup
to
the
API
people
want
to
do
it.
B
D
A
I
think
like
the
akka
thing,
is
a
perfect
example
of
that
and
I
think
if
we
can
prove
to
ourselves.
Well,
actually
that's
the
wrong
word
if
we
can
give
ourselves
confidence
that,
even
in
these
situations,
where
there
is
a
lot
of
asynchrony
and
we're
like
the
complexity
of
the
previous
API
might
have
had
some
real
leverage
like.
If
we
could
convince
ourselves,
it
wasn't
necessary.
Then
then
it
becomes
a
matter
of
just
software.
Engineering
I
think
right
now.
E
A
B
And
it's
like
Pavel's
mentioned
in
the
comments:
yeah
acha
vertex
things
that
potentially
are
boundary-pushing.
B
We
wanna
make
sure
we
we've
attacked
some
of
those
but
I'm
also
confident
and
as
the
people
who
were
kind
of
from
the
scala,
a
background.
I
then
I
can't
remember
his
last
name,
but
people
who
were
working
on
on
you
know
instrumenting
that
stuff
professionally
were
some
of
the
people
who
are
advocating
to
get
rid
of
the
continuations
and
go
to
something
more
like
scope.
So
that's
also
something
that
gives
me
like
faith
that
this
is.
B
This
is
something
that
works
when
instrumenting
that
stuff,
even
the
people
who
do
it
professionally
we're
kind
of
advocating
for,
but
maybe
what
we
should
do
is
because
we
are
already
getting
asked
in
getter
in
other
places.
For
for
some
kind
of
timeline,
we
can
make
a
commitment
to
try
to
have
everything
wrapped
up
in
a
month
and
then
at
the
next
ot
SC
meeting
call
agreed
to
pull
the
trigger.
Does
that
sound
like
a
good
check-in
point
to
people.
A
A
E
B
B
That's
that
Friday
would
be
two
weeks
from
now
or
something
that
week,
maybe
starting
that
Wednesday
the
18th
and
get
er.
We
can
start
making
announcements
on
that
day
to
kind
of
get
a
sense
of
where
people
are
at
and
maybe
have
a
target.
If
people
can
try
to
feel
like
they
have
everything
they
would
need
to
launch
by
the
20th.
B
B
All
right,
we
can
always
come
back
to
the
at
the
end.
If
someone
thinks
to
something
so
moving
out.
The
ecosystem
updates
something
I've
been
working
on
with
Ryan
Byrne
who's
holding
down
the
kind
of
API
has
been
instrumenting
proxies
and
getting
open
tracing
into
engine,
X
and
envoy
and
proxy,
and
trying
to
figure
out
what
the
best
strategy
is
there
and
we
have
in
genetics
instrumented
with
the
open
tracing
we
hadn't
brought
it
over
to
ot
contribute
because
we
were
still
working
on
on
what
the
sort
of
linking
model
should
look
like.
B
B
We'd
prefer
a
model
where
you
know
you
can
have
a
sort
of
open,
trace
and
compliant
engine
X
release
as
a
binary
people
can
tank
and
just
like
link
it
to
the
tracer
that
they
want
to
use,
and
so,
while
we're
in
the
process
of
that,
we
posted
on
the
engine,
X
mailing
list
and
then
kubernetes
scooped
it
up
and
brought
it
into
ingress.
To
start
editing
at
least
Zipkin
looks
like
they've
compiled
Zipkin
in,
and
so
that
was
pretty
pretty
great
to
see.
B
That's
alright,
so
anyways
long
story,
short
we've
started,
adding
open
tracing
to
engine
X
and
proxies,
and
it
almost
immediately
got
picked
up
as
soon
as
we
posted
to
the
mailing
list
for
people
to
check
it
out
and
got
added,
at
least
in
some
experimental
forms
to
kubernetes
ingress.
So
that
was
a
great
win
that
kind
of
came
out
of
the
blue.
A
I
mean
I
spent
I,
don't
know,
cumulatively
about
ninety
minutes
talking
with
them
about
it,
and
they
they
were
interested
in
not
really
understanding
like
the
type
of
thing
that
a
tracing
system
does
like
they.
So
kubernetes
like
this
giant
state
machine
and
the
individual
requests
that
come
in
and
modify
the
state
machine
happen
quickly
like
it's.
You
know
that
wasn't
latency
in
that
regard,
and
even
what
was
happening
wasn't
that
interesting.
But
then
the
state
machine
end
up
triggering
you
know.
A
Well
the
state
machine
so
like
triggers
this
like
massive
amount
of
activity,
and
it's
that
massive
amount
of
activities
really
what
they
wanted
to
model
and
I
think
that
they
did
recognize
that
it
would
be
possible
with
sufficient
effort
to
model
that
using
open
tracing
primitives
or
something
like
that.
It
was
like
a
true
dag,
not
like
a
sort
of
yeah
I
know
what
I
x
rays
thumbs
up,
but
I
think
the
concern
that
kubernetes
had
was
that,
like
they
weren't
going
to
be
able
to
use
like
really
anything
that
they
are
aware
of.
A
The
goals
they
had,
analytically,
it
wasn't
like
Stan
latency
analysis.
It
was
almost
more
like
debugging,
this,
like
fairly
complicated
state
machine,
so
I
think
they
decided
to
go.
I
didn't
I,
didn't
read
the
proposal
in
a
detail,
but
they
wrote
this
like
kubernetes
advance
proposal
was
just
really
just
a
way
of
like
describing
state
transitions
and
all
the
events
that
take
place
and
then
building
their
own
like
totally
ad-hoc,
analytics
tool
to
understand
debug
when
kubernetes
doesn't
do
the
right
thing,
which
I
can
actually
think
might
make
a
lot
of
sense.
A
A
Around
that,
it's
just
like
what
happens
afterwards.
So
that's.
Why,
like
they
had
this
PR
and
the
guy
who's
doing
it
was
like
yeah,
we
could
easily
add
up
and
tracing
or
whatever,
to
like
model
the
latency
of
those
actual
like
the
initial
request
that
comes
in,
but
that's
not
what
their
concern
was.
I,
don't
know
that
that
helps
you
understand
where
they're
coming
from.
G
B
You
know:
kubernetes
like
deployment
topology
and
stuff
like
that.
So
that's
that's
the
place
where
I
see
it
this
useful
and
that's
why
I
got
totally
surprised.
It's
been
put
into
ingress,
but
I
do
plan
on
following
up
with
them
now
to
kind
of
figure
out
how
we're
gonna
expand
that
offering
because
I
think
right
now,
it's
just
sort
of
hardwired
to
Zipkin.
Obviously,
if
it's
open
tracing,
we
want
people
to
be
able
to
plug
it
in
whatever.
A
A
One
where
I
think
there
is
actually
a
great
deal
of
interest
in
using
open
tracing
and
actually
a
great
deal
of
intent,
he's
open
tracing
for
that
and
their
conversations
even
placed
like
make
that
happen.
But
I
should
just
be
clear.
That
was
the
tumor
of
these
developers.
Understanding
kubernetes
is
where
they
wanted
to
do
something
that
was
bespoke.
F
A
F
G
A
B
A
E
A
Done
anyway,
aren't
we
yeah
we're
very
close,
I
I
do
think
this
next
thing
is
sort
of
interesting
I
actually
had
a
question
for
people
about
it.
So
if
you
haven't,
you
should
look
at
the
trace
context,
github
organization
and
the
trace
context,
pack,
repo.
Just
the
only
thing.
That's
in
there,
it's
it's
not
a
formally
part
of,
but
it's
it's
sort
of
a
suit
of
the
open
census.
Work
that's
being
led
by
bogdan,
drew
to
it
at
google
and
adrian
and
yuri
and
many
others
have
been
participating
a
lot
in
it.
A
The
stated
goal
is
to
standardize
on
not
the
way
that
spins
are
described
or
serialized,
but
the
way
that,
like
context,
data
is
sent
over
the
wire
between
processes.
So
the
starting
point
was
a
standard
way
to
send
trace
context
data
over
HTTP
and
it
there
are
like
a
number
of
like
kind
of
what
I
would
describe
as
like
syntactic
issues
that
have
come
up
like
just
how
to
represent
a
given
64-bit
number.
Then
there
are
a
number
of
like
sort
of
like
not
super
complicated
but
still
problematic.
A
Semantic
issues
like
how
wide
should
have
trace
ID
be
like
how
many
bits
for
the
beach
to
be
variable
length
that
sort
of
thing.
And
then
there
are
a
number
of
much
like
bigger-picture
semantic
questions
like
the
there's,
some
folks
on
Microsoft's
who
are
chiming
in
and
they
have.
They
actually
passed
a
lot
of
like
path.
A
There's
one
thing
to
like
decode
the
bits.
But
then,
if
you
are
participating
the
trace,
you
have
to
be
able
to.
You
know
at
some
at
some
way.
You
have
field
like
create
a
span
and
to
do
that
like
if,
if
there's
a
bunch
of
like
tracing,
trace
or
specific
semantics
that
are
encoded
into
like
the
context,
information
I'm
unclear
on
on
like
how
this
thing
guarantees
any
sort
of
interoperability,
because
you'd
still
need
to
be
able
to
like.
A
At
that
point
where
you
might
be
better
off
just
saying
the
context
is
in
a
given
place
and
it
has
like
a
given
like
basically
for
encoding,
but
it's
just
a
blob,
and
then
you
pass
this
blob
off
to
the
tracer
and
let
it
do
what
it
needs
to
do
for
creating
spans
and
so
on
and
I'm,
like
I'm,
just
like
confused
at
what
the
purpose
of
it
I
think
I'm.
Maybe
this
isn't
the
right
place
to
bring
it
up,
but
I
mean
I.
A
I
can
ask
on
that
repo
as
well,
but
I
think
they're,
making
very
upset
so
like
for
people
have
been
participating
on
it.
Does
anyone
understand
like
what
what
the
end
goal
is
like?
What
Interop
are
we
actually
trying
to
achieve?
I
guess,
I'm
sort
of
asking
URIs
I
think
you've
been
spending
a
lot
of
time
in
it,
but
I
don't
get
that
I.
C
Think
there
is
one
use
case,
which
is
they
have
in
mind,
but
it
simply
it
kind
of
presumes
that
the
tracing
systems
are
very
similar
in
how
they
create
spans
and
and
the
use
case,
imagine
that
there
is
no
open
tracing
API
for
Java
right
and
so,
but
but
it
exists
for
go
and
other
languages,
and
so
we
have
Jaeger
and
all
other
languages,
but
nothing
in
Java
and
then,
but
in
Java.
You
have
this
big
echo
system
already
covered
by
Zipkin,
so
that's
I
think
the
use
case.
They
can
say.
C
Okay
well
I
already
have
my
spring
integrator
too,
as
it
can
with
sleuth,
whatever
the
libraries
are.
So
why
can't?
They
just
use
that
with
all
instrumentation,
that
Jaeger
has
another
languages
rightist
and
then
because,
especially
because
you
can
you
make
an
assumption
that
once
you
collect
the
spans
from
Zipkin,
you
can
still
kinda
send
them
to
Jaeger,
for
or
vice
versa,
like
to
one
tracing
system
in
the
back,
which
is
what
Zipkin
does.
Let's
say
with
with
with
step
drive
right.
A
That
the
the
tracer
is
job
within
a
process
is
to
take
these
things
coming
in
over
the
wire
and
then
send
a
bunch
of
data
out
in
some
standards.
So
like
there
needs
to
be
a
parent
in
between.
Like
did
have
interrupt.
You
need
to
both
have
standardization
of
this
and
of
an
out-of-band
format
like
the
Zipkin
format
that
sent
a
sack
driver,
or
this
doesn't
make
sense,
is
that
is
that
fair,
just
like
otherwise.
E
A
C
I
think
for
that
use
case
you
need
goes
and
I
guess,
there's
also
another
use
case,
which
is
has
to
do
with
the
X
rays.
So
if
you
have
your
a
bunch
of
your
own
services,
runyan
with
your
own
tracing
system,
but
then
at
some
point
you
might
cause
into
costed
services
like
Amazon,
let's
say
and
they
create
their
own
tracing.
So
this
is
another
use
case
for
Interop.
A
C
A
B
A
Yeah
there's
been
like
some
sort
of
informal
conversation,
just
people
working
on
envoy
and
a
certain
assent,
sto
sort
of
like
along
the
lines
of
what
I
was
describing
and
discussing
I.
Think
there's
like
one
world
where
you're
focused
or
one
frame
of
mind
where
you're
focused
on
the
use
case,
where
you
have
like
a
single
tracing
system.
That's
observing
you
know
an
entire
distributed
system
and
then
another
world
where
you
expect
to
have
multiple
that
are,
you
know,
observing
pieces
of
a
system
and
then
correlating
in
some
way.
A
I
think
that
the
the
flavor
of
the
discussion
in
the
sto
conversation
is
more
focused
on
the
mode
where
you
have
a
single
trace
in
system,
observing
everything,
at
least
within
the
scope
of
sto
or
an
sto
deployment,
which
is
probably
a
fair
assumption,
given
the
nature
of
that
technology.
So
they
were
pursuing
something
that
well
the
sign
of
a
something
that
was
considerably
simpler
than
what's
happening
in
the
trace
context.
Organization
and
I
was
actually
supposed
to
have
a
drink
last
night
with
Bogdan
from
Oh
consensus.
A
To
discuss
this
exact
topic
because
I
don't
want
to
see
happen
is
like
I.
Don't
want
there
to
be
a
bunch
of
unnecessary
churn
between
like
the
open
census
project,
the
trace
context,
project
and
open
tracing
I
would
actually
prefer
I,
don't
really
care
where
it
lives,
but
it'd
be
nice.
If
there's
only
one
effort
going
on
in
this
area,
but
I
feel
that
their
requirements
pulling
from
like
the
sto
world
that
are
a
lot
different
than
the
requirements
that
you're
a
just
outline.
A
To
to
try
and
like
sort
out
a
way
of
moving
forward
as
this
stuff,
so
that
we
we
don't
have
like
a
bunch
of
partially
overlapping
projects
like
I,
think
there's
a
way
to
have
these
different
efforts
just
be
like
nested.
If
that
makes
sense,
so
we
can
have
like
a
standard
at
one
layer
of
the
spec
and
then
a
standard,
a
layer
deeper.
A
If
you
want
to
get
into
like
how
you
extract
a
correlation,
ID
or
whatever
so
I'm
gonna,
try
and
make
some
progress
on
that
and-
and
it
probably
won't
be
on
github
just
because
that's
just
like
such
in
my
mind,
actually
very,
like
time-consuming
place
to
try
and
discuss
like
high-level
stuff,
but
but
I
I
will
try
to
report
back.
If,
if
we
make
any
progress
on
that
stuff.
B
Awesome
thanks:
I
was
too
lazy
to
sign
back
in
since
we're
almost
done
and
I
wanted
to
hear
the
conversation
apologizing
if
I
still
sound
like
a
robot,
but
we've
looks
like
we've
gotten
to
the
end
of
the
established
agenda.
We
still
have
a
couple
minutes
left.
If
anyone
has
any
final
words
say
we
want
to
say
or
any
final
topics
you
want
to
bring
up
so
one
round
of
death
going
once.
A
It's
like
a
totally
you
know
thing,
but
you
know
in
previous
to
this
meeting.
We
actually
had
a
calendar,
invite
that
had
individual
people
added
to
it,
and
then
we
switched
this
model
where
there's
like
this
link
for
a
calendar
that
you
can
overlay
on
your
calendar
and
I
noticed
that
when
we
had
the
calendar,
invite
we
had
like
five
or
six
people
from
the
companies
that
are
in
the
industrial
advisory
side
of
this
who
dialed
in
and
today,
I
think
if
I'm
I
think
we
have
close
to
zero.
A
So
maybe
I'm
not
reading
the
user
names
correctly.
So
I
think
that
there's
some
like
signal
loss
by
having
this
calendar
that
you
have
to
add
to
your
calendar
and
realize
that
it's
not
like
your
normal
work,
calendar
that's
been
invited
and
so
on.
So
I
I
might
kind
of
combine
this
by
actually
explicitly
inviting
people
as
well
yeah.
B
A
Yeah,
totally
and
I
would
say
that
the
the
I
don't
think
anyone,
even
the
ISTE
of
folks,
would
argue
about
that.
I
think
everyone's,
like
violent
agreement
that
like
having
a
standard
place
from
just
like
literally
naming
the
header
and
like
having
enough
information
that,
at
the
very
least
you
could
pass
it
through.
You.
A
Maybe
you
don't
do
anything
else
when
you
pass
it
through,
everyone
I
think,
think.
That's
a
really
good
idea.
The
question
is
like
how
how
much
agreement
we
need
to
have
about
the
innards
of
that
blob
like
like
the
minimal
thing,
is
like
literally
no
agreement.
It's
just
like
a
version
bit
and
a
blob.
Then
there's
like
you,
have
a
correlation,
ID
and
then
there's
you
have
a
correlation,
ID
and
all
this
other
stuff,
and
that's
I.
Think
where
that,
where
the
debate
like
in
terms
of
scoping
comes
out,
does
that
make
sense
right.
E
So
the
other
thing
that
I'm
wondering
if
we
could
get
some
benefit
out
of
this
is
having
like,
and
so
at
least
in
the
the
Java
space.
There's,
not
really
a
good
standardized
standardized
system
for
context
within
a
request.
So
maybe
that
could
be
a
potential
standard
that
could
come
out
of
this.
That
frameworks
could
adopt
as
a
way
of
like
building
out
that
context,
a
little
bit
better.
Other
systems
like
I,
think
dotnet
have
that
already
in
place
at
the
language
level.