<div dir="ltr">2016-07-20 3:45 Michael Van Canneyt <span dir="ltr"><<a href="mailto:michael@freepascal.org" target="_blank">michael@freepascal.org</a>></span>:<span class=""><br></span><span class=""></span><br><span class=""></span><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Because all Pascal TCP toolkits out there offer a HTTP Client. (lnet, indy,<br>
synapse). By doing this, I leave the choice up to the user which one to use<br>
for various APIs that are built ON TOP of HTTP.<br>
<br>
Your use case is simply one I didn't foresee,<br>
Because I assume that any decent TCP toolkit offers a HTTP client.<br>
<br>
However, now that I understand what you actually need, we can consider this use-case.<br>
<br></blockquote><div><br>The change I am proposing should be accepted even if i did not have that problem to solve. Decoupling the TFPHTTPClient class from the underlying socket framework brings many benefits. Perhaps, the most important benefity is improving the testability of the class. For example, one can test the core functionality of the TFPHTTPClient through "fake" TCP adapters.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I will accept the patch, on the condition that you provide a binding for a C<br>
TCP/IP library too. If your c library is open source, then we can use that.<br>
if not, then I'd ask you to provide an libevent implementation.<br>
<br>
It has no point abstracting out something if we have only 1 implementation.<div class=""><div class="h5"><br></div></div></blockquote><div><br>Great! I will provide the bindings. My bindings are for the <a href="https://developer.mozilla.org/pt-BR/docs/NSPR">Mozilla 's NSPR toolkit</a>. <br><br></div><div>Best regards<br></div></div></div></div>