lburgazzoli edited a comment on issue #673: URL: https://github.com/apache/camel-kamelets/issues/673#issuecomment-1008088423
> > Does the Camel DSL or some subset extend to KameletBindings or is it limited to Kamelets? How much room for configuration do people have if all they want to do is blend existing Kamelets into a solution? > No, the goal of KameletBinding (which should be renamed to Binding) is to abstract the underlying engine so we do not expect to add any Camel DSL capability directly to the Binding, if you need such flexibility then you should think about using an Integration where you can use any Camel DSL. > > I see a need for a generic CloudEvent payload processor Action at some point in the future that gives the ability to read and manipulate any payload not just ones that are JSON encoded. Maybe it is limited to payloads defined with a json schema or protocol buffer or some such to make accessing the contents more predictable. It might involve introducing a block of user defined code (groovy or python script block?) added to the kameletbinding yaml that executes in some sort of sandbox. > Adding scripting capabilities through a Kamelet is pretty simple. But I want to point you that this has almost nothing to do with CloudEvents as a CloudEventn is nothing more than an envelope that matches what in Camel is a Message (as Andrea pointed out, there is an issue about a better CliudEvent support in Camel). Camel offers already a way to manipulate Messages (of course) by using a scripting language. -- 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: commits-unsubscr...@camel.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
