There is no need to use ServerMethodDefinition in codegen. The create()
method itself could be helpful to a dynamic HandlerRegistry
implementation, so we won't remove it.
This reduces the amount of logic built into the generated code. If we
swap to an alternative form of decoding we should have greater ability
to adapt the existing API to make use of the new one. Previously most
changes would require duplicating all the nano marshalling code.
- Remove blockingClientStreamingCall() which is not used, and we don't
actually want that API.
- Rename duplexStreamingCall() to asyncDuplexStreamingCall() to align
with other async methods.
- In unary call and client streaming call, do not request for additional
response after the first response.
This gives us more flexibility in API changes in the future.
Unary call and server streaming call should call the flow-control method
call.request() only once. Previously it was called whenever a request
arrives, which is wrong. Now it's fixed.
Resolves#436
Resolves#511.
- In generated code, make CONFIG private and METHOD_* fields public.
METHOD_* fields are MethodDescriptors now, users of the CONFIG field
should switch to using the METHOD_* fields.
- Move MethodType into MethodDescriptor (#529).
- Unify the fully qualified method name. It is fully qualified service
name + slash + short method name. It doesn't have the leading slash.
- HandlerRegistry switches the key from short method name to fully
qualified method name.
- Pass CallOptions to Channel.newCall() and
ClientInterceptor.interceptCall().
- Remove timeout from AbstractStub.StubConfigBuilder and add deadline,
which is stored in a CallOptions inside the stub.
- Deadline is in nanoseconds in the clock defined by System.nanoTime().
It is converted to timeout before transmitting on the wire. Fail the
call with DEADLINE_EXCEEDED if it's already expired.
Other classes are already following the convention that ClientFoo for
client-side, and ServerFoo for server-side. Call has been the black
sheep of the family.
- Call -> ClientCall
- Calls -> ClientCalls
- ForwardingCall* -> ForwardingClientCall*
This allows people who cannot run the pre-compiled ``protoc`` pulled
from Maven Central to use their own ``protoc``.
Upgrade to protobuf-gradle-plugin:0.4.1 to display error messages of
protoc failures.
- Switch all system properties to project properties.
- Use the ``javaLocalNamingStyle`` instead of the
``dot.delimited.style`` for property names, so that it can be directly
referenced by ``rootProject.propertyName``.
- Recommend users to put GRPC-specific properties in project-level
``build.properties`` instead of the user-level.
- Stop defining custom architectures because VisualCpp toolchain doesn't
allow it. Reference to built-in architectures 'x86' and 'x86_64' since
they are supported by all toolchains.
- Remove 'local_arch' from platforms. For unsupported platform, we just
do not specify the target.
- Target no more than one platform at a time. This simplifies the build
script a lot.
- Remove the TARGET_ARCHS environment variable. Add system property
``arch`` to override ``osdetector.arch``.
- Add ``vc.disable`` to override the default choice of VisualCpp on
Windows.
- Add ``vc.`` prefix to the properties that are only used with VC++
The plugin has been published on plugins.gradle.org
Conforming to the Gradle standard that plugin IDs must be name-spaced,
the plugin ID has been changed to com.google.protobuf.
Commit 76f0a09 after the previous release
(ws.antonov.gradle.plugins:gradle-plugin-protobuf:0.9.1) defers the
generation of generateProto tasks to post-evaluation of the project,
which make them no longer available in the evaluation phase. We need to
move the manipulation of these tasks to post-evaluation too.
- Add -lprotobuf etc to linker.args if libprotobuf.a etc doesn't exist in
LDFLAGS
- install does not do architecture and dependency check on the artifacts,
because it may produce non-publishable artifacts due to the above
change.
io.grpc.nano sort of seems like a "small" version of grpc-java. And
io.grpc.proto could also mean multiple things. Using "protobuf"
and "protobuf nano" gets us consistent names that are still
understandable, predictable, and more similar to protobuf project
itself.
-Xlint:-options is not available on some earlier JDK 7s, but won't fail
if unsupported. It prevents the warning wanting bootclasspath specified
since target/source is 1.6.
Protoc should be in PATH and the project properties protobuf.include and
protobuf.libs should be set. For example:
gradlew build -Pprotobuf.include=C:\path\to\protobuf-3.0.0-alpha-2\src ^
-Pprotobuf.libs=C:\path\to\protobuf-3.0.0-alpha-2\vsprojects\Release
When running more than once, it is probably more convenient to create
%HOMEDRIVE%%HOMEPATH%\.gradle\gradle.properties with contents like:
protobuf.include=C:\\path\\to\\protobuf-3.0.0-alpha-2\\src
protobuf.libs=C:\\path\\to\\protobuf-3.0.0-alpha-2\\vsprojects\\Release
Eric Anderson
David P. Baker
Kun Zhang
Carl Mastrangelo
nmittler
Louis Ryan