Release 3.0 without ASP.NET Core features

[kal]

Hi all,

I have a big outstanding task on the 3.0 project plan that I'm in two minds about. On the one hand it would be really nice to have an up-to-date version of the IIS handlers that Rob wrote for dotNetRDF back in the day. On the other hand to do it properly (i.e. fully configurable and properly implementing the appropriate standards) is still quite a lot of work which would mean delaying the 3.0 release.

If we don't release in 3.0, there is still the option of adding this feature to a future 3.x release as it would be simply adding a assembly and NuGet package and shouldn't involve any breaking API changes.

[stefannikolei]

What about dropping .net472 and go on with .net6/7 to reduce complexity?

[kal]

What about dropping .net472 and go on with .net6/7 to reduce complexity?

I did consider that initially. The main reason I decided not to do that was because MS still officially support .NET Framework and as our core code is all written against the .NET Standard 2.0 API that means we can support back to .NET Framework 4.7.2 without conditional sections in the code.

[stefannikolei]

Ok. Yeah then a first step could be dropping net472 and only target netstandard2.0

Which dropping net472 some newer things could be introduced. Perhaps span can help in some situations.

[kal]

Thanks for the discussion @stefannikolei ! It is definitely helping my thinking on this.
AFAICS the only elements that we have that rely on .NET Framework are the ASP.NET library and the Virtuoso adapter (because the Virtuoso client library requires .NET Framework). The ASP.NET library is very old and I think should be replaced with a modern ASP.NET Core implementation. The Virtuoso library is actually a bit redundant I think as Virtuoso does support SPARQL Protocol so you can use the generic SPARQL Protocol adapters to connect to a Virtuoso server rather than the proprietary client library.

So I think that we could maybe do the following before releasing 3.0:

• Verify that the generic SPARQL connectors work with Virtuoso
• Drop the Virtuoso client library and document the recommendation to use the generic connectors
• Drop the ASP.NET library and remove it from the docs (include a big note about this in the changelog for 3.0 so that people are aware)

Does that make sense?

Does anyone object to losing the ASP.NET handlers?

[kal]

I just did a bit of checking of the Virtuoso situation and I can confirm that the basic graph store protocol and SPARQL query/update endpoints will work with Virtuoso. There's a bit of additional work required to ensure that requests have the correct authentication, but that's standard HTTP authentication stuff. So, the native client is slightly more convenient if you don't have user accounts properly set up in Virtuoso (because you can just execute SQL directly against the database), but I'm pretty comfortable with dropping support for the native client unless/until Virtuoso provide a .NET Core version of their library.

[stefannikolei]

@kal #537 in this pr I dropped net472. It targets .net6 and .net7 now.

[stefannikolei]

@kal I looked into the current Asp.Net implementation.

I see two ways how this could be implemented for ASP.NET Core.

1. Implementation with Middleware

• This could be just an port of the current Handlers to one or Middlewares

2. Implementation of separate Endpoints

• complete new implementation. Probably much more complex, but probably very flexible at the end.

[kal]

Yep, that was my initial analysis too. I think a set of middleware and maybe some helpers would be a nice way to provide ASP.NET Core support that is more of a "developer toolkit" for building your own endpoints. We could provide sample code for some simple endpoints implemented via the middleware but leave the full implementation to the users of the library.

I haven't yet really thought through what the design of the middleware would look like though, but I'm thinking that there should be middleware components for SPARQL query, SPARQL update and SPARQL graph store protocol (and maybe for Linked Data Fragments too) which can all hook in to a store that is configured on server startup.

Since starting this discussion and not getting much feedback on it, I had decided that these components could be added in the 3.x lifecycle (i.e. in some releases after 3.0) rather than holding up a 3.0 release until they are added.