-
Notifications
You must be signed in to change notification settings - Fork 18
Application Layers
A hamburger 🍔 has three layers (2 buns and a patty). You can swap the bread, change the patty, add ketchup, anything really. If you put it into a blender, it becomes very hard to fix or change anything. You have to start from scratch or keep adding until the flavor is right! Not to mention, it becomes a disgusting mess.
Just like a cheeseburger has layers, 6 layers all come together to make TCR work. TCR itself consists of 3 layers that all use abstraction.
TCR having 3 layers allows us to have the same freedom as a hamburger. Pieces are replaceable, easily changeable, distinctive, and just as delicious.
The layers are as follows:
- Chat Service
- ChatClient
- TerrariaChatRelay Core
- Adapter
- Game framework (TShock or TML)
- Terraria
Let's go over the layers individually to understand more!
Let's start from the middle with TerrariaChatRelay's core. This is the meat 🥩 of the plugin, containing the foundational logic to process chat, commands, routing, configurations, and more. It receives incoming chat from above (ChatClients) and below (Terraria through the Adapters). It is not concerned with anything else other than taking chat, processing it appropriately, and sending it to the other end. It's also the parent connection manager, handling it's own connection to the adapter and it's own connection to the ChatClient (not the Chat Provider, a key difference).
Adapters are one of the buns 🍞 of the plugin. They help TCR figure out where to get chat from on TShock/TML. Where do I get boss events? How do I see when a player logs on? Can you connect me to Terraria? Without an adapter, TCR has no way of knowing how to communicate with TShock/TML to communicate with Terraria.
TCR could "hardcode" the ways for each framework and remove the need for an adapter. BUT then it would require different files for each framework inside of TCR's Core. This makes it harder to maintain, having to change code in two places. That would couple the code to each framework separately. It's just easier to have someone else do the job and translate it for us, and that someone is Adapters.
The other bun 🍞 of the plugin, ChatClients. These help TCR figure out where to chat from for any service we program. For this, we'll use Discord as an example.
TCR has no idea how to reach out to Discord. It could learn how to do that, but then it couples TCR to chat providers and gets messy to maintain. Plus, it's lazy. 🦥 It's only interested in receiving chat, not where and how to get it.
ChatClients are programmed to figure out how to connect to a chat provider. Once they connect, they know how to send and receive chat to that provider. They also know the strict rules and regulations a chat provider might have so the connection can be maintained. They can also take the chat and dress it up however they like before sending it to the chat provider. For example, Discord has the ability to bold text or put text into boxes. Discord can do it's own fancy formatting on the chat it receives from TCR before sending it off.
ChatClients do all of this for TCR and it's none the wiser.
And that's the layers of TCR! Since ChatClients and Adapters are buns 🍔 of the plugin, you can put them on either side of TCR (the beef) and it won't care. The buns receive chat and send it to the TCR Core. As long as TCR is receiving chat from one side, it will send it to the other side. Have fun eating the burger upside down!