Fis-MessageTransmission/doc/explanation.txt

2 Jan 2025:
Things to do: 
- Get the socket transwmission working first.
- Sepearate out the logic for receiver Identification, make it modular 
- Put actor concept aside. That one will be a separate project






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

Note: As for the Http
- Understandably it works differently, but nevertheless, the existing code to emulate channel via just tranmission and emission will remain the same.
OF course, ample efforts to use request-response adapter will be allocated to fuflill chin's vision, but nevertheless, the standard channel concept is to 
be preserveed for consistencies.
-So going forward, after the UML draft is done, continue with the http development, so that I can test out multiple use of transport services. Of course, I can
probably also use 2 socket, but it just feels wrong.

DevLog:
As of 12/12/2024: 
-Fixed the axios error by cutting out the timeout param, but it also expose other problems, in that the reconnection logic needs to be fixed, because it always
reconnect under new profile?? have to check again.

As of 14/12/2024:
Discussion points during meeting: Keep track and monitor the performance and it's associated ram and cpu usage. When coding, keep track of the instances instantiated from
overloading the system. It's not just getting the behavior right, but also making sure unused var and instances are also properly organized and deleted when no longer used to
prevent memory leak.
And there's going to be an upcoming meeting to present my findings and progress:
Target for the day:  Get the HTTP Services ready. at least the channel version, so that I get right on with the testing and proceed with Emulating request Response adapter.

As of 16/12/2024: (Monday)
-SO tomorrow I have to present something concrete. Will first finish up the UML diagram, and then proceed to hash out whatever errors there is for HTTP servcies.
-If I manage to hash out all the remaining problems. Then proceed to do request response. Test with same app first, before developing for web UI version. it use fetch
instead of axios, so there's going to be some tweaking. 


Calm down, don't be stupid, it's just a game. Focus on what's I'm supposed to do today.