using Neon to surface the Rust opaque-ke "client login start" API to Node.js, along with some getters
Details
called the new APIs from a Node module and confirmed the results
Diff Detail
- Repository
- rCOMM Comm
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
keyserver/addons/opaque-ke-node/src/lib.rs | ||
---|---|---|
154–177 ↗ | (On Diff #18999) | These two seem to be almost identical. Can we somehow share the logic between them? |
keyserver/addons/opaque-ke-node/src/lib.rs | ||
---|---|---|
154–177 ↗ | (On Diff #18999) | I'm wondering if it would be worth implementing this API in a more object-oriented way. // in JS, instead of const startResult = clientLoginStart(...); const loginStateArray = getLoginStartStateArray(startResult); const loginMessageArray = getLoginStartMessageArray(startResult); // do this const startResult = clientLoginStart(...); const loginStateArray = startResult.getStateArray(); const loginMessageArray = startResult.getMessageArray(); But not sure how could this affect the complexity/readibility of this code and if it is even convenient to mix JsBox and JsObject |
I think the object oriented way is a bit cleaner, especially if everything needs to go through a context object anyway.
Personally I'm not a fan of get in method names, generally it's implied.
keyserver/addons/opaque-ke-node/src/lib.rs | ||
---|---|---|
154–177 ↗ | (On Diff #18999) | I wanted to do this in a more object-oriented way, but I couldn't figure out how to get data from a JsBox on the javascript side |
154–177 ↗ | (On Diff #18999) |
Can't think of a good way besides introducing an enum as a function param, but that adds a different kind of complexity... https://linear.app/comm/issue/ENG-2384/improve-the-opaque-ke-node-library |