Find a long-term solution for keepalive

[wikier]

As reported in the mailing list, looks like the keepalive module has been removed in version 3.9.1 of urlgrabber.

I found some discussions about the issue:

• http://stackoverflow.com/questions/1037406/python-urllib2-with-keep-alive

But I need to read more to find a long-term solution for such feature...

[indeyets]

Long term solution is Requests

[wikier]

@indeyets sure, requests is for sure in the pipeline for 2.x (issue #37). So the question is to refactor 1.x to use it, a push the development of 2.x. What do you think?

[indeyets]

Requests is compatible with 2.6+. So, it means that refactoring 1.x will lead to the loss of compatibility with 2.5 (I don't remember is 2.4 is supported)

[indeyets]

oh… I just noticed, that you only use 2.7+ in Continuous Integration since 6 days ago. If that's the plan, then we can definitely use Requests for emulating current network interface

[wikier]

@indeyets honestly I'd prefer to switch to requests in 2.x...

[wikier]

According to henrysher/urlgrabber#2 does not look that urlgrabber is going to work under Python 3.x...

[wikier]

Using this port http://pastie.org/2388246 could be an option, but I think the author (@bgw) has not published any package with it, or at least I can't find it.

[gromgull]

it's only ~300 lines of code - just add it to SPARQLWrapper directly ?

On 3 November 2015 at 08:29, Sergio Fernández notifications@github.com
wrote:

Using this port http://pastie.org/2388246 could be an option, but I think
the author (@bgw https://github.com/bgw) has not published any package
with it, or at least I can't find it.

—
Reply to this email directly or view it on GitHub
#51 (comment)
.

http://gromgull.net

[wikier]

@gromgull LGPL license

[wikier]

I'd personally remove the keep alive support until we do the major refactoring for 2.x; opinions on that?

[wikier]

Solved by using a new keepalive package (required by license terms).

[niklasl]

I don't have deep insight into how SparqlWrapper is being used in applications, but I wonder if mechanisms like these should be pluggable and interchangeable? By which I mean that SparqlWrapper (and thus RDFLib) shouldn't bundle a lot of choices by default, but support opt-ins by using a pluggable API.

It could even provide sensible defaults for "advanced" behaviour by doing try-imports and declaring optional dependencies. (But avoid opinionated choices.)

Or perhaps better, work as a component in an application responsible for optimizing its HTTP handling (and choice of e.g. keep-alive, HTTP/2...).

[wikier]

A completely valid point @niklasl; please add it to issue #37.