The admin functionality of Fuseki as a webapp (whether packaged as a war
file (jena-fuseki-war) or a combined jar (jena-fuseki-fulljar) is fixed
and always present.
It's "old style" for integrating in with a host machine that may run
many services.
The runtime area (FUSEKI_BASE) is required and will be written. It is
not optional.
Installing and managing OS services has become complicated. A current
example is tomcat9+systemd+fuseki. The user needs to go in and allow
writing to /etc/fuseki by changing the systemd configuration.
The style is quite un-docker-like as well where "one container, one
service" is the style.
Adding admin functionality to Fuseki/Main (jena-fuseki-server) is an
opportunity to step back and design for a different style.
It would be good to have online reconfiguration. That is now possible to
provide: all the services go into a single registry. The code is now
structured so that the reading configurations from disk builds a new
service registry and so reload is rebuild and switch the registry. This
can be done safey without loss of service, not even needing for there to
be no active requests. Old requests just play out.
Here is a proposal - it is trying to be simpler. It reduces the need for
/$/ functions which can be reintroduced later (it being easier to add
functionality than remove it), and then as optional.
Currently, to run Fuseki/main, all the configuration is on the command
line, including "--conf" for a Fuseki configuration file.
To add persistent administration, the server state would be in a directory:
fuseki --base=DIR
and no other configuration arguments allowed at the same time. It's
already wrong to mix setup forms like --conf and an explicit configuration.
That is, the command line is one of "--mem", "--file=FILE" "--loc=TDB"
"--conf=" and now "--base=DIR"
If subsequently run without --base, the confiuration state is ignored
(unlike Fuskei/webapp - it always reads the configuration area).
Pesistent configuration it has become "opt-in".
A simpler admin area:
/server.ttl - top level file for the server section; optional.
log4j2 configuration file; optional.
/databases/
File area for persistent databases.
/configuration/
Service configurations
/logs/
Logging is entangled with the OS logging because even in docker
containers, admins and tools expect logs to be in "the normal place"
(i.e. /var/log) but /logs/ may be a symbolic link if desired or
individual files be symbolic links or by sing the log4j configuration.
The standard form NCSA request log can be split out - a lot of tools can
process this webserver standard format.
"server.ttl" is a file to put in a server section in. Or a complete
config.ttl. It is a matter of style, not enforced.
/configuration/ is a directory of Fuseki services. These are fragments
of a Fuseki configuration files (as at present in Fuseki-webapp).
Each is parsed separately - you can't split a single service across
multiple files; a file can have more than one service definition in it.
The "no split" rule isn't necessary - could just read everything into
one graph and process that but it does stop badly written fragments
clashing and it is generally clearer to the user.
Checking for a server section and either issuing a warning or causing an
error would be good. It is probably a user-setup mistake.
Rereading and reloading the server section is a bit more tricky but at
least all the /configuration/service files that go to make the registry
are reloadable with new ones causing a new dataset and deleting files
causing datasets to disappear.
It does enable some file-driven processing and spot changed files then
only reload those.
But - for now - I would not have the facility to send server definitions
by HTTP. Fuseki/weabpp admin uses this - there are templates for the
common forms of in-memory and TDB-backed datasets, and complex service
description can be POSTed to /$/datasets/ to create a service.
This just over complicating things. We don't need to require a admin/UI
so functionality that is specific to the UI can wait. It is easier to
add the ability later than remove it later. It makes security easier -
it has moved onto the administrator having access to the Fuseki disk
area and only that.
Andy
PS Most of the code for parsing configuration files already exists in
org.apache.jena.fuseki.build (in jena-fuseki-core) and the centralizes,
switchable registry is DataAccessPointRegistry after the last round of
improving request dispatch.
