You are absolutely right and thanks for pinpointing these issues. I was looking through a newer approach to handle resources and after reading your comment here is the final workflow I designed :-
- For resource encryption the encrypted resources will be saved in their exact path they were before in the resource folder.
- Yes its not right, so what I can do is instead of reading file buffer we can decrypt the resource directly in the
temp-cache folder by using the encryptionService().decryptFile() which already decrypt the resource in chunks making is more efficient and give the app the decrypted-filePath to render.
Resource does not get read while creating an embedd (e.g., <img src="local-vault://resource_id"> or <a href="local-vault://resource_id">). There are 2 different ways of how it will be handled :
FOR IMAGES :
Unless the image is in visible screen the editor treats it just as a normal embedd once its in the visible screen it asks the app for the image. (No need to handle this its the default behavior)
Here the app checks -> is the image locally_encrypted? If yes -> decrypt the resource chunk by chunk in temp-cache and hand it to the ui. No buffer.
FOR PDF:
When the pdf is clicked this line of code handles it :
const openItemById = async (itemId: string, hash?: string) => {
logger.info(`Navigating to item ${itemId}`);
const item: BaseItemEntity = await BaseItem.loadItemById(itemId);
if (item.type_ === ModelType.Note) {
await goToNote(itemId, hash);
} else if (item.type_ === ModelType.Resource) {
// here this part
await showResource(item);
} else {
throw new Error(`Unsupported item type for links: ${item.type_}`);
}
};
Simply intercept it with the same logic, is the pdf locally encrypted? YES -> decrypt in temp-cache -> Opens pdf
If the render pdf is on, it lies in the same section as the images so it is already handled in images section.
FOR VIDEOS:
It's either clickale or will be displayed, No new code needed the above 2 already handles this too.
You are correct about finally block being too risky and also about the multiple windows open edge case.
So the best way to handle it is deleting the temp-cache folder on the app's clean exit.
This solves the problem you mentioned, if both windows has same note open and one window closes no finally block runs now so other windows are still working + If the user again and again switch notes extra CPU will not be used to again and again decrypt the resource for the current session making the performance more better.
In case of crash, at the startup (begning of each new session) run a small lighweight command to just wipe off the temp-cache and start fresh with an empty folder. (The method I discussed before it)
