Posted by Jerry Stuckle on 01/21/08 02:28

Mark A. Boyd wrote:
> Jerry Stuckle <jstucklex@attglobal.net> posted in comp.lang.php:
>
>> Mark A. Boyd wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> posted in comp.lang.php:
>>>> I will continue to recommend cURL for the reasons I have outlined.
>>>> The difference is I have no relationship with cURL, other than as a
>>>> user of the library.
>>> PMFBI, but I don't understand why you don't see the flexibility offered
>>> by Manuel's class.
>> I see the flexibility. But it's still not as flexible as cURL.
>
> Thanks, that wasn't clear to me from previous posts. Well, you were very
> clear about what you thought about cURL.
>
>>> I suspect that most of us are not hired at the consultant level, but as
>>> application/Web developers. As such, we likely have much less influence
>>> over our clients' decisions about Web server configurations. If a
>>> client is paying consultant fees for advice, I would think they are
>>> more willing to listen to such advice. When hiring/contracting a Web
>>> developer, they are more apt to set the requirements that he/she must
>>> comply with.
>> As a web developer, you are a consultant. And my customers don't set
>> the requirements - we discuss them and agree on the requirements. They
>> trust my advice, because I have sound reasons for giving them.
>
> Makes sense. Although I envision more situations where it might be difficult
> to convince a large client to reconfigure a server.
>
>>> So, if one can build a library of reusable code via the httpClient
>>> class that works with/without cURL, well, isn't that flexible?
>> Sure. But I can do more with cURL than you can with the httpClient
>> class.
>
> Understood - when cURL is available.
>
>>> Or are you suggesting that one should develope this library with code
>>> to handle either situation oneself? If you were to do that, would you
>>> create two separate libraries of code or would you create a class that
>>> can handle either situation? (Ponder this question as a developer, not
>>> as a higher-paid consultant.)
>> I didn't say any such thing. The only thing I said was that cURL is
>> more flexible. Period. Nothing more.
>
> Thus the second question above. I wouldn't have asked if you had already
> answered. AFAIK, only top-posters and Jeopardy players think with the mind-
> set of answers first-questions later.
>

First of all, there is no difference between a developer and a
consultant. A developer IS a consultant.

Now, some consultants may do more, and therefore command a higher fee.
But any developer worth his salt should be able to do this.

And I'm not suggesting anything. One thing I have found - fsockopen()
is more often blocked off by hosting companies than cURL is. That's
because fsockopen() can be used for a lot more malicious operations.

Also, by themselves, fsockopen()/fread/fwrite/etc. are much more
flexible than cURL. But also much harder to use.

>>> Or would you simply turn down jobs that cannot use cURL?
>> As I said. I negotiate with my customers. I didn't say what I would or
>> would not use in any specific situation.
>
> Hmm, I think your answer to the question is "I negotiate with my customers."
> Vague, but OK. I'm certainly not trying to pry into your negotiating
> techniques.
>

No, the customer tells me what he wants. I determine what is required
to satisfy his needs in the most efficient manner. I then look at their
hosting to see if they supply what is required.

If so, no problem. I tell the customer we're OK and can move on.

However, if not, I look at other options, especially those offered by
their current host. I then present the user with the options and
advantages and disadvantages of each option.

And if I recommend they change hosting companies, I have the reasons as
to why they should - and at least two or three options for hosting (none
of which I have any affiliation).

They then have the choice. But most of the time they accept my
recommendations because I have solid reasons. It's all a part of
servicing the customer.

>> I use the tool most suited for the job.
>
> Cliche as this answer may sound, I accept it for the omitted answers. After
> all, cliches become cliches for good reason.
>
>
>

Not a cliche - the absolute truth. For instance, right now I have a
site mostly built on VBScript and Access database (no, I didn't develop
the original site). I need to interface to two other websites (no XML
in either). So it's request pages, parse results, post data to pages,
parse results... All the while still interfacing with their their
current pages and database. This part I'm doing in PHP (using cURL, BTW)
because it's the best tool for the job. But it also meant building a
lot of PHP code to interface to their current database.

In this case VBScript was not the correct tool. My other options could
have been Perl or even C/C++. But PHP was the best tool for this job.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]