Cleaning up HttpOp

[Andy Seaborne <an...@apache.org>]

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

Re: Cleaning up HttpOp

[Andy Seaborne <an...@apache.org>]

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" <an...@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
>

Re: Cleaning up HttpOp

[Rob Vesse <rv...@yarcdata.com>]

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" <an...@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