Decide if we want the CLI be stateless or stateful

[labra]

At this moment, the CLI exposes a stateless interface where each action is deterministic in the sense that it requires all the necessary parameters to perform its action and is not based on previous commands.

For example, if one wants to validate a graph with a schema and a shapemap, the CLI is something like:

• rudof validate --schema example.shex --shapemap example.sm example.ttl

If we want to validate with a different schema, we could use:

• rudof validate --schema example2.shex --shapemap example.sm example.ttl

In this way, the result of validation is the same and doesn't depend on previous calls, which is nice...but if the graph is large and loading the graph can take time that the second call could save.

A different approach, which I feel is more natural in the database community is to have an internal state which would allow the user to reuse the loaded data. The previous example could be something like:

• rudof load example.ttl (loads the graph to internal state, which can take time)
• rudof validate --schema example.shex --shapemap example.sm (only takes the time to validate)
• rudof validate --schema example1.shex --shapemap example.sm (this second call will only take the time to validate, saving the time to load the graph)

This stateful behaviour is quite common in the database community, for example tools like psql, mysql, mogosh, etc. are stateful.

However I think there is a trend for more stateless CLIs. The advantages is that they can be more deterministic and offer better integration with CI workflows. The pros, is that the parameters can be long and reduce the usability of the command.

Some points with discussions about this stateful vs stateless feature:

• Stateless vs stateful systems
• Similar discussion about MCP being stateful or stateless
• Writing CLI tools that AI agents want to use
• Stateful vs stateless engine in dagger

One intermediate possibility which could try to have the best of the two options is to offer a connect command that connects to a database and generates a temporary file with information about the connection id or other needed things and then a parameter to the validate command could point to that file. The pattern could be something like:

• rudof load example.ttl -o connection_details.toml (creates a connection to the database and stores the connection details)
• rudof validate --schema example.shex --shapemap example.sm --connection connection_details.toml (reuses those connection details)
• rudof validate --schema example1.shex --shapemap example.sm (reuses the connection details again)

The problem of this option is that I think we wouldn't be able to work with in-memory databases because once the first command exits, the memory of the process holding the in-memory database would be lost (maybe there is some way to bypass this constraint?).

Another possibility would be to provide a rudof shell which could work as:

• rudof shell it would open an interactive shell with some commands like connect to connect to the database, or validate to validate the database. The shell could be stateful.

So the 4 options that I can see are:

• Stateful CLI
• Stateless CLI + generation of connection details
• Stateless CLI + interactive shell

Notice that this discussion doesn't affect the Python bindings and the rudof-lib which are already stateful.