There's a new (well, 12 months old) SDK for interacting with JetStream, package github.com/nats-io/nats.go/jetstream. It makes things a bit easier for interacting with JetStream so we want to use it in https://github.com/knative-extensions/eventing-natss but there's a different implementation for the underlying message, jetstream.Msg instead of *nats.Msg.
It would be worth adding support to this SDK, but since our github.com/cloudevents/sdk-go/protocol/nats_jetstream/v2.Message implementation exports both the Message struct and the Msg field, it would technically be a breaking change:
|
// Message implements binding.Message by wrapping an *nats.Msg. |
|
// This message *can* be read several times safely |
|
type Message struct { |
|
Msg *nats.Msg |
|
encoding binding.Encoding |
|
} |
This new SDK also requires nats-server >= 2.9.0.
What are people's opinion on this? If interested, should we just add a new package supporting both and deprecate the old one in future? Any ideas on what this package should be?
There's a new (well, 12 months old) SDK for interacting with JetStream, package
github.com/nats-io/nats.go/jetstream. It makes things a bit easier for interacting with JetStream so we want to use it in https://github.com/knative-extensions/eventing-natss but there's a different implementation for the underlying message,jetstream.Msginstead of*nats.Msg.It would be worth adding support to this SDK, but since our
github.com/cloudevents/sdk-go/protocol/nats_jetstream/v2.Messageimplementation exports both theMessagestruct and theMsgfield, it would technically be a breaking change:sdk-go/protocol/nats_jetstream/v2/message.go
Lines 29 to 34 in 6408c01
This new SDK also requires nats-server >= 2.9.0.
What are people's opinion on this? If interested, should we just add a new package supporting both and deprecate the old one in future? Any ideas on what this package should be?