Replies: 3 comments 2 replies
-
|
Not really afaik. Some endpoints let you get minificated versions, which are still pretty big tbh. And even this feature is broken on some endpoints anyway. There are ongoing API changes right now so this might change in the future (and you'll have to update your client when that happens - but nobody knows when that'll be). For your problem, maybe try using like a streaming approach that parses it bit by bit if your programming language/framework can do that? |
Beta Was this translation helpful? Give feedback.
-
|
I'm afraid not. I have a very limited HTTP stack. It allows sending POST and GET requests and receiving JSON as a response. At the same time, 5-8 KB is already a critically large response, which will result in an “Out of Memory” error. |
Beta Was this translation helpful? Give feedback.
-
|
When you have very little available RAM, smaller responses will only help so much. You will soon hit a limit with users having many books and or podcasts/ collections that will cause overflow. Because I don't know your programming language, I can't really say if it supports it, but I'm pretty sure it will support streaming/chunking. For example, Kotlin should have a JsonReader that works with an InputStream. Another way would be to host a proxy in between. I believe that even if there are changes made to the API, 5-8kb could be easily achievable by a user (Currently some endpoints don't even support pagination). But to break it down, there is currently no way of receiving smaller responses than minified responses for those endpoints that support it. This might be added in the future, but if and when will only show time |
Beta Was this translation helpful? Give feedback.
-
|
Vito, thanks for your involvement!
Of course I'm not going to implement a fully functional client on a tiny screen. That would be a mockery of the user. The idea is that the user creates playlists in the web and fills them with content. In the watch app, he chooses which playlist to sync with the device. That's the whole interface with the audiobookshelf. I have already implemented a similar approach for the litres website and I like the result.
I am absolutely sure that the Monkey C language does not support this feature
A proxy server is a fairly obvious and 100% working solution. The problem is that this way will make the client unusable. No one will want to deploy an additional server for an application on a smartwatch. In fact, I only need 3 methods from the API, something like: If these methods have pagination, I will be really happy |
Beta Was this translation helpful? Give feedback.
-
|
Ah sorry, I forgot it was about a watch. Silly me. Yeah, I also couldn't find any streaming capabilities. I think this is currently not achievable then. The playlist endpoint doesn't have pagination (as far as I can tell), and the book endpoint can easily exceed 8kb for just one book if it has many files and/or long descriptions. All three routes would probably exceed the RAM limit because, as you mentioned, the API returns too much data. I don't think this is currently feasible. (You can also respond to this thread and don't need to create a new one) -- If there isn't a similar issue already, you could open an issue requesting such minimal endpoints. |
Beta Was this translation helpful? Give feedback.
-
Hi!
I am going to develop a client for Garmin watches.
This devices have very limited system resources (RAM and processor).
API is very generous in sharing data that is often not needed in the current context. For example, when I request playlists, I expect to receive only a list of playlists, but not their contents, including mp3 files. Is it possible to limit the response to only the requested data?
Beta Was this translation helpful? Give feedback.
All reactions