You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Apologies for combining a couple of basic questions into one, just trying to understand the way things work a little better.
I've been using rmfakecloud for some time just for having the safety of permanent sync without needing the Connect subscription and sending all my files to the cloud, so first off thanks so much for the project!. On the side I'm trying out building a custom client (as a learning exercise for Rust) and hit a couple of issues.
Listing documents in a browser esque style
I saw from issue #260 that the /document-storage/json/2/docs API is effectively deprecated with the new sync implementation. It's hard for me to tell from the code which endpoints deal with the old/new storage, but I can figure that out, though it would be nice if this was clearer in the docs/code. So instead I switched to /sync/v3/files but I quickly realised I'm making potentially hundreds of API calls as I recurse that structure and pull hashes until I find metadata files.
Is this the approach native clients take at this point, or am I missing something? Also I noted that the rmfakecloud UI API has its own implementation of listDocumentshere which effectively builds the file+metadata list server side. Would it be reasonable to adapt the old API to do the same or would that break compatibility? Does the official client API still use that old endpoint or is it really blasting the sync API to learn the full dir structure? (PS. I don't know Go at all so I did try following the rmapi code as a reference but I got lost real quick! Any tips on how to use and reverse engineer that welcome 😄 )
Custom Integrations?
My eventual goal is to sync a github repository with a folder on the remarkable tablet, driven by a hook as soon as a push is made to the repository. I will turn this repository of markdown files into PDF (I don't think remarkable can render markdown files natively?) using sphinx or some such in github actions and then want to push this to the tablet. Should I look at a custom integration for this, or should I just use the WebDAV integration and have github shove the eventual PDFs into to my own WebDAV server? I could also use the local folder integration but I see this is still marked experimental.
It feels like a cool feature of rmfakecloud in theory would be being able to use the integration API endpoints to create custom things, but I might be misunderstanding what they do.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Apologies for combining a couple of basic questions into one, just trying to understand the way things work a little better.
I've been using rmfakecloud for some time just for having the safety of permanent sync without needing the Connect subscription and sending all my files to the cloud, so first off thanks so much for the project!. On the side I'm trying out building a custom client (as a learning exercise for Rust) and hit a couple of issues.
Listing documents in a browser esque style
I saw from issue #260 that the
/document-storage/json/2/docsAPI is effectively deprecated with the new sync implementation. It's hard for me to tell from the code which endpoints deal with the old/new storage, but I can figure that out, though it would be nice if this was clearer in the docs/code. So instead I switched to/sync/v3/filesbut I quickly realised I'm making potentially hundreds of API calls as I recurse that structure and pull hashes until I find metadata files.Is this the approach native clients take at this point, or am I missing something? Also I noted that the rmfakecloud UI API has its own implementation of
listDocumentshere which effectively builds the file+metadata list server side. Would it be reasonable to adapt the old API to do the same or would that break compatibility? Does the official client API still use that old endpoint or is it really blasting the sync API to learn the full dir structure? (PS. I don't know Go at all so I did try following the rmapi code as a reference but I got lost real quick! Any tips on how to use and reverse engineer that welcome 😄 )Custom Integrations?
My eventual goal is to sync a github repository with a folder on the remarkable tablet, driven by a hook as soon as a push is made to the repository. I will turn this repository of markdown files into PDF (I don't think remarkable can render markdown files natively?) using sphinx or some such in github actions and then want to push this to the tablet. Should I look at a custom integration for this, or should I just use the WebDAV integration and have github shove the eventual PDFs into to my own WebDAV server? I could also use the local folder integration but I see this is still marked experimental.
It feels like a cool feature of rmfakecloud in theory would be being able to use the integration API endpoints to create custom things, but I might be misunderstanding what they do.
All reactions