►
From YouTube: Protobuf Oneof automata and stream visitor MR overview
A
A
A
Each
response
is
a
message
where
one
of
these
three
fields
can
be
set
only
one
of
them
that's
guaranteed
by
this
grouping,
so
either
headers,
where
we
send
what
committee
was
or
the
object
where
we
send
one
or
more
messages
per
one
file
per
each
file.
So
if
file
is
big,
I
think
the
constant
is
128
kilobytes
and
you
said
multiple
objects
and
then
once
you
have
sent
all
of
them,
we
send
the
traders.
This
is
more
like
for
future.
A
Then
we
need
to
ensure
that,
on
the
on
the
client
side,
we
need
to
ensure
that
the
server
has
followed
the
protocol
and
hasn't
closed
the
stream
prematurely
before
sending
us
all
the
objects,
because
if
it
did
because
of
a
bug
or
something,
then
we
would
apply
this
to
a
cluster
and
then
we
will
potentially
delete
some
valid
objects
because
of
a
bug.
So
it's
kind
of
a
big
deal
to
ensure
that
the
protocol
is
followed
correctly
so
to
to
address
this.
A
I
wrote
some
hard
to
read
code
here,
so
we
just
track
if
the
headers
have
been
received
and
trailers
have
been
received,
and
there
is
basically
an
automata
that
we
import
here
like
what
is
the
next
thing
that
is
being
that
is
expected
this
constant.
So
we
are
expecting
headers.
Then
we
are
expecting
objects
or
trailers
and
then,
after
trailers,
we
are
expecting
end
of
end
of
the
stream.
A
And
then
we
check
this
all
these
conditions
in
the
right
places
and
return
an
error
or
log
an
error
if
and
abort
if
the
protocol
is
not
followed
and
then
here's
this
crazy
switch
as
well.
That
ensures
everything
was
okay
and,
on
the
then
cause
the
callback
to
apply
this
to
the
cluster.
So,
as
you
can
see,
it's
a
lot
of
boilerplate.
A
A
This
is
an
option
that
is
defined
on
can
be
defined
by
the
user
by
on
any
field,
and
this
is
an
option
that
can
be
defined
inside
of
any
one
of
so
here
we
encode
this
automata
that
to
with
it's
a
list
of
what,
once
you
get
this
field,
what
is
what
are
the
next
fields
that
are
allowed
in
the
stream?
Basically,
as
part
of
this
one-off
group,
and
this
one
is
what
is
the
first
field
when
you
start
reading
stream?
What
what
are
it's
repeated?
A
So
it
can
be
multiple
first
fields,
one
of
them
should
be
the
first
one
also
at
least
so.
We
use
this
to
annotate
our
one-off.
It's
the
same
rpc
file.
This
is
our
one-off
objects
to
synchronize
response,
so
first
one
must
be
number
one
which
is
headers.
Then
after
headers
it
must
be
number
two
or
number.
A
Three,
which
is
objects
or
trailers,
so
if
there
are
no
objects,
the
server
must
send
the
trailers,
and
if
there
are
some
objects,
it
should
send
some
objects,
multiple
potential,
multiple
times
it's
a
loop
in
the
automata
and
then
once
it's
done
after
the
all,
the
objects
have
been
sent.
It
should
send
the
trailers
after
the
drivers,
minus
one
is
a
special
thing
for
end
of
stream.
You
off
that's
the
annotations,
and
then
I
wrote
a
stream
visitor.
A
I
think
that
analyzes
this
and
analyzes
you
give
the
proto
message
so
objects
to
synchronize
a
response
and
it
analyzes
it.
It
builds
the
representation
of
this
automata
like
what
is
allowed
from
from
this.
You
can
go
to
this
list
and
stuff
like
that,
and
then
it
calls
the
callbacks
that
you
provide
so
and
to
use
it
you
do
where
is
it?
A
This
is
our
watcher,
which
was
which
looked
crazy
on
master,
and
this
is
the
branch.
This
is
how
it
looks
so
we
defined
here
we
constructed
here.
We
tell
that
we
are
going
to
be
processing
stream
of
objects
of
this
type
object,
synchronous
response,
and
this
is
how
we
travel.
Basically,
and
we
say,
visit
the
stream
well,
we
get
the
stream
make
their
pc
to
the
server
to
cast.
A
Then
we
visit
the
stream
and
we
want
for
headers
this
callback
for
objects,
this
callback
and
for
traders,
this
callback
to
be
called-
and
it's
this
visitor
thing
which
is
right
here
and
you
can
see
for
headers.
This
code
is
being
executed,
for
objects,
discord
and
for
trailers.
Nothing
to
do
at
the
moment
looks
much
nicer,
doesn't
it?