Suggestions for the Object Model
Create a top-level object called "meta".
** Add attributes like model version, API version, etc.
** Move "limits" into it since those describe the model itself.
Create a new top-level object called "platform".
** Move boards, directories, inputs, network, userSessions and volumes into it.
** Move board temps and voltages to sensors.
** Create a sub object called "identity" (maybe?).
*** Add attributes to it to indicate RRF vs DSF and their versions to create a common mechanism to determine which platform you're connected to.
Create a new top-level object named "state" or maybe something else?
** Move all other objects to it.
This would make it easier to get the data you need without a lot of data you might not need. It would also make it easier to connect without having to try different scenarios, especially if RRF created a /machine/status alias for rr_model.
Oh, I forgot "seqs". That would go into "meta" as well.
The current structure of the object model works well and we don't plan to make any major changes to it. 'limits' describes limitations of the RRF implementation. Clients can keep up to date with rapidly-changing information using the 'f' flag, and only need to ask for other data when the corresponding 'seqs' value changes.
I can't remember whether the RRF network API version is included in the OM. but if it isn't then we'll add it.
As chrishamm has pointed out in another thread, there isn't enough buffer RAM to assemble the complete OM on most Duets, so we'll stick to rr_model with its selection criteria as the way to retrieve the OM from a Duet.
@dc42 "works well" doesn't mean it couldn't work better. I wasn't asking to change how the OM is created or stored or maintained, just to re-arrange the output to make it work better and it's a high-level change at that. Basically just moving the top-level objects down one level into "state", "meta" and "platform". I'm also not suggesting that it go into RRF 3.x, just "some future release".