Why so inconvenient protocol binding for NATS?

[skillcoder]

Did you try to use this v3 API in production?
https://github.com/cloudevents/sdk-go/tree/main/protocol/nats_jetstream/v3

Why do you think it is "OK" to create separate protocol binding object for each type of event?

If you don't see the issue, I will clarify:

The problem in the cejsm.WithSendSubject - actually this is not an Option, this is required setting!!!
You just can't send any event without setting this "Option"

And since this option not possible to set on Send - you MUST create Protocol for each type of event, since each event should send to separate subject.

[embano1]

@stephen-totty-hpe can you please jump in here with your NATS experience and since you did the v3?

[stephen-totty-hpe]

@embano1 @skillcoder
To be honest, I was carrying forth the precedent set by previous implementations of the protocol. Actually, earlier implementations also forced you to send the streamName as part of the constructor.

As for the "required option", I believe at one time during the implementation PR, I had the sendSubject in the constructor and was asked to remove it.

The Sender interface is:
Send(ctx context.Context, in binding.Message, transformers ...binding.Transformer) (err error)

If needed, someone could define a "sendSubject" inside of the context.Context, similar to the way bindings do it here:
https://github.com/cloudevents/sdk-go/blob/main/v2/binding/write.go#L111

Then, Send could first look at the context.Context, and then look from the constructor. If neither is set, then it could fail.
This would not break the current implementation, but would allow multiple Send calls to change the subject via the context Object.