Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide photos in a way that can be consumed by the front-end #115

Closed
2 tasks
gmaclennan opened this issue Jun 22, 2023 · 2 comments · Fixed by #117
Closed
2 tasks

Provide photos in a way that can be consumed by the front-end #115

gmaclennan opened this issue Jun 22, 2023 · 2 comments · Fixed by #117
Assignees

Comments

@gmaclennan
Copy link
Member

Description

We store photos in the blob store, and we need to display these photos in the frontend. In Mapeo 5 photos are just stored as files, and to display them we pass a file path to the front end, which sets the file path as the src for an image. This is quick and efficient. We don't have a file path for images stored in the blob store.

Passing the images around as blobs is not really an option. React Native (and the bridge we use) does not support buffers, so they would need to be encoded to Base64 or equivalent. This has big memory and performance overheads. In addition, in React Native images are actually drawn on the UI thread, not the thread that the JS code is running, so this blob needs to go across another bridge (the React Native -> mobile Native world) to be displayed. This will be really expensive for performance.

A couple of options:

  1. Serve the images via a local http server
  2. Use MirrorDrive to copy the hyperdrive to disk
  3. Copy files to disk on-demand to cache storage and cleanup after, e.g. add a mapeo.getBlobFilePath(blobId) method that will copy to cache storage, and cleanup if not accessed for a while.

I think (2) will use up too much disk space and is not really an option due to space restrictions on mobile. (3) will use less disk space, but it can still be an issue. (1) is clunky, but it might end up being less work than trying to deal with the caching of (3).

We also need to bear in mind the upcoming audio and video file storage, which will have similar requirements.

Tasks

  • Decide which approach is going to work best
  • Implement the API for this
@ximenabb
Copy link

ximenabb commented Jun 26, 2023

@achou11 @gmaclennan can you both chat and see if this ticket needs to be separated into research and implementation? keep @sethvincent in the loop

@ximenabb ximenabb assigned achou11 and unassigned achou11 Jun 26, 2023
@achou11
Copy link
Member

achou11 commented Jun 28, 2023

Discussed with @gmaclennan and decided that implementing an HTTP server will be the most reasonable approach for this.

@gmaclennan gmaclennan moved this from 🔖 Todo to 🏗 In progress in Mapeo - Sprint 2023 (Archived) Jul 6, 2023
@gmaclennan gmaclennan moved this from 🏗 In progress to 👀 In review in Mapeo - Sprint 2023 (Archived) Jul 7, 2023
@achou11 achou11 self-assigned this Jul 17, 2023
@github-project-automation github-project-automation bot moved this from 👀 In review to ✅ Done in Mapeo - Sprint 2023 (Archived) Jul 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants