Thanks Chris for your mail.
We've started exploring different RPC techniques as we plan to write glusterd 2.0 in go and it seems like go doesn't have sun RPC library support. All the details will be put up once we share the glusterd 2.0 high level plan.
Having said that, we'd definitely consider your points in terms of designing it. Also any form of contribution for glusterd 2.0 Is more than welcome :)
-Atin
Sent from one plus one
On Jul 31, 2015 10:43 PM, "chris holcombe" <chris.holcombe@xxxxxxxxxxxxx> wrote:
I've been working on writing a gluster library that speaks the native RPC to gluster so that I could avoid using the CLI. I've been successful but the endeavor has brought up some interesting insights. I plan on open sourcing the code so that everyone can benefit from this.
struct gf_cli_req {
opaque dict<>;
};
and
struct gf_cli_rsp {
int op_ret;
int op_errno;
string op_errstr<>;
opaque dict<>;
};
are used to make a lot of the CLI calls. The opaque dict passing back and forth creates a need for string parsing on both sides. My understanding of RPC was that each call would have its own struct associated with it so that no parsing need happen. It would also make it much easier for other people to build libraries to interface with Gluster if the call parameters were clearly defined. Each time I want to make a call work with glusterd 1.0 I need to figure out what parameters need to be packed into the dict. This involves some hunting.
Since glusterd 2.0 is a refactoring I figured this would be a good time to ask for adding additional more explicit RPC calls to the API. That would make it a breeze to run an rpcgen command against the .x file and have a working library to glusterd!
Thanks,
Chris
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
