I thought that the following pattern would be preferable in an async world.
fn update(x_transid: i64, key:i32, value:i32) → bool {
// x_transid is expcted to be unique. Only one call to x_transid will succeed in external call ; if at all…every other call will fail
// therefore reducers will ALWAYS return true
}
fn lookup(x_transid: i64, key: i32) → bool {
// did update suceed in external call with key being updated with attached x_transid
}
So you make the call to update; but rely on lookup to know whether the update actually suceeded. Of course support is required from the external system.
Well observed! Indeed, we are implementing a simple sample dApp in Rust and Motoko. The dApp will pull ICP exchange rates from Coinbase and offer the rates over an on-chain API.
What the feature will be capable of is to allow canisters to make GET requests to external services and receive the (transformed) response. If responses of the Web 2 server are not deterministic, you need to define a transform function to make it deterministic, i.e., remove non-deterministic attributes like timestamps and session ids. This allows then all replicas to receive the same transformed response and let consensus agree on it.
POST
Doing POST calls is a rather small extension that would be added after an initial release. Doing a post with this feature assumes that the Web 2 service can handle that the same request be made by all nodes of the subnet. Web 2 services that support the Idempotency-Key header as specified in the draft RFC should work for correctly processing POST requests when using the Idempotency-Key header in the request.
It’s definitely not implemented by every service. So this is something that practically limits the possibility of POST requests to Web 2.0 HTTP-based services using the current version of this feature.
We are currently wrapping up the MVP implementation of the feature, only a few small things remain to be done. We plan to launch the feature in July. The MVP will be an IPv6-only launch for the reason of our replicas not having IPv4 addresses. Going via boundary nodes, as initially planned, may be added at a later stage, but the main issue is that all subnets then share the rate limits of services as we only have 10-20 boundary nodes currently.
What is missing now are the following items:
Merge some MRs that are under review
Finish the sample dApp demonstrating the feature (ICP price quotes from Coinbase)
HEAD and POST extensions and corresponding system test
Local https-capable setup for system tests (currently going via external site); requires support for self-signed certificates
Enable SDK (almost done, still requires replica with feature to be shipped)
Cycles charging: decision on price (under discussion)