I've created a GitHub organization called 'SwiftNIO Extra'. The idea is to use that as a common place for 3rd party protocol implementations for SwiftNIO. That is, just channel handlers which parse and/or emit a specific network protocol. Absolutely no higher level framework specific stuff (e.g. wrappers for client libs etc.). The idea being, that such can be reused across all NIO based frameworks instead of being tied to specific, "opinionated" implementations.
Right now it just contains the two protocols I implemented (and open-sourced):
If someone is interested, I'm very happy to add additional people and repos to that organization. If not, well, that will be the place where I put my protocol implementations (and ports of vendor specific implementations) nevertheless
Again the idea is that it just contains generic stuff which works with just NIO and doesn't add extra wrappers. As a consequence I suggest that the modules all start with NIO, like NIOIRC, NIORedis, etc. A nice client wrapper (which would not be part of this effort) could then be named just Redis or whatever the framework vendor wants. (e.g. I split my clients out of the packages above and put them into own ones over at Noze.io)
Such a protocol module would usually consist of three things:
types to represent the parsed or emitted entities (e.g. IRCMessage or RESPValue)
inbound channel handlers which emit those types, outbound channel which consume those types
a pipeline config function (e.g. configureRedisPipeline())
Or in other words: They are supposed to work the same like the builtin modules e.g. NIOWebSocket or NIOHTTP1.
I don't care that much where it lives (it just shouldn't have a brand attached) - e.g. maybe we could also just use the server-api effort - but an idea here was that this thing is specifically for 3rd party modules the core SwiftNIO team itself does not want to support. (i.e. different to swift-nio-ssl or swift-nio-http2).
I think there is scope for having both. swift-nio-extras ultimately aims to serve small use-cases. @Helge_Hess1's proposal seems to cover larger use-cases: things that benefit from having their own repository, but are not within the main area of focus of the core NIO team.
Maybe we can rename the org @Helge_Hess1 to avoid confusing with the one under the Apple org.
For example, SwiftNio Community like Vapor Community · GitHub?
I renamed to title and the description of the org, looks good to you? I think it is good to clarify that those are not SwiftNIO supported official projects.
The TL;DR: why not both?
I don't care too much, but I would almost like to suggest that the swift-nio-extras could also just live at that Extras org. Maybe under a different name, like swift-nio-common?
In the end it depends on what actual contributors want. Is there anyone who would want to open a repo under such an umbrella? @IanPartridge?
Someone in the forum was working on a statsd client a few days ago. I think that would be something which could live here too.
To make this work, there has to be a desire on the contributors side to go that extra step to add a framework agnostic module. So far I only know me and maybe NIO itself which has interest in that
This is just a suggestion, my hopes are not super high that this will actually work, but I thought I give it a go. In the worst case it just stays my private org
