►
From YouTube: 2020-12-16 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
A
A
Yeah
yeah:
let's
see
if
anyone
else
is
going
to
show
up
but.
A
A
C
C
A
A
Hey
we
got
a
carlos
wow
dude;
it
must
be
so
freaking
late
unless
you're
down
in
mexico,
you're
kind
of
in.
B
B
A
Yeah,
so
these
were
two
issues
you
raised.
That
would
be
easier
to
maybe
get
get
some
live
discussion
on
this
going
for
hop
piling
into
the
discussion
thread,
so
I
think
the
question
I
had
around
like
shut
down,
so
one
is
shut
down
and
the
other
is
flush
and
it
seemed
like.
Maybe
the
question
was
shut
down.
We
definitely
need
to
have
a
shutdown
there's
some
stuff
with
like
lambda.
A
B
I
would
say
it's:
the
goal
is
to
have
what
needs
to
be
shut
down,
shut
down
and
so
like.
If
the
span
processor
needs
to
be
shut
down,
the
tracer
provider
could
delegate
to
it,
but
that
seems
like
it
has
some
corner
cases
like
if
the
span
processor
is
used
by
other
things,
and
at
least
in
java,
like
I
don't
think
it's
a
weird
thing
where
like.
If
something
is
close,
if
we
close
that
thing,
rather
than
having
a
global
method
so
like,
if
I.
B
A
Yeah
in
my
ideal
world,
the
person
who
is
setting
all
this
stuff
up
is
the
person
who
who
shuts
it
down
yeah
and
it
seems
like
I
was
maybe
a
little
bit
confused
about
how
some
kind
of
sharing
would
go
on.
So
I
was
just
wondering
what
what
specifically
you
were
thinking
of
in
that
case.
B
So
if
you
called
shutdown
on
one,
then
the
other
one
will
get
affected
in
a
weird
way,
and
so,
instead,
if
you
want
to
shut
down
the
spam
prices
shut
down
the
spam
processor
instead
there
trying
to
make
bring
the
control
to
where
it
is.
So.
That's
the
case
where
you
can
imagine
where
the
span
processor
could
be
shared,
and
we
could
try
hard
to
forbid
this.
B
D
B
A
Yeah,
I
I
feel
part
of
what
I
wonder
is
I
kind
of
feel
like
to
a
certain
degree.
I
would
prefer
having
a
single
top
level
shutdown
call,
which
did
everything
for
me.
I
wouldn't
want
to
have
to
be
as
the
end
user,
closing
and
shut
downing.
A
All
of
these
lower
level
things
partially
just
for
like
order
of
operations,
usually
like
shutdown
works
best
when
it's
when
it's
ordered
properly,
and
so
it
seems
like
you
would
want
the
sdk
to
have
everything
registered
with
it,
and
then
you
tell
the
sdk
shut
down,
and
then
it
shuts
closes
things
in
the
proper
order
which
would
be
like
you
know,
harder,
certainly
more
annoying
to
manage
as
an
end
user.
So.
B
A
I
should
review
the
spec
on
this
front,
but
we
don't
we
don't
really
define
that
object
very
definitively.
If
I
recall.
A
I
I
would
so
there's
like
a
question
of
whether
these
things
should
have
a
shutdown
call
and
if
they
need
them,
I
think
they
should,
but
then
there's
the
other
question
of
who
who
should
be
calling
this
the
end
user
or
you
know,
should
this
be
managed
by
by
a
higher
level
object.
So
everything
that's
closable
gets
closed
by
the
top
level.
Object
that
thing
yeah.
A
So
I'd
like
to
see
that
and
then
I,
but
then
there's
like
a
second
question
of.
Does
that
mean
we
want
to
hide
all
these
shutdowns
and
make
them
private
or
is
it
just
like?
You
have
a
bunch
of
closable
things?
That's
normal,
but,
like
the
expectation
is
you
know,
you
you
hand
all
this
stuff
to
the
sdk
and
you
shut
that
down
and
as
an
end
user.
If
you
do
other
things
like
well
you're,
just
doing
it
wrong.
A
Certainly
the
worst
case
that
should
happen
is
these.
Things
should
just
become
like
no
ops
if
you
shut
them
down
and
then
or
call
shut
down
twice
or
or
anything.
B
B
Yeah,
like
I
think
so,
that's
what
I
mentioned
with
scalability,
like
it's,
probably
okay,
but
if
we
want
a
global
shutdown
to
shut
everything
down,
it
means
like
sort
of
every
single
interface
you
expose
right
now.
It's
just
span,
processor
span,
exporter
and
sampler.
I
don't
know
what's
going
to
come
in
the
future,
but
anything
we
expose
that
we
can
expect
to
have
a
version
that
accepts
resources
would
have
a
shutdown
method.
I
think
that's
the
only
way
to
achieve
that,
and
it
seems
a
bit
weird
like
the
implementation.
B
A
Are
the
two
things
I'm
balancing
yeah?
I
just
realized.
Given
these
things
are
plug-ins
third-party
plug-ins
that
people
can
write,
so
we
actually
can't
make
shutdown
private
yeah
because
of
the
interface
exactly
yeah,
and
so
I
think
these
things
have
to
be
closable.
A
I
mean
there's
a
question
of
like:
is
it
required
for
them
to
be
closable,
I
I
would
say
yeah
and
that
should
just
be
a
no-op
if
you
do
nothing
with
it,
but
I
think
it's
also
important
to
to
structure
this
so
that
as
an
end
user
you're
not
shutting
down
all
the
individual
things.
A
Okay,
I
don't
know
if
this
I'll
have
to
review
what
the
spec
looks
like
on
that
front.
But
does
that?
Does
that
seem
reasonable
to
you
honorary.
B
B
So
I'm
I
personally
find
it
like,
I
would
say,
I'm
personally
fine
with
it
being
independent
for
the
user,
like
each
component
be
shut
down
separately,
I
mean
especially
if
you're
using
spring
or
something
it
does
it
automatically
anyway.
So
it's
no
problem,
but
you
can
see
that
people
that
that's
not
always
going
to
be
the
case,
and
so
maybe
having
the
top
level.
A
E
D
A
Other
and
that's
where
I
just
wonder
if,
if
that's
realistic
to
my
mind,
there's
not
like
a
great
reason
to
be
sharing
plug-ins
across
multiple
sdk
instances.
I
mean
it's
code
right.
You
can
do
what
you
want,
but
it
seems
like
like
that
just
seems
that's
complicated
things
that
seems
unnecessary
if
you're
gonna
create
two.
E
B
Yeah,
I
guess
one
thing
I
just
sort
of
imagined
I'm
again,
these
are
all
going
to
be
sort
of
contrived
examples,
but
like
if
a
user
has
two
services,
two
grpc
services
in
their
app
and
they
want
to
have
different
sampler
for
one
versus
other.
They
might
still
be
in
the
same
app,
but
they
set
up
two
different
tracers
one
for
the
grpc,
with
the
always-on
sampler
one
with
a
different
sampler,
but
they
share
the
same
spam
processor.
B
A
I
just
yeah
I'm
just
wondering
whether
it's
realistic
that
I
think
it's
we
have
to
defend
against
shutdown
being
called
twice,
but
I
don't
like
I'm
not
sure
that
we
need
to
extend
this
beyond
the
idea
that
all
of
this
shared
stuff
would
be
shared
across
multiple
sdks
right
like
where
you
would
be
like
I'm
closing
all
this
stuff
down
over
here,
but
I'm
I'm
leaving
it
up
somewhere
else.
I
mean.
B
E
E
B
A
A
If
you
call
these
things
excessively
or
at
the
wrong
time,
it
won't
do
anything
useful,
but
it
won't
blow
your
program
up.
E
E
Maybe
maybe
another
option
is
if,
on
our
sdk,
we
provide
a
tool.
Builder
method
and
people
can
modify
some
of
the
things
like
trace,
config,
like
whatever
they
can
modify,
get
a
new
instance
and
that
new
instance
will
not
be
shut
shuttable
or
whatever
shut
down
the
world,
and
people
always
have
to
call
the
shutdown
on
the
root
one
and
all
these
rappers,
that
change,
samplers
or
change
a
couple
of
other
things
will
will
not
will
not
call
shutdown
or
will
not
need
shutdown.
E
B
E
B
F
Yeah
I
mean
the
two
builder
two
builder
opened
up
all
sorts
of
cans
of
worms
around
this,
like
you
know
what
we're
talking
about
with
shared
components
and
should
they
be
shared?
Should
they
not
be
shared?
Can
they
be
shared?
F
F
E
E
I
depends
on
the
world,
but
yes
in
some
worlds
they
are,
and
I
think
it
makes
sense
to
have
them.
Okay,
but.
D
E
A
B
I
think,
like
you
mean
someday
not
now
right
but
even
someday
like.
I
think
it
is
common,
not
call
me
like
it
serving
two
sort
of
independent
services
in
the
same
app,
especially
like
grpc
apps.
I
think
it
does
happen
and
wanting
to
totally
different
tracing
configurations,
but
maybe
the
same
exporter.
F
E
A
B
A
Yeah,
let's
see
if
we
make
that
happen.
Okay,
moving
on
to
the
the
other
issue
that
was
brought
up
around
force
flush,
I
really
want
to
ensure
that
something
like
flush
doesn't
go
on
to
the
api.
We
we
do
have
it
on
the
sdk,
but
just
to
explain.
I've
used
to
maintain
tracing
implementations
that
had
a
flush,
and
it
was
just
abused
by
users,
because
it's
sort
of
like,
if
you
hand
them
something
like
that,
they
assume
what
you're
telling
them
is
that
they
have
to
manage
flushing.
A
Right
because
they're
like
I
have
some
weird
problem,
I
don't
know
what
it
is,
but
then
I,
like
brute
force
my
way
through
it
by
calling
flush
left
and
right
and
it
seemed
to
work
so
now
I
just
reflexively:
do
it
everywhere,
john
made
a
good
allusion
to
to
manually
calling
gc
operations
in
java
and
how
that
had
to
get
turned
into
a
no-op
for
similar
reasons?
A
So
so
I
don't
think
it
should
be
on
the
api
we
do
have
it
on
the
sdk,
which
is
at
least
a
little
bit
better,
and
that
was
for
use
in
lambda
was
the
specific
reason
we
added
flush
to
the
sdk.
So
I
was
curious.
Why
is
there
a
reason
why
having
flush
on
the
sdk
is
insufficient.
B
So
I
think
the
biggest
reason
was
actually
came
to
mind
when
reading
your
dock
and
how
it
also
does
mention
that
we
expect
your
instrumentation
to
only
use
the
api
full
stop,
and
so
I
mean
again
so
it's
either
adding
it
to
the
api.
Otherwise,
if
we
just
add
a
caveat
to
that
statement
that
some
instrumentation
like
lambda
might
need
to
access
force
flush
in
the
sdk
that.
E
F
E
B
B
But
if
they're
not
owning
the
instrument
like
so
they
could
call
like,
we
could
force
the
user
to
call
force
flush
on
the
sdk
at
the
end
of
the
request
handler.
But
I
think
that's
too
annoying
like
our
instrumentation
does
call
force
flush
at
the
end
like
so
that
a
user
doesn't
have
to
worry
about
this,
and
that
is
definitely
how
we
should
do
it.
E
B
A
I
was
going
to
say
I
think
so.
The
way
we
went
about
this
with
lambda
is
to
say
that
users
should
use
the
single
span
processor
rather
than
calling
force
flush
on
the
batch
processor,
because
the
issue
is
lambda
can
freeze
you
at
any
time,
and
so,
if
you're
running
the
sdk
from
within
the
lambda
process,
you
just
want
you
don't
want
spans
hanging
around
and
if
you
use
the
single
span
processor,
then
that
that
solves.
E
They
still
run
a
bit
of
code
that
they
can
do,
can
continue
to
run,
and
then
they
can
ensure
that
fl
force
flash
finishes
correctly.
I
don't
actually.
B
Think
that's
the
case.
Correct
me.
If
I'm
wrong,
so
there's
two
points,
one
like
so
the
reason
not
to
use
simple
span
processor.
I
agree
with
bogdan,
like
it's
worth
getting
the
extra
performance.
If
we
can
batch
those
bands
per
invocation
because
there
will
be
usually
at
least
three
or
something
spans
right
and
then
yeah,
so
there's
no
magic
of
the
framework
providing
a
way
for
flushing,
hopefully
someday.
B
It
does
like
that's,
definitely
a
feature
that
lambda
should
provide,
but
in
the
meantime,
like
our
instrumentation,
since
it's
wrapping,
the
request
handler
like
after
the
user
is
done
with
the
request.
It
still
runs.
It's
like
our
instrumentation
is
running
some
logic
at
the
end,
within
the
scope
of
the
request
and
at
the
very
end
we
call
force
flushing
the
instrumentation.
That's
how
we're
doing
it
right
now.
B
A
B
B
But
the
extensions
still
get
like
we
have
been
to
and
the
extensions
don't
work
because
the
extensions
get
frozen
and
they
say
I
mean
I
can't
say
much
but
like
someday
it'll
be
fixed,
I
think,
but
that's
still
a
year
or
something
away
so.
E
Too,
so
so,
okay,
before
we
do
the
extension,
if
that's
not
working
yeah,
how
do
we
fix
this?
We
have
a
solution
with
simple
spam,
not
ideal.
It's
working
again,
not
ideal.
Don't
don't
get
me
wrong.
The
second
thing
is,
which
is.
E
B
E
The
rapper
needs
access
to
this,
and
I'm
thinking
I'm
thinking,
maybe
maybe
one
another
option,
because
this
is
just
a
limited
case
here.
We
can
make
this
if
the
user
has
to
pass
the
instance,
the
user
can
pass
the
instance
plus
a
plus
a
callback
or
a
callable
that
is
called
flash,
and
even
though
they
pass
an
instance
that
doesn't
have
this.
A
E
E
B
B
A
A
I
was
gonna
just
getting
back
to
passing
the
sdk
around.
I
think
there's
a
point
I
want
to
make
there,
which
is,
I
agree,
instrumentation
shouldn't
touch
that
thing,
but
there
are,
you
know,
application
owner
programs
spring
is
an
example
of
that
right.
Spring
sleuth
like,
and
so
I
just
have
a
question
for-
does:
can
your
lambda.
A
What
I'm
wondering
is
like
is
this
thing
in
addition
to
instrumentation,
also
an
application
owner
effectively,
like
can
you
just
hand
off
the
management
of
the
sdk?
To
this
thing,.
E
There
is
another
option
here:
by
the
way
there
are,
we
can
split
the
package
into
two
parts,
one
that
does
the
pure
instrumentation,
which
creates
a
span
at
the
beginning
of
every
handler
and
ends
the
the
thing
and
another
package
which
includes
the
first
one
plus
gets
a
dependency
on
an
sdk
and
say:
okay
for
open
telemetry.
Sdk
here
is
everything
that
even
initialize
the
sdk
and
and
kind
of
a
starter
like
you
have
you
have
the
instrumentation
and
you
have
the
starters
thinking
yeah
anyway.
E
This
is
another
because
that's
the
difference
in
spring
sloot
spring
sloot
is
a
starter,
is
not,
I
think,
even
spring
sloot
has
two
components:
open,
telemetry,
core
or
the
pure,
open
telemetry,
and
the
starter
with
our
sdk.
B
A
B
A
B
A
Think
it's
like,
maybe
we
can
clarify.
I
think
I
I'm
starting
to
try
to
clarify
some
of
these
roles
in
general,
because
we
haven't
really
written
them
down
in
my
pr
but
like
clarifying.
There
is
like
an
instrumentation
author
over
here
and
there's
an
application
over
owner
over
here
and,
and
you
can
have
like
starter
code
right,
you
can
write,
you
can
write
sdk,
they
wouldn't
be
called
sdk
plugins,
but
you
can
add
an
sdk
component.
That's
like
an
sdk
manager
and
that's
a
reasonable
thing
to
add.
It's
just
clarifying
that.
A
That's
not
instrumentation
you're
trying
to
instrument
something
you
shouldn't
be
grabbing
at
that
stuff,
which
is
why
bogdan
was
saying
this
should
be.
The
thing
you're
describing
in
land
is
actually
two
pieces,
there's
something
that
instruments
the
stuff
and
then
there's
something
that
that
doesn't
pay
management.
Okay,
we're
just
trying
to
keep.
E
Learning
this
time
and
but
but
we
know
for
sure
that
force
flash
was
a
big
problem
in
the
past,
so
we
push
hard
to
not
add
it
on
right.
A
It
I
did
successfully
take
this
away
from
my
users
in
the
past
and
they
never
complained
about
its
absence.
I'm.
E
A
They
kept
using
it
but
anyways
the
point
being
more
that
they
didn't
weren't
coming
back
and
being
like.
No
really,
I
need
to
be
flushing
all
over
the
place.
It
was
more
that
they
thought
they
should,
because
we
were
giving
it
to
them
sort
of
like.
If
you
give
people
shutdown,
then
they
go
all
right.
Well,
I
have
to
call
this
shutdown
thing
if
you
give
them
flush.
They're
like
oh,
I
have
to.
I
have
to
manage
flush.
E
E
D
E
Yeah
like
again,
and
only
one
is
the
sdk
and
then
and
then,
if
you
derive
from
there,
you
get
the
apis,
which
you
don't
have
to
call
shutdown
anyway,
just
random
ideas.
Again,
I'm
not
interesting.
A
Without
adding
this
and
then
and
then
go
from
there,
because
yeah
we've
managed
to
avoid
it
in
every
other
situation
so
far
so
kidding,
you
know
I
was
sad.
We
had
to
add
flush
at
all,
but
I
do
want
to
land
the
case
for
why
you
need
it
someday.
A
E
Another
option
how
google
solved
this
in
in
the
cloud
function
that
they
had,
but
they
didn't
give
you
they
didn't
give
you
the
option
to
install
another
sdk
so
essentially,
essentially
lambda
was
for
was
not
giving
you.
Essentially
you
don't
give
any
option
besides
maybe
an
otlp
endpoint,
where
the
the
things
that
things
should
be
pointed
and
if
they
want
to
have
these
lambdas
then
redirected
to
lightstep,
you
ask
them:
okay,
deploy
one
collector
somewhere
and
all
the
lambdas
will
will
point
to
that.
E
Collector
you'll
talk
only
on
tlp
and
then
from
there
user
can
configure
whatever
they
want
and
then
and
then
lambda
can
control
hundred
percent.
The
instance
that
is
created
the
bachelor
everything
gets
onto
the
lambda
and
user
can
only
access
the
instance
that
is
passed
by
the
lambda
framework.
Anyway,
I'm
not
sure
if
amazon
wants
to
do
something.
A
A
A
B
E
But
even
even
that
you
have
two
options:
push
to
x3
or
push
to
an
endpoint
using
yeah,
yeah,
yeah
and
then
and
then,
and
then
by
default,
is
push
to
x-ray,
enabled
but
give
user
an
option
if
they
really
want.
Instead,
instead
of
doing
all
these
things
to
point
to
an
otlp
endpoint
and
they
have
to
provide
that
endpoint
p
and
you
can
force
to
be
in
the
same,
a
z
and
whatever
whatever
yeah,
and
they
can
start
an
instance
there
and
from
there
redirect
to
lifestyle
if
they
want
so
again.
E
Maybe
this
is
possible,
I
don't
know
how.
Maybe
is
not
the
time
to
ask
about
extensions,
but
maybe
you
can
give
me
some
documents
about
extensions.
A
E
E
Yeah,
instead
of
using
generated
code,
I
directly
generate
the
byte
array
that
we
need
to
put
on
the
wire
and
we
got
25.
30
percent
improvement.
D
E
E
Then
we
serialize
them
now,
I'm
just
creating
the
metric
data
and
from
here
I'm
writing
the
bytes,
but
again
could
be
more
optimal
if,
if
we
write
them
directly
in
from
the
sdk,
but
that's
kind
of
probably
be
almost
impossible,
because
it
makes
the
sdk
kind
of
depend
on
protobuf,
even
though
only
on
the
model
and
stuff
but
yeah.
A
This
is
where
I've
I've
longed
for,
like
an
alternate
implementation
like
we
have
our
our
framework
model
of
sdks,
but
we've
written.
This
was
for
against
open
tracing,
but
we
wrote
an
implementation
that
just
completely
did
away
with
any
kind
of
optionality.
A
A
But
you
can't
really
mix
that
in
with
like
a
flexible
framework,
it's
sort
of
like.
E
Yeah,
but
we
can
still
do
that
by
the
way
we
can
still
do
that,
even
with
our
format,
the
the
way
how
we
can
do
it
is
we
can
make,
and
it
will
be
two
copies
of
the
bytes,
which
is
fine.
I
mean
it
will
be
to
to
you'll
copy
twice
the
the
whole
byte,
but
what
I
was
thinking
is
if
we
modify
internally
our
metric
data
to
be
backed
by
a
byte
array,
that
is
the
proto
representation.
E
Then
then,
when
you
serialize,
you
just
put
these
bytes
one
close
to
each
other.
So
so
you
still
can
do
that
and
expose
the
interface
as
metric
data,
but
internally
you
have
byte
arrays
that
are
serialized.
So
every
time,
every
time
when
we
do
otlp,
we
just
put
all
these
bytes
together.
Yeah
and
I
didn't.
E
A
E
It's
still
a
lot
of
of
of
help
like
we
still
want
a
lot
of
performance
here.
A
E
B
E
B
E
B
A
A
Envoy
you
talk
you're
you're,
connecting
from
from
the
the
client
connects
to
envoy
envoy.
Does
the
load
balancing
we'll
I'll
I'll
work
with
ryan
at
some
point
to
to
give
a
presentation
of
this?
It's
neither
here
nor
there
with
like
what
we're
doing
today,
but
it
was
pretty
cool
and
he
he
had
figured
out
like
a
pretty
good
way
to
make
it
work.
E
Anyway,
could
be,
but
it's
very
hard
because
you
have
to
send
the
the
headers
always
otherwise.
The
the
envoy
cannot
redirect
your
stream
at
a
halfway
through
unless
you
restart
the
stream
periodically.
So
so
I
think
what
he
did,
which
google
was
doing.
That
is
every
30
seconds.
You
restart
the
stream.
E
A
E
A
You
can
do
it
on
the
span
level
too,
because
you
know
when
the
spans
start
and
end.
So
if
you
want
to
be
buffering
till
you
have
a
complete
span
and
then
streaming
it
off
again,
you
can
do
that
or
looking
at
when
the
spans
start
and
end.
So
so
there's
a
way
to
do
that.
I
know
he
implemented
it,
but
anyways.
Well
that
that's
that's
neither
here
nor
there,
but
it
is
a
cool
idea
that
we'll
try
to
present.
At
some
point
sure
the
performance
games
were
impressive.
E
A
Yeah
yeah,
it
gets
a
lot
simpler
if
you
don't
well,
actually
there's
no
way
to
make
this
simple.
If
you
wanted
to
have
in-memory
access
to
this
thing
and
also
hard
to
implement
in
other
languages,
but
what
we
can
do
in
those
other
languages
is
bind
through.
Foreign
function
calls
to
like
the
c
plus
plus
sdk,
rather
than
using
the
language
specific
sdk.
That's
the
other
interesting
performance.
You
still
want
to
look
at.
E
A
Yeah
and
you
can
move
if
you're
moving
part
of
partial
of
this
would
be
if
you're
trying
to
do
format,
translation
or
other
things
like
that,
you
wouldn't
be
doing
it
in
the
client
right
you're
saying
like
do
that
at
the
edge,
the
gateway
off
to
prometheus
or
somewhere
else.
You
have
a
specialized
processor
there
that
that
does
the
translation
you're
not
paying
the
cost.
For
this
thing
that
you're
not
going
to
use
right
like
if
you're
going
to
do
all
that
processing
in
the
collector
somewhere.
Why
pay
the
cost
in
the
client.
E
That's
true,
but
people
will
say
that
they
don't
want
to
use
a
collector.
They
want
just
to
put
some
data
into
jugger
and
call
it
a
day.
So.
A
Yeah
yeah,
but
I've
wondered
if,
like
the
way
we
could
give
people
this
speed
boost
is
just
to
have
one
implementation.
That's
like
a
super
optimized
version
of
this
in
c,
plus,
plus
and
then
maybe
java
doesn't
want
to
bind
to
c
plus
plus.
If
you
need
one
there
too,
but
for
python
and
a
lot
of
other
languages,
you
could
just
have
an
alternate
sdk.
That
was.
E
But
you
cannot
have
it.
It
is
going
to
be
very
hard
to
do
something
like
that.
If
you
want
to
do
with
api
compatibility
and
and
stuff
you,
you
need
and
support
all
the
the
the
platforms.
So
probably
anyway,
what
I'm
trying
to
say?
E
Yes,
it
is
possible
and
that
implementation
can
directly
depend
on
the
proto
and
use
all
the
helpers
from
the
proto
library,
not
the
generated
code,
because
you
don't
need
the
generic
code,
but
you
need
all
the
helpers
like
zero
copy
protobuf
streaming,
because
they
have
a
thing
called
zero
copy,
protobuf
streaming,
so
you
just
put
the
bytes
and
the
whenever
you
call
it.
That
message
is
done.
The
the
proto
library
does
everything
for
you
so
and
that
can
be
simply
yeah.
We
we
can
do
something
like
that.
E
A
Yeah
you,
this
is
all
the
fun
stuff
we
get
into
once
we
get
get
stable
because
I've
liked
this
idea,
there's
like
a
bimodal
distribution
right,
some
people,
they
want
a
framework.
They
want
a
lot
of
flexibility.
They
want
to
write
plug-ins
in
their
language.
Other
people
just
want
the
fastest
possible
thing
and
they're
willing
to
trade
everything
else
in
order
to
get
the
most
efficient
implementation.
E
A
Okay
gang:
this
is
a
good
call.
I
gotta
run
yeah.