On Wed, 2022-02-23 at 00:56 +0100, Christian Grün wrote: > Quoting my previous reply: > > > For example, you can > prevent BaseX from reading the configuration from disk [1]. > > And one more quote (as I’m not sure it has been fully understood): > > > In other words, if we use BaseX embedded, we import it as Java > library. If we use it as standalone processor, we access it > externally, similar to other installed applications and along with > all their idiosyncrasies. > > If you call BaseX as an external and independent application via > scripting, you can't expect it to behave like an embedded library.
Thank you for reiterating the previous points, to help me see how they converge. I understand the behavior of using configuration files may be disabled through the library call, but is unconditional through the command-line application. The design seems to present a dilemma, as it is unlikely that there would be a viable route for beginning work on a Java application, before a concept is proved through much more lightweight development approaches. Returning to the thought of a feature request, let me suggest that adding switches to the command-line tool, for disabling the behavior mentioned above, and other behavior that may be relevant, or providing a complementary tool targeted at more self-contained deployments, might be a valuable enhancement to the tool chain.
