►
Description
Modifying gRPC Services Over Time [I] - Eric Anderson, Google
Services grow and stretch over time to accommodate features, bugs, and basic maintenance. Learn how gRPC services can change while managing existing clients.
About Eric Anderson
Staff Software Engineer, Google
Tech Lead for Java gRPC. Contributor to the gRPC wire protocol and experienced with HTTP/2.
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
A
Apparently
it's
not
a
fixed
thing
and
you
need
to
extend
it
so
as
far
as
intended
audience,
there's
actually
a
couple
different
ways:
you
can
go
about
this
sort
of
talk,
but
I
hope
that
you've
toyed
at
least
with
gypsy
and
protobuf.
You
know
what
the
protocol
er
is
to
give
you
the
generic
code.
You
have
messed
with
a
couple:
different,
primitive
data
types
and
protobuf.
Those
things
aren't
scary
to
you
in
any
way.
A
Also
I'm,
assuming
this
is
G
RPC
native
I,
know
that
rest
using
rest
with
GFC
is
is,
is
definitely
thing,
I'm
completely
good
with
that.
But
it's
not
gonna
be
as
much
of
a
focus
here.
There's
actually
some
other
documentation
on
how
to
build
nice,
clean
REST,
API
s--
with
G
RPC,
although
I
am
aware
of
it,
so
it'll
it'll
seep
through
some
places
and
also
I'm,
assuming
that
servers
are
updated
before
clients.
A
This
might
seem
completely
obvious
to
you,
but
if
you
have
back
in
scenario
that
you're
using
geography
to
communicate
between
two
servers,
you
can
totally
have
you
update
one
server
before
the
other.
It's
actually
a
client
and
it
sees
some
new,
updated,
proto's
and
fields
and
stuff
before
the
other,
and
so
it's
not
as
much
for
those
cases
granted
you've
got
some
things
that
are
harder
in
that
case,
because
you
can
upgrade
both
ways,
but
you
also
are
in
control
more
control,
so
some
things
become
easier,
but
I'm
not
really
talking
about
that.
A
A
So
we're
talking
about
changing
something
over
time.
There
have
to
be
some
constraints.
Well,
that's
actually
compatibility
with
all
people
who
are
currently
using
your
service,
but
there's
lots
of
different
types
of
compatibility.
You
can
have
binary
and
source
compatibility
which
relate
more
to
the
generic
generated
code
and
that
involves
particular
languages.
Then
you
have
wire
compatibility,
which
would
be.
However,
things
see
realized
on
the
wire
will
this
it
was
doing
that
earlier
as
well,
and
then
you've
got
behavioral
compatible,
behavioral
compatibility
where
everything's
good
on
the
wire.
A
Everything
seems
fine,
but
your
application
is
now
at
let's
say,
interpreting
something
differently
than
it
was
before,
and
that
ends
up
breaking
a
client
so
to
just
start
we'll
take
a
binary
and
source
just
at
the
same
time
and
there's
actually
quite
a
few
languages
that
protobuf
and
G
RPC
support,
and
so
that
means
basically
all
bets
are
off.
If
you're
trying
to
do
something
fancy,
if
you
rename
or
remove
something,
those
totally
will
break
someone.
That's
not
normal.
That's
not
surprise
to
anyone,
probably
if
you
change
a
method
type
from
one
name
to
another.
A
That's
gonna
change
method,
signatures
that'll,
totally
break
people
in
in
like
statically
compiled
languages,
but
maybe
it
wouldn't
break
broken
someone
if
they
were
using
Python
or
something
like
that.
Primitive
type
changes
you're
like
oh,
this
was
an
in
32
I'm,
now
gonna
make
an
in
64
and
you're
like.
Oh,
that's,
fine,
they're,
both
integers,
but
it's
lots
of
languages
will
not
be
happy
with
you
on
that,
because
it'll
be
an
implicit
caste
or
something
like
that.
A
So
that
basically
leaves
us
with
adding
services,
methods,
messages
and
fields
which,
if
you've
done
much
like
library,
API
mean
and
some
stuff
isn't
surprising,
you
can
basically
add
stuff.
That
is
the
limitation,
and
so,
as
we
sort
of
go
through
this,
it's
like
okay.
How
do
we
make
use
of
this
this
knowledge?
So
let's
say
we
just
sort
of
have
this
conceptual
library
service
which
is
in
some
is
used
as
an
example
in
some
places,
so
we've
got.
A
We
want
to
be
able
to
create
a
book,
go
ahead
and
get
above
list
stuff,
delete,
stuff
and
update
to
the
book
as
well,
and
so,
like
I
put
in
this
book
here.
As
a
string,
that's
going
to
be
some
identifier
for
the
book,
it's
gonna,
be,
let's
say
the
book
name
or,
but
it's
guaranteed
to
be
unique
and
we're
in
list
books
if
you're
not
familiar
with
part
about
the
Google
protobuf
empty.
A
That
is
just
a
message
with
nothing
in
it,
so
it's
the
the
equivalent
of
a
void
in
some
languages,
so
this
is
sort
of
what
we're,
starting
with
I'm,
not
saying
that
this
actually
works.
But
this
is
what
we're
wanting
to
do
and
we're
sort
of
going
from
here
to
to
further
to
make
it
actually
maintainable
and
so
I
introduced
some
of
these
best
practices.
We
should
plan
for
the
replacement
of
the
service.
A
Ideally
so
right
now,
it's
suggested
to
include
the
version
number
in
the
package
name
itself,
so
with
area
top
that
we
have
the
package.
That's
what
I'm
talking
about
here.
So
you
could
include
a
v1.
It's
actually
not
that
big
video.
If
you
forget
to
do
that,
because
you
can
have
a
v2
on
the
v2,
but
it's
having
a
version
in
the
package
er
or
in
the
service
name
itself
can
be
a
good
way
of
of
separating
things.
Whenever
you
have
a
breaking
API
change
in
the
service
change
in
the
future.
A
Also
we
GRDC
doesn't
let
you
have
multiple
arguments
or
some
things
like
that.
It
relies
very,
very
heavily
on
on
messages
and
you
extending
messages.
So
you
want
to
use
messages
for
your
extending
point,
because
that's
the
intention,
if
you,
if
you
sort
of
avoid
them
you're
gonna,
have
some
trouble
so
when
in
doubt
create
a
new
message
for
each
RPC
method,
so
you've
got
foo
method
and
you're.
A
And
then
you
can
also
feel
free
to
add
new
services
and
methods
as
necessary.
You
don't
have
to
limit
yourself
to
just
a
very,
very
few
number
of
methods.
You
can
add
them
as
they're
useful,
but
at
the
same
time
don't
have
an
explosion
for
every
single,
different
combination
of
possible
arguments.
This
is
probably
nothing.
A
You
have
a
place
to
put
that.
If
you
didn't
do
this,
it's
not
the
worst
thing,
the
worst
thing
in
the
world.
You
would
just
need
a
new
method.
That
then,
has
some
message
where
you
could
specify
those
things,
but
adding
adding
extra
parameters
to
a
to
an
RPC
is
just
happens
all
the
time,
and
so
you
can
plan
for
it
a
little
bit
and
then
you
avoid
having
tons
and
tons
of
methods
to
me
that
one
was
sort
of
resti.
A
Let's
say
that
we've
got
something
more
functional
like
a
computational,
and
so
let's
say:
we've
got
this
nice
infrastructure,
we're
in
the
infrastructure
and
we're
providing
a
clock
service.
It's
really
really
advanced,
you
call
it
with
no
arguments,
that's
the
empty,
and
then
you
get
back
a
timestamp.
This
is
this
isn't
some
ways
fine,
but
you
might
instead
choose
to
go
ahead
and
make
the
request
make
the
response
message
types
and
there
they
would
just
be
on
the
end.
So
this
is,
it
seems,
boilerplate,
lady
again
it
would
have
been
okay.
A
If
we
forgot,
we
would
have
just
end
up
having
a
better
time
method
later,
but
doing
this
ahead
of
time
does
save
us
that
cost
and
really,
if
for
the
users,
it's
not
that
much
harder
to
use
this
API
versus
the
one
we
had
before.
So
it's
not
with
it
too
much
cost.
Oh,
hey
hello!
People
chatting
with
me
alright,
so
that
so
that
gets
us
binary
and
source.
Now
we're
gonna
go
ahead
and
go
on
to
wire
compatibility.
A
This
one's
a
little
bit
more
in-depth,
so
RBC's
in
GRC
are
only
distant
distinguished
by
their
name.
So
that
is
the
package
they're
in
the
service
name
itself
and
then
the
method
name
anything
else
than
that
is
implicit,
and
so
that
means
request
and
response
types
are
implicit.
Those
names
that
are
used,
the
cardinality,
whether
it's
a
streaming
request
or
a
streaming
response,
or
just
a
single
request.
A
Those
things
are
implicit.
That
means
you
could
go
ahead
and
add
new
services
and
methods,
because
those
have
a
different
name
and
such
they
won't
collide
with
anything.
For
it
also
means
you
could
change
a
message
from
one
type
to
another
if
you
were
really
wanting
to
and
you
could
go
ahead
and
add
a
stream
keyword
to
an
existing
method,
but
because
of
where
we
were
before
with
api's
doing
those
last
two
will
totally
break
break
people
in
at
compilation
time
now
granted.
A
If
you
can
force
people
to
get
a
compilation,
error
and
then
they'll
update,
but
it
doesn't
work
as
well,
why
our
compatibility
for
protobuf
is
is
is
even
a
little
more
granted.
A
lot
of
people
have
had
familiar.
You
are
already
familiar
with
protobuf,
so
they
may
not
be
aware
of
some
of
this,
and
some
of
this
is
slightly
different
in
proto
3
than
proto.
But
message
names
are
implicit.
A
So
if
you
change
the
message
from
one
name
to
another,
it's
it
can
act
like
the
same
thing,
except
when
that's
not
the
case
like
any
and
except
I.
Guess
metadata
would
also
be
a
common
case
where
it's
sort
of
leaks
through
fill
beams
are
also
implicit.
That's
why
we've
got
the
tags
when
you
know
you've
got
the
equals
of
one
at
the
end
of
your
field.
Those
are
also
implicit,
except
when
they're,
not
JSON,
converting
to
and
from
JSON
is
pretty
common
and
field
mask
is
maybe
something
that
you
might
want
to
use.
A
I'll
talk
about
it
later,
so
you
know
I'm
saying
it
is,
but
then
it's
also
not.
We
do
know
that
field
tags
are
explicit.
You
cannot
change
the
the
tag
where
it
says
equals
one
equals
two
equals
three
at
the
end,
if
you
change
that,
yes,
you're
totally
gonna
be
breaking
someone.
That
should
not
be
a
surprise.
A
One
interesting
thing
is
some
tags
are
the
same
on
the
wire.
Oh
sorry,
some
types
are
the
same
on
the
wire
in
32
is
the
same
as
in
64.
So
that
means
you
could
actually
say.
I'm
going
to
upgrade
I
need
some
more
bits,
I'm
going
to
upgrade
this
to
an
n64.
As
far
as
protobuf
concern
is
concerned,
that
would
be
fine,
but
it's
risky
because
of
the
API
and
the
ABI
stuff
earlier,
so
really
nothing
new.
Our
limitations
were
pre-existing.
We're
really
just
limited
by
binary
and
source
compatible
compatibility.
A
So
I
don't
know
what
that
same
practices.
Oh,
yes,
we
follow
the
same
practices
we
were
talking
about
before
with
by
with
the
binary
source.
Now,
yes,
you've
got
more
options
here.
If
you
don't
care
about
that
binary
source,
you
could
do
more
fiddly
bits
here.
You
think
oh
I
control,
both
the
server
and
the
client.
That
means
I
can
control
things.
A
However,
in
a
larger
application,
even
if
you
control
both
sides,
it's
actually
really
hard
to
make
it
breaking
change
all
at
once
to
the
entire
code
base,
and
so
you
store
start
having
to
to
abide
by
the
earlier
roles
you,
you
really
only
get
to
break
stuff
whenever
it's
a
small
enough
project
and
you
control
both
sides,
and
then
that
takes
us
to
behavior
compatibility,
which
is
actually
a
really
really
wide
scope.
Most
of
your
effort,
I
think,
will
actually
be
spent
here.
The
other
stuff,
you
can
add
stuff,
that's
easy.
A
A
So
here's
some
of
the
best
practices
I
want
to
talk
about
we'll,
go
ahead
and
start
with
the
the
new
permanent
fields
default
to
zero
or
empty
string
or
the
each
primitive
sir
has
its
default.
Now
that
is
actually
a
statement
that
is
just
true.
That
is
how
new
default
fields
work
in
proto
3.
The
point
of
this
is
to
actually
accept
that
it
that's
how
proto
3
works.
Don't
try
to
to
avoid
it,
just
because
you
think
that
that's
silly,
there
are
ways
to
avoid
it.
A
There
are
ways
to
get
around
it,
but
if
you
just
let
the
zero
value
be
the
I,
don't
care
value
or
the
default
value.
You'll
you'll
probably
have
a
better
time
if
you
need
to,
if
you
need
to
know
field
presence,
because
that
was
removed
in
proto
2
proto
3
you
there
are
these
these
rappers
I'm
an
in
fact
it's
called
rappers
proto,
so
every
primitive
field
has
one
of
these
rappers,
and
so
it's
really
really
complexes
and
you've
got
a
string
value
and
it
contains
a
value.
That's
it
contains
a
string
value.
A
That's
that's
all
we're
talking
about.
These
are
not
anything
that
are
really
special,
it's
just
that
we
need
them,
and
so
there's
some
well-defined
ones
that
are
already
made
for
you,
so
you're
free
to
use
those.
Also,
if
there's
a
couple
different
fields
that
you
need
to
sort
of
know
about
whether
they're
there
or
not
together,
you
can
go
ahead
and
make
one
of
your
message.
That's
custom
that
has
those
specific
fields
and
that
message
overall
is
either
present
or
not.
A
A
You
have
an
int
in
your
java
or
c,
and
there
is
no
oh,
this
int,
isn't
there
you're
sort
of
forced
to
make
it
0
or
negative
1,
or
something
like
that,
and
if
you
need
it
to,
if
you
need
to
know
whether
it's
there
or
not,
you
end
up
making
a
pointer
to
it
and
then
having
you
know
or
something
like
that.
That's
the
same
thing
as
this.
This
is
just
normal
boxing
that
that
takes
place
in
languages
so
moving
on,
we
there's
updates.
A
Whenever
you
add
a
new
field,
if
you're
not
a
little
careful,
you
could
actually
have
some
client
that's
doing
an
update
clearing
that
field.
So
let's
say
that
we
we've
got
our
library
service
before
so.
I
just
took
out
the
important
part:
hearts
we've
got
update
book
and
I.
Ask
alright.
This
is
the
book
I
want
the
new
contents
to
be
that's
the
in
the
request
and
then
in
the
the
book
response
is
the
name
the
author
in
the
title,
and
that's
that's
really
all
we
have
right
now
well
and
I.
A
Guess:
let's,
let's
say
that
I'm
actually,
there's
a
client
that's
pre-existing
today
and
it
looks
at
the
book
request
and
it
goes
ahead
and
updates
the
author
name,
because
it
was
misspelled
or
something
like
that,
so
it
would
commonly
get
the
the
current
book.
You
would
modify
the
message
and
then
it
would
upload
it
again
be
an
update
book
if
we
end
up
having
a
new
field,
because
apparently
users
we're
forced
to
keep
on
reading
the
same
book
over
and
over
we're.
A
Now
going
to
introduce
this
field
called
read
and
if
it's
read
now,
then
we
have
a
little
icon
or
something
on
the
UI
to
tell
hey
user.
You
might
not
be
as
interested
in
this
book.
So
if
there's
an
existing
client
that
was
modifying
the
author,
it
downloaded
it,
the
the
red
bit
was
let's
say
on
whenever
it
processed
that
it
would
act.
A
That
client,
which
was
older,
would
throw
it
away
because
it
wouldn't
know
about
red,
and
so
then,
whenever
the
client
then
modifies
author
and
then
uploads
the
the
changed
version,
the
server
now
thinks
that
this
the
client
was
clearing
red
because
it
looks
the
value
of
red
and
it's
now
zero.
So
it's
now
accidentally
performing
a
change.
A
This
was
not
as
much
of
a
problem
in
proto
2
because
you
had
field
presence,
so
you
can
see
Oh
rad,
isn't
there,
it
must
not
be
a
set.
So
film
mask
is
actually
a
partial
solution
to
this.
You
might
not
have
looked
at
film
mask
before
it's
it's
there,
but
it's
not
necessarily
advertised
in
a
lot
of
places,
and
so
basically
all
it
is,
is
you
say
which
fields
you
care
about?
This
is
useful
for
both
query,
where
you
say:
I
only
care
about
these
three
fields.
A
Don't
bother
looking
up
the
rest
from
the
database,
but
this
can
also
be
useful
for
updating
briefs
say
these
are
the
fields
that
are
actually
selected,
and
so
it
can
have
a
basically
a
repeated
field
of
paths
where
you
specify
and
it
works
fine
with
sub
messages.
If
you
have
messages
nested
inside
of
other
messages,
you
can
say
just
the
fields
you're
interested
in
and
it
field
most
defaults
to
all
fields,
because
this
works
pretty
well
for
query.
A
Where
you
say
just
get
me
everything
and
you
don't
need
to
field
fill
in
the
field
mask
the
the
reason.
I
say
that
this
is
a
partial
solution
is
while
it
would
solve
our
problem
from
before,
because
the
the
client
would
say
I
only
updated
author,
and
so
the
server
would
know
to
only
update
author.
It's
really
annoying
to
use
all
the
time.
It's
it's
fine
to
use
some
places.
A
So
we
had
our
update
book
request
from
earlier
and
you
just
go
ahead
and
specify
a
mask
in
that
request,
and
then
this
is
what
Java
would
look
like,
but
each
each
language
has
some
helper
utility
in
order
to
use
this
field
mask,
and
so
we
go
ahead
and
get
the
name
of
the
book
and
we
load
the
book
from
the
database
with
its
current
values
as
they
are
right
now,
then
we
do
this
utility
function.
What
this
does
is
it
is
it
copies
fields.
A
I
can
even
point
with
this
ya
know
we
get
copies,
fills
fields
from
the
request
book
into
the
destination
book
into
the
current
version
that
we
just
grabbed
from
the
database,
but
it
filters
based
on
the
mask,
so
it
only
copies
the
ones
that
are
listed
in
the
field
mask
and
at
the
end
of
it
all
we'll
go
ahead
and
push
the
the
book
back
into
the
database
at
the
very
very
end.
So
that's
basically
the
flow.
There
are
some
options
that
on
the
field,
Maskull
util,
if
you're
doing
this
yourself,
you
can.
A
You
should
probably
take
a
look
at
those,
but
it's
not
important
for
this.
So
going
a
little
bit
more
I
mentioned
it
earlier,
there's
actually
some
other
API
guides.
The
rest
one
suggests
not
to
add
new
fields
to
things
that
are
updated
in
this
fashion.
Not
all
of
your
messages
are
used
with
that
sort
of
update
request
that
that's
actually
a
little
bit
hard
in
my
mind,
granted
there's
reasons
for
it.
I
think
that
this
is
still
slightly
an
unsolved
problem,
except
that
protobuf
three
5re
adds
unknown
field
support.
A
So
in
a
couple
more
months
has
heard
about
35
seats,
more
and
more
clients
using
it.
This
may
be
a
problem
that
is
just
not
an
issue
anymore.
It
just
evaporates
if
you
can
require
thread
about
35,
so
some
people
don't
necessarily
know
how
to
use
air
details
with
your
PC.
That's
completely
fair,
so
there
is
so
what
what
the
suggestion
is.
We've
got
the
status
code
and
that's
good,
but
it's
very,
very
coarse
for
additional
information.
You
should
make
a
message
for
it
and
you
make
that.
A
However,
you
want
sits
for
whatever
is
useful
for
your
application
to
say:
okay,
this
failed
clients
whenever
you
need
to
know
what
went
wrong.
Here's,
here's,
what
you
look
at
and
you
can
use
a
message
for
each
different
type
of
failure
or
for
a
small
class
there's
actually
some
predefined
ones
in
air
details.
Proto
I
just
took
a
sampling
here.
There's
there's
some
more.
A
debug
info
is
just
like
a
list
of
stacks.
Just
justice,
strings
quota
failure
has
a
little
bit
of
information,
say
Oh.
A
Was
this
a
failure
because
that
particular
clients
was
doing
too
many
QPS?
Or
is
this
a
failure
because
the
user
ran
out
of
disk
space,
so
it
can
provide
a
little
more
information.
Their
help
just
provides
a
link
to
a
documentation
so
that,
whenever
someone
sees
this,
they
can
actually
go
and
look
up
what
the
actual
more
words
than
can
fit
in
the
description.
A
They
can
look
at
what
went
wrong
and
there's
also
localized
message,
which
is
useful
because
in
the
normal
description
we'll
be
in
like
English
localized
message
can
be
localized
string
for
whoever
the
client
is,
and
so
then
they
can
read
it.
So
the
recommended
practice
is
to
use
these
messages
and
they
need
to
put
them
somewhere.
That
really
is
put
them
in
metadata,
which
is
what
we
used
to
recommend.
It
turned
out
to
be
hard
to
pass
that
around
in
some
languages,
and
it
was
unclear.
You've
got
this
metadata
and
you've
got
this
error.
A
It
was
a
little
unclear
which
how
they
related
exactly.
What
so
was
the
particular
metadata
key
because
of
the
error,
or
was
that
just
extra
information?
Let's
say
tracing
information
or
something
like
that,
and
so
Google
RPC
status
is
pretty
simple.
It's
the
code
in
the
message
which
exists
in
G
RPC
today
and
then
an
inny
for
details.
A
We
actually
G
RPC,
actually
used
to
use
this
exact
message
type
for
its
response
status,
and
there
was
a
point
that
we
decided
to
remove
the
dependency
on
protobuf,
and
so
we
went
ahead
and
removed
this
this
message,
but
we
did
we
decided
not
to
put
details
anywhere
other
than
just
the
metadata,
because
the
metadata
would
work
well
for
that
it
turns
out
that
that
it
does
work.
It's
just
sort
of
a
little
bit
hard
in
AP
is
to
propagate
all
these
things
together.
So.
A
Languages
are
receiving
utilities
to
work
nicely
with
Google
RPC
status,
not
every
language
has
it
yet,
but
it's
coming,
and
so
for,
like
Java
here's
the
difference
of
before
now
you
end
up
getting
a
status.
This
Google
are
Cacique
on
Google
RPC
status
as
opposed
to
the
normal
status,
and
this
is
what
the
client
code
would
look
like,
but
then
you
have
that
any
field
where
you
can
put
associate
information
if
you're
propagating
it
with
I
guess,
exceptions
and
Java
is
a
little
handled
already.
Java
was
was
able
to
do
it
some
other
languages.
A
And
then
the
last
thing,
because
we
like
streams
and
we
like
long-lived
RPC-
is
that's
one
of
the
things
that
are
really
nice
to
do,
because
you
can
issue
the
request
and
just
wait
for
an
event
to
happen.
I
highly
suggest
that
you
break
that
occasionally,
because
clients
are
really
easy
at
avoiding
work
that
they
don't
have
to
do
so,
whether
in
whether
on
purpose
or
not,
and
so
if
a
client
doesn't
realize
they
need
to
handle
the
fact
that
oh
this
RPC
might
fail
before
it
completes.
A
Then
they
very
likely
will
have
some
bug
in
that
code
path
and
so
go
ahead.
And
if
there's
something
that
takes
a
while
go
ahead
and
sometimes
purposefully
complete
the
RPC
prematurely.
That
could
just
be
after
a
fixed
age
or
randomly
just
to
introduce
some
noise.
And
then
the
client
will
see
that
it
it
completed
early
and
then
go
ahead
and
reissue
their
request
and
then
it'll
it'll
be
able
to
wait
a
while
longer.
A
A
So
does
does
anyone
have
any
questions
like
this
is
I
guess
free
for
all,
because
people
have
probably
dealt
with
their
own
problems
did
were
people
following
what
was
happening
with
the
unknown
fields?
You
might
not
have
even
noticed
that
undone
fields
were
being
added
in
progra,
3:5,
I
think
a
lot
of
people
that
probably
makes
them
pretty
happy,
because
that
was
a
feature
they
sorely
missed
from
protobuf
too.
A
So
the
question
was:
how
do
the
versions
work
or
how
do
they
they
interact?
Are
they
compatible
so
to
begin
with
most
languages
if
it's
supported
produce
to
originally
part
of
a
3-run
time
also
supports
protobuf
too,
so
you
can
mix
and
match.
However,
you
want,
in
that
case
now
granted
read
about
three
supports
more
languages.
It
was
a
simplification
in
part
to
allow
more
languages
to
be
supported,
and
so
you
may
not
have
as
many
LaPlante
languages.
A
That's
can
sport
it,
but
if
you
like
prota,
you
can
keep
rota
in
gypsy
works
find
the
prototype.
It
is
as
far
as
wire
compatibility
read
about
three
and
front
about
to
use
the
same
wire
format.
There
is
some
compatibility
there,
then
the
intended
way
of
dealing
with
it
is
let's
say:
you've
got
a
pret
about
three
clients
and
then
you've
got
a
protobuf
server.
A
So
there
is,
it
was
understood
that
you
might
need
to
mix
and
match
a
little
bit
and
as
far
as
the
the
and
put
about
three
compatibility
as
far
as
which
type
you
use
those
you
can
actually
have
proto
three
messages
include
proto
2
messages
and
even
that
level,
it's
not
like.
You
have
to
have
a
particular
tree
of
messages
that
you
don't
cross
the
streams
you
can
actually
mix
and
match
a
little
bit
more
than
that.
A
So
the
question
is:
when
do
you
know
when
you
break
compatibility
between
systems
between
proto,
2
and
Pro?
2
3
is
that
we
are
saying
so
that
is
basically
getting
here.
Add
stuff,
don't
remove
stuff,
don't
change
names.
If
you
aren't
wanting
to
support
JSON
or
field
masks,
you
can
change
names
that
was
classically
completely
fine
to
do
and
Preta
buff,
but
generally
nowadays
it's
it's
a
little
bit
closer
to
just
add.
A
So
the
question
is:
was
there
any
request
from
the
community
for
json-rpc
compatibility
or
translation?
I've
not
seen
any
for
reporters
specifically
json-rpc?
There
is
quite
a
bit
of
translation
between
protobuf
and
javascript
and
json
no
granted.
That
is
that,
may
not
I
think
some
people
get
a
little
confused
on
that.
That
is,
if
you
have
a
pretty
buff
message,
there
is
a
JSON
encoding
for
it
and
you
can
go
back
and
forth
between
it.
It's
not
I
have
some
arbitrary
JSON
and
I
want
a
protobuf
message
for
it.
A
A
A
B
A
Okay,
so
this
is
dealing
some
with
the
the
handshaking
that
goes
in
with
gzip
in
general.
You
should
be
fine.
If
you
are
wanting
to
respond
with
gzip.
Basically,
you
should
be
able
to
generally
just
say:
I
want
to
use
gzip
and
then
the
services,
the
client,
doesn't
support
that
and
then
just
it'll
send
back
uncompressed
or
and
ap
has
make
vary
a
little
bit
on
that
per
language.
But
basically
there
should
be
no
problem
for
the
server
to
send
back
gzip
whenever
it
wants
to
do
gzip,
because
the
client
informs
the
server.
A
What
it
supports.
The
much
harder
case
is
whenever
the
client
wants
to
send
gzip,
because
it
doesn't
know
like
it
needs
to
know
what
the
the
the
server
supports,
but
the
server
there's
not
a
handshake
before
you
do
the
message,
and
so
the
main
thing
we
did
there
is
to
make
sure
that
service
supported
gzip
before
1.
Oh
so,
you've
got
that
going
for
you.
You
know
that
you
can
make
a
client
that
goes
against
something
this
at
least
share
pc/104
and
things
should
work.
A
But
if
there's
let's
say
a
new
compression
protocol
or
compression
type
you're
still
going
to
have
that
problem,
I
think
that
that
part
is
unsolved.
I
would
liked
I
think
that
we
might
be
able
to
solve
it
some
with
a
client
config
in
order
to
notify
the
client
ahead
of
time.
But
if
you're
just
wanting
to
send
back
it
were
you
wanting
to
respond
with
gzip,
okay,.
A
So
so
the
question
is:
why
would
you
use
compression
with
ER
PC?
So
there's
a
couple
different
reasons,
one.
You
can
compress
just
one
message
worth
of
content,
and
so
let's
say
that
you're
transporting
a
bunch
of
bytes
from
a
file.
Well,
those
bytes
might
be
compressible
and
so
you're
like,
oh,
let's
compress
them
all.
So
there's
plenty
of
strings
in
Preda
both
messages.
Apparently
they
only
use
so
many
bits
because
they're
ASCII
and
things
like
that,
and
so
you
can
also
get
some
savings
there.
A
There
is
a
further
thing
that
we're
working
on,
although
it's
in
various
forms-
and
it
may
have
stalled
a
little
bit
because
of
a
push,
but
we
were
working
some
on
full
stream
compression
where
you
could
actually
send
a
stream
and
multiple
messages
would
be
able
to
be
compressed
with
one
compression
context.
The
that's
most
similar,
I
guess
normally
to
if
you
have
a
repeated
field
and
you've
got
very
similar
data.
A
One
message
should
in
the
next
will
be
similar
because
lots
of
data
happens
to
be
similar.
It's
the
same
name
over
and
over
you've
got
a
prefix
as
part
of
your
ID
name,
and
so
those
go
he
stripped
out
and
the
full
stream
and
compression
was
was
also
assuming.
That
fact
also,
some
people
will
send
like
HTML
back
responses
back
sometimes
or
things
like
that,
and
there's
plenty
of
payloads
that
compress
I.