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
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.
This is their reply - is there anything in this, or are they
misunderstanding the situation?
We run servers. We want
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
: 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 the various
Here's an idea. Provide commercial PHP support for ISP's for a fee.
Yearly subscriptions ?
via email?
-Original Message-
From: Brian Tanner [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 29, 2001 4:55 PM
To: [EMAIL PROTECTED]
Subject: RE: [PHP] Re: The future of PHP
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
If I didn't know you're not working for Zend, I'd suspect that was a
prepared-question :)
http://www.zend.com/engine2/ZendEngine-2.0.pdf
At 11:26 29-08-01, Geoff Caplan wrote:
Hi folks
While we are on the subject of strategic issues for PHP, a quick question on
the OOP functionality.
As many
Hi folks
While we are on the subject of strategic issues for PHP, a quick question on
the OOP functionality.
As many on this list will know, there is a peculiarity with the PHP object
model - in many situations it creates a copy of an instance when you would
expect a reference. This means that
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 simple
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 - I
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
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
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
most
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
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
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 that for
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 and wait
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 champ. Pity
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 an
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 to
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
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 and its
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
obvious. I'd
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 snmp module
Hi folks
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. Many quite
important libraries seem to be
, August 27, 2001 4:26 AM
To: [EMAIL PROTECTED]
Subject: [PHP] Re: The future of PHP
Hi folks
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
: 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 difficulty of finding
So sprach »Geoff Caplan« am 2001-08-27 um 11:26:09 +0100 :
standard, and no central repository. This compares badly with platforms such
as Perl and Java, who tackled this issue long ago.
Actually, I think you're right.
On the one hand, it's quite nice that there are so many librariries
which
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,
Hello,
Steve Orr wrote:
What kind of PHP application development frameworks, class libraries, or
templates are widely used? Is SiteManager any good? How about phplib?
Others? Doesn't the future of object oriented PHP depend on good foundation
classes? Any comments on PHP object
Greetings Php'ers:
2 cents
bahh to servelts-asp these are new kids on the block. Template this or that,
it doesnt matter, most templates are for lazy peeps anyways :)
, a solid base of people have been using phtml-php for years. It doesnt
matter to me what the e-zines say about which is more
XML is pretty standardized, but the implementation of it in various web
browsers isn't.
I wouldn't consider XML all that comparable to HTML. They don't serve the
same purpose. XML is generally used to order and describe data (metadata,
basically), and although HTML serves roughly the same
Christopher Cm Allen [EMAIL PROTECTED] wrote in message
003201c12be2$f9309b00$[EMAIL PROTECTED]">news:003201c12be2$f9309b00$[EMAIL PROTECTED]...
Greetings Php'ers:
2 cents
bahh to servelts-asp these are new kids on the block. Template this or
that,
it doesnt matter, most templates are for
Thomas Deliduka [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
A little background... Skip to THE JIST if you wanna make this quick.
I am on this webmaster's list where most of the people are fairly new
webmasters. They're just getting the hang of things. I am
On 8/22/2001 10:52 PM this was written:
I don't know if you refer to this list or other one, but I've been a
webmaster since 1993 and in computers in general since 1988 and I also
consider myself of the advanced type.
It definitely wasn't this list. It's another one.
--
Thomas Deliduka
IT
35 matches
Mail list logo
