Workflow changes when new feature is added

[giriraj-singh-couchbase]

Hello all,
I had a doubt and wanted to ask something, if let's say I developed a new feature and for that feature I need to do the changes in github actions, and for that new feature there are various dependencies which is needed to be satisfied and for that I need to do the changes in the makefile, config file and bazel build files as well as workflows(for github actions) . Upto what extent changes are acceptable?

[wwbmmm]

What kind of feature do you want to add? If you have a plan, you can draft a document, including the feature description, the files or classes you need to modify, and the dependencies you need to add. So we can judge whether it is acceptable.

[giriraj-singh-couchbase]

Hi Weibing, Currently I am working on implementation of couchbase support in bRPC using couchbase c++ SDK.
I will share the link of my repository: cb_bRPC.

The overview of the changes are as follows:

1. Actions & workflows are updated to install couchbase-cxx-client SDK before building and it's required dependencies.
2. Added couchbase.h and couchbaes.cpp which acts as a wrapper in using couchbase SDK.
3. Added examples on how to use the couchbase SDK, single and multi-threaded both.
4. Added the functionality to do the CRUD & Query operations using couchbase SDK.

However, the build using bazel is causing trouble in linux and needs to be tested more.
make, make with protobuf is working fine in linux and macOS.

[wwbmmm]

Hello, I've seen your repository. My main question is, how are the src/brpc/couchbase.h and src/brpc/couchbase.cpp files you implemented related to brpc? It seems they only use the brpc namespace, while the rest of the code is independent. If that's the case, why were they placed in the brpc repository?

Can you describe your use case scenario? Are you hoping to access couchbase servers through a brpc client to leverage advanced features like service discovery, load balancing, timeout and retry policies? If so, your current implementation does not fully meet the requirements, as it does not truly integrate the brpc client with the couchbase protocol. If you want the brpc client to support the couchbase protocol, you can refer to the implementation of the memcached protocol in brpc. The core task is to implement the serialization and deserialization of the protocol without introducing any external dependencies. However, fully supporting the couchbase protocol may involve a significant amount of work. I am not familiar with couchbase, it seems that the servers are stateful and the client needs to select the server based on the query, that would be quite complex. You could refer to the PR for brpc's support of Redis Cluster , which has not yet been merged. If the servers are stateless and the client only needs to randomly select a couchbase server, it would be much simpler.

[giriraj-singh-couchbase]

You guessed the use case scenario correctly. We have already fine-tuned the SDK for all the operations and it also supports the wide range functionality provided by SDKs. However, I have also Implemented using couchbase binary protocol but have very limited functionality for now, cb_bin_prot_brpc, this does not require any external dependency and also doesn't break backward compatibility. But it looses all the extra features and fine-tuned functionality of all operations provided by SDK.

[wwbmmm]

That's right. The PR couchbaselabs#4 you provided is the one worth merging into the brpc repository. On the other hand, I understand that the PR couchbaselabs#3 does not need to be included in the brpc repository. It is merely a wrapper for couchbase-cxx-client and is unrelated to brpc. If users require it, this code can be stored elsewhere.