Upload zip about rmapi HOT 8 CLOSED

+1.
We could call this a raw upload.

If we add more and more actions to the shell command, it could be interesting to thing about having more verbose commands, subcommands or arguments. If we end up having lots of geta, geto, put, putr, I think it can lead to confusion.

Maybe something as put raw mynote.zip that would differ from put file myfile.pdf.

The overall interface would make more sense.

What do you think?

from rmapi.

Sounds good @lobre. On the other hand it should be easy to detect if a file is raw, pdf, or epub. So different commands may not be needed for uploading after all.

Besides the raw upload, to enable some kind of selective synchronization, we may need to track and manage IDs locally. Do you have any thoughts on that? We may need to introduce a separate unique local ID to each document and store the mapping to remote IDs.

from rmapi.

Sounds good @lobre. On the other hand it should be easy to detect if a file is raw, pdf, or epub. So different commands may not be needed for uploading after all.

Yeah, I was also thinking along these lines, we could always detect the file and overload the put command.

Besides the raw upload, to enable some kind of selective synchronization, we may need to track and manage IDs locally. Do you have any thoughts on that? We may need to introduce a separate unique local ID to each document and store the mapping to remote IDs.

This is not the first time that this is brought up. For folks who use this tool to sync their files locally, it'd be nice to add some sort of .cache file where we keep of track of we have already in disk and use that to skip files that we know for sure we have and haven't changed. @leezu, is this what your are talking about?

from rmapi.

This is not the first time that this is brought up. For folks who use this tool to sync their files locally, it'd be nice to add some sort of .cache file where we keep of track of we have already in disk and use that to skip files that we know for sure we have and haven't changed. @leezu, is this what your are talking about?

Not exactly. Rather the suggested use-case is to allow deleting files from the tablet/cloud storage, storing them only on the computer running rmapi, but make it easy to add them back to the tablet if needed. The storage of the tablet is limited, so it is not feasible to keep all ever annotated documents on the tablet. Nevertheless, if exporting an annotated document to the computer and deleting it on the tablet, it would be nice to have the option to transfer it back in future and preserving the .lines annotations.

from rmapi.

So if we enable to get/put raw zip files, this use case is not far from being covered isn't it?

For instance, you could have a directory on your computer with all your notes and then put them back on the device when needed. Something would still be missing?

from rmapi.

Indeed. That's what I meant with "enabling uploading of zip files would be a first step."

The missing part is, that once exported as raw/zip from the remarkable/cloud, there is no guarantee that the ID used inside the zip file is still used by the same document (ie not deleted) / unused (deleted) / used by another document. So it may make sense to not blindly reuse the ID inside the zip file, but to follow some smarter strategy.

from rmapi.

As far as I understand, the ID is anyway unique per note as it is a UUID.

So that would mean it can help identifying a note. That can even help knowing if the same note is already on the device or not. So either is has been removed from the device or it is still there and we might want to force update the note from our version.

We may need to play a little bit to test this but I think we are good we this behavior.

from rmapi.

As far as I understand, the ID is anyway unique per note as it is a UUID.

So that would mean it can help identifying a note. That can even help knowing if the same note is already on the device or not. So either is has been removed from the device or it is still there and we might want to force update the note from our version.

We may need to play a little bit to test this but I think we are good we this behavior.

force uploading is no good, so far my testing has shown that the devices does not download newer versions from the cloud for existing files. the file has to be removed from the device first

from rmapi.