Re: php.ini configure package
On Mon, Jun 03, 2002 at 12:49:12PM -0500, Steve Langasek wrote:
> > Depends upon who you talk to. IMHO, Debian makes a great webserver at
> > the moment. ;-)
> Considering the alternatives, I still like Debian best. ;)
I didn't say that there are better solutions ;)
Just, Debian has IMO great policy and very good standards-compability.
For the web aplications it's not the case at the moment, I think.
There is still too much freedom for the developer. And from this it follows
that everyone uses another way to solve his problems. There are no real
One example for big problems this way is the include_path setted in .htaccess
or httpd.conf. First it only works for apache, second it overwrites users
include_path, and so previous settings are invalid.
Also there's no digest because of the 3-5 ways and no standard.
I think there should be one way which works for every webserver etc.
First idea is the described global include dir where only subdirs are allowed.
If you don't want to have use the global include path because your package
needy _only_ your include files, it's still open to add an entry to
On the other hand there is no performance problem if you have the whole
/usr/share/php in your include_path because you're not impelled to include
files you don't want. You can include with include("package/file.php"), or you
let it be. for php it's all the same if /usr/share/php has 1000 or 1000^100
> Of course, there are some PHP includes out there that I'm pretty sure I
> *don't* want made available in my global include_path, because of how
> badly written they are; but the easy solution there is to just not
> install them on any of my servers. ;)
Hey, tell me any good reason why it would be a penalty to have them in your
include_path. If you don't want your users to use them, tell them or just give
Push to test. <click> Release to detonate.
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org