Remarkable Tablet support?

[poundifdef]

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.

My branch - work in progress - is here: https://github.com/poundifdef/rclone/tree/remarkable-tablet

1. The tablet uses a very straightforward REST API to allow you to list files, download them, and create. Documented here.

2. The API is not publicly-documented. It has been a community effort to document the endpoints and figure out how to use them.

3. 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:

1. 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?

2. 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.

3. 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?

[ncw (Nick Craig-Wood)]

@poundifdef

My branch - work in progress - is here: https://github.com/poundifdef/rclone/tree/remarkable-tablet

Good work

This connects to the remarkable cloud rather than the device directly - is that right?

This will never be a general purpose backend because it can't store any type of file. We have a few of those already (like gphotos).

You wrote on the issue:

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.

@poundifdef

The API is not publicly-documented. It has been a community effort to document the endpoints and figure out how to use them.

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.

@poundifdef

• 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?

That seems useful!

@poundifdef

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?

If the API doesn't validate it then users will upload that kind of file so you need to check out what happens!

@poundifdef

How would we feel about a read-only backend, to avoid this complication?

Read only backends are useful (eg the http backend) but read write is more useful.

@poundifdef

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?

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?

There is a halfway house - to make it a plugin.

Any backend that gets merged needs integration tests. I don't know if you've looked at rclone's integration tests.

Nearly all backends use rclone's framework, but some (eg googlephotos and http) have their own tests since they aren't general purpose backends.

[poundifdef]

Hello! Thank you for your thoughtful response.

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!

[asdffdsa (jojothehumanmonkey)]

hi,
most devices enable file transfer via usb; that the device mounts as local storage.
have you tried that?

[ncw (Nick Craig-Wood)]

@poundifdef

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!

That sounds like a good course of action for the moment. Do add a link to the rclone wiki to your project when you think it is stable enough for other users and do post an announcement here too.