Hi! Finished working on an interface beetwen the database and my server code, it was really too messy earlier. So i made an interface that manages caching and retrieving the data, the only downside is that the data it returns (pointers to the cache) is completely immutable outside of the interface, so for every update you necessarily need to call update_user or update_channel or appropriate caching functions, other than that it should work pretty well and i made my previous example 1000 times simpler (in the photos I’ll provide a before and after).

How i made it

So while coding this new interface I encountered some problems, first of all I’m gonna remind myself to never use databases in C, i really hate all that boilerplate :d. I decided to make the interface pretty specific on users and channels, if i ever need to add anything to my database it’s gonna be a pain but I dont plan to do that (outside of files but those will come later), I also decided to use arena’s to manage memory in the cached user and channel struct because it’s cleaner cleanup. For last I was going to make a check_credentials function for log in but i decided to do that later as I need to implement hashing and md5 and that will be another dependancy. I think the next feature I’m gonna work on is probably making a decent client, if I continue the server I’m gonna have a functioning server without a client to serve. Later guys!

Hi there! This is my first devlog ever, so bear with me. It’s gonna be kinda long since this is a WIP project and I want to walk you through the codebase. This first devlog covers the pre-existing code and what I did in the ~5 hours I logged.

Overview

IOMessage is a centralized messaging CLI platform built entirely in C. Server and client are both meant to be multi-platform.
The app will implement:

• channels (groups where users can share messages)
• moderation capabilities (kick, mute, …)
• file sharing
• (maybe other things in the future)

Architecture

• CommunicationManager: this module handles I/O for each connected client
• ServerManager: this module handles requests and allows client communication
• ThreadManager / NetworkManager: modules that handles OS abstraction

Thread communication: CommunicationManager and ServerManager talk through shared queues. Each CommunicationManager pushes incoming requests to a shared request queue, ServerManager pops them, processes them, and pushes responses back to that specific client’s response queue in a consumer-producer model.

What I’m working on

Done: CommunicationManager, ThreadManager, NetworkManager.
WIP: ServerManager mainly the channel and messaging feature so i can ship a demo.

Right now I need auth and channels working. I was facing the problem of storing user data past program exit. I considered files/folders, but linking data got messy fast, example: channels need to reference actual users by id so the server can identify the allowed users, and once channels and members live in separate files with changing data, it turns into a mess.

So I choose SQLite: i choose because it stores data in just a file (minimum complexity) and as solid C API. Spent a good two hours designing the schema (it was the first time I used a DB lol).

Then the hard part: seed the DB with some info, get the server to open it, print the channels, exit and read a looooot of docs. then after I started coding, i read the documentation bit by bit and slowly became horrified… THE BOILERPLATE WAS ABSOLUTELY GRUELING: 5 function calls per query, each one can fail, so for each function there are 5 lines of code Handling the error and freeing memory. I tried wrapper functions, I really tried, but it didn’t help much.

Still need to find a way to cut the boilerplate down. I’m a bit of a perfectionist and it’s killing me. But after a lot of fighting, reading, and debugging, it finally works and displays the seeded info about channels.(the code I’m showing is basically 70% boilerplate for sqlite, btw the i swear the application can talk to clients, handle bad client behaviour and serialize the protocol, i have it turned off for testing so the app quits immediately after reading data from the database tho).