Allow to use `SubscribeSync` for `EncodedConn`

[exu]

Feature Request

API of EncodedConn is inconsistent with Conn which is confusing for users.

Use Case:

Single message passed to handler.

I don't want to encode data manually with nats.Conn would love to see SubscribeSync

Proposed Change:

Who Benefits From The Change(s)?

Testkube ;)

Alternative Approaches

Use Conn and mess with Marshalling / Unmarshalling data.

[ripienaar]

It’s perhaps worth noting that the encoded connections idea is essentially deprecated and incompatible with streams etc.

We have decided to take a look at it later and come up with something differrent that meets current needs better.

So you might want to consider if investing in using them now is a good idea.

[exu]

Hi @ripienaar thanks for quick reply - Docs from nats.go client doesn't say a word about any deprecations?

Is there any NATS idiomatic way than to automatically encode/decode messages? Or should I do all codec logic by myself?

[ripienaar]

I am not sure if its widely communicated as you say - for now I would suggest to do it in your code, tends to be not that big a deal.