I'm looking at the remote access APIs and HTTP usage.
Unless there are good reasons why not, I think using the JDK Java11 HTTP
code, java.net.http is good - less dependencies, lots of info on the
web. It has both sync and async support, and also HTTP/2. It is
complicated and there is value in having packaged ways for common use
cases that have the RDF handling baked in (base URI anyone?!)
Some thoughts:
RDFConnection:
* The name is a bit long!
* New RDFConn (other name?) same operations as RDFConnection but at the
Graph/Node level.
* RDFConnection is an adapter to Resource/Model.
SPARQL Query:
* Convert HttpQuery to use java.net.http.
* Keep the "default global setup" style, and share this with other
network-related code.
* Builder pattern for the per object settings.
* This may use HttpOp or directly use the java.net.http code.
Worth doing it the best way for the long term.
RDF-centric:
* Library of functions and RDF-centric BodyHandler/BodyPublishers,
Deal with compression on input stream, response to RDF,
* Could be useful for sync and async.
HttpRDF
* RDF operations eg.
Graph x = HttpRDF.getGraph(url)
Graph x = HttpRDF.getGraph(httpClient, url)
* GSP naming is in RDFConnectionRemote.
My play area is:
https://github.com/afs/jena-http/blob/master/src/main/java/org/seaborne/http/HttpRDF.java
HttpOp
* This can be smaller and focused on common uses cases; less coverage,
easier to use (and still support use for tests).
* common cases are sync usage of HTTP. If you are writing a spider with
async requests, you'll want control of the HttpClient.
* For each operation have httpGet(args) and httpGet(HttpClient, args)
versions.
* retain the idea of one default "system wide" HttpClient so common uses
cases "Just work". Share with QueryHTTP. Put this in one place "HttpEnv".
* No "HttpResponseHandler" variants, no "httpPostForm"
That's about 50% of the execs.
Andy
