Jump to content

Recommended Posts

Geschrieben

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.

 

Geschrieben

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 ;D.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gast
Reply to this topic...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...