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

41–49 of 49 posts

Re: SQLite builds for WASI since 3.41.0

#41

Post by remram »

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.

They can still destroy your site, they just can't destroy anything else on the same server.

Re: SQLite builds for WASI since 3.41.0

#42

Post by angelmm »

lioeters wrote: post #39
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…

> these projects use Emscripten, but in the future the same Wasm32-wasi module will work I'm curious to know more about this. Does it mean that when browsers support WASI, these projects will not need to use Emscripten? Or maybe use it for compiling to/with WASI but without the need for a runtime anymore. Is there anywhere I can keep track of when/how this might happen?

Those are great questions! I believe Emscripten will be required for some cases as it provides more features for targeting a Web Browser. If WASI is the only requirement for a Wasm module, then there are three possible solutions:

- Use a library that provides the WASI bindings in a browser environments: there are some OSS projects that provides WASI bindings on top of browser technologies. For example, workers-wasi from Cloudflare [1]. It could be even another Wasm module that provides the implementation for the main one. I know the people from Loophole Labs are experimenting with virtual filesystems (VFS) [2].

- Browsers provides a WASI implementation: server-oriented runtimes like NodeJS are already providing these bindings (under a experimental flag). I shouldn't have stated that as a fact, as browsers may provide it or not. However, I saw in the past the Google Chrome team experimenting with WASI and the browser FileSystem API [3]. So, I think it may happen :)

- [1] https://github.com/cloudflare/workers-wasi

- [2] https://www.youtube.com/watch?v=46jZSXVxYPw

- [3] https://github.com/GoogleChromeLabs/wasi-fs-access

Re: SQLite builds for WASI since 3.41.0

#43

Post by foota »

jraph wrote: post #31
foota wrote: post #22

Earlier quoted context omitted.

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? There's something specific about the public domain that in many places, you can't just decide to release something in the public domain. I guess that's why they actually accept contribution but require an affidavit dedicating the contribution into the public domain. IIUC an affidavit specifically needs to be witnessed by taker of oaths, which probabl…

Ah, it sounds like there are a variety of laws throughout the world. It does sound like the US recently moved to allow digital signatures for this and related purposes though. See https://scarincihollenbeck.com/law-firm-insights/copyright-o...

Re: SQLite builds for WASI since 3.41.0

#44

Post by stavros »

jraph wrote: post #10
raybb wrote: post #5

> For legal reasons, we could not contribute directly (their patches) What were the legal reasons?

Most likely what is documented at https://sqlite.org/copyright.html > SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution. In order to keep SQLite in the public domain and ensure that the code does not become contaminated with proprietary or licensed content, the project does not accept pa…

Why can they not just license the thing under CC0? Won't someone contributing implicitly understand that their contribution will also be licensed under CC0? This feels like it's more complicated than it needs to be.

Re: SQLite builds for WASI since 3.41.0

#45

Post by aldonius »

stavros wrote: post #44
jraph wrote: post #10

Earlier quoted context omitted.

Most likely what is documented at https://sqlite.org/copyright.html > SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution. In order to keep SQLite in the public domain and ensure that the code does not become contaminated with proprietary or licensed content, the project does not accept pa…

Why can they not just license the thing under CC0? Won't someone contributing implicitly understand that their contribution will also be licensed under CC0? This feels like it's more complicated than it needs to be.

Well for starters, SQLite is almost a decade older than CC0...

Re: SQLite builds for WASI since 3.41.0

#46

Post by stavros »

aldonius wrote: post #45
stavros wrote: post #44

Earlier quoted context omitted.

Why can they not just license the thing under CC0? Won't someone contributing implicitly understand that their contribution will also be licensed under CC0? This feels like it's more complicated than it needs to be.

Well for starters, SQLite is almost a decade older than CC0...

So? No reason they can't use it now.

Re: SQLite builds for WASI since 3.41.0

#47

Post by ncruces »

I think this should come with the disclaimer that this completely eschews synchronization mechanisms used by SQLite.

Using this to read from a DB concurrently with other writers will produce garbage results. Using this to write to a DB concurrently with other writers will corrupt your DB.

WASI does not expose file locking primitives, and the unix VFS simply stubs them out in WASI builds: https://github.com/sqlite/sqlite/blob/4e8e33ba84e253878797d7...

Re: SQLite builds for WASI since 3.41.0

#49

Post by lioeters »

angelmm wrote: post #42
lioeters wrote: post #39

Earlier quoted context omitted.

> these projects use Emscripten, but in the future the same Wasm32-wasi module will work I'm curious to know more about this. Does it mean that when browsers support WASI, these projects will not need to use Emscripten? Or maybe use it for compiling to/with WASI but without the need for a runtime anymore. Is there anywhere I can keep track of when/how this might happen?

Those are great questions! I believe Emscripten will be required for some cases as it provides more features for targeting a Web Browser. If WASI is the only requirement for a Wasm module, then there are three possible solutions: - Use a library that provides the WASI bindings in a browser environments: there are some OSS projects that provides WASI bindings on top of browser technologies. For example, workers-wasi f…

I appreciate the response, thank you! I've really enjoyed following the explorations of Wasm Labs.
Post reply on HN