(Note: this is a rough translation added to the original Japanese. No warranty.)
RpbErrorResp の errcode はより適切な値が設定されるべきである。(The errcode of RpbErrorResp should be set to more appropriate value.)
PBC API ではエラーが起きると、RpbErrorRespが返るがRIAKC_ERR_GENERALが常に設定されており意味がないのでREST APIと同等の値が設定されているべきです。 (When an error occurs on the PBC API, the value of RpbErrorResp is returned, though RpbErrorResp is always set to RIAKC_ERR_GENERAL so that the recipient cannot find what the real cause is. The value should be set the same as with the REST API.)
例えば、get operation において、notfound が返るのは多くの場合クライアント側にとって特に問題ないので、コストの高い例外処理がトリガーされない事が望ましい。
一方で、modifiedが返る場合、データのリペアをトリガするべきか、単に再度getするべきかはアプリケーションの設計の問題である。 (For example, on get operation the clients will find no problem when notfound is returned - exceptions of higher cost should not be triggered. On the other hand, if modified is returned, it is up to how the application is designed to trigger the repairment of the data, or to re-execute the get operation.)
errmsgフィールドの様にHumanReadableなフィールドはあくまでも人間にとって分かり易い事が大切であり、その内容は長い開発期間の中で微調整されるべきであり、不安定でも仕方のないものである。
きめ細かい例外処理を実現する場合、errcode フィールドを読み取って処理するべきなので、現状のPBC API実装は望ましくない。(The errmsg fields are human-readlable and that should be easily understood by humans; the contents do not necessarily have to be fixed or stabilized during the development phase. For a precise exception handling, the errcode field should be processed. The current PBC API does not fit with this principle.)
REST API が持つ便利な機能をPBC APIにも実装するべきである。 (All Functionality of REST API should be implemented on the PBC API as well.)
速度を何にも増して重視するユーザは全ての処理をPBC APIでやりたいと考えるだろう。
しかし、幾つかのAPI差分が存在する事によって全てをPBC APIで賄う事が出来ない。
(Users who put the first priority on the processing speed will want to implement all tasks on PBC API. But currently the difference between the APIs of PBC and REST prevents doing so.)
PBC API ではBacket Propertiesに対するアクセスが著しく制限されており、これはつまり事実上Backetの管理はREST APIでしか行い得ないという事であり、これは望ましくない。 (On PBC API, access to the bucket properties is very much restricted, and that suggests only the REST API is usable for supervising the buckets. This is not what I want.)
ある種のアプリケーションではエンドユーザ単位にBacketを作る、つまり大量のBacketを作っては捨てる事でアプリケーションの作りがシンプルで強力になるケースがある。(For some applications, making buckets for each user, which means making and discarding a lot of buckets, will simplify and strengthen the application design.)
Link Walking は非常に便利な機能であるのにPBC APIから使えないのは非常に残念な事だ。(Link Walking is a very convenient functionality; it's too bad you can't use it from PBC API.)
PBC API の RpbGetServerInfoResp は、REST API の/statsと同じ情報を返すべきだ。 (PBC API's RpbGetServerInfoResp should return the same information as in /stats of the REST API.)
RpbGetServerInfoRespは貧弱すぎて全く使い物にならない。 (RpbGetServerInfoResp is simply too weak to be usable.) /statsの中にはクライアントがRiakと自立協調動作する為に必要な多くの情報を含んでいる。 (The contents of /stats are informative with the necessary information for the clients which performs collaborative and autonomous functions with Riak.) クライアントが高速に動作する事を望むPBC APIのユーザこそがこれらの情報を望んでいる筈だ。(I believe that the PBC API users, who want to run a fast client, are the one who really want to have the information.)