Hello! I have written a prototype (though it works quite well!) implementation of a backend for the Remarkable tablet and wanted to ask whether we felt it would be the right fit to support within rclone! I'm not sure what the right criteria is for whether or not a given backend should be supported, but here are some information which might be helpful for evaluation.
The tablet uses a very straightforward REST API to allow you to list files, download them, and create. Documented here.
The API is not publicly-documented. It has been a community effort to document the endpoints and figure out how to use them.
The files are in a proprietary format: a .zip file, which contains a binary representation of the document. This has also been reverse engineered successfully.
All of that said, here are some decisions that one would want to make for supporting this as a backend:
My own implementation also converts the proprietary format to PDF (this behavior can be toggled), as I have no practical need to sync the raw document files. Would that be "okay" for a supported implementation?
For creating files, there are only 3 formats supported: their proprietary document format, epub, and pdf. Is rclone the right place to do validation to ensure these constraints? I haven't yet investigated the behavior of the API if you upload the wrong types of files, but then again, it's intended to only be used via the official clients.
How would we feel about a read-only backend, to avoid this complication?
Generally, does this seem like a good fit for a potential backend, or would the preference be for this to remain outside of the the rclone main line for now?
The SFTP implementation could work, however, it requires the tablet to be on the same network as the device running rclone, and provides access to the entire filesystem, rather than just the documents.
Is having to be on the same network as the tablet a problem?
My preference would be to not merge a proprietory protocol backend if there is a non-proprietry one which works well enough.
Having a non publically supported API makes life harder. I try not to merge those unless I really have to. We have two - mega and mailru both of which break from time to time.
That seems useful!
If the API doesn't validate it then users will upload that kind of file so you need to check out what happens!
Read only backends are useful (eg the http backend) but read write is more useful.
I think the decision would rest on
can we make the existing SFTP backend work well enough
can we make integration tests run
do enough users want to use it?
what is the use case? Backing up your tablet? Syncing docs to your tablet? Or?
I think that, when we stack up all of the pitfalls: proprietary APIs, proprietary file formats, and a current SFTP alternative, then I agree it makes it a little harder to feel like this would be a stable addition to rclone's main line.
I'll continue to develop this branch on my own as a plugin, and post updates here. And, if there seems to be a lot of "+1" enthusiasm for this feature, then we can revisit!