beenull/ente
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Not yet sure how but desktop drag drops have the full path

Browse source
This commit is contained in:
Manav Rathi 2024-04-27 20:38:49 +05:30
parent 7836562ff1
commit 9a37141d29
No known key found for this signature in database
1 changed files with 23 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

34
web/apps/photos/src/services/upload/uploadService.ts
View file

@ -431,9 +431,17 @@ export const uploader = async (
*
* The file can be either a web
* [File](https://developer.mozilla.org/en-US/docs/Web/API/File) or the absolute
* path to a file on desk. When and why, read on.
* path to a file on desk.
*
* This code gets invoked in two contexts:
* tl;dr; There are three cases:
*
* 1. web / File
* 2. desktop / File
* 3. desktop / path
*
* For the when and why, read on.
*
* The code that accesses files (e.g. uplaads) gets invoked in two contexts:
*
* 1. web: the normal mode, when we're running in as a web app in the browser.
*
@ -450,27 +458,31 @@ export const uploader = async (
*
* In the desktop context, this can be either a File or a path.
*
* 1. If the user provided us this file via some user interaction (say a drag
* 2. If the user provided us this file via some user interaction (say a drag
* and a drop), this'll still be a File.
*
* 2. However, when running in the desktop app we have the ability to access
* 3. However, when running in the desktop app we have the ability to access
* absolute paths on the user's file system. For example, if the user asks us
* to watch certain folders on their disk for changes, we'll be able to pick
* up new images being added, and in such cases, the parameter here will be a
* path. Another example is when resuming an previously interrupted upload -
* we'll only have the path at hand in such cases, not the File object.
*
* Case 2, when we're provided a path, is simple. We don't have a choice, since
* we cannot still programmatically construct a File object (we can construct it
* on the Node.js layer, but it can't then be transferred over the IPC
* boundary). So all our operations use the path itself.
*
* Case 3 involves a choice on a use-case basis, since (a) such File objects
* also have the full path (unlike the bona-fide web File objects that only have
* a relative path), and (b) neither File nor the path is a better choice that
* would be for all scenarios.
*
* The advantage of the File object is that the browser has already read it into
* memory for us. The disadvantage comes in the case where we need to
* communicate with the native Node.js layer of our desktop app. Since this
* communication happens over IPC, the File's contents need to be serialized and
* copied, which is a bummer for large videos etc.
*
* So when we do have a path, we first try to see if we can perform IPC using
* the path itself (e.g. when generating thumbnails). Eventually, we'll need to
* read the file once when we need to encrypt and upload it, but if we're smart
* we can do all the rest of the IPC operations using the path itself, and for
* the read during upload using a streaming IPC mechanism.
*/
const readFileOrPath = async (
fileOrPath: File | string,
@ -1040,7 +1052,7 @@ const withThumbnail = async (
} else {
// There isn't a normal scenario where this should happen.
// Case 1, should've already worked, and the only known
// reason it'd have been skipped is for image files on
// reason it'd have been skipped is for image files on
// Windows, but those should be less than 100 MB.
//
// So don't risk running out of memory for a case we don't