On 06/02/2018 04:35 PM, Michael Felt wrote:
>
>
> On 6/2/2018 8:20 AM, Patrick Monnerat wrote:
>> This is true for third party libraries, not for those provided as a
>> part of the OS. Is cURL a benefit to commercial platforms for free ?
>> If yes, by following your above statement, we should stop supporting
>> them.
>>
>> Don't take these words too strictly: I have been absurdly extremist
>> only for the purpose of demonstration ;-) All this stuff is a matter
>> of compromises.
> I package (for AIX), and try to support by reporting test failures
> (much different than bug reporting, imho) and I package from the
> perspective that the dependencies should be as small as possible -
> ideally none.
>
Agreed: you're working on a Unix family system.

> As to OS400 (IBM i would be better these days) support and TLS weaknesses.
OS400 should now be called i/OS: since it changed names 3 times in 10
years and the current name may be ambiguous with IOS, I prefer to keep
the *400 names, that all concerned people understand. IBM i is the
hardware, not the OS.

> Quick question: could you use PACE and maybe openssl.base for AIX -
> and my package? If yes, then that may be a solution for weak TLS
> support in IBM i.

PASE is much like an AIX virtual environment running under control of
low-level OS400 layers. In particular, it has not the same machine
architecture and instructions, is based on ASCII and has its own
addressing space. In addition, it does not support ILE/RPG which is the
main (i.e.: mostly used) compiled language of OS400 programmers and PASE
library entry points cannot be directly called from a program running in
the native OS400 environment. Your question is similar to ask "can you
call openssl in an ARM64 QEMU virtual guest machine from an i386 program
running on the host?"
Needless to say: if that were easily feasible, I wouldn't have done all
the work to port libcurl to OS400.
See implementation note
https://github.com/curl/curl/blob/71c39f29651523ffda10d0abc17f9057f54bd356/packages/OS400/README.OS400#L4
AFAIK, no open-source TLS library has been ported to the native OS400
environment.
>
> Cases like this are not curl's to solve. When the OS provider is not
> resolving it - this is not a responsibility for curl. Maybe it is a
> responsibility, or better a service, a packager provides. Daniel,
> e,g,. is usually friendly enough to assist with understanding possible
> solutions. Again, that does not make it his responsibility for
> permanent maint, or even inclusion in curl.
>
Agreed. But if you want to offer the possibility to package/use/link
some "external" lib with libcurl, you have to provide a mean to have a
compatible ABI, which libcurl already does its way (by providing bundled
specific wrappers we call "backends").
Maybe the TLS abstraction layer is not sufficient for a real separation
of libcurl vs TLS libraries, but it's currently not possible to do more,
as the current abstraction layer is not exposed publicly (header files
are under the ./lib directory and not intended to be installed by some
kind of "devel" subpackage), there's no "plugin" load facility, etc.
Going this way would be a big change in design architecture, with its
own lot of problems we do not have so far.
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-06-02