NETCURL is a network library with a backstory in the simplicity to find and extract lists of ip-addresses from websites, utilize them and register them as proxies of different types. In short, NETCURL was once built for the DNSBL API.
In the present day, NETCURL has been used in e-commerce platforms to simplify the multi-usage of both REST and SOAP-calls with the say initial method. The module is written to be quickly fired up with no preparing setup, as we often can see in many other libraries (where you need to configure all data by yourself). The only thing required for this module is to load it and then use your preferred request (GET, POST, PUT, DELETE, etc).
The intentions of NETCURL was never to rebuild the wheel as there are so many solutions that is already doing this. In many cases we see finished packages, where everything must be configured from scratch before a "proper" usage (Guzzle, Zend, etc). For NetCURL, this is not the case. In our case, we'd like to be able to utilize such packages and make the best out of it
NetCURL has changed purpose over time. What was planned to be scraping tool became, thanks to the self selective engine that was added, a tool to automatically fetch and parse data and transform it to standard output arrays/objects. The implementation supported common communications including SOAP and partially PHP built in streams though extra drivers - and it was autoselective. If the primary driver wasn't present, it jumped to next one and so on.
The intentions with NETCURL was probably never to rebuild the wheel. Many solutions already did this, but backfired somewhere when it came to setting the utilities up. Very often developers had to make all configurations manually (Both Guzzle and Zend does this), while NETCURL was firing up a high-verbose-level-fetching communications driver automatically. In our case, we wanted to utilize as much packages as possible and choose the best preferred method without asking question. The goal? Standard output, ready to be fetched by the endpoint developer.
Currently, and still in a one-man-army mode, the code for next verson (6.1) could be found here. There's a big difference between 6.0 and 6.1 - it's more standardized and PSR-4 complient. However, the goal is to keep compatibility to 6.0 so that developers can upgrade to proper code without ripping their hair off their heads. 6.1 will be merged into the master branch as soon as it has been properly tested which is primarily done with Bamboo, Pipelines and pipelines with regular ecommerce systems.
To keep compatibility with v6.0 the plan is to keep the primary class MODULE_CURL callable from a root position. It will probably be recommended to switch over to a PSR friendly structure from there, but the base will remain in 6.1 and the best way to instantiate the module in future is to call for the same wrapper as the main MODULE_CURL will use - NetWrapper (TorneLIB\Module\Network\NetWrapper) as it is planned to be the primary driver handler.