Revised request API

[mtmk]

Revised request(many) API based on #75
Also added start-up timer as per ADR-40. It's the max time to wait for the first message.

[mtmk]

Are we happy with the public interface i.e. NatsSub and Request*Async?

• I had doubts about the options being passed to Request but I can see the value of not littering the API with too many types.

• RequestMany returning async enumerator forces the developer to use await foreach. Returning a type with a channel e.g. NatsSub may be a better option.

[caleblloyd]

For the Request options - we need a way to pass Queue Group and Headers when not using Model types. So the only thing missing from NatsPubOpts is the ReplySubject which is defaulted.

For the Reply options of the RequestAsync methods we could cut those down, as many of the timeouts do not apply when waiting for a single reply. Or we could document that they have no effect when waiting for a single reply.

For the Reply options of RequestManyAsync - this pretty much does need to be the full set of NatsSubOpts

I think that returning NatsSub is fine for the RequestManyAsync methods

[caleblloyd]

I think this could be used - Headers and Queue Group could be set here right?

[mtmk]

Yes, spot on! Thank you. I forgot about headers when publishing. Queue group doesn't apply to pub-opts. But a good question. Does it make sense to have a queue group on an inbox subscription? If it does, how should we go about it when our inbox is mux-ed and shared, as in this case?

[caleblloyd]

Oops - yes - queue group is on subscribe. Good catch. No, I don't think an Inbox Subscription really needs to support a Queue Group, but it's also not a big deal if it does

[mtmk]

For the Request options - we need a way to pass Queue Group and Headers when not using Model types. So the only thing missing from NatsPubOpts is the ReplySubject which is defaulted.

see comment above

For the Reply options of the RequestAsync methods we could cut those down, as many of the timeouts do not apply when waiting for a single reply. Or we could document that they have no effect when waiting for a single reply.

I'm happy with documenting it. Changed my mind a little. Maybe it's better to keep Type footprint to a minimum. Also, in my opinion at this level of the API it's better to give clues that under the bonnet it is still a pub/sub powering the request reply pattern. We can certainly wrap this later with a much more opinionated/easy/lite API for less demanding applications.

For the Reply options of RequestManyAsync - this pretty much does need to be the full set of NatsSubOpts

Agreed.

I think that returning NatsSub is fine for the RequestManyAsync methods

I was thinking to wrap this PR up as a smaller step and discuss this on a some kind of 'internal redesign' PR. Happy to carry on here though if you like.

[caleblloyd]

I was thinking to wrap this PR up as a smaller step and discuss this on a some kind of 'internal redesign' PR

That sounds good!

[caleblloyd]

LGTM