Hi folks
Here is my ISPs comments on the advice from Rasmus:
Rasmus wrote:
>>
>> Well, I tend to prefer compile from source as well. I guess they simply
>> don't realize that you can compile most of the extensions as shared
>> libraries and configure what should be loaded at runtime in the php.
aam.com
>
> -Original Message-
> From: Richard Heyes [mailto:[EMAIL PROTECTED]]
> Sent: August 29, 2001 1:53 PM
> To: Rasmus Lerdorf
> Cc: PHP General
> Subject: RE: [PHP] Re: The future of PHP -- accessory libraries
>
>
> > So it looks like this is mostly a d
: PHP General
Subject: RE: [PHP] Re: The future of PHP -- accessory libraries
> So it looks like this is mostly a documentation issue. We have not done a
> good job educating the ISPs out there. But they should have been able to
> figure this out by looking at how PHP is packaged by th
> So it looks like this is mostly a documentation issue. We have not done a
> good job educating the ISPs out there. But they should have been able to
> figure this out by looking at how PHP is packaged by the various
> distribution vendours.
Perhaps a section in the manual dedicated to ISP rel
> Hi folks
>
> I asked my ISP to flesh out their negative comments about adding libraries
> to PHP.
>
> This is their reply - is there anything in this, or are they
> misunderstanding the situation?
>
> >
> We run servers. We want to compile stuff from source, for obvious reasons!
> As suc
MAIL PROTECTED]>; "Rasmus Lerdorf"
<[EMAIL PROTECTED]>
Sent: Wednesday, August 29, 2001 2:58 PM
Subject: [PHP] Re: The future of PHP -- accessory libraries
> Hi folks
>
> I asked my ISP to flesh out their negative comments about adding libraries
> to PHP.
>
&g
Hi folks
I asked my ISP to flesh out their negative comments about adding libraries
to PHP.
This is their reply - is there anything in this, or are they
misunderstanding the situation?
>
We run servers. We want to compile stuff from source, for obvious reasons!
As such, the question is
Rasmus Lerdorf wrote:
> > Exactly. When you do ./configure --with-foo=shared;
make
> > then modules/foo.so will appear magically and you can dl() that
or load it
> > using "extension=foo.so" in your php.ini. You don't have
to recompile
> > PHP.
> >
> > -Rasmus
>
> I am afraid that is only theor
At 11:13 29-08-01, Geoff Caplan wrote:
>I am not very technical, as you will have gathered. But all I can do is pass
>on the view of my (rather good) ISP. They offer Java, Perl and PHP, and say
>that they find PHP much the most difficult to extend.
Can you elaborate on what you (or they) mean by
Rasmus
>
> That's a pretty good list. And the Mandrake and Debian packages are every
> bit as complete. I am not as familiar with SuSE nor the fbsd port, but I
> would be very surprised if they were not very close to, if not better
> than, the current RedHat rpms.
>
Thanks for the education -
> Being practical, the vast majority of serious PHP applications will be
> running on Linux. If you were to cover RedHat, and .rpm compatible distros
> such as SuSE, you would cover the requirements of perhaps the majority of
> users.
But RedHat, SuSE, Mandrake, Debian and FreeBSD already have de
Rasmus
Thanks for your very full and thoughtful reply
> Surely there are things we can improve upon, but the current statement of
> the problem whichs assumes that Perl and Java are lightyears ahead of PHP
> when it comes to extending their functionality just isn't true.
I am not very technical
> > Exactly. When you do ./configure --with-foo=shared; make
> > then modules/foo.so will appear magically and you can dl() that or load it
> > using "extension=foo.so" in your php.ini. You don't have to recompile
> > PHP.
> >
> > -Rasmus
>
> I am afraid that is only theory. I tried that for the
Rasmus Lerdorf wrote:
> > That's not allowing me to simply dl() an SO file, because I don't have the
> > SO file to start with - that's what I was trying to get at. If I have
> > to reconfigure
> > everything, there's not much point, I don't think. Unless I'm missing
> > something
> > ob
> Exactly. When you do ./configure --with-foo=shared; make
> then modules/foo.so will appear magically and you can dl() that or load it
> using "extension=foo.so" in your php.ini. You don't have to recompile
This is very good news! I must have mis-rad the manual on this part!! Is
there any way
> That's not allowing me to simply dl() an SO file, because I don't have the
> SO file to start with - that's what I was trying to get at. If I have
> to reconfigure
> everything, there's not much point, I don't think. Unless I'm missing
> something
> obvious. I'd like to be able to simply have
Rasmus Lerdorf wrote:
>>Something which seems to not be a viable option for most things is SO
>>files. For some reason, the only "real" way (documented) to get
>>things into PHP is to compile them all into PHP. I've used the pdflib
>>SO file and just used dl() to bring it in - works like a ch
Rasmus Lerdorf wrote:
>>Look at it from their point of view. Say, as a customer, you want to use
>>library X. The ISP looks around and eventually find it lives on a personal
>>site in Greece or Hungary. Not very confidence inspiring. The ftp on this
>>site is broken, so they email the author a
Geoff (and the list) ...
You have presented an excellent, well-reasoned case, which I endorse 100
percent.
You also raised issues I have not had to consider, as my development has
been for lightly loaded servers under my control, with only the PostgreSQL
and MySQL libraries required. I'll als
> Something which seems to not be a viable option for most things is SO
> files. For some reason, the only "real" way (documented) to get
> things into PHP is to compile them all into PHP. I've used the pdflib
> SO file and just used dl() to bring it in - works like a champ. Pity I
> can't do th
> Look at it from their point of view. Say, as a customer, you want to use
> library X. The ISP looks around and eventually find it lives on a personal
> site in Greece or Hungary. Not very confidence inspiring. The ftp on this
> site is broken, so they email the author and wait a couple of days
Geoff Caplan wrote:
>Rasmus wrote
>
>>This is solved by people who roll distributions. Debian, Mandrake,
>>RedHat, FreeBSD, etc. It is very simple to add new features to an
>>existing PHP setup through these binary distributions of PHP, even for
>>newbies. Once you know your way around PHP a
>installation for the other 400 customers using the server. Then they have to
>take the server down to install the new build. Is it any wonder that they
>just say "no"?
I have to go with the (few) extensions/librarys provided by my ISP.
If you don't run your own server, that's how it works with
m
Rasmus wrote
> This is solved by people who roll distributions. Debian, Mandrake,
> RedHat, FreeBSD, etc. It is very simple to add new features to an
> existing PHP setup through these binary distributions of PHP, even for
> newbies. Once you know your way around PHP and its build system, you
> I love PHP, but for the following reason it could be the death of it. All
> the PHP intellectuals stand up, get together, and solve this problem, or at
> least give us some reassurance. (I'm only a newbie after all). :)
This is solved by people who roll distributions. Debian, Mandrake,
RedHat
Sent: Monday, August 27, 2001 6:11 AM
To: Geoff Caplan; [EMAIL PROTECTED]
Subject: [PHP] Re: The future of PHP -- accessory libraries
Geoff Caplan said:
> I would just like to highlight an issue which I feel has a negative effect
> on the acceptance of PHP.
> This is the difficu
Geoff Caplan said:
> I would just like to highlight an issue which I feel has a negative effect
> on the acceptance of PHP.
> This is the difficulty of finding, downloading, compiling and installing the
> various PHP libraries not included in the core distribution.
Amen.
As a member of a bac
27 matches
Mail list logo
