Hi,
Yes; both LocalSession and ClientSession instances take advantage of our locking architecture and can be used in parallel (as long as the server instance and the LocalSession use the same instance of the Context class).
Great!
- "basexhttp -l" starts just the API (local mode)
- "basexhttp -r" starts the API and connects to a remote BaseX server to
execute the queries etc. on (remote mode)
Your proposal is worth discussing. I'm still not sure, though, how to name such an additional option, and how to make it as self-explanatory as possible: if no alternative host name will be specified by the user, "remote" is rather confusing imho, as the database server will be located on "localhost", i.e., the same machine. – After all, the reason for the current approach was to reduce the number of options that would otherwise need more explanation, and could make things even more complicated (we even thought about completely discarding the local flag).
From the point of view of the server, it is still "remote" as it is accessed via TCP, even if that connection is a localhost connection. From my experience, it is quite unusual to treat a TCP connection to localhost differently than a TCP connection to any other host - and technically, after all, there is no difference. But then, I know how this stuff works, other who don't might find it less intuitive. Maybe "external" would be a better name? (as in, external to the JVM/OS process the API is running in). The current setup however makes it impossible to start a BaseX native server on a host, and then start an API frontend on the same machine but in a different process that connects to it - the remote IP would be "localhost" and the API would start a 2nd database server instance. So this would require work-arounds like adding a name to the /etc/hosts that resolves to 127.0.0.1 but is not recognized by BaseX as localhost. You might find that a strange setup, but together with SSH tunnelling it even becomes useful: The server runs on a machine far away that you can't directly connect to (or don't want to, unencrypted, as the network in between is untrusted). So you SSH in that machine and create a tunnel from the local BaseX port to the one on the other machine, and let the API connect to that local port (which in reality is a remote BaseX server). Okay, this might still be strange, but I think you get the point ;-)
But maybe I just have a strange intuition ;-)
Not at all.. And I still like the idea of directly communicating to the server and avoiding the ClientSession if it resides in the same JVM (it's mainly a question of how to implement it most properly).
Well, I could easily come up with a patch that essentially duplicates the "start server in JVM or not" logic and passes the info on to HTTPSession (I actually already had that patch done before I came up with the other one). But that would still be confusing to me, and the problem mentioned above would persist. At the very least, this magic behaviour should be documented (in the wiki and maybe also in the -h help text). I only learned how it works by looking at the source.
Kind regards, Ralf