spacedrive VS memfs

In the video, Mo talked about a few packages like Cidre and StrOm, and we referred to SpaceDrive.

AGPLv3 (switched in 2022 https://github.com/spacedriveapp/spacedrive/commit/8e5c71dea... ) and FWIW I don't see any mention of CLA or other license assignment, so I don't believe they can currently rug pull containing contributed changes since they don't own the license for them: https://github.com/spacedriveapp/spacedrive/blob/main/CONTRI...

Already opened a bug report for that: https://github.com/spacedriveapp/spacedrive/issues/1481

While Electron wouldn't be on top of my wishlist, if it looked nice and was functional I wouldn't mind at all. I found this project https://github.com/spacedriveapp/spacedrive which uses Tauri and seems to be very interesting, but they haven't released yet

In Tauri (or Axum) the app compiles to a single binary. rspc is the key to this because it allows for multiple transports with the frontend. It supports both Tauri IPC, HTTP or websockets. Our core crate (at ./core) exports an rspc router that is transport agnostic then within the apps (at ./apps/desktop or ./app/server) we expose it with a transport. We use Tauri IPC for desktop and websockets for Axum because we use subscriptions. Then in the wrapper React project (at ./apps/desktop/src/App.tsx) we create the rspc client with the Tauri link, mount its React context and then mount the app package (). You can give the codebase a look if you want cause it’s all open source https://github.com/spacedriveapp/spacedrive

Taking a departure from REST and GraphQL, I'd suggest checking out rspc instead of GraphQL and Prisma Client Rust as your ORM. Both have been developed by a coworker and I for Spacedrive, the company we work for, and have provided what we believe is the best Rust + TypeScript stack that doesn't use GraphQL (new GrpahQL server incoming one day tho).

This might help https://github.com/spacedriveapp/spacedrive

I am using the Python ecosystem (with full support for dynamic loading of C extension modules) as an initial motivating project. Also, the Python test suite is extremely useful to root out problems. I certainly hope that this can provide a more complete alternative to Emscripten to the community eventually. That said, Emscripten is huge, and the problems involved in creating a more maintainable modular WASM build tool are subtle. For example, when implementing a custom module loader for Python-wasm last week, I discovered several bugs in the memfs and unionfs Javascript libraries (https://github.com/streamich/memfs/pulls?q=is%3Apr+author%3A... and https://github.com/streamich/unionfs/pulls?q=is%3Apr+author%...). I had to learn the code sufficiently to fix all these bugs, submit PR's, etc. Emscripten has its own analogue of memfs, which is optimized specifically for WebAssembly in the browser, where memfs is a more general widely used library (with 10M+ downloads/week).

CoWasm has no support for asyncify. Where I've run into setjmp/longjmp so far, I've been rewriting the code instead. E.g., the dash shell uses setjmp/longjmp, and I'm rewriting that to use return error codes instead (see, e.g., https://github.com/sagemathinc/dash/commit/7117e1f6496728af0...).

> how would I go about porting a simple C->WASM w/ Typescript library project to CoWasm?

That's a great question, which I'm not sure how to quickly answer, so I've created a discussion item here https://github.com/sagemathinc/cowasm/discussions/40

Looks like this whole thing was motivated by the fact that, in order to get the encrypted PDF in a Buffer like they wanted, they had to save to disk and load it back. They could have instead used an in-memory filesystem such as https://github.com/streamich/memfs and just made the existing PDF library that was almost right use that.

How do I populate the input files? The filesystem API in emscripten talks about MEMFS, is that the same as this? https://github.com/streamich/memfs