►
From YouTube: 2021-02-18 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Hello,
we'll
take
we'll
give
it.
B
A
C
E
E
C
Yeah,
I
can
do
my
best,
but
I'm
still
about
to
or
currently
figuring
it
out
myself.
I
mean
I
know
how
to
integrate
with
telemetry,
but
he
wrote
a
lot
of
those
bridge
libraries
that
exist
right.
C
C
I
haven't
heard
from
vince
recently,
but
I've
had
good
success
using
his
cowboy
telemetry
integration
as
much
success
as
you
can
expect,
but
we've
seen
a
lot
of
weird
edge
cases,
but
we
did
get
things
working.
C
It's
like,
I
keep
telling
people
to
go,
use
it,
but
I
I've
only
barely
used
it
myself.
A
C
D
C
Have
to
maintain
open
telemetry.
Why
would
we
do
that?
So
it's
like
what?
What
is
it
really
going
to
give
you
that
we
couldn't
just
build
into
open
telemetry
other
than
not
making
people
change
stuff
which
right
it
shouldn't
be
that
big
of
a
change
anyway?
It's
like
you
probably
have
to
grab
your
code
base
and
be
like.
You
know
here
we're
using
spandex
tracer,
and
we
need
to
figure
out
how
to
replace
it
without
the
telemetries
or
macros
and
stuff.
A
A
Yeah
I
mean
I'd
like
I
mean
just
sort
of
get
a
feeling
for
what
people
might
be
expecting
make
sure
our
api
covers
the
cases.
Possibly,
we
could
create
a
document
about
migration.
C
Yeah
I
was
planning
on
eventually
doing
that
because
I
think
that's
that's
where
the
decision
comes
down.
If
we
don't
keep
maintaining
spandex
forever
as
like
a
bridge
into
open
telemetry,
then
we
need
a
migration
path
that
people
can
follow,
which
I
don't
think
it
should
be
that
bad.
But
I
have
a
lot
of
tooling
outside
of
spandex
that
we
use
with
spandex.
So
maybe
I'm
just
jaded.
A
All
right
yeah,
so
we
can
start
on
the
actual
agenda.
The
first
thing
is
my
dog
wants
to
go
out.
First
thing
is
the
the
0.6
has
been
out,
and
I
think
it's
essentially
our
for
a
sort
of
release
candidate
for
1.0,
because
it
covers
the
1.0
tracing
spec.
D
A
D
D
A
Yeah
I'll,
probably
just
link
yeah
yeah,
it's
just
yeah
brian
reached
out
asking
to
get
something.
A
A
You
could
try
to
ask
greg,
I
think
your
questions
gustavo.
D
And
things
like
that
over
the
weekend
I
was
upgrading,
I
created
a
new
library
and
was
upgrading
from
0.4
to
0.6
and
during
that
migration,
some
of
the
handlers
we
wrote
didn't
work
anymore
and
since
there
is
no
no
dogs
or
or
guides,
or
things
like
that
and
I
had
to
go
to
the
code
base,
read
a
little
bit
and
things
like
that.
It
was
okay
for
me
because
I
I
contributed.
D
D
I
have
to
wrap
around
the
open
telemetry
start
span
in
in
spam
to
track
the
parent,
because,
right
now
we
don't
track
the
parent,
it's
okay.
When
we
think
about
application
code,
we
can
use
the
width
span
and
it
will.
It
will
work
greatly.
D
But
when
you
look
at
telemetry
handlers
and
third-party
libraries
and
we
would
have
to
track
the
parents
in
some
cases,
so
I
want
to
know
if
you
how
you
approach,
we
will
approach
that
we
will.
We
create
a
new
function
on
opening
telemetry,
that
explicitly
strikes
the
parents
to
be
using
telemetry
handlers
or
just
let
instrumentation
library
maintainers.
Do
they
their
own.
C
D
Yeah
so
there's
two
main
cases
for
telemetry
handlers
and
one
of
them
you
create
a
hood
spam.
So
there's
no
need
to
track
parents
because
there
is
no
parent,
but
others.
They
are
not
hood
spam,
for
example,
ecto
telemetry
handlers.
You
won't
create
a
hood
spam.
It's
most
likely
will
be
a
child
spam
and
things
like
tesla
telemetry.
It
will
also
be
a
child's
pain
in
those
cases.
You'll
have
to
attract
parents.
A
Well,
in
the
tesla
case,
there's
it
needs
to
or
should
probably
be
a
middleware
instead
of
I
don't
know
how
it
will
use
the
telemetry
events
for
spans,
because
it
also
needs
to
update
headers,
and
I
think
that
would
require
a
middleware.
But
I
don't
know
I
don't
remember
how
middlewares
are
called.
So
I
don't
know
if
with
span
will
be
an
option
for
a
telemetry
middleware
tesla
middleware.
D
D
A
D
A
But
yeah
first
up
like
obon
one
question
I
had
with
the
so
spandex
every
time
you
started
a
trace,
it
put
it
into
a
list
in
the
process
dictionary
or
something.
C
Yeah,
so
the
way
spandex
works
is
the
entire
trace
itself
is
in
the
process
dictionary
so
like
there
is
no
table
anywhere
else
that
that
they're
referring
to
so
it
it
makes
things
annoying
sometimes,
but
it
makes
it
very
easy
in
the
general
case
of
like
each
trace
only
exists
in
a
process,
one
process,
and
if
you
want
to
propagate
it
between
processes,
it's
annoying,
but
you
just
do
regular
context
propagation
between
the
processes.
However,
you
need
to
do
that
and
then,
like
the
child
process,
for
example,
would
just
have
its
own
trace.
A
C
So
so
in
spandex,
like
a
trace,
is
the
overall
like
trace
and
then
each
span
is
can
be
a
child
of
apparent
span.
But
it's
all
in
one
trace
id,
and
so
each
span
knows
what
its
parent
span
is,
and
it
knows
what
trace
it's
in
so
to
make
a
child
span,
you
just
like
start
span
and
span,
and
it
just
it
just
pushes
it
onto
the
stack.
C
Yeah
right
it
marks
yeah,
it
marks
it
as
finished
and
then
it's
not
at
the
top
of
the
stack
anymore.
Okay,.
C
So
like
in,
I
guess
in
spandex
the
way
that
we
track
parents
is
that
there's
a
stack
in
the
current
process,
dictionary
of
the
of
the
traces
and
spans
well,
there's
only
one
trace
but
yeah
all
the
spans.
C
But
you
could
like,
we
also
have
an
api
where
you
can
get
what
the
current
trace
and
span
ids
are,
and
you
can
just
set
the
parent
on
any
span
with
whatever
you
want
right.
It
doesn't
like
it
doesn't
validate
or
make
sure
that
it's
you
know
correct.
A
A
Well,
no,
you
you
can.
If
you
use
one
there's
two
things
you
can
one
you
can
set
the
current
active
span
which
sets
it
in
the
process
dictionary,
but
there's
no
tracking
of
what
the
parent
was.
It
just
sets.
What
the
active
one
is.
Oh.
A
Stack
number
of
libraries
have
some
form
of
that
in
erlang
and
elixir,
and
it's
just,
I
felt
it
was
much
more
complicated
in
the
end,
even
though
it
feels
at
first
like
it's
simpler,
because
you
don't
really
know
what
span
you're
ending
when
you
call
finished
spinning
the
in
this.
But
this
way
with
the
lowest
level
api.
There's
no
issue
of
that
something
can
be
built
on
top
of
it.
I
don't
know
whether
or
not
we
should
include
it
it's
possible,
I
mean.
A
Maybe
it
should
be,
there's
the
option
of
an
open,
telemetry,
telemetry
library
that
provides
this
useful.
This
stack
of
spans
that
you
can
so.
A
Higher
level
tracking
for
you,
like
the
other
ones,
do.
D
A
Yeah
it's
yeah,
I
mean,
but
if
we're
expecting
people
to
I
mean
if
we
were
just
expecting,
you
know
certain
library,
core
libraries
like
ecto
obon,
all
those
phoenix
to
do
this
that'd
be
one
thing.
But
if
we're
expecting
people
to
instrument
their
code
with
telemetry
and
then
hook
it
up
to
open
telemetry,
so
every
library
almost
doing
that,
we
should
probably
put
that
in
a
in
a
helper
library,
at
least.
C
I
I
do
wonder
whether
there's
something
in
like
the
telemetry,
the
telemetry
api
itself,
has
a
has
like
a
span
function
or
a
macro.
I
think
that
you
can
call
and
it
does
the
the
try
catch
and
emitting
the
events
and
stuff.
I
wonder
if
there's
some
way
that
we
could
integrate
with
that.
That
would
give
you
the
hooks
you
need
to
to
do
the
steps
I
mean
because,
like
it
already,
it
already
has
the
three-point
step
where
it
starts
and
stops
and
exceptions
and
stuff.
B
Yeah,
I
mean
that's
the
problem,
though,
like
we're
talking
about
like
we
keep
talking
about
things
that
are
like
rappable
and
like
a
particular
thing
and
when
it
comes
to
using
the
telemetry
hooks
like
nothing
is
rappable
and
it's
the
same
thing.
It's
the
exact
same
issue
in
plug
like
if
you
were
to
write
a
plug
thing
like
the
on
the
whatever
it
is
like
the
the
force
end
and
the
first
part
of
it
like
that's,
not
something
that
you
could
like
wrap,
because
it's
called
in
two
separate
complete
functions.
B
B
Do
this
manually,
like
grabbing
with
contacts
and
passing
around
and
keeping
track
of
things
which
to
me
should
be
the
exception,
because
I
feel,
like
that's
a
much
more
rare
thing
that
happens
than
the
default
of
like
start
and
stop,
because
if
somebody
didn't
even
like
go
in
and
look
in
with
fans
if
they
like,
if
I
was
coming
from
hotel
like
to
the
stylist
point
like,
and
I
just
saw
like
star
span
and
span
like
it,
just
it
wouldn't
work,
it
would
like
automatically
break
right
like
unless
I
do.
The
width
span,
part
of.
A
A
C
Yeah,
I
don't
know
why,
but
I
feel
like
people
expect
that
it
will
do
the
magic
stuff
like.
I
don't
think
they
expect
it
to
be
a
functional
pattern
when
they
see
the
start
span.
They're,
like
oh
cool,
the
span
has
started
now
and
then
they
just
do
their
thing
and
then
they're
like
and
span
wait.
What
do
I?
How
do
I?
What
am
I
supposed
to
pass
into
this
yeah,
which
is
not
anything
against
the
way
that
it's
implemented?
It's
just
like
yeah,.
A
D
I
think
that
we
can
assume
that
people
who
need
starting
in
spain
will
be
instrumentation
library,
maintainers
and
everyone
else
will
likely
use
with
spam.
We
can
document
as
such
saying
that.
Okay,
if
you
want
to
use
start
spam,
be
sure
that
you
need
to
use
thread
span
and
then
spam,
if
you
don't
need
use
with
stream,
but.
B
So
I
think
the
one
thing
I
would
throw
out
real
quick,
because
that
was
on
the
code
that
you
posted,
like
it
only
works
if
you're
one
telemetry
handbook
beat
because
we're
setting
to
like
a
generic
key.
So
like
my
concern,
is
really
around
the
fact
that,
like
if
I,
if
we
have
to
start
a
span
and
then
like
we
have
to
then
like
have
some,
you
essentially
need
a
unique
id
or
a
stack
of
ids
to
name
space
to
be
able
to
unders.
B
A
You
could
do
it
the
way
that
0.4
did
it,
which
is
just
a
two
tuple,
so
you
have
the
the
first
element
in
the
tuple
is
the
current
span.
The
second
element
is
the
previous
context,
context,
which
is
also
a
two
tuple
unless
it's
undefined.
So
then
it's
just
keeps
going
back,
so
you
pop
it.
You
go
to
the
next
two
tuple
unless
it's
undefined
and
then
that
means
you're
at
the
root
but
yeah.
It's
basically
just
a.
A
A
A
This
open,
telemetry
spec,
which
I
came
to
to
think,
was
you
know
much
better
because
it's
lower
level
because
you're
not
doing
it
for
everybody,
but
it
doesn't
have
those
corner
cases
if
you
just
use
with
spam,
so
it
just
felt
safer
and
that
you
can
build
on
top
of
it
with
something
like
tracking
it.
As
a
tuple
of
a
tree
of
spans.
C
Does
does
open
telemetry
have
a
concept
of
like
including
conveniences
in
your
library
they're,
not
part
of
the
spec.
It
seems
like
that's
that's
dangerous
ground,
but
I
wonder
if
that's
like,
because,
like
from
a
user
from
a
user
standpoint
right,
like
you,
don't
want
to
tell
them,
you
have
to
include
an
open
telemetry
library
and
then,
if
you
want
to
be
easy
to
use,
you
also
need
this
one
right
like
that's,
not
a
good
experience
for
people.
C
D
C
People
are
going
to
get
confused
that
they
need
to
write
telemetry
events
in
their
app
and
that's
just
like
so
much
wasted
effort
and
it's
not
as
easy
to
do
it
that
way.
Yeah.
B
A
C
If
you
made
an
api
that
like
became
the
the
unofficial
official
api,
that
people
actually
use,
then
it's
like
now
you
have
to
maintain
that
and
maybe
it
won't
be
compatible
with
future
open,
telemetry
or
something
weird.
C
A
A
Well,
that
span
exists
outside
of
it.
It
doesn't
and
there's
no
yeah.
D
C
B
B
But
I
also
don't
think
like
putting
open,
I
mean
like
at
the
end
of
the
day
like
putting
open
telemetry
into
echo.
It's
not
gonna
happen
like
it's,
not
gonna
go
into
phoenix.
It's
not
gonna.
Go
enough,
though,
it's
not
going
to
go
into
the
vast
majority
of
these
libraries.
Nor
would
I
tell
them
to
so
yeah
yeah.
D
What
about
integration
telemetry
with
open
telemetry,
so
we
suggest
that
pass
this
spam
context
here
in
the
main
metadata
for
by
default,
so
at
least
in
the
start,
having
we'll
have
a
metadata
for
respond
context
in
the
stop.
We'll
also
have
that
same
spam
context,
because
telemetry.spam
will
track
that.
For
for
us,
I
think
that's
from
the
point
of
view
of
view
of
users
would
be
the
the
cleanest
way
to
to
do
it.
We
just
integrate
telemetry
with
helping
telemetry
and
okay.
Now
library
maintainers
can
use
whatever
they
want.
D
D
A
A
I
know
I
mean
there's
other
languages
that
like
dot
net,
it's
integrated
this
stuff
into
the
core
api
because
they
can
have
so
that
in
having
a
span,
function
and
concept
in
telemetry
itself
that
didn't
have
to
use
open,
telemetry
it
just
it
could,
but
in
other
cases
it
would
do
something
different.
You
can
hook
into
it
in
some
way,
I
think
might
be
a
better
solution,
but
then
these
libraries,
where
they
have
to
switch
to
using
span
instead
of
just
outputting,
start
and
stop,
and
I
don't
even
know.
D
C
Yeah,
I
want
to
say
that
phoenix
isn't.
I
need
to
go,
look
real
quick,
but
I
I'm
pretty
sure
it
is
doing
start
stop
and
exception,
but
I
think
the
reason
is
that
the
span
the
telemetry
span-
api
doesn't
give
you
all
of
the
things
you
would
need,
like
you
can't
return
different
metadata
on
the
exception
versus
the
stop
or
whatever,
because
it
only
it
only
returns
a
certain
thing,
I'm
just
talking
too
much,
not.
A
C
I
think
it
I'm
trying
to
pull
up
the
code
here.
C
A
The
telemetry
span,
the
the
another
event-
that's
fired.
A
C
C
Use
spam
in
that
phoenix
case,
because
it's
doing
a
bunch
of
stuff
in
in
like
before
before
it
sends
the
stop
before
it
sends
the
exception.
Like
there's
some
metadata
calculations
in
there,
there
might
be
a
way
that
you
could
standardize
that
stuff
because,
like
honestly,
probably
every
app
that's
doing,
this
is
doing
the
same
things,
but
currently
it
doesn't
have
that
like
it.
Just
has
the
function
that
you
want
to
run
the
span
around.
A
Yeah,
that's
why
I
would
say
it
would
be
its.
It
would
just
fire
something
else
sort
of
like
an
event,
but
it
would
call
it
would
basically
call
with
spam
and
open
telemetry
if
you
have
that
installed
as
the
span
handler.
Otherwise.
C
A
C
A
C
C
C
E
C
I
don't
know
where
yeah
I
don't
know
if
it
would
make
sense
to
add
it
to
telemetry
or
or
just
to
otp
itself,
somehow
or
the
runtime,
but
that's
what
I'm
kind
of
thinking
is.
Maybe
it
needs
to
be
built
in
at
that
level
if
we
wanted
to
to
work
in
a
generic
and
reusable
way,
because
building
building
a
decorator
like
that
is
actually
not
trivial
at
all.
C
Like
there's
a
lot
of
stuff,
you
have
to
do
at
compile
time
and
and
stuff
to
make
that
work
and
it'd
be
nice.
If
that
was
just
sort
of
a
built-in
feature,
somehow
or
at
least
if
it
was
easier
and
if
it
was
consistent,
because
I
think
part
of
the
problem
is
that
this
telemetry
span
thing
and
the
start
and
stop
span,
there's
like
so
many
things,
you
could
do
that.
C
It's
not
constrained
enough
right,
like
I
think,
it'd
be
easier
if
it
was
more
constrained
where
you
always
get
whatever
the
params
are
that
are
passed
into
that
function
as
your
metadata
and
when
it
stops,
you
always
get
whatever
the
return
value
is
you
know
like,
then,
the
library
of
maintainers
don't
have
to
decide
what
metadata
to
put
in
there.
C
But
I
do
feel
like
if
we
gave
library
authors
an
easy
way
to
just
have
a
macro
that
they
can
wrap
around
stuff.
That
would
be
better
right
because
I
think
what
we
want
is
the
width
span
macro
wrapped
around
stuff
and
then
it's
easy.
So
if
we
could
have
a
telemetry
version
of
that,
which
I
guess
is
the
span
thing,
but
it
doesn't
exactly
do
what
they
want
it
to
do,
so
they
aren't
using
it.
C
C
But
so
I
kind
of
know
how
it
works.
But
yeah
I
haven't
tried
to
use
this
fan
thing
because
I
didn't
even
know
existed.
A
Yeah-
and
I
think
we
can-
I
mean-
and
I'm
certainly
not
closing
the
door
on
the
idea
of
putting
this
in
the
open,
telemetry
api
package,
some
sort
of
another
module
that
is,
has
start
spam
that
actually
sets
it
in
a
list
in
the
process
dictionary
or
whatever.
A
B
C
Yeah,
I
think
you're
always
kind
of
just
hoping
that
it's
the
right
span
you're
ending
right,
because
if
you
get,
if,
for
whatever
reason
the
library
sends
you
two
stop
events,
you're
gonna
stop
the
wrong
one.
If
you
don't
know
what
you're
stopping
or
if
it
never
sent
you
the
start
event,
because
the
telemetry
handler
got
detached
because
it
crashed
last
time.
This
is
something
that
happened
to
me
yesterday.
C
So
it's
not
hypothetical
like
if,
if
you
crash
in
your
start
event-
and
you
had
a
different
handler
set
up
for
that,
telemetry
will
detach
that
one,
but
it
won't
detach
the
stop
event.
So
you'll
start
getting
stop
events
that
aren't
associated
with
anything
and
it'll
just
start
either
ending
the
wrong
thing
or
just
throwing
an
error
because,
like
I
don't
have
a
trace,
I
can't
stop
the
trees.
C
C
C
C
A
A
A
A
A
A
Spans
that
have
been
alive
too
long
and
just
get
rid
of
them
with
a
configurable.
This
has
been
alive
too
long
and
configurable
way
of
dealing
with
it.
You
can
have
it
actually
end
it
in
which
kit
and
set
an
attribute
like
this
timed
out
or
you
can
just
have
it
get
rid
of
it
or
you
can
have
it
end
it
with
no
attribute
so
but
yeah
there's
a
janitor.
C
C
C
A
Hopefully,
oh
yeah
yeah:
where
should
they
be
so
yeah?
I've
struggled
with
the
question
of
where
should
other
libraries
live
so
like
instrumentation
of
tesla
or
something
the
the
argument
from
the
open
telemetry
people
is
everything
should
have
to
go
through
the
cncf
sign
off
thing
where
you
sign
over
your
rights
and
that
companies
won't
use
the
libraries
unless
they
go
through
that
and
I
don't
think
that's
actually
a
problem.
In
our
case,
it's
probably
a
problem
in
java,
world
and
stuff,
but
it's
possible
that
it
could
become.
E
A
C
B
More
like
to
run
your
test,
suites
like
you,
could
have
like
massive
amounts
of
dependencies
that
would
need
to
be
downloaded
and
run
like
if
I
actually
tested
against
phoenix
instead
of
like
what
I
currently
do,
which
is.
I
literally
reconstructed
essentially
like
the
plug
con,
which
is
brittle
but
like
that
was.
The
solution
was
to
like
create
different
plug
cons
and
just
store
it
as
fixture
data.
B
C
A
B
C
A
B
B
B
A
D
C
Yeah,
I
think
less
places
to
look
is
definitely
helpful
because
right
now
I
feel
like
there
are
too
many
even
for
me
to
keep
track
when,
when
I'm
like
pretty
heavily
involved
here,
like
there's
too
many
different
github
works
and
stuff
to
go.
Look
at.
D
Yeah
my
main
motivation
for
this
question
was
exactly
that:
where
should
I,
I
contribut
contribute
back
the
library
where
I'm
creating
right
now
greg
saints
uplink,
a
library
there
is
the
open,
telemetry
bing.
I
saw
that
others
open
telemetry
special
interest
groups.
They
have
those
instrumental
instrumentation
libraries
inside
they
help
us.
So
this
question
was
more
about.
A
Yeah,
I
think,
right
now
the
open
telemetry
beam
org,
but
that
I'll
look
into
the
contrib
repo
and
if,
if
we're,
still
able,
if
we're
able
to
like
move
stuff
from
another
org
into
it
and
cover
all
the
cncf
stuff,
I
think
we
should
consider
it
just
to
have
that
checkbox
above
this
went
through.
C
Yeah,
I
think,
if
nothing
else,
we
should
at
least
have
that
available,
so
that,
like,
for
example,
if
phoenix
wanted
to
do
that
for
theirs,
then
they
could
do
that
and
get
better
visibility,
and
then
we
figure
out.
I
mean
I
guess
to
some
extent,
though
it's
not
the
phoenix
developers
developing
these
integrations,
it's
like
brian.
So
like
it,
it's
kind
of
unclear
who
it's
up
to
to
to
like
make
the
official
thing
that
goes
in
the
official
repo
too
like
is
it?
A
C
B
C
A
B
That
would
just
be
like
one
of
the
considerations
so
like
to
the
earlier
point
like
right
now.
It
doesn't
really
matter
where
you
put
it.
I
mean
like,
I
think,
the
ones
that
we
have
in
the
in
the
open,
telemetry
beam
are
more
like
are
the
list
of
ones
like
that,
like
we
are
officially
supporting
this
more
long
term
support
this.
C
And
then,
just
since
you
mentioned
uplink
gustavo,
I
feel
like
uplink
is
probably
the
way
that
I
would
recommend
people
integrate
open
telemetry
into
at
least
our
elixir
apps.
D
The
monitor
library
we're
creating
is
they
have
some
some
things
to
augment
open
telemetry
and
they
have
instrumentation
libraries
too.
So
we
have
instrumentation
library
for
urban
tesla.
We
have
rectal
phoenix
we're
trying
to
see
if
we
can
create
for
kafka
eggs,
but
don't
remember
the
hair
they
have
in
telemetry
events,
and
so
it's
it's
more
like
something
that
you
just
put
in
your
application
and
now
it's
instrumented
by
default.
D
D
And
then
the
monitor
is
more
like
something
to
a
standard
dies.
Everything
related
to
open
telemetry
at
magnets
and
something
that
I
believe
at
least
the
instrumentation
libraries
could
be
contributed
back
to
the
community,
we're
going
to
open
source
this
library.
I
already
got
permission
for
that,
but
there's
more
to
it
than
a
wrapper
around
open,
telemetry
and
there's
more
to
it
other
than
instrumentation
libraries.
C
It
may
not
be
exactly
what
you
want,
but
you
can
always
modify
it
and
make
it
do
what
you
want,
but
having
a
good
example
to
start
from,
or
just
like
a
good
default
that
you
could
just
use.
If
you
wanted
to,
I
think,
is
useful
and
we've
we've
gone
back
and
forth
a
bunch
of
times
on
different
monitors
that
we
have
internally
like
phoenix
versus
plug
versus
cowboy,
and
then
we
just
decided.
C
Let's
just
have
one,
that's
http
that
does
whatever
it
can
from
all
of
those
things
and
make
one
span
from
it
so
like.
If
that
was
a
an
example.
That's
out
there,
you
could
just
say:
hey,
try!
You
know
like.
I
recommend
you
use
this.
One
that's
what
we're
using
kind
of
thing
versus
like
each
company
having
to
start
over.
A
Yeah
definitely
yeah,
so
I
mean
we
should
move
this
discussion
to
slack
we're
out
of
time
and
I've
got
to
go
shovel
a
foot
of
snow
or
something
so.