I don't do roadmaps, but...

Geek Speak, Linux

I’m in the process of putting together a series of releases for The Server Framework. It’s a little more complex than usual so I thought I’d explain why that is.For the past year we’ve been working on a Linux/Mac version of The Server Framework with several clients. This has involved adjusting a lot of the code and moving some stuff around; for example there was code in our “Win32Tools” library that isn’t Win32 or even Windows specific and so that now lives in a new tools library, “CoreTools”, that contains code that can build on all platforms. Switching to building code with multiple compilers tends to expose some new warnings and errors and building on Unix platforms requires that we change all of the path separators in the include statements (thankfully Windows supports ‘both’ path separators). We’ve had a “Linux spike” version of the code for some time and now we’re pulling these changes into the mainstream releases in preparation for releasing the UNIX versions of the code to a wider audience.

In addition to the UNIX changes we have a major design change for the “SocketTools” library. This is stuff that has been in progress since around 2015 and makes it easier to unit test the code and makes it possible to support other operating systems. The main thrust of these changes is that “internals” of the networking code are now easy to replace, either with mocks for testing or with different implementations for cross platform support; so we can support IOCP, EPoll, KQueue, etc. The “new sockets” code lets 90% of your server stay the same no matter which platform it’s running on and ‘simply’ switches out the code that does the networking. There’s an optional “compatibility” layer that helps with migration but, in general, the best approach is to change to using the new callback interfaces and the whole “new sockets” design. The code massively simplifies things, especially in terms of “pluggable filters” for things like TLS and flow control (in summary, pluggable filters are no more as we were the only people to ever develop them, they adversely affected performance and they were complex to write, TLS, TCP flow control, etc are all now “included” in the code using the “internals” concept).

So, to that end, we have the following releases in the pipeline:

  • 6.9.3 - This is a release of the 6.9.2 code with the textual changes for include paths and cross platform compilation and changes to move the code towards “modern C++”. Since we’re now reaching the point where some of the older Microsoft compilers are out of support we can drop support for them and start fully utilising some slightly more modern C++ features where appropriate. There are no bug fixes in this release but there’s a LOT of change.

  • 6.9.4 - This is a new features and bug fix release. Right now we’re still accumulating issues for this release, it currently contains: a design change that makes dealing with read completion errors slightly easier for some clients; some debug output when an async file log becomes synchronous due to the amount of log lines queued (this seriously affects performance and often doesn’t get noticed, it will now); some optional debug for helping with TLS handshake issues.

  • 7.0 - This is a release that takes 6.9.4 and moves the code around so that we could build cross platform, note that it doesn’t actually include any code that lets you build cross platform. Like 6.9.3 there’s a lot of change to the files but, hopefully, no functionality changes. Things like JetByteTools::Win32::_tstring are now JetByteTools::Core::_tstring for example and include paths have changed.

  • 7.1 - This is intended to be a “normal” 7.x release with new features and bug fixes.

  • 7.2 - This will include support for our “new sockets” code.

  • 8.x - It’s intended that the UNIX support will be released in release 8.0

The 6.9.3 release is due soon. The 6.9.4, 7.0 and 7.1 releases are expected to be released in quick succession, if not simultaneously. Upgrading your code to 7.0 will take some work. We have a simple ‘find and replace’ program that can be run on 6.9.x code and that does “most of the work”, but it’s not perfect so you should allocate more time than normal for dealing with a framework upgrade and, ideally, let us know in advance when you intend to do the work so that we can ensure we have space in our schedule to help you. Upgrading from 7.1 to 7.2 will be painless unless you decide to “opt in” and switch to “new sockets”. You only NEED to switch if you intend to move to cross platform support in 8.0, though “old sockets” will eventually be deprecated.

Moving forward there will be a Server Framework Option Pack for UNIX. I expect this will include both the Linux and MacOS changes and I expect that it will be priced the same as the majority of the other Option Packs. If you’d like to get involved with the UNIX beta code then get in touch.

The 6.9.x and 7.0/7.1 releases are currently moving through our build and test system, 7.2 and 8.0 are further off.