|
|
Posted by Jerry Stuckle on 09/13/07 03:06
Steve wrote:
>> Not at all. OK, on a Windows system MySQL support is supplied by
>> php_mysql.dll. And if MySQL isn't installed, the DLL won't load and
>> phpinfo() will show MySQL support isn't enabled.
>>
>> The MySQL interface is NOT compiled into PHP on the distributed Windows
>> binaries - or you'd never be able to run PHP unless you had MySQL
>> installed.
>
> again, you brought up the mysql example. i'm keeping this generic and
> modules like .net and others can certainly be compiled directly into php.
>
Nope, I just corrected your misstatements about PHP and MySQL. It is
typical of the way PHP modules act. Other modules act the same way.
> now to say that i have to have mysql (specifically) installed on my system
> that runs php and enables php is rather odd since i should be able to
> connect to any server running mysql if i provide the proper credentials,
> etc.. for this specific mysql lib, you're saying the dependency is an
> absolute must (that i have to have mysql installed on the same server though
> i otherwise have NO intention of ever using it)? can you tell me you've
> actually *done* this in order to prove it to yourself before? do you have a
> documented reference to support this?
>
You need to have the MySQL client libraries installed on the system
running PHP - just like if it were MSSQL Oracle or any other module. So
yes, the dependency is an absolute must.
You need to learn how these modules work. It's not just PHP - the same
is true in C/C++, for instance.
>>> what i'm saying is that this exactly parallels ".net support enabled".
>>> php does NOT do/provide any additional features to ensure that third
>>> party applications are installed, nor should it. php either has the
>>> extensions compiled in or loads them when executed. these
>>> extensions/modules determine whether support is enabled/disabled which
>>> has nothing to do with the existence of the actual third-party
>>> application on a target system...the question pondered by the op.
>>>
>> Nope, it's just the opposite.
>
> references please...i'm not just going to take you at your word...sorry.
>
Quite frankly, I don't give a damn if you take my word for it or not.
Look it up yourself. I'm not going to bother to correct your
misconceptions. A hint - search this newsgroup for all the problems
people have had installing MySQL support when the client libraries
aren't in the path. Or MS SQL when the client libraries aren't
installed on the system.
>>>>> while php may very well provide mysql libraries, it certainly has no
>>>>> relationship to microsoft such that it would warrant providing the .net
>>>>> framework especially given how bulky it is and the frequency at which
>>>>> it is updated and outdated.
>>>>>
>>>> Check again. PHP does not supply mysql libraries any longer.
>>> again, you're missing the point. it used to as a module but now is
>>> compiled in...which was not my point anyway, which i was careful to point
>>> out when following the "by your argument" line of comparison. whether a
>>> compiled feature of php or a loadable module, it is the code that
>>> provided the support to use external tools such as .net and this support
>>> is *completely* independent of whether that external tool is actually
>>> installed on a target system.
>>>
>> No, it is not. It is a dll loaded dynamically at startup, if the php.ini
>> file says to load it and the MySQL libraries are properly installed.
>
> again, that may be the case with mysql but it is not the case with other
> modules and extensions.
>
That is the case with ANY extension which requires external support.
>>>>>> PHP cannot integrate with something which does not exist. But
>>>>>> obviously, since the extension is experimental, they still have some
>>>>>> bugs to work out.
>>>>> yes, which is what i was trying to state...i just didn't go into the
>>>>> 'experimental' part of it. if i need to use .net developed source in
>>>>> php, i just compile it to a standard COM object and use php's COM
>>>>> function to consume it. works for me.
>>>> I just don't use OS-specific code. Works for me.
>>> i'm glad you've got that leeway. as for me, i build what my
>>> paycheck-provider asks. ;^)
>> So do I. :-)
>
> i had to whip up a lib for credit card processing once. not only would the
> boss-man not consider another venue, he insisted on using a user-control
> addon that required a form to be instanciated...however, he wanted the the
> user-control wrapped into a com object dll that had no forms! man i hated
> that guy's thought processes. anyway, that required me to call kernel level
> functions to create a window, coinitial the user-control, and expose it's
> interfaces. all said and done, it was called via COM in php for online,
> instant credit card processing and on his POS desktop systems. about 5
> months after it had been in use, boss-man decided to use another vendor with
> cheaper rates and newer software...at least that one was already a proper
> dll.
>
>
Great. Now try to get it to work when the COM module you're calling
isn't installed on the system. Or the new vendor when you don't have
the DLL installed.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|