oscerd commented on issue #328: URL: https://github.com/apache/camel-kamelets/issues/328#issuecomment-5791608316
Cross-referencing, because this and #929 turn out to be the same request and have been tracked apart for five years. This issue asks for the output type of a source and the expected input type of a sink to be declared. #929, opened a year later, asks the same for headers. Both already have a mechanism in `spec.dataTypes`, and both are stuck at the same low adoption: | | where it lives | adoption | |---|---|---| | this issue, media types | `spec.dataTypes.<in\|out>.types.*.mediaType` | 20 declarations across 19 Kamelets | | #929, headers | `spec.dataTypes.<in\|out>.headers` | 19 of 262 Kamelets | So the answer to point 1 and point 2 here is that it is already expressible, by exactly the 19 Kamelets that declare a data type. `aws-s3-source`, `google-mail-source` and `slack-source` all state `application/json` on their output; the other 243 say nothing. The reason adoption sits at 7% is the same for both: the declaration hangs off `dataTypes`, so a Kamelet that does no data type transformation has no natural place to put it, and nothing validates or consumes it. The detail I wrote up on #929 applies unchanged here — `KameletsCatalog` reads the underlying Camel component rather than the Kamelet's own declaration, so a consumer asking the catalog what a Kamelet emits does not get these values back. Point 3, examples for input and output types, has no mechanism at all today. None of this is a new decision. It is the same three questions already on #929: whether the declaration should be decoupled from `dataTypes`, whether the validator should enforce it, and whether the catalog API should prefer it over the component. Answering them once covers both issues, and doing so is what would let either be implemented across the catalog rather than in the 7% that happen to transform data. --- _Claude Code on behalf of Andrea Cosentino_ -- 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]
