run_processor: do we really _always_ want to save_mets() ?

[bertsky]

core/src/ocrd/processor/helpers.py

Line 160 in 62cf25c

workspace.save_mets()

Now that we have the METS Server option, we should reconsider this behaviour. It gets used in both the standard processor CLI (via ocrd_cli_wrap_processor) and in ocrd_network (via invoke_processor).

At least the latter should be able to opt out of intermediate METS serialization. (Should only be done when stopping the METS Server.)

[bertsky]

Admitted, this would be a rather severe (and therefore risky) change. We should wait until we have robust real-life real-data regression testing (again).

To elaborate, I believe the following would need to change:

1. run_processor: no final .save_mets
2. instead, on the CLI, the caller of ocrd workspace server start would also need to do ocrd workspace server save or ocrd workspace server stop at some point (which I am quite sure they already do)
3. on the Processing Server: IIUC we are currently stopping the METS Server (and thus doing a final .save_mets) when and if there are no more open requests cached for that workspace:

core/src/ocrd_network/processing_server.py

Line 600 in f9ce65b

self.deployer.stop_uds_mets_server(mets_server_url=mets_server_url, path_to_mets=path_to_mets)

core/src/ocrd_network/runtime_data/deployer.py

Line 172 in f9ce65b

stop_mets_server(self.log, mets_server_url=mets_server_url, ws_dir_path=workspace_path)

core/src/ocrd_network/utils.py

Lines 163 to 171 in f9ce65b

	if protocol == "tcp":
	request_json = MpxReq.stop(ws_dir_path)
	logger.info(f"Sending POST request to: {mets_server_url}, request_json: {request_json}")
	response = Session_TCP().post(url=f"{mets_server_url}", json=request_json)
	return response.status_code == 200
	elif protocol == "uds":
	logger.info(f"Sending DELETE request to: {mets_server_url}/")
	response = Session_UDS().delete(url=f"{mets_server_url}/")
	return response.status_code == 200

Thus, nothing would need to change here!

4. if running Processor Servers standalone (without Processing Server), I am not sure who is responsible...

IMO we can simply test this in a PR branch (which can then be run with OCR-D/ocrd_all#449).