Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 21 Current »

Code

Currently, and still in a one-man-army mode, the code for next verson (6.1) could be found hhereere. 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.

Live information

There's a Mailinglist put up for everything concerning netcurl. That's also where you can find release information (for now). You can subscribe to the list here.

Supported Versions

BranchDevelopment startedInitial ReleaseActive Support UntilMaintenance
5.02016-12-16Never2017-08-172017-08-17
6.0

2017-08-17

2017-09-01
Commit 397c036fc61
2020-04-012022-01-01
6.12019-09-01
According to commit b4dea50fd24
2020-05-24Not decidedNot decided

Inline documentation

Autogenerated docs can be found, daily, at https://gitreport.tornevall.net/tornelib-php-netcurl-6.1/.

Compatibility

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.

Project status

v6.1.1

Key Summary T Updated Status
Loading...
Refresh

v6.1.0

Key Summary T Updated Status
Loading...
Refresh

Backstory

History

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.

Present time

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.

  • No labels