Great points all around. I'd like to address them and get some clarity
regarding dependencies.

*Dependencies*

Currently, none of the open or draft PRs introduce new dependencies. For
core, this leaves us with just ONNX and Lucene, which makes total sense.
That won't change.

I agree that addons *could* be a good place to allow new dependencies,
provided we use them sparingly. When they are necessary, we should use an
SPI service loader over an interface so that accepting them becomes a
startup-pluggable decision. Since none of the current open PRs require new
dependencies, I am completely fine with a rule allowing zero new
dependencies for now.

*gRPC PR*

The gRPC PR does bring in netty, and I think early on we all agreed to make
it a separate build anyway. It is currently in a Proof of Concept (PoC)
status, it does not belong in core.

For the server dependencies, I chose vanilla Netty because it is fast,
reference-standard, and widely adopted.

Whenever I introduce a new dependency, I follow the SPI loading approach
used by Quarkus and Micronaut: create a service interface with a pure JDK
default implementation (e.g., saving to disk instead of S3), but provide
interfaces for optional storage layers like S3 or Azure. I would eventually
like to offer the ability to save trained models from the server to S3,
Azure, or Google Cloud via a thin repository service layer, keeping
everything dependent on gRPC interfaces to avoid other dependencies.


*Downloads & Hosting Models*
LEGAL-732 <https://issues.apache.org/jira/projects/LEGAL/issues/LEGAL-732>
cleared up our current limitations, and none of the PRs are breaking so
far, so we should use that as our guideline. For new models, as long as we
follow those rules, we can use the downloader
<https://github.com/apache/opennlp/pull/1211> or host models that we train.
Since that PR is open, we can address any downloader concerns directly
there.

Regarding hosting models, I have a dozen or so ideas for new models we
could host, but I would love some guidance on how we should go about that.

I am a big fan of the addons approach as long as the jars are pushed to
Maven Central so they are actually usable.

Thoughts?

Best regards,
Kristian

Reply via email to