NATS .NET Version 2.0

[ColinSullivan1]

Please add your ideas, feature requests, and other thoughts on a NATS.NET version 2.0.

Some initial thoughts:

• Version 2.0 will be a new API, assembly and likely another Github Repository. It will replace the current version, which will be sunset at a reasonable period of time with only security and bug-fix releases applied after V2 is GA.
• Will be async all the way from base level I/O up for use in WASM/Blazor, etc.
• Emphasis on ease of use (specifically, to use .NET idiomatic APIs), and performance.
• Thinking of using .NET version 7.0, but open to 6.0 for LTS.
• Ensure seamless use within Blazor, MAUI, and Unity.
• Runs at the edge (Windows 10 IoT Core, Linux arm64, etc).

Comments and suggestions are welcome!

[iskandersierra]

For Apps I prefer using the last cutting edge, like .NET 7.0, but for libraries, I think is preferable to go for LTS .NET 6.0, which still have 10 month to be challenged by .NET 8.0, or even .net standard 2.1, so that we could use it in .NET Framework 4.x.

We may focus on the LTS version, and later, any developer/team than need the library to work on non-core frameworks could work on making the necessary configurations to be able to build there.

Also, I think the client design should reach for being minimal in the sense of not providing functionality beyond what NATS APIs already offer, other than socket re-connection and such. At least on the core library. Then we could extend and develop richer interfaces over the core API to add any fancy functionality or usage patterns.

[sixlettervariables]

.NET Standard 2.1 is not supported on the .NET Framework confusingly enough.

[Kaarel]

+1 for simple core
+1 for additional functionality / helpers for usage patterns

[sixlettervariables]

I believe .NET 6 is the better choice.

If we wanted to multitarget, then having the necessary ifdefs to support .NET Standard 2.0 + System.Memory ref would be nice. Though I think that should be a secondary concern.

[iskandersierra]

Agree!

[ColinSullivan1]

Sounds good to me.

[caleblloyd]

I think NATS.NET V2 should follow the new LTS release lifecycle

• nats.net 2.x should be: net6.0 and supported until .net6.0 reaches end of support (slated for November 12, 2024)
• do a major version bump and use net8.0, support that until net8.0 reaches end of support
• so on and so forth

This would mean when folks go to upgrade .NET to stay current with Microsoft Support lifecycle, they can also doing nats.net upgrades as part of that work.

[cliffchapmanrbx]

As a consumer of this library we would have a strong preference for .NET6 support, please :)

[iskandersierra]

Should we offer both a thread-safe and a non-thread-safe versions of the core APIs?

Given that thread safety is not a zero-cost abstraction in dotnet and given that NATS is used for high throughput communication, we should offer a clear access to a lock-free implementation. Then also add a default thread-safe implementation, as performant as we can, but leaving the users access to the core implementation in case they need to configure thread-safety in a different way.

[caleblloyd]

I have been studying the https://github.com/cysharp/alternats project. It has a very good foundation for the protocol and is async-only. I think we could start with it as a base and then review the public API surface.

The public API should support extensability for any interfaces that it interacts with via a service provider. We should provide 1 implementation with sane defaults. In my opinion the default implementations can be non thread safe.

Example being the header dictionary in an INatsMsg - in the default implementation, the backing store for that can be a regular Dictionary accessed without locks and not a Concurrent Dictionary.

[iskandersierra]

That is a nice project to get inspired by on API design and implementation

[satish860]

I like the thought process but I believe its not just API design that we need to look at but also the Zero copy TCP client connections done at the lower level. I am happy to contribute on that once we start the project

[caleblloyd]

Definitely, AlterNats does zero copy already so that is another reason I think it would be a great base to use.

[satish860]

When are we starting this Project. I am working on a project with Alternats and unfortunately it does not support Jetstream. I am thinking either to contribute there or look for the new version to come out.

[caleblloyd]

The nats-io/nats.net.v2 repo is live. At this point it is mostly a fork of Cysharp/AlterNats which can be used as a base for the client. Let's move discussion over to the new repo!