Ok…I reviewed the video. Basically, if you add the messaging we’ve been working on at Origyn with the CanDB stuff and add transactions I think you get this system. And most of it is already built
We need open-source Motoko and rust clients as well. Right now CanDB mostly assumes that you are working from an outside application and using JS. But I think we can abstract it to a simple interface…even with transactions.
In addition, we’ll be adding icrc_16 candy-like structures that with the proper libraries should allow you to cast back and forth from generic data structures to strongly typed data structures.
Help would be greatly appreciated as we’re a bit spread thin at the moment.
@berestovskyy Great feature! I enjoyed the presentation and discussion today.
As I mentioned in the meeting, I think it’d be great to roll out a “trapdoor” to the system-call tracking that’s planned in the future.
While the tracking is meant to make each query “correct” (reflect the current system state), there may also be a use case for caching “stale” system state. If a query uses the trapdoor version of a call, it would get that state, save it, and not invalidate future matches that get a different version from the trapdoor.
The main use case for this feature is for developers to get access to the internal state of the system when a cached call occurs (for whatever purpose that is helpful, e.g., diagnostics or debugging something else) without inhibiting the caching and reuse of that call.
Very impressive work, great presentation. We didn’t talk much about the challenges with implementing this for composite queries, I would love to know if that will be difficult or if it’s relatively straight-forward.
I agree. Just to be clear, System API tracking seems like a very lowest hanging fruit for now, and we will focus on that during our next iteration. Later it will be clear if there are still lots of queries which requiring further optimizations…
AFAIK the initial implementation of the composite queries won’t support cross-subnet calls, so it seems quite straightforward to keep the cache coherency.
It will be much easier to prioritize this once we have some numbers in hands. If most of the queries are composite, it might be worth focusing on this even if the engineering effort is significant…
This week we’ll have a presentation from OpenChat for the Scalability and Performance WG. They’ll talk about some of the tricks they use to keep the UX snappy in OpenChat (both on the frontend and in the canisters).
Thursday October 19th at 5:30 pm CEST (GMT+2) Zoom link
Due to some scheduling issues, the WG won’t be happening this month. But we’ll be back next month and changing the date to December 14th so that we don’t interfere with holiday vacations.
Hi everyone,
I’m excited to announce that this week we’ll have Timo Hanke(@timo) talking about the High Performance Ledger at the Scalability and Performance WG.
Thursday December 14th at 5:30 pm CEST (GMT+2) Zoom link
