Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SQLite builds for WASI since 3.41.0

wasmlabs.dev

Post reply on HN
Print view View original

21–30 of 49 posts

Re: SQLite builds for WASI since 3.41.0

#21

Post by KronisLV »

jillesvangurp wrote: post #15
jraph wrote: post #8

> For legal reasons, we could not contribute directly, but we could discuss the required changes with someone from the SQLite team and then iterate with them by testing or commenting. Ah, here's the catch! I knew SQLite didn't accept code contributions, I was suprised they managed to contribute anyway, and then this sentence clarified the situation. So they indeed did not manage to contribute their code itself, but t…

https://www.sqlite.org/copyright.html To summarize, instead of using one of the OSS licenses, the copyright holders simply declare the source to be in the public domain. In order to preserve that status they don't accept patches unless you submit some signed document that you agree with that. To make things more complicated, they also use their a relatively niche version management system instead of git. Which would…

> To make things more complicated, they also use their a relatively niche version management system instead of git. Which would complicate making contributions (if they accepted them).

The Fossil VCS actually has a page explaining why it was created, instead of just using Git: https://sqlite.org/whynotgit.html

Honestly, a lot of those points make sense, especially how Git is perhaps a little bit more complex and tricky to wrap one's head around than it should be, making you think more about the VCS than just what you want to do. To that end, I'd actually suggest that people have a brief look at Fossil, it even comes with a built in web interface and some common functionality out of the box (vs most folks needing to setup Gitea/GitLab or use GitHub/Bitbucket etc. separately): https://fossil-scm.org/home/doc/trunk/www/index.wiki

