afs commented on issue #1993: URL: https://github.com/apache/jena/issues/1993#issuecomment-1683582609
I'm curious as to what features you think are missing. Code is never finished. The requirement for Jena is to provide APIs and in most cases hiding the details of HTTP. Semantic Web usage of HTTP isn't the full generality of HTTP. Jena used to use AHC (Apache HttpClient) version 4. There was some ability to optionally configure AHC for connection pools but APIs provided the functionality for SPARQL (query/update and graph store protocol) without requiring the user to understand AHC. There was some URLConnection usage as well. Support for authentication was a bit basic. No HTTP/2 support. AHC5 is quite different at least to get the new features such as HTTP/2 support. So migrating from AHC4 was a significant change either way. The new-as-of-11 JDK HTTP code (JHC) is good. My view is that it is has become an important part of the JDK and will receive maintenance and refresh because of use in modern distributed systems including authentication integration. That can't be said for `URLConnection` but at Java1, HTTP wasn't as significant as it is today. One reason to choose JHC is less dependency complexity. One role for Jena is as a library. Any package that might be used by a system using Jena as a library runs into dependency complexity around on versions. Jena had already been having to control which version of AHC was used, excluding it as a dependency of some Jena dependencies due their dependencies not being updated. So the decision was more like "is JHC good enough?". JHC is lower level than AHC and has a simpler API surface, though I would not be surprised to learn that AHC inspired some of the design of JHC. Abstractions can be built on top of JHC. `HttpRequestModifier` is part of that because, despite W3C standards, different remote endpoints of (commercial) triple stores have different requirements. Short of hard-coding the variations into Jena itself, being able to tweak the query string and the headers. `RDFConnection` (and its companion `RDFLink` for `Graph` and `Node`) pull the main mechanisms together (QueryExecHTTP, GSP etc) although those mechanism do have more direct ways of controlling headers because it's per operation related. So my take is that JHC is a good engine for modern HTTP with good prospects for long term stability and support. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
