nats create stream does not expose noAck about jetstream

[ripienaar]

Boolean CLI options take —no-ack unfortunately the library they generate the CLI doesn’t show this clearly

[matthiashanel]

Boolean CLI options take —no-ack unfortunately the library they generate the CLI doesn’t show this clearly

Yep, just tried that. it takes it. but it does not make it into help.

[ripienaar]

Yeah it’s also a pain to prompt for because you get basically a 3 state Boolean.

Will see if I can turn it into a nil pointer Boolean which is really annoying in go

[matthiashanel]

No Rush, I basically filed this so it's not forgotten.
The option is a result of jetstream acking whenever there's a response subject, I believe the fix should be in not doing that.

[ripienaar]

@matthiashanel If I follow what you're saying you want JS not to ack receiving messages via the reply subject? How else would it ack receiving messages?

[matthiashanel]

@ripienaar , I assume things can still change while in technical preview.
For starters I'd not use nc.Request(q.Topic, out, timeout) to receive an ack.
It forces the entire connection to use old style inboxes.
I would add a call that does basically does what request does (create an inbox, subscribe, auto unsubscribe 1, publish request, s.next) but instead uses an inbox with a new prefix $JS._INBOX.
This would still be be compatible with the protocol.
Adding a helper say nc.RequestJSAck(...) would keep usage simple.
Jetstream would only respond if such an inbox was used.

To support publishrequest getting multiple answers, from nats clients as well as jetstream, I'd make the inbox name format known and add a call NewInboxWithAckResponse(), So that the client can create it's own subscriber etc...

[ripienaar]

While those would be interesting improvements one of the main driving forces for the JS design is to be “just nats” it has to fit in naturally with what people already know.

We don’t want to create ways to do JS specific requests and that’s a feature imo.

Re the inboxes - we have to use old style inboxes so JS know when interest is gone

[matthiashanel]

This is at the cost of requiring configuration that at best has to be set, at worst allows you to shoot yourself in the foot.
Either way smth. new has to be learned, semantic overload of existing calls and thus new responses, or a new inbox soliciting a certain response (an inbox we could, by name design, make subject to permissions).
I just want to have brought it up.