Semen
Hey Michael, i'm agree with the idea, but as i explained i other issues\PR I would be very careful with `client` and `provider` words. I had a worry, that when...
In `java-spring-template` I generate inner class for `allOf` where each property of aggregation is present as variable, please have a look: https://github.com/asyncapi/java-spring-template/blob/9ba5e5a8c6f19376b2367c9803b826e88188a2d0/template/src/main/java/com/asyncapi/model/%24%24objectSchema%24%24.java#L85-L112 for support of `anyOf` or `oneOf` an empty...
> @Tenischev if there would be 2 operations for a RequestReply. Where is the need for the relation between them? You asking about code or spec? If about the spec,...
Regarding the topic, I see a logical problem that `action` and `channel` fields which are **required** in Operation Object will be not required in child object (at least `channel` could...
@derberg as requested 😄
The `$ref` from `reply` to `operation` would work for generation, but I see a drawback in use case here, because now `pingReply` has defined `action` = receive. Thus it couldn't...
could we allow design like: ```yml operations: pingRequest: action: send channel: $ref: '#/channels/ping' reply: pongReply: channel: $ref: '#/channels/pong' ``` ? Consequently ```yml operations: pingRequest: action: send channel: $ref: '#/channels/ping' reply:...
@derberg @smoya What do you think about my suggestion here https://github.com/asyncapi/spec/issues/981#issuecomment-1779173573 ? In this way structure under `reply` will have a name either by direct definition or by name of...
@GreenRover You are right, that reply not mandatory to be handled asynchronously and some libraries provide default methods to handle it synchronously. But here we have the spec, not a...
> What i intended with the current solution is that you can generate code out of the spec that full fills the classic blocking request reply. Looks like we have...