Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Time to deprecate gskit
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Patrick Monnerat via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 6 Jan 2023 20:36:15 +0100
On 1/6/23 18:44, Calvin Buckley via curl-library wrote:
> On Tue, 2023-01-03 at 20:07 +0000, Sam James wrote:
>
> Apologies for the late reply. I forgot to subscribe to the list when I
> sent this, so my mail got eaten for the public list (sorry you'll be
> receiving this one again Daniel!), but I took the time to revise this
> based on things I've learned talking to someone at IBM.
Hi Calvin,
Many thanks for the info.
> Speaking as someone who has submitted patches to fix the curl build on
> IBM i, I suspect there are some "dark matter" ILE curl users that
> Patrick mentioned.
Yes, they are mainly ILE/RPG developers that do Cobol-like programming
and sometimes strongly need a data transfer. If libcurl was not
available to them, they would have to write awful command scripts (CL)
involving very heavy external IBM programs and a lot of real file
read/writes !
> (I note that there lots of users for PASE, but that's just basically
> AIX w/ limitations. IBM provides ttheir own builds there.)
Agreed: from the software point of view, PASE is not "OS/400" !
> The big annoyances and possible challenges are:
>
> - No CI; without this, everyone knows development is much harder if you
> can't catch the FTBFS when it starts.
> - I have capacity on a shared system intended for open source
> development. I should be able to set up some kind of CI runner here.
> The very annoying part is Go isn't supported (bar an experimental port
> of 1.16), so the stock GH Actions runner et al is likely to cause
> trouble. I know Jenkins' runner works fine.
When I started porting libcurl to OS/400, it did not have CI tests! But
the local test system was already in place. I investigated to enable it
on OS/400, but gave up because it was a too heavy work for a single man
(requires perl at least). I then relied on tests on other platforms for
the functionalities and often manually tested the OS/400 specific parts.
A simple but very incomplete CI would be to have an automatic pull +
compile every night.
> - Not as many users, because no binary builds. It's pretty easy to
> build, but having to build it at all is a hurdle. Not to mention the
> other dependencies (zlib, libssh2).
This can be combined with the automatic nightly build mentioned above.
zlib and libssh2 are optional for libcurl and should also be in poor
shape: I've not heard about someone maintaining the OS/400 versions
since 2016 when I lost access to an IBM i (I'm also the OS/400 version
author for these libraries).
> - I'd be tempted to offer binary builds that can be linked from
> /download.html. Compilers let you target two versions back, and you can
> get pretty much the entire install base that matters.
> - Binaries would basically involve a savefiles of the POSIX
> filesystem parts (the headers) and the native system objects (the
> shared library, build artifacts... also headers in a different form)
AFAICR, the ILS save file could also be a QSYS object included in a
single downloadable SAVF.
> - GSKit is the system TLS library on i, and IBM is actually fairly good
> about backporting feature updates to it for older versions of i (i.e.
> TLSv1.3 et al). Plus features someone might care about like crypto
> acceleration. However, it's definitely not popular anywhere else.
This is why curl and its gskit backend need a regular maintainer that
has an OS/400 access!
> Long-term, it might be useful to look into porting a different TLS library,
> even if it adds another dependency.
> - Native environment on i is basically something CHERI/WebAssembly
> shaped, but with EBCDIC. Something like mbedTLS/BearSSL that doesn't
> ask much of its host, sprinkled with iconv.
I partially agree: the drawbacks are TLS libs are not yet ported to
OS/400, are heavy and very picky about security.
If you need an iconv wrapper that is more conform to other
implementations than the IBM systems one, see
https://gitlab.gnome.org/GNOME/libxml2/-/tree/master/os400/iconv (yes, I
ported libxml2 too!).
Cheers,
Patrick
Date: Fri, 6 Jan 2023 20:36:15 +0100
On 1/6/23 18:44, Calvin Buckley via curl-library wrote:
> On Tue, 2023-01-03 at 20:07 +0000, Sam James wrote:
>
> Apologies for the late reply. I forgot to subscribe to the list when I
> sent this, so my mail got eaten for the public list (sorry you'll be
> receiving this one again Daniel!), but I took the time to revise this
> based on things I've learned talking to someone at IBM.
Hi Calvin,
Many thanks for the info.
> Speaking as someone who has submitted patches to fix the curl build on
> IBM i, I suspect there are some "dark matter" ILE curl users that
> Patrick mentioned.
Yes, they are mainly ILE/RPG developers that do Cobol-like programming
and sometimes strongly need a data transfer. If libcurl was not
available to them, they would have to write awful command scripts (CL)
involving very heavy external IBM programs and a lot of real file
read/writes !
> (I note that there lots of users for PASE, but that's just basically
> AIX w/ limitations. IBM provides ttheir own builds there.)
Agreed: from the software point of view, PASE is not "OS/400" !
> The big annoyances and possible challenges are:
>
> - No CI; without this, everyone knows development is much harder if you
> can't catch the FTBFS when it starts.
> - I have capacity on a shared system intended for open source
> development. I should be able to set up some kind of CI runner here.
> The very annoying part is Go isn't supported (bar an experimental port
> of 1.16), so the stock GH Actions runner et al is likely to cause
> trouble. I know Jenkins' runner works fine.
When I started porting libcurl to OS/400, it did not have CI tests! But
the local test system was already in place. I investigated to enable it
on OS/400, but gave up because it was a too heavy work for a single man
(requires perl at least). I then relied on tests on other platforms for
the functionalities and often manually tested the OS/400 specific parts.
A simple but very incomplete CI would be to have an automatic pull +
compile every night.
> - Not as many users, because no binary builds. It's pretty easy to
> build, but having to build it at all is a hurdle. Not to mention the
> other dependencies (zlib, libssh2).
This can be combined with the automatic nightly build mentioned above.
zlib and libssh2 are optional for libcurl and should also be in poor
shape: I've not heard about someone maintaining the OS/400 versions
since 2016 when I lost access to an IBM i (I'm also the OS/400 version
author for these libraries).
> - I'd be tempted to offer binary builds that can be linked from
> /download.html. Compilers let you target two versions back, and you can
> get pretty much the entire install base that matters.
> - Binaries would basically involve a savefiles of the POSIX
> filesystem parts (the headers) and the native system objects (the
> shared library, build artifacts... also headers in a different form)
AFAICR, the ILS save file could also be a QSYS object included in a
single downloadable SAVF.
> - GSKit is the system TLS library on i, and IBM is actually fairly good
> about backporting feature updates to it for older versions of i (i.e.
> TLSv1.3 et al). Plus features someone might care about like crypto
> acceleration. However, it's definitely not popular anywhere else.
This is why curl and its gskit backend need a regular maintainer that
has an OS/400 access!
> Long-term, it might be useful to look into porting a different TLS library,
> even if it adds another dependency.
> - Native environment on i is basically something CHERI/WebAssembly
> shaped, but with EBCDIC. Something like mbedTLS/BearSSL that doesn't
> ask much of its host, sprinkled with iconv.
I partially agree: the drawbacks are TLS libs are not yet ported to
OS/400, are heavy and very picky about security.
If you need an iconv wrapper that is more conform to other
implementations than the IBM systems one, see
https://gitlab.gnome.org/GNOME/libxml2/-/tree/master/os400/iconv (yes, I
ported libxml2 too!).
Cheers,
Patrick
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-01-06