Begin with the end in mind.
Steven Covey
The SDK RFCs are where we think through the mechanics and semantics of new API being added to Couchbase. The goal is to iterate on what the level of detail should be before writing a full implementation and to quickly surface things we may want to take into consideration in the design. As it grows from an idea to shipping in a supported release, an SDK RFC will traverse along:
- Identified: A need has been identified for an SDK RFC, but there's little more than a filed issue to point to at the moment
- Draft: The owner of the SDK RFC has started to draft up how the subject will be handled and may be reviewing with a core group. Comments are certainly welcome at this stage even though the owner hasn't worked through enough details to ask for...
- Review: This SDK RFC is in a review period. Stakeholders and the owner may still be iterating on some final details before signoff. A minimum review period has been defined.
- Accepted: All stakeholders have signed off and this SDK RFC is now or will be implemented soon.
Coding happens all the time and is encouraged. We just recognize there is a point where we will want to move from code having been written as a subproject or an experimental feature to a feature of the system. At that point we want the feature to take into consideration more use cases and development platforms than it had when it was merely experimental. We want the end result to feel like it's been designed, rather than merely written.
| RFC # | Description | Owner | Status |
|---|---|---|---|
| 1 | The RFC Process | Matt | ACCEPTED |
| 5 | VBucket Retry Logic | Brett | ACCEPTED |
| 11 | Connection String | SDK | ACCEPTED |
| 13 | KV Error Map | Brett (Mark) | ACCEPTED |
| 20 | Common Flags | Brett | ACCEPTED |
| 24 | Fast failover configuration and behavior | Jeff | ACCEPTED |
| 26 | Ketama Hashing | Mike G | ACCEPTED |
| 30 | Client-Side Compression | Sergey | ACCEPTED |
| 32 | Field-Level Encryption | Jeff | ACCEPTED |
| 48 | SDK3 Bootstrapping | Brett | ACCEPTED |
| 49 | SDK3 Retry Handling | Michael | ACCEPTED |
| 50 | SDK3 Datastructures | Brett | ACCEPTED |
| 51 | SDK3 Views | Sergey | ACCEPTED |
| 52 | SDK3 Full Text Search | Sergey | ACCEPTED |
| 53 | SDK3 CRUD API | Jeff | ACCEPTED |
| 54 | SDK3 Management APIs | Charles | ACCEPTED |
| 55 | SDK3 Transcoders & Serializers | Jeff | ACCEPTED |
| 56 | SDK3 Query API | Michael | ACCEPTED |
| 57 | SDK3 Analytics API | Michael | ACCEPTED |
| 58 | SDK3 Error Handling | Jeff | ACCEPTED |
| 59 | SDK3 Foundation | Brett | ACCEPTED |
| 61 | SDK3 Diagnostics | Michael N. | ACCEPTED |
| 64 | SDK3 Field-Level Encryption | David N. | ACCEPTED |
| 69 | KV Error Map V2 | Brett L. | ACCEPTED |
| 76 | KV Subdoc Replica Reads | Charles D. | ACCEPTED |
| RFC # | Description | Owner | Status |
|---|---|---|---|
| 29 | Server Version Identification [gdoc] | Brett | DRAFT |
| 38 | Enhanced Prepared Statements [gdoc] | Michael N. | DRAFT |
| 39 | Alternate Address Support (formerly Multi Network Configurations) [gdoc] | Brett | DRAFT |
| 45 | Advanced Analytics Querying [gdoc] | Michael N. | DRAFT |
| 46 | Synchronous Replication [gdoc] | Sergey | DRAFT |
| 47 | Unified User Agent [gdoc] | Michael N. | DRAFT |
| 62 | Eventing Management APIs [gdoc] | Michael N. | DRAFT |
| 63 | User Impersonation [gdoc] | Brett | DRAFT |
| 65 | CreateAsDeleted Support [doc] | Graham P. | DRAFT |
| 66 | Collection-Aware Query Support [doc] | Michael R. | DRAFT |
| 67 | Extended SDK Observability (also known as "Tracing & Metrics") [doc] | Michael N. | DRAFT |
| 68 | Collection-Aware FTS Support [doc] | Michael R. | DRAFT |
| 69 | ReplaceBodyWithXattr Support [doc] | Graham P. | DRAFT |
| 71 | HTTP Client [doc] | David N. | DRAFT |
| 72 | Queues And Topics [doc] | Michael N. | DRAFT |
| 73 | KV Range Scan [doc] | David N. & Michael N. | DRAFT |
| 74 | Configuration Profiles [doc] | Mike R. | DRAFT |
| 75 | Faster Failover and Configuration Push | Sergey | DRAFT |
| 77 | couchbase2 support [gdoc] | Graham P. | DRAFT |
| 78 | Zone-Aware Replica Reads | Sergey | DRAFT |
| RFC # | Description | Owner | Status |
|---|---|---|---|
| 9 | 2i Query Support | SDK | IDENTIFIED |
| 15 | Collection Support | Brett | IDENTIFIED |
| 17 | Cross-Cluster Failover | Michael | IDENTIFIED |
| 18 | Timeouts for Configuration and Operations | Michael | IDENTIFIED |
| 21 | Generic find Queries [issue] | Brett | IDENTIFIED |
| 40 | Feeds | Brett | IDENTIFIED |
| 41 | Multi-Document Atomicity | Graham | IDENTIFIED |
| 42 | Config Publish Interleave | Charlie | IDENTIFIED |
| 44 | XDCR Durability | SDK | IDENTIFIED |
comment: # Next RFC ID 79
| RFC # | Description | Owner | Status |
|---|---|---|---|
| 2 | Mark | SUPERSEDED | |
| 3 | Simon | SUPERSEDED | |
| 4 | Michael | SUPERSEDED | |
| 7 | Brett | SUPERSEDED | |
| 8 | Mark | SUPERSEDED | |
| 10 | Michael | SUPERSEDED | |
| 12 | SDK | SUPERSEDED | |
| 14 | SDK | SUPERSEDED | |
| 16 | Mike G | SUPERSEDED | |
| 19 | Brett | SUPERSEDED | |
| 22 | Subhashni | SUPERSEDED | |
| 23 | GET_COUNT and MKDOC |
Mark | SUPERSEDED |
| 25 | Brett (Mark) | SUPERSEDED | |
| 27 | Michael (Brett) | SUPERSEDED | |
| 28 | Brett L | SUPERSEDED | |
| 31 | Mike G | SUPERSEDED | |
| 33 | Michael N | SUPERSEDED | |
| 34 | Sergey | SUPERSEDED | |
| 35 | Mike G | SUPERSEDED | |
| 36 | Michael | SUPERSEDED | |
| 37 | Subhashni | SUPERSEDED | |
| 43 | Michael | SUPERSEDED | |
| 60 | SDK3 Response Time Observability [gdoc] (superseded by 67) | Mike G | SUPERSEDED |
We take the addition or extension of API seriously because we intend this work to have a lifecycle of years or decades. Toward that end, we had originally been writing a set of "one pagers" which had been influenced by experience in other software development organizations. While those were great and we're even porting some of them over to RFCs, we recognized that we'd caught some mistakes late and want to focus ourselves on identifying affecting all platforms as early as possible.
Thus, we defined a new SDK RFC process. We're not alone in this kind of endeavor. Note that Joyent have created RFDs (which came from some similar experience @ingenthr and @trondn had at Sun as well), and Rust has Rust RFCs in addition to the well known IETF RFCs.
Even though this says "SDKs", frequently the discussion here will expose things not always considered at protocol and component design. Those issues may be discussed in the SDK RFC or the discussion may spawn off to Couchbase's issue tracker