Playing around with yaml

[amnuts]

Looking into using yaml for come of the config files - config, rooms, and command help docs.

Could be a pre-cursor to having the users as a single yaml file per user (user details, mail, reminders, macros, etc.)

Did consider SQLite as well and having everything in there, but this seemed an easier route that people could still easily update without having to go through anything but a text editor.

[Uzume]

I question the value of putting things like mail and/or chat logs into the same file as user setting data, etc. That said, a standard text format like YAML is probably a good idea.

[amnuts]

@Uzume, I was thinking that direction just to have a single user file that's all self-contained - no more multiple-directories to read from for one user. What's your concern about having a user's related content in a file a single file for that user?

Agreed about yaml, and seemed to fit better in this context than json/jsonl. And would certainly make it much easier to add new properties to the user object than the specific structure it has now!

[Uzume]

@amnuts If one places all data about a user into a single file, then anytime the system needs to know something about that user that is not already cached, it has to parse through such a file. If that file is large containing years of logs, mail, and other details it could get prohibitively slow and/or expensive.

If on the other hand, things are kept separate and compartmentalized, a large hit parsing through all of a users logs and/or mail, etc. only need to be taken when specifically requested (e.g., the user wants to read all his/her mail).

Suppose user settings are saved in the same file as you propose and one of the settings is a user's display markup (where one can add escape codes to their displayed name) and you need a command that dumps a log of all the logins for the last month/year or whatever and you decide it would be nice to mark them up with their display attributes. Say also your talker has been around for years and many of your users have a large number of stored mail, logs, etc. If you have to parse through all of such for each user just to get a list of user logins you can see how that command is going to become prohibitively expensive and likely slow if not expensive.

The above example might be slightly contrived but the I think it demonstrates the point I am trying to make.

One key thing to consider is what data about users needs to be always accessible vs. what data is only really necessary on-demand when such a users are logged in and requesting functions that required such data.

Think about how you might organize such data in a relational database. You probably would not organize users mail such that it was available as part of a users indexed records but instead separately via multiple indirect indexes this allow one to store the data in smaller individual pieces that allow you create code with separate concerns as you see fit.

[amnuts]

You make some really good points there, @Uzume. If I keep this branch going, I'll not combine the user files. Will convert to yaml, but individual files as the are now.