Long term goals for OpenTK (4.0 onwards)

Details

4.0 as a whole has a number of goals that makes it significantly different from the legacy versions of OpenTK. In short, these are the goals we want to attain in 4.0.

• A modularized library. In the past, OpenTK has been one single monolithic assembly, containing everything from sound to graphics to input to math. This has been problematic from both a development and a user perspective requiring the presence of the entire library even if only a small portion is used.

  Mirroring the structure of Microsoft's recently released .NET Core, we want to split the previously monolithic structure into several independently consumable subsystems. If a user only needs audio, all they get is audio. If they only need OpenGL 3.3, all they get is OpenGL 3.3.

  Each subsystem should live in its own project, and be published as its own nuget package.

• Wider platform support. Until 4.0, OpenTK has targeted .NET 2.0 for maximum platform support. This has worked fine, but it has been a major hurdle in keeping up with the evolving .NET ecosystem. Furthermore, with the advent of new runtimes like .NET Core, we've reached the end of what can be done with .NET 2.0. It is, simply put, too old and too unsupported.

  Our goal is to retarget the library to .NET Standard 2.0, ensuring its language-guaranteed compatibility with all known runtimes out there (without any runtime-specific hacks!) and giving us all of the new tools and features that has evolved over the last 16 years.

• Code quality. It's an unfortunate fact that a lot of the code in OpenTK isn't the best. This stems from its long history, and the fact that it's been targeting .NET 2.0 up until now. We've been crippled in our tool repertoire, and been unable to use new language features, standard library types, and external libraries.

  In 4.0, we want to change this. We are updating the target framework to .NET Standard 2.0 (as described above), and we intend to use it to its fullest degree. This means updating old patterns, using more specialized types, and leveraging new language features wherever we can.

• Consistency. As a result of the library's long history and numerous contributors over the years, the consistency of the code has suffered. Multiple naming styles, indentation styles, documentation styles, brace styles, et cetera are present in the codebase. There is no common set of rules that everyone must follow.

  Normalizing and standardizing the code style across OpenTK is one of our primary goals, and to that end, we've written a style guide that any new contributions must follow. Every subsystem needs to be updated to match this guide, and we'll be continuously working to ensure that the codebase is kept up to date.

• Reliability. With its large and arcane codebase, OpenTK has been subject to more than its fair share of strange behaviour and bugs. Unit and integration testing has, up until now, not been standard practice, and it was only recently that the mathematical subsystem was given a reasonable set of tests (uncovering several bugs in the process)

  The future brings tests and reliability guarantees. Anything that can be tested, should be tested. Writing automated tests should be as high as a priority as writing the business code itself, and we hope to one day be able to confidently say that the library is thoroughly tested.