Of course, realistically, Fossil will be dead in the water for most, given that it's still niche and won't have integrations with any graphical software that some might want to use (e.g. SourceTree, GitKraken, Git Cola exist, but I'm not aware of a rich ecosystem of solutions for Fossil, something like Fuel seems dead https://fuel-scm.org/fossil/brlist), or even with any CI/CD server solutions.

Re: SQLite builds for WASI since 3.41.0

#22

Post by foota »

jraph wrote: post #12
foota wrote: post #9

Earlier quoted context omitted.

Looks like this: https://www.sqlite.org/copyright.html Kind of weird, couldn't they use a CLA?

It's not enough to guarantee the code has not been copied from somewhere / can be released in the public domain. The only way to have this guarantee is to write it yourself.

I suppose that's true, but that's no different from any other project, no? If I write a contribution to React that wasn't actually mine, it doesn't matter that it's just open source and not being released into the public domain, it's still a violation of the real author's copyright.

So if they've chosen a different risk model than essentially every other company doing open source software then that's up to them, but I'm not sure the need for it follows from it being public domain?

Re: SQLite builds for WASI since 3.41.0

#23

Post by angelmm »

aargh_aargh wrote: post #2

What would you use this for? I don't get the whole picture and the article doesn't talk about it.

(Wasm Labs team member here) SQLite is a pretty popular database and it's a critical dependency for many different applications. By compiling it to Wasm32-wasi, you can add it to any WebAssembly module.

This enables a new set of possibilities for Wasm and SQLite. For example, now you can run a full WordPress application in the browser [1][2] / server [3] using the same Wasm module. Note that for the browser these projects use Emscripten [4], but in the future the same Wasm32-wasi module will work. A teammate gave a lightning talk about SQLite and WASI at KubeCon EU [5].

In general, any environment that includes a wasm runtime can potentially run applications that uses SQLite under the hood. Before, it wasn't possible.

- [1] https://wordpress.wasmlabs.dev/

- [2] https://developer.wordpress.org/playground/demo/

- [3] https://wasmlabs.dev/articles/running-wordpress-with-mod-was...

- [4] https://emscripten.org/

- [5] https://www.youtube.com/watch?v=E7tWtgf9V2s

Re: SQLite builds for WASI since 3.41.0

#24

Post by angelmm »

aargh_aargh wrote: post #16
fastball wrote: post #11

Earlier quoted context omitted.

The goal of WASI is to add a standardized system API to WebAssembly, allowing you to access underlying systems (filesystem, networking, etc) in a homomorphic and secure way. In practice, this means that you can compile your Rust/C++/etc code to WASM + WASI, and that code will run anywhere you have a WebAssembly VM. So the same code that accesses the "filesystem" in a browser context can also access the filesystem in…

What I don't get specifically is what's being implemented here with SQLite. Assuming WASI is an interface an application can call into for things like filesystem access, sockets, does this add SQLite as interface (analogously to sqlite.h) next to these as part of WASI? So SQLite will be "under" the interface, i.e. part of a standard runtime? How much "batteries included" is this runtime (planned to be)? If I understo…

The main work behind this patch is to ensure that SQLite can compile to Wasm32-wasi. WASI doesn't offer all syscalls that SQLite may require, so it may require some conditional definitions and code to ensure it works properly. It doesn't mean that SQLite is part of WASI, but you can embed SQLite in a Wasm32-wasi module.

In the future, the WASI standard will include more and more features. This will allow SQLite to enable more internal features that are currently skipped due to the limitations on WASI.

Re: SQLite builds for WASI since 3.41.0

#25

Post by i2cmaster »

angelmm wrote: post #23
aargh_aargh wrote: post #2

What would you use this for? I don't get the whole picture and the article doesn't talk about it.

(Wasm Labs team member here) SQLite is a pretty popular database and it's a critical dependency for many different applications. By compiling it to Wasm32-wasi, you can add it to any WebAssembly module. This enables a new set of possibilities for Wasm and SQLite. For example, now you can run a full WordPress application in the browser [1][2] / server [3] using the same Wasm module. Note that for the browser these pro…

I guess that's one way to prevent malicious plugins from destroying your site.

Re: SQLite builds for WASI since 3.41.0

#26

Post by gorgoiler »

jillesvangurp wrote: post #15
jraph wrote: post #8

> For legal reasons, we could not contribute directly, but we could discuss the required changes with someone from the SQLite team and then iterate with them by testing or commenting. Ah, here's the catch! I knew SQLite didn't accept code contributions, I was suprised they managed to contribute anyway, and then this sentence clarified the situation. So they indeed did not manage to contribute their code itself, but t…

https://www.sqlite.org/copyright.html To summarize, instead of using one of the OSS licenses, the copyright holders simply declare the source to be in the public domain. In order to preserve that status they don't accept patches unless you submit some signed document that you agree with that. To make things more complicated, they also use their a relatively niche version management system instead of git. Which would…

From an administrative stance, I’m sure any project would happily consider a patch if you emailed it to them.

For local work, you can easily dump a codebase into your favourite version control system, work on it, then generate the final patch using your VCS’s tooling. Iterating towards a working change is as easy (or as hard) as exchanging patches between the feature developer and the committer of the upstream project.

It’s a bit old school, but it’s a good workflow to become comfortable with. I regularly patch my own private projects from my work account by emailing patches to my personal address. Once you compress and base64 a change it’s also humbling how little content goes into a piece of work!

(This isn’t a rebuttal to the parent post — more a call to arms that patch juggling isn’t as awful as others might think it is.)

Re: SQLite builds for WASI since 3.41.0

#27

Post by [deleted] »

aargh_aargh wrote: post #16
fastball wrote: post #11

Earlier quoted context omitted.

The goal of WASI is to add a standardized system API to WebAssembly, allowing you to access underlying systems (filesystem, networking, etc) in a homomorphic and secure way. In practice, this means that you can compile your Rust/C++/etc code to WASM + WASI, and that code will run anywhere you have a WebAssembly VM. So the same code that accesses the "filesystem" in a browser context can also access the filesystem in…

What I don't get specifically is what's being implemented here with SQLite. Assuming WASI is an interface an application can call into for things like filesystem access, sockets, does this add SQLite as interface (analogously to sqlite.h) next to these as part of WASI? So SQLite will be "under" the interface, i.e. part of a standard runtime? How much "batteries included" is this runtime (planned to be)? If I understo…

[deleted]

Re: SQLite builds for WASI since 3.41.0

#29

Post by gzurl »

i2cmaster wrote: post #25
angelmm wrote: post #23

Earlier quoted context omitted.

(Wasm Labs team member here) SQLite is a pretty popular database and it's a critical dependency for many different applications. By compiling it to Wasm32-wasi, you can add it to any WebAssembly module. This enables a new set of possibilities for Wasm and SQLite. For example, now you can run a full WordPress application in the browser [1][2] / server [3] using the same Wasm module. Note that for the browser these pro…

I guess that's one way to prevent malicious plugins from destroying your site.

Yes, exactly. We wrote an article here regarding PHP on Wasm that covers that: https://wasmlabs.dev/articles/mitigating-php-vulnerabilities...

Re: SQLite builds for WASI since 3.41.0

#30

Post by ridruejo »

samwillis wrote: post #6
aargh_aargh wrote: post #2

What would you use this for? I don't get the whole picture and the article doesn't talk about it.

So far the official WASM support from the SQLite project have only targeted WASM in the browser with a JS API. If I follow correctly this is about working with the SQLite team to upstream WASI support, which will eventually enable official support for it, and hence WASM on the server/cloud/edge and other WASI complement runners.

Correct!
Post reply on HN