Hello the BaseX team,

First of all I'm really impressed with the quality of the BaseX XML database. I'd particularly highlight the high compliance with the standards XQuery, XPath and the outstanding performance! Thank you very much for the great product!

I'm new to the system and I've faced several configuration deficiencies while trying to configure the BaseX database to fit my needs. What follows is my use case (I hope it is a basic and classical one required by much wider audience), the configuration problems I've faced (I hope these can be easily solved by extending your current implementation) and my proposal to solve the above mentioned configuration problems (I hope this will further improve the quality of your product).

*My use case (access the basexserver run as a systemd service via the basexclient)*

- I've installed the basex package on Manjaro (Arch linux) into /usr/share/java/basex/ - I want to run the basexserver as a systemd service under the already created basex system user (see the attached basex.server unit file) - I want to store the XML databases and the BaseX logs under /var/lib/basex/data /var/lib/basex/log respectively - I want to manage the basexserver configuration (namely DBPATH, LOGPATH, SERVERPORT) separately from the basexclient configuration (namely HOST, PORT, USER, PASSWORD) in a separate files under /etc/basex and ~/ respectively. I do not want to get my configuration overwritten with unnecessary default options that are already in the system and so clutter my clean just-what-you-need configuration files - I want to manage the XML databases and execute queries against the server using the basexclient from my console by providing XQuery command and queries in a file

*Configuration problems (mixed config for client and server in a single .basex file under hardly linked home directory)*

- My .basex file mixes server and client configuration in one single file so I cannot separate the configuration into server-related at /etc/basex and client-retated at ~/ - My .basex file gets overwritten with unnecessary default options that clutter my minimal and clean configuration - When I start the basexclient a new .basex configuration file is created in the current working directory. I start the basexclient from many different direcotries, but I want to have the basexclient configuration only in my home ~/ directory - It seems that the location of the .basex file is hardly linked to the home directory forcing me to place data, log and config directories under a single home directory. I want to manage my data in /var/lib/basex/data, my logs in /var/lib/basex/log and my server and client configuration in /etc/basex and ~/ respectively - I cannot find any way (via environment variables or command line options) to instruct both the basexserver and the basexclient to look for the configuration file .basex

*Proposal to improve configuration*

- Do not overwrite the user-provided configuration files with unnecessary default options that are already in the system or at least use a different file (e. g. .basex-default) - Separate the server-related configuration from the client-related configuration into different files (e. g. .basexserver, .basexclient) - Do not mandate the location of configuration files to be under the home directory because there are different aspects of database management that are usually managed in different directories with different policies and quotas (e. g. data, log, client and server config) - Provide separate options for basexserver and basexclient to locate the corresponding configuration file (e. g. via environment variables BASEX_SERVER_CONFIG, BASEX_CLIENT_CONFIG or command line options -server-config, -client-config) - In order to introduce the proposed improvement you can keep your current implementation unchanged (following the open-closed principle) and just extend the implementation with the alternative locations for the separate configuration files via environment variables or command line options. The only change that is required is to stop overwriting the user-provided configuration files with the default options

Can the above described use case be configured with the current implementation of the configuration management?

Thank you in advance! I'm open to further discussion and collaboration mostly on the design side to get these improvements to work for all other use cases not covered here.

Thank you, Vlad