I have to wonder about the scope of the PR. Reading a bit between the lines, the goal seems to be to provide enough information to an external program that wants to open a database used by a running Kodi instance.

The database name is not enough to establish a connection. In the case of sqlite, the path is required as well and mysql/mariadb require host name, user and password at a minimum.
The sqlite path may be altered from default by advanced settings or the use of multiple profiles by the way.

So it seems to me that the "host" part of DatabaseSettings needs to be exposed as well, probably as a tuple with the db name.
Even if Kodi is not a high security application, exposing db user name and password sounds like a no-no.

Also accepting a string db type is not very robust but I don't know if it's possible to define constants or enums for json or python.

I have to wonder about the scope of the PR.

Well, I think we need to take a step back here and first need to clarify on the points @CrystalP brought up wrt completeness of functionality, and security concerns.

If you assume the external program already has access to path/hostname/user/password through other means, then it can also know the custom base names (if any), ssl parameters, etc.
In that case, all that's missing to connect is the db version number, which is much easier to retrieve.

I have to wonder about the scope of the PR. Reading a bit between the lines, the goal seems to be to provide enough information to an external program that wants to open a database used by a running Kodi instance.

The database name is not enough to establish a connection. In the case of sqlite, the path is required as well and mysql/mariadb require host name, user and password at a minimum. The sqlite path may be altered from default by advanced settings or the use of multiple profiles by the way.

So it seems to me that the "host" part of DatabaseSettings needs to be exposed as well, probably as a tuple with the db name. Even if Kodi is not a high security application, exposing db user name and password sounds like a no-no.

I wasn't aware sqlite required a path to login (using mariadb here) but if so then it sounds like something to consider, especially if it can vary at the profile level.

The db name in-use is generated internally and required for db access. It can change behind-the-scene via api version change so it makes sense for a way to ask Kodi what the current db name in-use is.

The hostname could be exposed without concern imo.

I wouldn't recommend exposing login/password, if not necessarily for security but as a matter of generally bad practice. I think it's a reasonable barrier-to-entry that they know the login/password as a prerequisite without Kodi telling them.

If you assume the external program already has access to path/hostname/user/password through other means, then it can also know the custom base names (if any), ssl parameters, etc. In that case, all that's missing to connect is the db version number, which is much easier to retrieve.

I think it's better to provide the exact database name in-use given Kodi already knows it and there's no good reason I can see in making the user generate it themself.

Re-did the patch set based on Ksooo's refactor.

[databases] Refactor CDatabase (get rid of name and version virtual methods) and add CDatabaseManager::GetDatabaseNameByType. (supplied by ksooo)

Can you please fix the commit message. It reflects what was in an earlier iteration of my work, not what is in the patch I sent you which is now part of this PR.

Should read: "[databasemanager] Add CDatabaseManager::GetDatabaseNameByType()"

@bacon-cheeseburger this needs a rebase