Skip to content
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.

Parity-as-a-library #4842

Closed
2 tasks
rphmeier opened this issue Mar 9, 2017 · 9 comments
Closed
2 tasks

Parity-as-a-library #4842

rphmeier opened this issue Mar 9, 2017 · 9 comments
Assignees
Labels
F8-enhancement 🎊 An additional feature request. M4-core ⛓ Core client code / Rust.
Milestone

Comments

@rphmeier
Copy link
Contributor

rphmeier commented Mar 9, 2017

  • APIs for running full and light nodes
  • C interface
@rphmeier rphmeier added F8-enhancement 🎊 An additional feature request. M4-core ⛓ Core client code / Rust. labels Mar 9, 2017
@rphmeier
Copy link
Contributor Author

rphmeier commented Mar 9, 2017

...and then the ability to cross-compile this library to IOS and Android.
@debris in your experience what will be the hardest part of that?

@debris
Copy link
Collaborator

debris commented Mar 10, 2017

... what will be the hardest part of that?

Probably cross-compiling libraries containing C code... Besides that, writing C interfaces itself, cause it's super time consuming

@arkpar
Copy link
Collaborator

arkpar commented Mar 10, 2017

The C interface can be simple enough. It's mostly configuration, creating, starting and stopping Parity service and polling for status to detect critical errors. In the simplest implementation configuration can be done by passing text in toml format. So basically just 3 functions.

parity_service_handle parity_create(const char* config);
void parity_destroy(parity_service_handle handle);
void parity_poll_status(parity_service_handle handle, parity_status* status);

All other communication goes over RPC/IPC.

If we want to expose our rich API to C, these bindings need to be auto-generated from RPC traits.

@rphmeier
Copy link
Contributor Author

rphmeier commented Mar 10, 2017

That definitely seems like a good approach.
I wonder about the viability of running an RPC server for a hosted node within an app. We might want to just have a native code RPC endpoint

char* parity_rpc(parity_service_handle handle, const char* request);
which just wraps a thread pool + event loop + future.wait() internally.
I'm not sure if null-terminated strings is the best approach here as it's probably for FFI, and most languages these days would deal in a [ptr, len] pair, but the basic idea stays the same.

@adrianbrink
Copy link

adrianbrink commented Apr 4, 2017

@debris But wouldn't that be the worry of an implementor to compile libraries that contain C code. From our side we would only need to worry about writing the C interfaces (which will take a lot of time).

@adrianbrink
Copy link

To expose the C api something like rusty-binder or rusty-cheddar would be good to use.

Also, let's see if the rust team will support this in the future.

@rphmeier
Copy link
Contributor Author

rphmeier commented Apr 5, 2017

@adrianbrink I think @debris was referring to C/C++ libraries we have as dependencies, which may be hard to cross-compile.
To expose a C API we can just use #[no_mangle] pub extern fn in Rust code.

@adrianbrink
Copy link

Oh right. Didn't know parity had C/C++ deps.
Yeah, rusty-cheddar/binder could be used then to auto-generate the C header files.

@5chdn 5chdn added the Z3-stale 🍃 Issue is in principle valid, but it is not relevant anymore or can not reproduced. label Sep 4, 2017
@5chdn 5chdn closed this as completed Sep 4, 2017
@tomaka
Copy link
Contributor

tomaka commented Mar 22, 2018

Reopening as I'm going to work on this soon-ish.

@tomaka tomaka reopened this Mar 22, 2018
@tomaka tomaka removed the Z3-stale 🍃 Issue is in principle valid, but it is not relevant anymore or can not reproduced. label Mar 22, 2018
@tomaka tomaka self-assigned this Mar 22, 2018
@5chdn 5chdn added this to the 1.11 milestone Mar 23, 2018
@5chdn 5chdn modified the milestones: 1.11, 1.12 Apr 24, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
F8-enhancement 🎊 An additional feature request. M4-core ⛓ Core client code / Rust.
Projects
None yet
Development

No branches or pull requests

6 participants