wenjin272 commented on PR #1382: URL: https://github.com/apache/flink-agents/pull/1382#issuecomment-6817653195
I agree with exposing these capabilities through Resource APIs so users can call them directly from Actions. For the public API, I would prefer task-specific interfaces, such as `SpeechSynthesisModel`, `TranscriptionModel`, `ImageGenerationModel`, and `VideoGenerationModel`. Their inputs, options, and results have different semantics. A single `generate(content, parameters)` interface leaves users to discover the actual contract from the configured `task`, with most mistakes only caught at runtime. This does not necessarily require a separate `ResourceType` for each capability. They could still share `MEDIA_MODEL` for resource registration and lifecycle management, while exposing more specific interfaces to callers. I would also separate asynchronous job management from the task-specific API. Providers that support submitting and querying cloud jobs could implement a shared `AsyncJobModel<Request, Result>` interface with `submit`, `fetch`, and `wait`. Synchronous TTS would not need to implement unsupported job operations. An asynchronous provider could still offer `generate()` as a convenience that submits a job and waits for its result. Here, “asynchronous” means a provider-side job with a reusable handle, rather than simply running a blocking call on another thread. Shared polling, job-state handling, and serialization can remain reusable implementation components. This would also give request timeouts and polling budgets separate, explicit contracts. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
