Re: RSocket Followup (post TOC meeting)


Great presentation, RSocket is an interesting project - the flow control handling with the lease based model is impressive.  Speaking for myself and the NATS team, we’re happy to see more messaging related projects being proposed, giving CNCF end users more options to find the best fit for their use case.

In the past I’ve made product comparisons with incomplete information - it was a learning experience, and Alexis can vouch for that. :)  To that end, what does the TOC think of having public comparison cards for related projects, where project maintainers would provide their own input on their feature sets, implementation details, etc?  I think something along those lines would go a long way to help users educate themselves about different projects without bias, and this would facilitate the CNCF in providing guidance to end users.

In the slides, there are a few things I’d like to clarify.  But first, any suggestions on how we can improve our documentation to make our feature set and implementation details clearer would be much appreciated. My general clarification here is that while NATS uses a simple text based protocol, we are payload agnostic, supporting payloads of any type, including binary.

We do appreciate the product comparison. Here is some more detailed clarification.

Slide 36:

  • Binary - Is this referring to the protocol or payload support? ...NATS does supports binary payloads.
  • Max Payload Size - NATS can be configured to be effectively “unlimited”, although the default is 1MB.
  • Browser support:  To clarify, for NATS support is via third party but maintainer support is coming soon.
  • Bidirectional Channel:  Maybe N/A for NATS?. We support multiple streams (subjects) under a request/reply API, but at a lower level all of NATS is async.

Slide 37:

  • Inline Errors - N/A, we provide asynchronous error notifications.

Slide 38

  • NATS Languages - See
  • Reactive Streams Support - Third Party
  • IPC - The protocol is text, but payloads are binary (payload agnostic).
  • Creators - We credit Derek Collison as the creator of NATS rather than a specific company or organization.

Again, we’re really happy to see more messaging projects proposed, and I hope this can clarify to create a more accurate project comparison.  I’d love to hear what people think about some sort of public feature set comparison, endorsed by the CNCF.



Join to automatically receive all group messages.