work on data dispatcher

[DJ2LS]

A class which adds a "type" information to the info frame when opening an ARQ session. It allows, dispatching data by the type or using different compression algorithms.

Transmit Example:

from arq_data_type_handler import ARQDataTypeHandler

        example_data = b"Hello FreeDATA!"
        formatted_data, type_byte = self.arq_data_type_handler.prepare(example_data, "raw_gzip")

Receive:

--> Dispatcher will be called after a successfull ARQ transmission.
dispatched_data = self.arq_data_type_handler.dispatch(type_byte, formatted_data)
corresponding endpoints can be added in arq_data_type_handler.py

[ptsmonteiro]

Could we call this something similar to a received ARQ transfer data handler or FreeDATA handler? Data handler is maybe too generic?
Instead of injecting this DataDispatcher inside an ARQSession, I suggest we exploit the result of calling the on_frame_received() of the ARQSession. This could return the transfered data to the ARQ Session frame handler and keep this "FreeDATA" logic outside of an ARQ transfer/session.

[DJ2LS]

Could we call this something similar to a received ARQ transfer data handler or FreeDATA handler? Data handler is maybe too generic? Instead of injecting this DataDispatcher inside an ARQSession, I suggest we exploit the result of calling the on_frame_received() of the ARQSession. This could return the transfered data to the ARQ Session frame handler and keep this "FreeDATA" logic outside of an ARQ transfer/session.

@ptsmonteiro I moved the dispatcher as suggested to the on_frame_received part. I also adjusted and splitted the dispatcher naming. Please let me know if its more clear now or if it needs further adjustments

[DJ2LS]

Yes, that's what I have been initially thinking. So it's good we are in sync now.
I think it's worth going this way.
So I'll drop the json based approach and moving on to the 1byte info field. This brings us more flexibility and efficiency to ARQ without causing too much complexity.

[ptsmonteiro]

I was thinking about having two layers of data. At this lower level I would only say if the arq session payload is freedata data and how to get to it (compression algorithm) OR data for another app that might use the freedata platform (other data types).
Then, at the freedata level, we could potentially have multiple types of messages (p2p, etc ..) and this would be indicated in the JSON structure inside every freedata payload.
Does this make sense to you or have we already mixed everything up and so it doesn't matter any more?

[DJ2LS]

I think the additional data layer would make the entire system more scalable. If we are doing this at arq level and therefore inside this data handler, it would be bloated fast I think.
So one use case, one endpoint should be the direction in my opinion.

Inside message module we then can define several types with json structure. Which shouldn't be too much byte overhead because of compression. For this we could use the existing formatter with encapsulation?

[DJ2LS]

@ptsmonteiro I removed the data formatter. From my side this can be reviewed again.

Work on further features like a data dispatcher should be done in a separate PR for keeping work packages small and per use case.

I think we can also leave the p2p related stuff inside this module as it's making data dispatching later easier and avoids additional header data for data types not message related. Sure, it's some kind of mixing layers, but I think this could simplify things a bit. If we don't like it, we can change it later the next weeks while gathering experience with this design approach

[ptsmonteiro]

We should do something about the failing checks.
Other than that, looks good to me 👍