Historical JS endpoints #2285
Historical JS endpoints #2285
Conversation
src/apps/js_generic/js_generic.cpp
Outdated
| auto kv_tx_id = tx.get_read_tx_id(); | ||
| ccf::TxID tx_id; | ||
| tx_id.view = static_cast<ccf::View>(kv_tx_id.term); | ||
| tx_id.seqno = static_cast<ccf::SeqNo>(kv_tx_id.version); |
There was a problem hiding this comment.
This is very annoying. I'm doing this so that I can to_str(). The casts are needed as kv::TxId uses signed, while ccf::TxID uses unsigned ints.
|
letmaik/js-historical-endpoints@20552 aka 20210315.17 vs main ewma over 20 builds from 20148 to 20500 |
samples/apps/logging/js/app.json
Outdated
| "execute_outside_consensus": "never", | ||
| "authn_policies": ["jwt", "user_cert"], | ||
| "historical": true, | ||
| "readonly": true, |
There was a problem hiding this comment.
Historical implies readonly, it would be elegant if the config reflected that.
There was a problem hiding this comment.
"mode": "readonly|writable|historical" ? Or were you thinking of something different?
There was a problem hiding this comment.
Yeah I think that'd be good. Paging @eddyashton for API input, but I think this would have the merit of ruling out historical: true, readonly: false and the validation and error that'd need to go with it.
There was a problem hiding this comment.
Yes, I think this is a tri-state enum. I like readonly and historical but not convinced by writable. I think readwrite is what we've used elsewhere (eg tx.rw)? I could also go for canwrite or maywrite or just write, but I think readwrite is best.
There was a problem hiding this comment.
readwrite is fine. I'll do the change.
There was a problem hiding this comment.
@achamayou @eddyashton Done, please have a final look if the change looks good.
|
Looks good! Can the logging JS section in the doc and the changelog be expanded accordingly please? |
Co-authored-by: Amaury Chamayou <[email protected]>
There's only a C++ section for logging currently. Let's do docs in another PR. |
| quickjs.enclave | ||
| PUBLIC -nostdinc -DCONFIG_VERSION="${QUICKJS_VERSION}" -DEMSCRIPTEN | ||
| -DCONFIG_STACK_CHECK | ||
| PRIVATE $<$<CONFIG:Debug>:-DDUMP_LEAKS> |
There was a problem hiding this comment.
Just to check, this is saying "when building this target in Debug, set DUMP_LEAKS", right?
| export type Proof = ProofElement[]; | ||
|
|
||
| export interface Receipt { | ||
| signature: string; |
There was a problem hiding this comment.
Could we add a jsdoc comments like /** base64-encoded signature of the root by the node identified by nodeId */, and if we did, would it get picked up by sphinx-js? Just wondering, not requesting :)
There was a problem hiding this comment.
Yes and yes, see the CryptoKeyPair interface in #2313
No description provided.