co⚡e: Sparkplug™ MQTT edge

with [r181] you no longer need to call InitializeStructure from outside the FB_Payload folder.
Todo: update example project.

Hi,

FB_Payload.InitializeStructuredPayload( ); Is at this moment difficult testable :-(
Therefore I 'd suggest to see this method "disappear" i.e. become private and therefor, working by design.

Maybe the FB_payload should become as 'user-friendly' as possible by reducing all burnerplate code. If the FB get instanciated and called, the underlying code could intialise itself without any exterior help?? Also, consider declaring all helper functions for FB_Payload as 'Internal' for the library so that they also disappear from view.

I hope any and all initialisation can be brought back to the bare minimum as possible.
Also, the interaction with this FB is event driven so it makes sense to write against methods as much as possible.

I hope you'll consider this preliminary feedback, to be continued...

But when do you initialize the structured payload?

Can't the FB initialise itself and then the user can "hook" its resources via some method trickery?

InitializeStructuredPayload( ) gets rid of any previously added metrics and any previously added timestamps, sequences, uuids or bodies.
So when should it do that?
Answer:
1. At the start of decode (which is already done internally)
2. after you are finished using the previous result and ready to start adding a new metric / timestamp etc. which you want to be encoded.

So when does the FB know when you are finished with the previous result and ready to start fresh adding new stuff? Currently it is when you call this method.

Okay, after thinking the architecture over I have got a solution which should ease the effort for developers while giving the freedom to arrange stuff in the 'background'.
To achieve this, FB_Payload can be encapsulated into a new FB (a wrapper around it).

This wrapper FB then provides enough 'space' to initialise and implement the encapsulated FB and also expose simplified interfaces (methods/properties) to the developer.

On top of this you might consider splitting the core of FB_Payload into several FB's which provide only the encoding and decoding etc etc, this solution might be better maintainable and testable I guess..

What do you think? Let's share thoughts on this?

• FB_Payload (wrapper)
  • FB_Payload_Core(s) // single Core FB or several core FB's

• Status: open --> accepted

• status: accepted --> closed