pagination for long outputs: usage of small displays

[arkadirenko]

I started an discussion in the mopidy-mpd github (mopidy/mopidy-mpd#66), because my plan is, to control an music player with an limited display.
For my purpose mopidy seems to be the right player for me, but unfortunately the JSON-RPC of mopidy is not microcontroller friendly speaking of ressources. So I figured out, that the leightweight mpd protocol is far better for my purpose and for my luck mopidy also supports the mpd protocol.
As I have the idea, to create extended versions of all protocoll command, which produce more output, that a small display could show, I finally thought, that this might be worth to be discussed here as well (and perhaps here is the right place at all).

So I have some questions to this group:
Are there plans (or have I overseen someting in my research), that one can implement own mpd commands for example with an special prefix like the X- prefixed http headers?
Are there plans to support paging for bigger outputs?
In short my idea looks like, having for all commands with expected bigger outputs an extend version. For example lsinfo could be extend with:
X-lsinfo /path/to/directory
would now report back only the number of results, while:
X-lsinfo /path/to/directory offset=10 count=5
would return 5 results of this directory, starting on offset 10.
My current idea is, that the first call (without offset and count) would cache the result from the underlying lsinfo, and upcomming calls with offset to the same path would be served from this cache. A call to another extend command or with an different path would invalidate the cache.

[owl770]

Why not do all the caching and pagination in the client and leave mpd 'lightweight'?

[arkadirenko]

because the "client" is a small microcontroller with limited ressources

[jcorporation]

Many commands have a window parameter. I think it would be the best to extend the commands with this optional parameter.

[MaxKellermann]

Agree. The MPD protocol already has all the concepts that are needed, and I find these "x-" commands disgusting.

[arkadirenko]

The concept of x-commands (or whatever prefix you wan't) is not to win a price for beautiness, especially as I believe that expressions like "disgusting" don't belong in technical discussions. Many protocols, I referenced HTTP, have implemented this prefix, as the only sense is, that third party can try protocol extensions in forks, own products, whatever else and can be sure, that their "invention" will not collide with future legit protocol commands.
The only thing, the protocol maintainer has to do, is define a prefix for such things.
Like you see in HTTP many X-Inventions became part of the protocol with a new own name. Many others disappeared in nirvana.

Thanks for the tip with the window-parameter! I check into this and this is also the perfect example, for X-Commands. When extending certain commands you can do this with an X-variation of this command and let the original command untouched. Maybe this might not be needed for this, if "window" can be solved as an optional parameter. But as soon, as a developer checks, that his implementation may change an original behaviour, he can use an X-version. Do tests, show it to the community, find either solutions how to solve issues with impleneting this into the original command or define a new name for the extended new command.