susanw1 / zscript

Command interface processor for embedded devices
MIT License
1 stars 0 forks source link

Rework callbacks on client end #125

Closed More-Wrong closed 11 months ago

More-Wrong commented 11 months ago

The current system puts individual callbacks on individual commands, which is not scalable to notifications, and forces the user to collect the information from a command sequence and combine it on their end. An ideal system would:

More-Wrong commented 11 months ago

Have decided the form to use:

ResponseCaptor<ActivateResponse> activateCaptor = ResponseCaptor.create();
device.send(CoreModule.activateBuilder().capture(activateCaptor).setStuff(23471).build()
        .onResponse(resps -> {
    ActivateResponse r = activateCaptor.get();
    List<ZscriptResponse> r = resps.getResponses();
    resps.getFinalStatus();
}));

This requires 1 object per response of interest, which we've decided is not too much... The callback is the point at which the Captors are guaranteed to have the command, and also gives the response sequence level object, which can give courser grain information, and give the (non-specially typed) Response objects, which could be used for the whole process. The generics on the ResponseCaptor are fully checked (at least in user code) at compile time, and the user needs no casts of any kind. The user gets the general information (the List<ZscriptResponse>) on all response elements, but can mark the commands of interest, and get more info on them. The responses would be linked to the commands (with e.g. getCommand()).

In a notification, the Captors would change content between callbacks, but the callback would give a period when they all contained the content from exactly one notification