Because I want the plugin to be able to access the binary resources of joplin, but there is currently no way to know the location of the Joplin root directory. Although I can scan the system process through nodejs or let the user fill it out, these are a bit troublesome. What do others think?
Why do you need access to the profile dir? Perhaps there's some other API that could be added to achieve what you want, without accessing binary resources directly?
Open this resource after click, but currently you need to manually configure the joplin root directory
ref: https://github.com/rxliuli/joplin-vscode-plugin/blob/dev/src/service/HandlerService.ts
Hmm, the way I see it the API should be thought as a server that may be running anywhere. Most likely on the user's computer, but technically it could be on a remote machine. With that in mind, you could approach the issue like you would with any remote API - just download the file to a temp folder and open it.
To download the file you can use /resources/:id/file (which I guess you're already using to display images) and once you got the file you can open it. It's less efficient that accessing the file locally directly but I expect for most files it shouldn't be an issue.
No, I won't do this, because modifying the attachment resource in resource will automatically synchronize. I don't want to create a temporary file and then manually control the synchronization. Is it possible to use plug-ins to extend the api?
I don't get that, it shouldn't. Synchronisation happens only when the resource metadata changes, not when the file changes. But in any case, it's not safe to directly change files in this directory, you'll have problems with conflicts or apps that will lock files.
I think what you need is access to the ResourceEditWatcher which perhaps could be made available via the /services end point.
1 Like
Just like this, an obvious usage scenario here is drawio.svg flow chart attachment resource. When I modify the file, I hope it can be synchronized automatically.
In addition, does the current modification of resources only modify the local content? So when will resource metadata change?
For the next pre-release, I've added access to the resource editing service:
openAndWatch
curl --data '{ "action": "openAndWatch", "resourceId": "RESOURCE_ID"}' \
'http://localhost:27583/services/resourceEditWatcher/?token=TOKEN'
stopWatching
curl --data '{ "action": "stopWatching", "resourceId": "RESOURCE_ID"}' \
'http://localhost:27583/services/resourceEditWatcher/?token=TOKEN'
isWatched
curl --data '{ "action": "isWatched", "resourceId": "RESOURCE_ID"}' \
'http://localhost:27583/services/resourceEditWatcher/?token=TOKEN'
I don't know if I want to make this part of the official API yet, but you can give it a try to see if it works for your app.
1 Like
Thank you very much, but there is a problem. When opening the attached file with Joplin Desktop, will the monitoring program be opened? For example, I opened test.txt in Joplin Desktop, modified some content, and then saved it. Will this be synchronized?
I find it difficult to guarantee that stopWatching will be called. For example, the user directly closes VSCode. Will there be any side effects? What if it is opened from Joplin Desktop?
Once you start watching a file, any change will be automatically saved (and later synced). Calling stopWatching is not critical I guess. If the user has finished editing the file, they won't change it anymore so it doesn't matter if the file is being watched or not.
ʻOpenAndWatch` does not need to open the file, only monitoring is enough. The application layer decides how to open it instead of joplin forcing it to use the system default program to open it.
Note 1: The openAndWatch including the previous noteAction is the same(The typical use case here is: Some files of vscode can be opened, but some cannot be opened, so it needs to be controlled in vscode plugin)
Note 2: Is it convenient to listen here to return the file path?
Are there any updates? @laurent
The current API simply exposes the existing resource watching service. At the moment, there's no plan to add more than this unfortunately.
Is it possible to remove the behavior of opening files?
Right, I see that just preventing it from auto-opening the file shouldn't be hard to add. It will be in v1.4 though since 1.3 is nearly ready for release.
1 Like
I hope to modify the openAndWatch of the previous noteAction to only watch instead of open (～￣▽￣)～