Fis-MessageTransmission/doc/explanation.txt

Concept as of 5/12/2024:
So, when an application run, it will instantiate the transmission manager that will in turn instantiate adapter manager. The adapter manager will turn first check the 
configuration file, whether a config json file or .env depending on the environment, and set up the necessary transport services in order to be able to create the 
necessary adapter instance, but not right away. It will have the information, but not create them right away, unless there are already clients connected. The adapter
manager would also cater for the situation that it would also connect with existing transport that are active. Of course, the details for such mechanism are yet to be
discussed further. Until then, current context will only assume that this adapter will instantiate the necessary components. Now the scenario is such way that when 
there a client receiver that wishes to connect, it will first perform then necessary handshake protocol, in this socket case, which is to specify  whether or not
the client is a new clietn or a previously connected client. Then the tranpsort services that was instantiated earlier on by the adapter will first assign the necessary
details to the connected clients so that the information of the client is first established and kept in record so to speak. Same things goes for previius client, Until
the transport service can establish their respective identiites, no message transmission will be carried out, and in the case of old clients, the transmitted messages
will still be in the buffer. So, once the identities of the clients receiver has been established, the transport service will then in turn publish a transport event,
and then transmission manager who had been subscribed to that event bus will pick up the signal so to speak, and instantiate the necessary transmission components.
So what happens here also, is that during that procress, it will also liase with adapter manager to instantiate and return available adapters, so that that it can
included in part of the transmission set. So once, the "package" of transmsision set is ready, which by now consists of a set of transmission and it's respective 
adaptesr, along side with the buffer mechanism in place, the application or the producer or client if you would can start using these transmitter and receiver 
transmission components to start sending and receiving messages without having to worry about the underlying transport system. 
Things to note, the logic to decide which adapter to use and how many adapters will be placed in transmitter tramsmission itself. Naturally, there would be 
presumably eitehr a performnace metrics measurement of it's kind, whether self-written or an existing library to be consulted so to speak, before deciding 
on the usage of the available adapters. The transmission components will also have the ability to take and throw away their adapters, depending on the signal
given by transmission manager. Essentially, transmission manager will keep itself up to date via the aforementioned event bus, and notify and return additional
adapters if there are any. Adapter manager will basically keep an out or instantiate more circumstantially, and will update transmission manager via the event bus.



Things to do:
- Connection Manager to manage different transport options. Default using websocket, but will also consider fail detection on each transport and decide on adapters swap
- Also need to cater for browser environment. Right the now, the default behaviour is that one would assume to instantiate a socket server, instead of client. 
Need to cater for those cases too.

Target for week: (Same for Week4)
i) R&D for multi channel data traversal.
-That means utilizing multiple TCP ports or network cards or transport services.
-To be Prep via documents for discussion 
ii) Functional Http Service options to be made available.
-Default transport will be geared towards socket at the moment.
iii) Code Adjustments and Cleaning
-Make sure the file structure and folders are in order
-Necessary comments
iv) Documentation
-A special Readme file to help understand the usage and what it does.
-Also guide for future enhancements
 
DONT  FORGET TO UPDATE SPICEWORK!!!!!!

Optiomal but cool things to do:
i) A global logging service that can be configured and toggled <DONE>
- instead a console.log, create a logging features in utility. It's like nestjs version but but my own. It will just read from logSetting.json configurations


Things to be discuss later: (as of 2/12/2024)
i) If a service crashes and comes back up, does client(UI sender) still send requests?
-Since the service loses all it's memory and have no clue who were connected and what it was doing unless there's a state machine.
-Current paradigm only solves for internet disruption, it doesn't assume either of the sender and receiver crashes.

Discussion points as of 5th December:
i) Transmission Components can be using multiple adapters for transmission operatores. There would be utilities to measure performances as such
to be included in the near future.
ii) Actor system: May or may not expose methods circumstantially. So it all depends. But utlize interfaces for services and have them become functional so thatit
it can be reusedd again
iii) Learn how to use uml to better represents my ideas and absracting a concept so to speak.
Dont' forget about depedencies injection