Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rethinking argument un/packing for RPC calls #38

Open
ecpeterson opened this issue Feb 14, 2019 · 0 comments
Open

Rethinking argument un/packing for RPC calls #38

ecpeterson opened this issue Feb 14, 2019 · 0 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@ecpeterson
Copy link
Contributor

The current RPC message specification is built around the python calling convention: the |params| field of an |RPCRequest| object is populated by a dictionary with keys *args, a list of positional arguments, and **kwargs, a dictionary of named arguments. From a cross-language perspective, this is very idiosyncratic: other languages do not divide arguments up into these two classes, or at least not in quite the same way.

My preference is to eliminate position arguments entirely, to insist that all arguments be named, and for the |params| dictionary to house the value currently keyed on **kwargs. This solution has some awkward points:

  • This will be awkward for languages (e.g., C) that do not have a notion of named (or optional) parameters. I would hope that this can be mostly ameliorated through judicious use of macros: we can wrap RPC-server-generated calls to C functions with some helper that takes the task of unpacking the arguments based on their names in the C source.
  • This will require some migration of our internal software: we definitely have some packages that make use of positional arguments. As far as I can tell, there's no instance where this migration would be difficult, but it will require effort, time, and probably cross-repository PRs.

Countervailing opinions and alternate suggestions are welcome.

@ecpeterson ecpeterson added enhancement New feature or request question Further information is requested labels Feb 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant