SSWG-0018: MQTTNIO Proposal

Server Proposals
1

The review of SSWG-0018: MQTTNIO begins now and runs through December 31, 2021. (Note the extra week due to the holiday period)

Reviews are an important part of the Swift Server Work Group incubation process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager (via email or direct message in the Swift forums).

What goes into a review of a proposal?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, become listed on the Swift Server Ecosystem index page .

When reviewing a proposal, here are some questions to consider:

  • What is your evaluation of the proposal and its APIs/implementation?
  • Is the problem being addressed relevant for the wider Swift on Server ecosystem?
  • Does this proposal fit well with the feel and direction of the Swift Server ecosystem?
  • If you have used other libraries in Swift or other languages, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Thanks,
Tim Condon
Review Manager

12 Likes
2

+1, an MQTT implementation is an important for Swift on the Server.

I didn't spent much time reviewing the protocol in detail but what I saw looks great. Thanks very much @adam-fowler, great work!

2 Likes
3

+1, MQTT has been on the list of desired server libraries for a long time and would be a great addition to the ecosystem.

1 Like
4

+1 It is an essential library for the Swift on Server ecosystem. I have also used it and it worked great!

1 Like
5

+1. Reviewing this is the first I've learned about MQTT so I can't comment much on the low level details here, but I've read through the proposal a couple times and the high level details of MQTT.
Given it is a standard for IoT such a library definitely seems valuable to the ecosystem, and this one appears to do all the right things in terms of following the feel/direction of other libraries - built atop NIO, EventLoopFuture and async APIs that follow similar patterns to other libraries, integration with swift-log, cross-platform, etc.

2 Likes
6

+1 from me, I'm somewhat familiar with MQTT and it is very popular in some scenarios or communities. Awesome to offer it also in our ecosystem :slight_smile:

No concerns about adopting into Sandbox level.

Minor note: try await client.subscribe(to: [subscription]) could become an async sequence, but that could just be additional API :slight_smile:

1 Like
7

Konrad do you mean something like this?

// subscribe to topic
await.client.subscribe(to: [subscription])
// return async sequence of publish messages received from server
let seq = client.createPublishListener()

as this is already available

8

That’s what I meant yeah, thanks! A bit weird why it is two API calls? The subscribe can return the sequence and we cancel it as one breaks out of the loop etc

9

It two separate calls because it's two separate actions really. I know there is a relationship there in that you receive PUBLISH messages based on what subscriptions you setup. But you can also receive PUBLISH messages because you had a subscription setup from a previous session. If the only way to process those messages if via a subscribe call the messages from previous sessions could be lost.

Also the SUBACK message we wait on after sending the SUBSCRIBE message contains information. By just returning an AsyncSequence of messages we lose that information.

1 Like
10

I see, thanks for the explanation! Seems i wasn’t fully up to date with how these work :slight_smile:

1 Like
11

Thank you very much, everyone, for your participation in this thread!

I am pleased to announce that the SSWG has voted to accept MQTTNIO at Sandbox level.

@tomerd will lock this thread and add the package to the SSWG package index.

12 Likes