From b5d34cf6fc1daeb7e1140c34282885a13a1df473 Mon Sep 17 00:00:00 2001 From: stack Date: Tue, 4 Oct 2016 08:34:10 -0700 Subject: [PATCH] HBASE-16742 Add chapter for devs on how we do protobufs going forward; ADDENDUM -- add in Duo Zhang remark --- src/main/asciidoc/_chapters/protobuf.adoc | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/main/asciidoc/_chapters/protobuf.adoc b/src/main/asciidoc/_chapters/protobuf.adoc index 3cbc504fdf7..41818780e9d 100644 --- a/src/main/asciidoc/_chapters/protobuf.adoc +++ b/src/main/asciidoc/_chapters/protobuf.adoc @@ -74,12 +74,13 @@ practice needs to whither. We'll make plain why in the later xref:shaded.protobuf[hbase-2.0.0] section. [[cpeps]] -=== Coprocessor Endpoints +=== Coprocessor Endpoints (CPEPs) xref:cp:[Coprocessor Endpoints] are custom API a developer can add to HBase. Protobufs are used to describe the methods and arguments that comprise the new Service. Coprocessor Endpoints should make no use of HBase internals and -only avail of public APIs. This is not always possible but beware +only avail of public APIs; ideally a CPEP should depend on Interfaces +and data structures only. This is not always possible but beware that doing so makes the Endpoint brittle, liable to breakage as HBase internals evolve. HBase internal APIs annotated as private or evolving do not have to respect semantic versioning rules or general java rules on