Lucio Lelii
5e6636d3b9
InternalOllamaLLMProvider carried its own client, its own error mapping and logging, and its own request bodies and parsing, all mixed together. OllamaProtocolProvider pulls out everything that is genuinely the protocol - nested options, think:true, top_k, the JSON-path defaults the flow assistant depends on, response parsing - onto the transport base, leaving InternalOllamaLLMProvider about fifty lines: its own URL, its own key, and nothing else. getName() still returns "InternalOllama" - that string is persisted in seventeen places in workflow-editor-init/flows.json, in every existing flow, and in the vault's provider column, so it could not change even in a refactor this size. Not extended from OpenAIProtocolProvider, even though Ollama also exposes an OpenAI-compatible endpoint: the native shape differs enough - nested options, think, top_k, none of which OpenAI has - that a subclass would override every method the parent provides, which is not a subclass, it is a different implementation wearing one. The base ended up with two hooks instead of the OpenAI family's one, because there is a real asymmetry here that family does not have: resolveApiKey() lets InternalOllamaLLMProvider ignore whatever credential a caller passes and always use its own server-configured key, while RemoteOllamaProvider - the new provider, for an Ollama instance other than our own - requires the caller's. baseUrl() has the same shape as OpenAICompatibleProvider's: a constant for the internal instance, read from the credential (and validated through OutboundEndpointGuard) for the remote one. RemoteOllamaProvider cannot list its models either, for the same reason OpenAICompatibleProvider cannot: listing would run from the editor, with no credential and therefore no endpoint to ask. InternalOllamaLLMProviderBodyTest - the existing test pinning every request body byte for byte - passes unchanged, which is what "extraction" is supposed to mean here. InternalOllamaLLMProviderHttpTest is new: no test before this one exercised the actual HTTP round trip, only the bodies, so there was no way to confirm the 4xx-carries-its-body upgrade (the whole reason for building the shared base) actually reached Ollama until now. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|---|---|---|
| .mvn/wrapper | ||
| src | ||
| .gitattributes | ||
| .gitignore | ||
| CITATION.cff | ||
| Dockerfile | ||
| LICENSE | ||
| LICENSE-ADDENDUM | ||
| NOTICE | ||
| README.md | ||
| mvnw | ||
| mvnw.cmd | ||
| ollama-preloaded-docker | ||
| pom.xml | ||
| run_service.sh | ||
README.md
RUN LOCAL SERVICE
./run_service.sh
BUILD DOCKER IMAGE
docker buildx build –platform linux/amd64,linux/arm64 -t luciolelii/humainflow:latest . –push
HOST
License
Copyright (C) 2025-2026 Lucio Lelii — ISTI-CNR.
HumAIn Flow is released under the GNU Affero General Public License v3.0 or later (LICENSE), with an additional attribution term under section 7(b) of that license (LICENSE-ADDENDUM).
In practice this means:
you may use, study, modify and redistribute it freely;
if you run a modified version as a network service, you must offer its source to the users of that service;
any work based on it must keep the attribution below, both in the source and where the interface shows its legal notices:
Based on HumAIn Flow, originally developed by Lucio Lelii (ISTI-CNR) — https://github.com/luciolelii/humainflow-service
If you use HumAIn Flow in academic work, please cite it — see CITATION.cff.