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 |
| 2 | SubDocument API | Mark | ACCEPTED |
| 3 | Index Management | Simon | ACCEPTED |
| 4 | RYW Consistent Queries – at_plus | Michael | ACCEPTED |
| 5 | VBucket Retry Logic | Brett | ACCEPTED |
| 7 | Cluster Level Authentication [issue] [draft] | Brett | REVIEW |
| 8 | Datastructures | Mark | ACCEPTED |
| 9 | 2i Query Support | SDK | IDENTIFIED |
| 10 | Full Text Search (FTS) API | Michael | ACCEPTED |
| 11 | Connection String | SDK | ACCEPTED |
| 12 | SDK | SUPERSEDED | |
| 13 | KV Error Map | Mark | DRAFT |
| 14 | SDK | SUPERSEDED | |
| 15 | Collection Support | SDK | IDENTIFIED |
| 16 | RBAC Support [issue] | Mike G | DRAFT |
| 17 | Cross-Cluster Failover | Michael | IDENTIFIED |
| 18 | Timeouts for Configuration and Operations | Michael | IDENTIFIED |
| 19 | SDK 2.0 APIs | Brett | ACCEPTED |
| 20 | Common Flags | Brett | ACCEPTED |
| 21 | Generic find Queries (draft discussion) | Brett | DRAFT |
| 22 | User Management API | Subhashni | DRAFT |
| 23 | Subdoc GET_COUNT and MKDOC |
Mark | DRAFT |
| 24 | Fast failover configuration and behavior | Jeff | IDENTIFIED |
| 25 | XATTR Support | Mark | DRAFT |
| 26 | Ketama Hashing | Mike G | ACCEPTED |
| 27 | Analytics Querying | Brett L | DRAFT |
| 28 | Enhanced Error Messages | Brett L | DRAFT |
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