INI config

[the-moisrex]

.ini config file manager support.

The initial source is from: https://github.com/pulzed/mINI

I'm implementing a .ini config file parser and writer and generator. I'm using the mINI project as the initial source code. I have to change that project because:

1. It's not using allocators
2. Namespace
3. Coding Style
4. Doesn't match my initial thought on how it should be
5. Doesn't match the C++20 concepts that I need to match the other config file types.

More info: https://t.me/webpp/345

[looopTools]

You asked on Twitter whether or not you are wasting your time doing this. I will say the following, even though INI has been replaced by nicer formats (YAML, TOML, JSON,..) there are still some Windows Applications that are heavily reliant on INI files and do not use alternative files for configuration.

Therefore, I do not believe it is a waste of time, but the user group is very limited (and grows even smaller as we speak (hopefully)).

Therefore, the question should not be: Am I wasting my time, but rather is it a good place to spend time right now or should it be a back burner thing. I think the latter in this case. Additionally, I would say that issues like #86 is more important because! TOML is still gaining traction in the developer community and is popular across most operating systems and languages.

[the-moisrex]

Thanks for the comment. You are correct.

The reason why I started implementing this is because I am thinking of a "configs" concept that will include many configuration file types. I just started with ini because it seemed easy enough.

But now I found projects like toml++ project which is waaay too complicated with too much macros but just the right amount of features that got me thinking ...

Should I write wrappers for config file formats and don't bother writing/modifying from scratch?

That's what I did with json in this library. Currently I have a working wrapper for rapidjson and I am thinking of adding more wrappers for other libraries like boost::json and etc.

I did copy and paste and modified the mINI source code to support allocators and stuff. Now I think I should use toml++ library without modifying it and just provide a wrapper.

Should I use toml for ini files or should I finish the ini implementation and use that one?

[looopTools]

1. I think the wrapper approach is great. [not a request] For instance I would like to have a wrapper for nlohmann/json as that is the library I in general use for JSON and by providing wrappers instead of customer implementation that will make a lot of peoples lives, I am guessing yours too, easier.

2. hmmm... I am thinking TOML for INI is not the best path but I can see the allure of this. My question would be, who easy would it be to adopt to having support for INI files this way?

[the-moisrex]

A wrapper is designed in a way that it'll let you switch between the library used underneath, without changing the source code (that's ehat I'm doing with json).

But in case of config files, this is what I was initially thinking; but now, I'm not sure; because every file format has it's own way of representing data that finding a common struct that can let us access every config file format with that config file's full features seems way too hard.

We need to return an specific type that's related only to that file format and has nothing to do with the others in order to let the user have access to the full features of that format.

For example toml has areays, ini doesn't. There's no common interface for this unless we get hacky and provide a serialized array type which is a string under the hood. Ini doesn't support that, and just switching to another config format is easier than getting hacky with the old formats.

So, the answer to second question is it depends on how deep I'm willing to go ☺️.

[looopTools]

Then I would argue you should ignore ini for now

[the-moisrex]

Honestly, I'm just scared to start working on "views" and the database stuff. Specially the database stuff.

[looopTools]

Hehe... I found out with QueryC++ that a lot of the RDBMS's shares data types to a hire extend than I thought in terms of naming. I knew T-SQL DB's would be close but I didn't think they would share type names as well :)

[the-moisrex]

I need a Query Builder and an ORM and a few more ideas that will let the user config the database usages of the sub-apps (for example the blog that the user uses might need a database to work, and the admin page might too, there shouldn't be a problem when we need them both.)

So there are plenty of work to be done in that area.

I saw your querycpp project. I must say that I saw that its implementation is not what I would describe as perfect. There are many places that string view could be used instead of strings and other issues like ALL CAPS MEMBER FUNCTIONS and stuff like that.

In my framework, you can change the underlying string and string view and allocator types inside of them through out the whole framework by passing something I call "traits" as a template type.

I like that level of customization. That's why the project is taking this long to finish (that and also because I've been a deployed soldier coding on my phone for the past year or so 😅)

[the-moisrex]

So far, this is what I've come up with. It has missing a lot of stuff but you get the gist.

What do you think?

https://github.com/the-moisrex/webpp/blob/dev/core/include/webpp/db/database_concepts.hpp#L16-L63

[looopTools]

I like it

[looopTools]

Also yes I would move to string_view and other stuff. The reason for the all caps, was actually a request from someone else XD also lower case and is reserved in C++. It is actually a work in progress where I will swap to using string_view for a lost of things and I know queryc++ is far from perfect XD.

[looopTools]

I also want to add concepts and stuff :)

[the-moisrex]

It would be great if we could combine our efforts if possible! At least for the query builder part. What do you think?