It would be more elegant/future-proof/flexible to remove most extension-related APIs from the BrickMaster, and move these to separate Extension APIs.

 

In Java, you could have the following in BrickMaster

 

List<Extension> getExtensions();

 

And you could have new classes like

 

public class WifiExtension implements Extension {..}
public class RS485Extension implements Extension {..}

 

This refactoring would clean up the BrickMaster API to reflect more of its essence.

 

Yes, i agree. We had this discussion already quite often. It would be possible to generate something like this. It was once even planned during the protocol V1 to protocol V2 transition. But we decided to not invest time in this for the moment, since must of our users configure their Extensions in the Brick Viewer and don't need the API anyway.

 

There is a huge list of TODOs and new products and so on, we have to pick our battles wisely .