My extension targets my Go SQLite bindings (the VFS is implemented in Go) [1].
This extension, and the wrapper, target public SQLite APIs, so if anyone wants to replace SQLite with libSQL, that should be easy.
You simply need to include a little bit of glue C code that I append to the amalgamation, and use some SQLite compile options.
I explicitly support building and providing your own, custom, Wasm SQLite "blob" (it just needs to include my glue code).
As for Adiantum encryption, as I said, reimplementing this in C/C++/Rust to make it a loadable extension is perfectly viable, and would be compatible with libSQL, again because this uses only public SQLite APIs (that's the point, basically!)
But this is predicated on it being a secure scheme (that's the feedback I was looking for this time around).
PS: I've got nothing against Turso, or libSQL. In fact I spent the last year perusing their virtual WAL API. The problem is that I found no documentation, nor any useful open source implementations of it. If there any I'd be very interested. So, thus far, I also don't have anything that drives towards libSQL.
> PS: I've got nothing against Turso, or libSQL. In fact I spent the last year perusing their virtual WAL API. The problem is that I found no documentation, nor any useful open source implementations of it. If there any I'd be very interested. So, thus far, I also don't have anything that drives towards libSQL.
Hey, this is v and I am an engineer at Turso. We do have some documentation and an example implementation of Virtual WAL
for an open source implementation, you may check how Bottomless works. Bottomless is another project which does back up like litestream and it internally implements a Virtual WAL.
I find that documentation completely insufficient to implement a virtual WAL. The example (which I had looked into) it's just a "do nothing" wrapper. I learn that there are 25 methods I should implement, and that I can just forward them to another implementation.
For my bindings, I implemented an entire SQLite VFS from scratch for a handful of different platforms, including file-locking and shared-memory primitives. However, and having studied your virtual WAL code for about a month, I still have no idea where to even start. It just doesn't feel like an coherent API (more like an internal SQLite API, simply exposed for outside use).
I'll look into Bottomless, but I'm not very hopeful at this point. Maybe it's just me and Rust; if that is so, I'm sorry.
This extension, and the wrapper, target public SQLite APIs, so if anyone wants to replace SQLite with libSQL, that should be easy.
You simply need to include a little bit of glue C code that I append to the amalgamation, and use some SQLite compile options.
I explicitly support building and providing your own, custom, Wasm SQLite "blob" (it just needs to include my glue code).
As for Adiantum encryption, as I said, reimplementing this in C/C++/Rust to make it a loadable extension is perfectly viable, and would be compatible with libSQL, again because this uses only public SQLite APIs (that's the point, basically!)
But this is predicated on it being a secure scheme (that's the feedback I was looking for this time around).
PS: I've got nothing against Turso, or libSQL. In fact I spent the last year perusing their virtual WAL API. The problem is that I found no documentation, nor any useful open source implementations of it. If there any I'd be very interested. So, thus far, I also don't have anything that drives towards libSQL.
[1] https://github.com/ncruces/go-sqlite3