HTTP TPC v2

[bbockelm]

This is a renewed version of the TPC code. The core algorithms and approaches are identical but improvements include:

• File naming follows Xrootd naming scheme.
• Backport from C++11 to C++03
• Implement an equivalent to curl_multi_wait for platforms with very old curl.

With this, the TPC code should function on SL6.

[ffurano]

Hi,

manually on my Ubuntu machine it compiles fine, it only misses to add its item to the little summary printed in the cmake phase. As it's an XrdHTTP plugin I'd list under it.

On a build system for sl6/cc7/x86_64/i386 the TPC is not compiled, as the needed libcurl is not listed in the deps of the specfile, so my nightly test machines are still without it.

Brian, is there any special requirement for libcurl in the specfiles ? Would you mind to fix these two little things?

[abh3]

Umm, this pull request violates EPEL packaging rules. A shared library cannot also serve as a plugin library. It's either one or the other but not both. So, the packaging here needs to be rethought. I don't have an immediate solution but I'm sure there is one.

[abh3]

Here is a suggestion that would likely work:
a) Keep LIB_XRD_HTTP as a MODULE (maybe the variable should be renamed PLUGIN_XRD_HTTP.
b) In this module only include XrdHttpProtocol (you may want to research to see what other object files are only referenced by XrdHttpProtocol and include those as well).
c) Anything left over goins into libXrdHttpUtils.so (notice this does not have a plugin suffix).
d) The plugin modulewould also link against libXrdHttp.so.
Doing it this way keeps backward compatibility and adheres to EPEL packaging rules.

[bbockelm]

@abh3 - are you sure it's an EPEL packaging rule? The closest I can see are the Devel Packages section here: https://fedoraproject.org/wiki/Packaging:Guidelines.

This clearly discourages using an unversioned shared library, but it says nothing against having one module link against another module.

Another route, perhaps less-disruptive, would be to load libXrdHttp.so from the plugin itself. That'd work here, but would clearly discourage other plug-in writers...

[xrootd-dev]

Hi Brian, We were hit by EPEL refusing to accept our initial version where a shared library served as a plugin as well as linkable target. The specific rule is that you are not allowed to link against plugins. The other rule that, as far as I can tell, is not specifically listed is that a shared library cannot be a plugin as well as a link target because it essentially violates the first rule. Add to that that we version plugins using a name extension makes it problematic anyway. So, the cleanest solution is to separate plugin code from anything you need to link with. Since it's relatively easy to do, we do it that way. What I outlined in my comment is trivial to do the sloppy way and not much more difficult to do the right way (i.e. proper refactoring). Andy

…

On Thu, 14 Jun 2018, Brian Bockelman wrote: @abh3 - are you sure it's an EPEL packaging rule? The closest I can see are the `Devel Packages` section here: https://fedoraproject.org/wiki/Packaging:Guidelines. This clearly discourages using an unversioned shared library, but it says nothing against having one module link against another module. Another route, perhaps less-disruptive, would be to load `libXrdHttp.so` from the plugin itself. That'd work here, but would clearly discourage other plug-in writers... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #737 (comment) ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1

[bbockelm]

In retrospect, having a versioned interface will help plugin library writers manage version changes in the future.

I just pushed a commit to refactor things into a separate utilities library and touch-up the appropriate packaging. Any external packages that currently link against libXrdHttp.so should continue to function.

[xrootd-dev]

Hi Brian, Yep, that will work, thanks. Andy

…

On Thu, 14 Jun 2018, Brian Bockelman wrote: In retrospect, having a versioned interface will help plugin library writers manage version changes in the future. I just pushed a commit to refactor things into a separate utilities library and touch-up the appropriate packaging. Any external packages that currently link against `libXrdHttp.so` should continue to function. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #737 (comment) ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1

[bbockelm]

@ffurano - I added the TPC build status to the cmake summary.

For libcurl, you just need the standard library headers (provided by the libcurl-devel RPM). I backported some functionality such that the TPC should function even with the very old version in RHEL6. Additionally, I just added the corresponding build requirement to the packaging scripts.

(Is it possible to improve the Travis-CI configuration so things like packaging can be checked for errors prior to merge?)

[ffurano]

Hi Brian, I am on it. Will know by tomorrow, I am off but will take a look anyway.