Domino leverages Tika for Fulltext index file filtering to retrieve attachment text.
Tika itself is a very useful component which would be usable for other functionality.
But Tika is automatically managed by Domino and started/stopped when needed by the FT engine.
Therefore it cannot be used by other applications.
The REST API endpoint is bound to localhost (127.0.0.1) which could make the Tika endpoint available for other applications on the server.
Tika is a REST endpoint which could be also handled outside of Domino. Specially in the container world a separate Tika container would the the more natural deployment option.
Please add external Tika support for localhost and also TLS protected remote server support, which could be for example configured via a notes.ini parameter.
If the parameter is set use the address specified instead of starting a Tika instance.
Today only TIKA_PORT exists to switch the port for example partitioned servers.
Having a TIKA_ADDRESS pointing to the loopback address or with a HTTPs address pointing to a remote server would help to optimize Tika deployments for single and partitioned server providing dedicated Tika servers as a service.
For example on Kubernetes a Tika DaemonSet per Host would allow to optimize the Domino deployment by providing Tika as a separate service.
In addition it would allow Tika as a service to have a lower risk vector running it as a service in an hardened Tika container without data and remove the Domino JDK dependency.
