Skip to content

Conversation

coriolinus
Copy link
Collaborator

This is entirely untested and has certain known pain points and inefficiencies, but fundamentally it should demonstrate the viability of this kind of approach.


PR Submission Checklist for internal contributors

  • The PR Title

    • conforms to the style of semantic commits messages¹ supported in Wire's Github Workflow²
    • contains a reference JIRA issue number like SQPIT-764
    • answers the question: If merged, this PR will: ... ³
  • The PR Description

    • is free of optional paragraphs and you have filled the relevant parts to the best of your ability

What's new in this PR?

Issues

Briefly describe the issue you have solved or implemented with this pull request. If the PR contains multiple issues, use a bullet list.

Causes (Optional)

Briefly describe the causes behind the issues. This could be helpful to understand the adopted solutions behind some nasty bugs or complex issues.

Solutions

Briefly describe the solutions you have implemented for the issues explained above.

Dependencies (Optional)

If there are some other pull requests related to this one (e.g. new releases of frameworks), specify them here.

Needs releases with:

  • GitHub link to other pull request

Testing

Test Coverage (Optional)

  • I have added automated test to this contribution

How to Test

Briefly describe how this change was tested and if applicable the exact steps taken to verify that it works as expected.

Notes (Optional)

Specify here any other facts that you think are important for this issue.

Attachments (Optional)

Attachments like images, videos, etc. (drag and drop in the text box)


PR Post Submission Checklist for internal contributors (Optional)

  • Wire's Github Workflow has automatically linked the PR to a JIRA issue

PR Post Merge Checklist for internal contributors

  • If any soft of configuration variable was introduced by this PR, it has been added to the relevant documents and the CI jobs have been updated.

References
  1. https://sparkbox.com/foundry/semantic_commit_messages
  2. https://github.com/wireapp/.github#usage
  3. E.g. feat(conversation-list): Sort conversations by most emojis in the title #SQPIT-764.

This is entirely untested, but fundamentally it should demonstrate
the viability of this kind of approach.

Note that due to the `block_on` calls, when building for wasm the
user must ensure that this is running within a web worker.
@coriolinus coriolinus force-pushed the prgn/feat/impl-storagebackend branch from 87b1cd3 to d2d5a11 Compare September 10, 2025 09:05
Adds editor configuration, a makefile, documentation, and some
code adjustents to provide bindings to the `OpfsBackend` on WASM.

In general, we wouldn't expect web users to construct this directly:
it doesn't (yet) give them anything that they can't more conveniently
get by using the relevant APIs directly.

However, it's necessary to run this on a web worker, because
the necessary trait is synchronous. This means that we need to support
two use cases: where the "main" part of the rust code also runs on
a web worker, and where it does not.

Where the "main" part of the rust code runs on a web worker, then
things are easy: just add this as a dependency as shown in the readme
and everything stays fast and easy on the Rust side of the FFI boundary.

Where the "main" part of the rust code runs on the main thread, however,
then things are less easy. We need to let JS people launch this part
of the code on the worker, and provide a handle which they can give to
OPFS on the main thread. That handle will also implement the
`StorageBackend` trait, but it will do so by communicating with the
web worker. This part is not yet built. Still, having the design
in mind means that we know we will need a standalone struct which can
be created in JS-land, which we can then call `.handle()` on to
get that handle to pass back to the main thread. So that's why we have
this thing. We just need to write the handle.
@coriolinus coriolinus force-pushed the prgn/feat/impl-storagebackend branch 2 times, most recently from 3fb67e1 to 046173e Compare September 12, 2025 12:27
We're getting closer! We have now demonstrated that initializing
the wasm module can succeed. But the app still hangs on
`OpfsBackend.open`. So we need to sort that.
@coriolinus coriolinus force-pushed the prgn/feat/impl-storagebackend branch from 046173e to 5a8e140 Compare September 12, 2025 12:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant