{"action":"created","issue":{"url":"https://api.github.com/repos/apache/jena/issues/151","repository_url":"https://api.github.com/repos/apache/jena","labels_url":"https://api.github.com/repos/apache/jena/issues/151/labels{/name}","comments_url":"https://api.github.com/repos/apache/jena/issues/151/comments","events_url":"https://api.github.com/repos/apache/jena/issues/151/events","html_url":"https://github.com/apache/jena/pull/151","id":164170653,"number":151,"title":"JENA-576: Moving away from deprecated HttpCommons Client API","user":{"login":"ajs6f","id":110994,"avatar_url":"https://avatars.githubusercontent.com/u/110994?v=3","gravatar_id":"","url":"https://api.github.com/users/ajs6f","html_url":"https://github.com/ajs6f","followers_url":"https://api.github.com/users/ajs6f/followers","following_url":"https://api.github.com/users/ajs6f/following{/other_user}","gists_url":"https://api.github.com/users/ajs6f/gists{/gist_id}","starred_url":"https://api.github.com/users/ajs6f/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ajs6f/subscriptions","organizations_url":"https://api.github.com/users/ajs6f/orgs","repos_url":"https://api.github.com/users/ajs6f/repos","events_url":"https://api.github.com/users/ajs6f/events{/privacy}","received_events_url":"https://api.github.com/users/ajs6f/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":15,"created_at":"2016-07-06T20:50:12Z","updated_at":"2016-07-13T14:28:06Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/apache/jena/pulls/151","html_url":"https://github.com/apache/jena/pull/151","diff_url":"https://github.com/apache/jena/pull/151.diff","patch_url":"https://github.com/apache/jena/pull/151.patch"},"body":"This is a bit of a shake-up in the HTTP machinery, but as per discussion with @afs , a \"big bang\" discarding the use of mutable HTTP clients seems like the least painful approach to move forward. Several pieces of Jena machinery are removed in this, including `HttpAuthenticator` and its impls, in favor of directly using HTTP Commons machinery to the same ends. This will cause some annoyance to folks who have used those Jena types, but I think we can reasonably mitigate that with good release docs and readiness to help on-list.\r\n\r\nThere is at least one TODO that remains here, which is to reenable the total-read-timeout for `QueryEngineHTTP`. The immutable nature of HTTP clients in the current HTTP Commons API means that it's no longer a simple matter to just pass through that timeout to HTTP machinery. I will work up a [replacement piece](https://stackoverflow.com/questions/6764035/apache-httpclient-timeout) using `ScheduledThreadPoolExecutor` to timeout running requests, but I wanted to get this out there and let folks react to it to make sure that I'm on the right road before going any further."},"comment":{"url":"https://api.github.com/repos/apache/jena/issues/comments/232372364","html_url":"https://github.com/apache/jena/pull/151#issuecomment-232372364","issue_url":"https://api.github.com/repos/apache/jena/issues/151","id":232372364,"user":{"login":"ajs6f","id":110994,"avatar_url":"https://avatars.githubusercontent.com/u/110994?v=3","gravatar_id":"","url":"https://api.github.com/users/ajs6f","html_url":"https://github.com/ajs6f","followers_url":"https://api.github.com/users/ajs6f/followers","following_url":"https://api.github.com/users/ajs6f/following{/other_user}","gists_url":"https://api.github.com/users/ajs6f/gists{/gist_id}","starred_url":"https://api.github.com/users/ajs6f/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ajs6f/subscriptions","organizations_url":"https://api.github.com/users/ajs6f/orgs","repos_url":"https://api.github.com/users/ajs6f/repos","events_url":"https://api.github.com/users/ajs6f/events{/privacy}","received_events_url":"https://api.github.com/users/ajs6f/received_events","type":"User","site_admin":false},"created_at":"2016-07-13T14:28:06Z","updated_at":"2016-07-13T14:28:06Z","body":"@rvesse : Basically, I think we share the same picture of the situation. I wouldn't claim that this new API presents quite the same \"ergonomics\" as what we now have. I think the heart of the matter is well-expressed by your characterization: \"it replaces a nicely encapsulated API with requiring users to directly interact with a lower level API\". The question is: is that okay? Because the concern here is HTTP/networking, and I think it's at least arguable that HTTP/networking really isn't a concern of Jena. It's something that Jena itself relies on a library to achieve, and I'm suggesting that we don't really gain all that much for our users by repacking that functionality, unless it is cheap to do and there is some kind of value we can add while so doing. (And obviously, I don't think that's so much the case here.)\r\n\r\nYou're quite right that complex authN schemes (and forms-based stuff is a good example) get a little more onerous for the user with this new API. I would suggest, though, that we can mitigate that pretty well with good examples and docs. Showing people how to get their cookie and then hand around the `HttpContext` that holds it shouldn't be too hard. I can put myself on the hook to write some examples in the tests (or some other appropriate place), if it would help with your concerns?"}}
{"actor":{"display_login":"ajs6f"}}