Evolve or Rewrite?

[goofballLogic]

My understanding of the history of this library is that it was ported from the initial Java implementation. It was also built for standalone builds targeting multiple platforms when the tooling was a bit less sophisticated than it is these days.

As we consider supporting JSON-LD 1.1, should we evolve the current library to adopt modern .NET practices or attempt a rewrite?

[asbjornu]

I'm generally opposed to rewrites, just like Joel Spolsky. Unless there's some major deficiency in the core architecture of this codebase, or the changes involved to support JSON-LD 1.1 are so massive that a rewrite is easier, I would prefer a slowly evolving codebase.

In order to support that, we need a fully functional CI/CD pipeline that allows us to get continuous feedback on tests and also make it easy to publish new versions to NuGet and perhaps also pre-releases to the GitHub Package Registry. I've started that work in #58.

[goofballLogic]

Is there anything you can use help with on #58 ?

[goofballLogic]

I'm happy to stick with evolving the codebase. I have some changes which I'd like to propose overall (partly in connection with #59) but these could be accomplished by evolving the codebase through major releases. Initial thoughts below:

1. I think we should aim for the lowest possible .NET standard for basic algorithm functionality (more discussion on Proposed .NET version compatibility #59)
2. Given that the default JSON serializer in .NET Core is now System.Text.Json I propose that we attempt switching internal logic and the default API to use the native JSON tooling.
3. If we switch internal logic to use System.TextJson, I propose that we move the JSON.net-based methods into a distinct package which can optionally be installed to accomodate drop-in JSON.Net compatibility with the existing version but without imposing the installation of JSON.Net for those who don't want the overhead
4. I propose that, in addition, we support working on raw JSON strings without placing a requirement on the caller to have parsed the JSON into a JObject (or System.Text.Json equivalent).