Done. (need to add more tests into Fuseki but I timed out at that point yesterday)

I've tried to rationalise the number of function calls in HttpOp. The triple of HttpClient/HttpContext/HttpAuthenticator all occur together or not at all. I'm not sure that's the best way - do add back anything I over zealously pruned.

I am rather tempted to rename completely so HttpOp.execHttpGet becomes "GET" or "httpGET" etc etc.

All calls go through one place now (debugging and logging).

DatasetGraphAccessorHTTP exclusively uses HttpOp.

        Andy



On 28/06/13 19:17, Rob Vesse wrote:
No, please go ahead.

DatasetAccessors was next on my hit list for adding auth support but if
you want to go ahead and refactor a bit to make this easier to do please
feel free

Rob


On 6/28/13 11:10 AM, "Andy Seaborne" <a...@apache.org> wrote:

Rob,

I was looking at cleaning up DatasetAccessors for HTTP to use HttpOp.

In looking at HttpOp, the handling of results via a
Map<String, HttpResponseHandler> is getting in the way of leaving the
dispatch on content type to the RIOT registries.

Instead, I'd like to have one HttpResponseHandler, and if theer is a
need to switch on content type, then it's a HttpResponseHandler that
dispatches to other HttpResponseHandlers.

The interface HttpResponseHandler will change - remove passing in the
content type (does not work properly for multipart).

This shouldn't get in the way of your authentication changes (that's on
the way out, HttpResponseHandler is on the way back in again).

As it's in the same sort of area, I thought I'd explicitly mention it.

If it's a bit close to changes you have in progress, I can hold back and
wait.  Just shout.

        Andy


Reply via email to