rfc: Electron C APIs #3
Conversation
|
|
||
| There is no restriction on API names, and it is not recommeneded to prefix the APIs with `electron_` unless they directly manipulates things of Electron. | ||
|
|
||
| This is because the actual implementations of C APIs may not necessarily reside in Electron's codebase, and we may not have control of its API names. |
There was a problem hiding this comment.
I'm not sure I understand why this might occur in practice. In the skia example, would Electron be exposing headers for Chromium's included version of skia?
There was a problem hiding this comment.
Skia is a C++ library that does not have stable APIs, exposing its headers won't be very useful in practice. To provide C APIs for it we have to write a translation layer.
Another better example is the ui/views library of Chromium, to provide C APIs for it we will need a non-trivial project. I have actually made a demo which I plan to introduce as the first set of C APIs to include in Electron some time later: https://github.com/photoionization/chrohime.
There was a problem hiding this comment.
The idea of allowing folks to extend Electron without needing to go through the review process or forking is certainly appealing.
If you're open to it, I think scheduling a meeting within the API WG to go over chrohime and how this RFC enables its efforts would go a long way in getting more attention here.
There was a problem hiding this comment.
Yeah I'm good with it, thanks for bringing it up!
|
|
||
| Most components of Chromium are written in C++, and to expose C APIs for them a separate C wrapper must be written, and they may require extra maintaince work during Chromium upgrades. | ||
|
|
||
| A possible stratege to solve this is to ask the implementation of C wrapper to live outside Electron's codebase, and only be included in Electron as an optional componenet which can be easily turned off, so it won't add up to the maintaince work of Chromium upgrades. |
There was a problem hiding this comment.
If a component were disabled during an upgrade, how might app developers discover whether it's supported in newer versions? Would maintaining a supported status for each C API be needed?
There was a problem hiding this comment.
Yeah I think we will need to maintain an updated documentation for the status of C APIs.
|
|
||
| ### External JavaScript bindings | ||
|
|
||
| For Electron apps to make use of the C APIs, they usually want to use JavaScript APIs instead of writing all the code in C. In which case a JavaScript bindings also needs to be implemented for the C APIs, and the separated layer can be difficult to use when the JavaScript bindings get out of sync with changes in the C APIs. |
There was a problem hiding this comment.
Thinking beyond JS, I wonder if wasm's component model could be used to enable support to other languages. This may be a larger discussion than the scope of this RFC though.
There was a problem hiding this comment.
We can probably wait to see how Node.js and Chromium will support it first.
|
|
||
| ## Unresolved questions | ||
|
|
||
| The API and ABI stability of C APIs are not covered in this RFC. I think if a set of C APIs has been depended on so much that we actually need to promise API and ABI stability for them, we should probably make them built-in JavaScript APIs, or the independent C library version of the APIs should have already gained enough popularity that it no longer needs Electron team's resources to go on developing. |
There was a problem hiding this comment.
I think a stages process could be useful in defining a path towards stability—somewhat similar to ECMAScript's stages. Probably not necessary until significant community contributions are made.
This RFC is modified from the Electron C APIs spec doc with implementation details added, which can be used to bootstrap some basic facilities.