Technically it would be possible of course, yes, but it will make the code more complicated, and maintenance harder. So far I haven't seen any reason one would prefer MySQL/MariaDB over PostgreSQL, although I know that some hosters provide a MySQL db and not Postgres, so this could be a legitimate need. I will definitely think about it.
Just for my curiosity - why would you need to run elibsrv on MySQL instead of PostgreSQL?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have my own selfhosted Intel NUC server. I removed PostgreSQL from my server, because I just wanted to run the less possible number of databases, so I concentrated the other webapps on MariaDB (MySQL), I just didn't want to use another database for one app, even if this app is really nice. It's also a common case for open source applications to support many databases, at least the triumvirate: MySQL/MariaDB, PostgreSQL, SQLite. By example, the following apps support the triumvirate: ownCloud, Wallabag, Gogs... I could make a survey on http://www.mobileread.com/ to better understand if your users would like to use elibsrv on MySQL. By the way, don't you prefer to use GitHub, GitLab, Gogs instead of Sourceforge? IMHO, it could improve the contribution from users for pull requests and issues.
Last edit: HLFH 2015-05-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
after much thoughts, it's unlikely that elibsrv will come with mysql support. not only because of my own dislike of this db engine, but also because adding new storage engines to elibsrv is a non-trivial task. I do understand however that PostgreSQL is not the most evident solution for many people, and that it can appear complicated to newcomers. this is why I plan to integrate an SQLite backend to elibsrv at some point in the future (maybe soon, but can't really promise). I don't know yet whether it would be in addition to, or instead of PostgreSQL. I'd have to do some benchmarks. If the performance loss is not significant, then SQLite will become the new db engine for elibsrv. Otherwise it will be an option.
In any case, this should resolve the trouble of having hard-to-maintain dependencies (I had some requests for plain text files also, for similar reasons).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did some tests, and it appears that SQLite is significantly slower than PostgreSQL when it comes to writing new data, but for read operations it's either similar or even faster than PostgreSQL. elibsrv doesn't write much to the database (other than the first time it is run), and only reads data most of the time. This means that using SQLite for elibsrv is fine, and its performances are perfectly acceptable, so it can be used in lieu of PostgreSQL. The obvious advantage being that SQLite is totally maintenance-free and setup-free, which should greatly simplify elibsrv installation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Technically it would be possible of course, yes, but it will make the code more complicated, and maintenance harder. So far I haven't seen any reason one would prefer MySQL/MariaDB over PostgreSQL, although I know that some hosters provide a MySQL db and not Postgres, so this could be a legitimate need. I will definitely think about it.
Just for my curiosity - why would you need to run elibsrv on MySQL instead of PostgreSQL?
I have my own selfhosted Intel NUC server. I removed PostgreSQL from my server, because I just wanted to run the less possible number of databases, so I concentrated the other webapps on MariaDB (MySQL), I just didn't want to use another database for one app, even if this app is really nice. It's also a common case for open source applications to support many databases, at least the triumvirate: MySQL/MariaDB, PostgreSQL, SQLite. By example, the following apps support the triumvirate: ownCloud, Wallabag, Gogs... I could make a survey on http://www.mobileread.com/ to better understand if your users would like to use elibsrv on MySQL. By the way, don't you prefer to use GitHub, GitLab, Gogs instead of Sourceforge? IMHO, it could improve the contribution from users for pull requests and issues.
Last edit: HLFH 2015-05-06
after much thoughts, it's unlikely that elibsrv will come with mysql support. not only because of my own dislike of this db engine, but also because adding new storage engines to elibsrv is a non-trivial task. I do understand however that PostgreSQL is not the most evident solution for many people, and that it can appear complicated to newcomers. this is why I plan to integrate an SQLite backend to elibsrv at some point in the future (maybe soon, but can't really promise). I don't know yet whether it would be in addition to, or instead of PostgreSQL. I'd have to do some benchmarks. If the performance loss is not significant, then SQLite will become the new db engine for elibsrv. Otherwise it will be an option.
In any case, this should resolve the trouble of having hard-to-maintain dependencies (I had some requests for plain text files also, for similar reasons).
I did some tests, and it appears that SQLite is significantly slower than PostgreSQL when it comes to writing new data, but for read operations it's either similar or even faster than PostgreSQL. elibsrv doesn't write much to the database (other than the first time it is run), and only reads data most of the time. This means that using SQLite for elibsrv is fine, and its performances are perfectly acceptable, so it can be used in lieu of PostgreSQL. The obvious advantage being that SQLite is totally maintenance-free and setup-free, which should greatly simplify elibsrv installation.
I released a new elibsrv version a minute ago. since now, elibsrv doesn't use PostgreSQL any more, and relies entirely on an internal sqlite database.