[PHP-DEV] Re: PHP 5 Features

[J Smith]

I doubt you're going to get a really good answer for this question because

1. PHP 5.0 isn't out yet and won't be out for a while. (Not until Zend 
Engine 2.0 is done, I'd assume.)

2. This is a PHP development group, so do you really think you're going to 
get an unbaised answer here? Would you ask a Microsoft representative 
whether or not Windows XP is better than linux? 

J


Michael Heuberger wrote:

> Hi
> 
> I'd like to have a look on the new features in PHP 5.0 because I need to
> evaluate different technologies for a new big website.
> 
> I ask: PHP 5.0 or JSP, what's better?
> 
> Can you give me some information, links or documents?
> 
> Thank you!
> 
>  - Mickey from Switzerland
> 
> ---
> Dipl. Ing. Inf. Michael Heuberger
> SoftCon Informatik AG
> Dufourstrasse 185a
> CH - 8008 Zürich
> Fax   +41 1 388 71 22
> 
> www.softcon.ch
> mailto:[EMAIL PROTECTED]
> 
> This e-mail and any attachments are confidential and contains information
> that may be privileged or otherwise protected from disclosure. If you are
> not the intended recipient, you should not disseminate, distribute, copy
> or otherwise make use of this e-mail. Please notify the sender immediately
> by e-mail, if you have received this e-mail by mistake and delete this
> e-mail from your system. We undertake every effort to keep our network
> free from viruses. Please do nonetheless verify that this email and any
> attachments are free of viruses. We do not take responsibility for any
> computer virus which might be transferred by way of this e-mail. By
> sending me/us messages through e-mail, you agree to correspond by e-mail
> in the relevant matter.


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP 5

[Stig S. Bakken]

On Wed, 2002-01-02 at 17:09, Joao Prado Maia wrote:
> 
> On Wed, 2 Jan 2002, Zeev Suraski wrote:
> 
> > At 16:06 02/01/2002, Björn Schotte wrote:
> > >* Zeev Suraski wrote:
> > > > Well, I think that the main motivation for separating the modules away was
> > > > the release schedule.  I.e., separating the release schedule of each
> > > > extension from the release schedule of the PHP core itself.
> > >
> > >Jep. Just to note: I'm +1 for it.
> >
> > I'm +1 for separating the less popular ones, but I'm -1 for separating
> > everything (look up the archives as to why...)
> >
> 
> Why not separate everything and then bundle the more popular ones to the
> normal PHP distribution on the time of a release ? I would love to be able
> to upgrade just the 'GD' extension if there was a bug on the extension on
> release PHP4.1.12 and it was fixed on PECL version of the extension
> 2.1.23.
> 
> I would also love to be able to tell the users of my application to just
> use the PEAR installer to download and install the bugfix release of the
> GD extension instead of telling them to not use a particular buggy / not
> compatible version of PHP.
> 
> I can understand that it will mean more work to you guys to handle
> several release independent extensions, but if you can just use the PEAR
> installer to download the stuff from the repository, you will be able to
> download the stable releases from PEAR and then build the general PHP
> distribution.

I'm getting into this discussion three weeks late, but anyway...

There is _one_ issue that needs to be dealt with seriously and solved if
this is all going to work: binary compatibility for loadable
extensions.  If you upgrade PHP to a version where Zend got some tiny
new function (that your extension does not use), you still need to
rebuild your extension.  This is a problem, rebuilding PHP and a
gazillion extensions separately is a lot more work than just rebuilding
PHP with the same config.nice you used last time.

I guess there are mainly two cases where ZEND_MODULE_API_NO changes:

1. A new function is added, does not affect old extensions, so they
should be able to load.

2. A function's parameter list is changed, may affect old extensions. 
The best thing is of course to not change parameter lists, but if it's
really needed we should try working out something.

Libtool's versioning system should be able to help us out, but it would
require going from dates to consecutive numbers (or adding the latter).

 - Stig


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: PHP 5

[John Lim]

Hi,

Peter Illes <[EMAIL PROTECTED]>  has this feature request he posted in
php.windows. Looks useful to me for php 5:

My original problem is simpler than that, though: I'd like to pre-allocate a
buffer for the string. Is this possible in PHP?

This is possible in both C/C++ and Delphi (with SetLength() in Delphi). The
reason for this to have let's say 4-5 re-allocations instead of ~10,000+
re-allocations.

Of course we could get into the source of PHP to add the functionality (or
alternatively, roll our own cache object), but this is a very basic feature,
and I'm sure it does have it, I'm just too unlucky not finding out how...

Happy New Year,
Peter


Andi Gutmans <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Hey,
>
> The Zend Engine 2 has made lots of progress.
> I think we should have a discussion of what other things besides the
> scripting engine we'd like to change for PHP 5.
> I know there was talk on deprecating some stuff such as old-style function
> names, moving extensions to PECL etc.. I think it's a good time to start
> discussing some of these issues (hopefully we can keep things short :)
> Also, let's try and keep the scope to realistic changes which won't turn
> PHP upside down and which are doable within a relatively short period of
> time. I think it'd be really cool if we could get an alpha of PHP 5 out by
> Spring.
>
> Unrelated, I'm still waiting to hear exactly what mechanism the PEAR guys
> implemented for PECL. I know that if it's not a really cool easy to use
> mechanism I would prefer to wait until we write one. One of the main
> strengths of PHP is that everything is bundled together and is easy to
> setup. We shouldn't make it much harder on people. Although we're planning
> on only move the unimportant extensions out of PHP I still think it should
> be extremely easy to get a list of available extensions (maybe even a part
> of the ./configure process) and to easily download/configure/install them.
>
> Andi
>



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Joe Webster]

Works perfectly -- god love Apache ;)


-Joe

"Joe Webster" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> That rocks, pending it works, my problems are solved. It would still be an
> awesome feature for PHP, but nice to know apache will work otherwise. IIS
> SUCKS!
>
>
> Thanks again!,
> Joe
> "Sander Steffann" <[EMAIL PROTECTED]> wrote in message
> 008d01c193e3$53c14980$[EMAIL PROTECTED]">news:008d01c193e3$53c14980$[EMAIL PROTECTED]...
> > Hi,
> >
> > We do exactly the same with Apache SetEnv:
> >
> > SetEnv  media_regionaamapeldoorn
> > SetEnv  media_regioid  27
> > SetEnv  media_module   index
> >
> > And we get them in the PHP script with
> > $GLOBALS['HTTP_SERVER_VARS']['media_regionaam'];
> >
> > Works great for us.
> > Sander
> >
> > - Original Message -----
> > From: "Zeev Suraski" <[EMAIL PROTECTED]>
> > To: "Joe Webster" <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Wednesday, January 02, 2002 11:40 PM
> > Subject: Re: [PHP-DEV] Re: PHP 5
> >
> >
> > > This could probably be done.  It does sound helpful.
> > >
> > > Zeev
> > >
> > > At 00:29 03/01/2002, Joe Webster wrote:
> > > >Yes it would have to be in every script in the vhost, location or
> > directory
> > > >directive.
> > > >
> > > >It could be a constant =) That would make my life easier.
> > > >
> > > >Thanks,
> > > >-Joe
> > > >
> > > >"Zeev Suraski" <[EMAIL PROTECTED]> wrote in message
> > > >5.1.0.14.2.20020102234728.028651c0@localhost">news:5.1.0.14.2.20020102234728.028651c0@localhost...
> > > > > At 23:33 02/01/2002, Joe Webster wrote:
> > > > > >I have something that I am currently dealing with:
> > > > > >
> > > > > > Using mod_perl with apache, you can put this in a apache
> > directive
> > > > > >(vhost, location, directory):
> > > > > > PerlSetVar somevarname somevarval
> > > > > > and that would pre-define somevarname equal to somevarval.
We
> > are
> > > >trying
> > > > > >to move completely to php (we're 1/2 php and 1/2 perl) however,
we
> > really
> > > > > >need to be able to set the vars like this. I did look through the
> > > >mod_php.c
> > > > > >and I noticed the php_value, php_flag, php_admin_value, and
> > > >php_admin_flag,
> > > > > >but nothing for a variable.
> > > > >
> > > > > Would it be defined in every PHP script that runs?  Does it really
> > have to
> > > > > be a variable, or can it be a constant?
> > > > >
> > > > > Zeev
> > > > >
> > > >
> > > >
> > > >
> > > >--
> > > >PHP Development Mailing List <http://www.php.net/>
> > > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > >For additional commands, e-mail: [EMAIL PROTECTED]
> > > >To contact the list administrators, e-mail:
> [EMAIL PROTECTED]
> > >
> > >
> > > --
> > > PHP Development Mailing List <http://www.php.net/>
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > To contact the list administrators, e-mail:
[EMAIL PROTECTED]
> > >
> > >
> > >
> >
> >
>
>



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Lenar Lõhmus]

Joe Webster wrote:

> Example:
> 
> We have 200+ radio station websites in a network. The way we store
> data
> in the database is by call letters (since some websites have more than one
> domain). So call letters (whor-fm :) ) are the key to just about
> everything we do. So, in the vhost file for apache we want to set the
> station call letters so that the letters are available to the code.
> 

Maybe you should use SetEnv?

Lenar

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Zeev Suraski]

Good point :)

At 01:15 03/01/2002, Sander Steffann wrote:
>Hi,
>
>We do exactly the same with Apache SetEnv:
>
> SetEnv  media_regionaamapeldoorn
> SetEnv  media_regioid  27
> SetEnv  media_module   index
>
>And we get them in the PHP script with
>$GLOBALS['HTTP_SERVER_VARS']['media_regionaam'];
>
>Works great for us.
>Sander
>
>- Original Message -
>From: "Zeev Suraski" <[EMAIL PROTECTED]>
>To: "Joe Webster" <[EMAIL PROTECTED]>
>Cc: <[EMAIL PROTECTED]>
>Sent: Wednesday, January 02, 2002 11:40 PM
>Subject: Re: [PHP-DEV] Re: PHP 5
>
>
> > This could probably be done.  It does sound helpful.
> >
> > Zeev
> >
> > At 00:29 03/01/2002, Joe Webster wrote:
> > >Yes it would have to be in every script in the vhost, location or
>directory
> > >directive.
> > >
> > >It could be a constant =) That would make my life easier.
> > >
> > >Thanks,
> > >-Joe
> > >
> > >"Zeev Suraski" <[EMAIL PROTECTED]> wrote in message
> > >5.1.0.14.2.20020102234728.028651c0@localhost">news:5.1.0.14.2.20020102234728.028651c0@localhost...
> > > > At 23:33 02/01/2002, Joe Webster wrote:
> > > > >I have something that I am currently dealing with:
> > > > >
> > > > > Using mod_perl with apache, you can put this in a apache
>directive
> > > > >(vhost, location, directory):
> > > > > PerlSetVar somevarname somevarval
> > > > > and that would pre-define somevarname equal to somevarval. We
>are
> > >trying
> > > > >to move completely to php (we're 1/2 php and 1/2 perl) however, we
>really
> > > > >need to be able to set the vars like this. I did look through the
> > >mod_php.c
> > > > >and I noticed the php_value, php_flag, php_admin_value, and
> > >php_admin_flag,
> > > > >but nothing for a variable.
> > > >
> > > > Would it be defined in every PHP script that runs?  Does it really
>have to
> > > > be a variable, or can it be a constant?
> > > >
> > > > Zeev
> > > >
> > >
> > >
> > >
> > >--
> > >PHP Development Mailing List <http://www.php.net/>
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
> >
> >


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Re: PHP 5

[James Cox]

actually,

you can also use the getenv function to get them, so you don't have to
reference a variable array.

see http://www.php.net/getenv

(also http://www.php.net/setenv )

James Cox

> -Original Message-
> From: Sander Steffann [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 02, 2002 11:15 PM
> To: Joe Webster; Zeev Suraski
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] Re: PHP 5
>
>
> Hi,
>
> We do exactly the same with Apache SetEnv:
>
> SetEnv  media_regionaamapeldoorn
> SetEnv  media_regioid  27
> SetEnv  media_module   index
>
> And we get them in the PHP script with
> $GLOBALS['HTTP_SERVER_VARS']['media_regionaam'];
>
> Works great for us.
> Sander
>
> - Original Message -
> From: "Zeev Suraski" <[EMAIL PROTECTED]>
> To: "Joe Webster" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Wednesday, January 02, 2002 11:40 PM
> Subject: Re: [PHP-DEV] Re: PHP 5
>
>
> > This could probably be done.  It does sound helpful.
> >
> > Zeev
> >
> > At 00:29 03/01/2002, Joe Webster wrote:
> > >Yes it would have to be in every script in the vhost, location or
> directory
> > >directive.
> > >
> > >It could be a constant =) That would make my life easier.
> > >
> > >Thanks,
> > >-Joe
> > >
> > >"Zeev Suraski" <[EMAIL PROTECTED]> wrote in message
> > >5.1.0.14.2.20020102234728.028651c0@localhost">news:5.1.0.14.2.20020102234728.028651c0@localhost...
> > > > At 23:33 02/01/2002, Joe Webster wrote:
> > > > >I have something that I am currently dealing with:
> > > > >
> > > > > Using mod_perl with apache, you can put this in a apache
> directive
> > > > >(vhost, location, directory):
> > > > > PerlSetVar somevarname somevarval
> > > > > and that would pre-define somevarname equal to somevarval. We
> are
> > >trying
> > > > >to move completely to php (we're 1/2 php and 1/2 perl) however, we
> really
> > > > >need to be able to set the vars like this. I did look through the
> > >mod_php.c
> > > > >and I noticed the php_value, php_flag, php_admin_value, and
> > >php_admin_flag,
> > > > >but nothing for a variable.
> > > >
> > > > Would it be defined in every PHP script that runs?  Does it really
> have to
> > > > be a variable, or can it be a constant?
> > > >
> > > > Zeev
> > > >
> > >
> > >
> > >
> > >--
> > >PHP Development Mailing List <http://www.php.net/>
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >To contact the list administrators, e-mail:
> [EMAIL PROTECTED]
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Joe Webster]

That rocks, pending it works, my problems are solved. It would still be an
awesome feature for PHP, but nice to know apache will work otherwise. IIS
SUCKS!


Thanks again!,
Joe
"Sander Steffann" <[EMAIL PROTECTED]> wrote in message
008d01c193e3$53c14980$[EMAIL PROTECTED]">news:008d01c193e3$53c14980$[EMAIL PROTECTED]...
> Hi,
>
> We do exactly the same with Apache SetEnv:
>
> SetEnv  media_regionaamapeldoorn
> SetEnv  media_regioid  27
> SetEnv  media_module   index
>
> And we get them in the PHP script with
> $GLOBALS['HTTP_SERVER_VARS']['media_regionaam'];
>
> Works great for us.
> Sander
>
> - Original Message -
> From: "Zeev Suraski" <[EMAIL PROTECTED]>
> To: "Joe Webster" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Wednesday, January 02, 2002 11:40 PM
> Subject: Re: [PHP-DEV] Re: PHP 5
>
>
> > This could probably be done.  It does sound helpful.
> >
> > Zeev
> >
> > At 00:29 03/01/2002, Joe Webster wrote:
> > >Yes it would have to be in every script in the vhost, location or
> directory
> > >directive.
> > >
> > >It could be a constant =) That would make my life easier.
> > >
> > >Thanks,
> > >-Joe
> > >
> > >"Zeev Suraski" <[EMAIL PROTECTED]> wrote in message
> > >5.1.0.14.2.20020102234728.028651c0@localhost">news:5.1.0.14.2.20020102234728.028651c0@localhost...
> > > > At 23:33 02/01/2002, Joe Webster wrote:
> > > > >I have something that I am currently dealing with:
> > > > >
> > > > > Using mod_perl with apache, you can put this in a apache
> directive
> > > > >(vhost, location, directory):
> > > > > PerlSetVar somevarname somevarval
> > > > > and that would pre-define somevarname equal to somevarval. We
> are
> > >trying
> > > > >to move completely to php (we're 1/2 php and 1/2 perl) however, we
> really
> > > > >need to be able to set the vars like this. I did look through the
> > >mod_php.c
> > > > >and I noticed the php_value, php_flag, php_admin_value, and
> > >php_admin_flag,
> > > > >but nothing for a variable.
> > > >
> > > > Would it be defined in every PHP script that runs?  Does it really
> have to
> > > > be a variable, or can it be a constant?
> > > >
> > > > Zeev
> > > >
> > >
> > >
> > >
> > >--
> > >PHP Development Mailing List <http://www.php.net/>
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >To contact the list administrators, e-mail:
[EMAIL PROTECTED]
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
>



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Sander Steffann]

Hi,

We do exactly the same with Apache SetEnv:

SetEnv  media_regionaamapeldoorn
SetEnv  media_regioid  27
SetEnv  media_module   index

And we get them in the PHP script with
$GLOBALS['HTTP_SERVER_VARS']['media_regionaam'];

Works great for us.
Sander

- Original Message -
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Joe Webster" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, January 02, 2002 11:40 PM
Subject: Re: [PHP-DEV] Re: PHP 5


> This could probably be done.  It does sound helpful.
>
> Zeev
>
> At 00:29 03/01/2002, Joe Webster wrote:
> >Yes it would have to be in every script in the vhost, location or
directory
> >directive.
> >
> >It could be a constant =) That would make my life easier.
> >
> >Thanks,
> >-Joe
> >
> >"Zeev Suraski" <[EMAIL PROTECTED]> wrote in message
> >5.1.0.14.2.20020102234728.028651c0@localhost">news:5.1.0.14.2.20020102234728.028651c0@localhost...
> > > At 23:33 02/01/2002, Joe Webster wrote:
> > > >I have something that I am currently dealing with:
> > > >
> > > > Using mod_perl with apache, you can put this in a apache
directive
> > > >(vhost, location, directory):
> > > > PerlSetVar somevarname somevarval
> > > > and that would pre-define somevarname equal to somevarval. We
are
> >trying
> > > >to move completely to php (we're 1/2 php and 1/2 perl) however, we
really
> > > >need to be able to set the vars like this. I did look through the
> >mod_php.c
> > > >and I noticed the php_value, php_flag, php_admin_value, and
> >php_admin_flag,
> > > >but nothing for a variable.
> > >
> > > Would it be defined in every PHP script that runs?  Does it really
have to
> > > be a variable, or can it be a constant?
> > >
> > > Zeev
> > >
> >
> >
> >
> >--
> >PHP Development Mailing List <http://www.php.net/>
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>
>



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Joe Webster]

Awesome, that will rock. Now, not to be an impatient lil' dork, but is there
something that I could easily do to my mod_php that would swing it for me?

Thanks for the help,
Joe

"Zeev Suraski" <[EMAIL PROTECTED]> wrote in message
5.1.0.14.2.20020103004035.04527460@localhost">news:5.1.0.14.2.20020103004035.04527460@localhost...
> This could probably be done.  It does sound helpful.
>
> Zeev
>
> At 00:29 03/01/2002, Joe Webster wrote:
> >Yes it would have to be in every script in the vhost, location or
directory
> >directive.
> >
> >It could be a constant =) That would make my life easier.
> >
> >Thanks,
> >-Joe
> >
> >"Zeev Suraski" <[EMAIL PROTECTED]> wrote in message
> >5.1.0.14.2.20020102234728.028651c0@localhost">news:5.1.0.14.2.20020102234728.028651c0@localhost...
> > > At 23:33 02/01/2002, Joe Webster wrote:
> > > >I have something that I am currently dealing with:
> > > >
> > > > Using mod_perl with apache, you can put this in a apache
directive
> > > >(vhost, location, directory):
> > > > PerlSetVar somevarname somevarval
> > > > and that would pre-define somevarname equal to somevarval. We
are
> >trying
> > > >to move completely to php (we're 1/2 php and 1/2 perl) however, we
really
> > > >need to be able to set the vars like this. I did look through the
> >mod_php.c
> > > >and I noticed the php_value, php_flag, php_admin_value, and
> >php_admin_flag,
> > > >but nothing for a variable.
> > >
> > > Would it be defined in every PHP script that runs?  Does it really
have to
> > > be a variable, or can it be a constant?
> > >
> > > Zeev
> > >
> >
> >
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >To contact the list administrators, e-mail: [EMAIL PROTECTED]
>



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Zeev Suraski]

This could probably be done.  It does sound helpful.

Zeev

At 00:29 03/01/2002, Joe Webster wrote:
>Yes it would have to be in every script in the vhost, location or directory
>directive.
>
>It could be a constant =) That would make my life easier.
>
>Thanks,
>-Joe
>
>"Zeev Suraski" <[EMAIL PROTECTED]> wrote in message
>5.1.0.14.2.20020102234728.028651c0@localhost">news:5.1.0.14.2.20020102234728.028651c0@localhost...
> > At 23:33 02/01/2002, Joe Webster wrote:
> > >I have something that I am currently dealing with:
> > >
> > > Using mod_perl with apache, you can put this in a apache directive
> > >(vhost, location, directory):
> > > PerlSetVar somevarname somevarval
> > > and that would pre-define somevarname equal to somevarval. We are
>trying
> > >to move completely to php (we're 1/2 php and 1/2 perl) however, we really
> > >need to be able to set the vars like this. I did look through the
>mod_php.c
> > >and I noticed the php_value, php_flag, php_admin_value, and
>php_admin_flag,
> > >but nothing for a variable.
> >
> > Would it be defined in every PHP script that runs?  Does it really have to
> > be a variable, or can it be a constant?
> >
> > Zeev
> >
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Joe Webster]

Yes it would have to be in every script in the vhost, location or directory
directive.

It could be a constant =) That would make my life easier.

Thanks,
-Joe

"Zeev Suraski" <[EMAIL PROTECTED]> wrote in message
5.1.0.14.2.20020102234728.028651c0@localhost">news:5.1.0.14.2.20020102234728.028651c0@localhost...
> At 23:33 02/01/2002, Joe Webster wrote:
> >I have something that I am currently dealing with:
> >
> > Using mod_perl with apache, you can put this in a apache directive
> >(vhost, location, directory):
> > PerlSetVar somevarname somevarval
> > and that would pre-define somevarname equal to somevarval. We are
trying
> >to move completely to php (we're 1/2 php and 1/2 perl) however, we really
> >need to be able to set the vars like this. I did look through the
mod_php.c
> >and I noticed the php_value, php_flag, php_admin_value, and
php_admin_flag,
> >but nothing for a variable.
>
> Would it be defined in every PHP script that runs?  Does it really have to
> be a variable, or can it be a constant?
>
> Zeev
>



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Joe Webster]

That is our fall-back plan, but that's not terribly effecient =)
"Joao Prado Maia" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...

On Wed, 2 Jan 2002, Joe Webster wrote:

> I have something that I am currently dealing with:
>
> Using mod_perl with apache, you can put this in a apache directive
> (vhost, location, directory):
> PerlSetVar somevarname somevarval
> and that would pre-define somevarname equal to somevarval. We are
trying
> to move completely to php (we're 1/2 php and 1/2 perl) however, we really
> need to be able to set the vars like this. I did look through the
mod_php.c
> and I noticed the php_value, php_flag, php_admin_value, and
php_admin_flag,
> but nothing for a variable.
>

I know it is not the same as having it on the httpd.conf (.htaccess too?)
but you can set a 'auto-prepend' PHP script, which could be used to define
any constant or variable. Is this not an option for you guys ?

Cheers,
Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br




-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Joe Webster]

Example:

We have 200+ radio station websites in a network. The way we store data
in the database is by call letters (since some websites have more than one
domain). So call letters (whor-fm :) ) are the key to just about everything
we do. So, in the vhost file for apache we want to set the station call
letters so that the letters are available to the code.

Thanks for the interest,
-Joe
<[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> On Wed, 2 Jan 2002, Joe Webster wrote:
>
> > I have something that I am currently dealing with:
> >
> > Using mod_perl with apache, you can put this in a apache directive
> > (vhost, location, directory):
> > PerlSetVar somevarname somevarval
> > and that would pre-define somevarname equal to somevarval. We are
trying
> > to move completely to php (we're 1/2 php and 1/2 perl) however, we
really
> > need to be able to set the vars like this. I did look through the
mod_php.c
> > and I noticed the php_value, php_flag, php_admin_value, and
php_admin_flag,
> > but nothing for a variable.
>
> Could you give some example of why this would be that useful? (Just
> wondering in which way you use this).
>
> Derick
>



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Joao Prado Maia]

On Wed, 2 Jan 2002, Joe Webster wrote:

> I have something that I am currently dealing with:
>
> Using mod_perl with apache, you can put this in a apache directive
> (vhost, location, directory):
> PerlSetVar somevarname somevarval
> and that would pre-define somevarname equal to somevarval. We are trying
> to move completely to php (we're 1/2 php and 1/2 perl) however, we really
> need to be able to set the vars like this. I did look through the mod_php.c
> and I noticed the php_value, php_flag, php_admin_value, and php_admin_flag,
> but nothing for a variable.
>

I know it is not the same as having it on the httpd.conf (.htaccess too?)
but you can set a 'auto-prepend' PHP script, which could be used to define
any constant or variable. Is this not an option for you guys ?

Cheers,
Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[derick]

On Wed, 2 Jan 2002, Joe Webster wrote:

> I have something that I am currently dealing with:
>
> Using mod_perl with apache, you can put this in a apache directive
> (vhost, location, directory):
> PerlSetVar somevarname somevarval
> and that would pre-define somevarname equal to somevarval. We are trying
> to move completely to php (we're 1/2 php and 1/2 perl) however, we really
> need to be able to set the vars like this. I did look through the mod_php.c
> and I noticed the php_value, php_flag, php_admin_value, and php_admin_flag,
> but nothing for a variable.

Could you give some example of why this would be that useful? (Just
wondering in which way you use this).

Derick


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Zeev Suraski]

At 23:33 02/01/2002, Joe Webster wrote:
>I have something that I am currently dealing with:
>
> Using mod_perl with apache, you can put this in a apache directive
>(vhost, location, directory):
> PerlSetVar somevarname somevarval
> and that would pre-define somevarname equal to somevarval. We are trying
>to move completely to php (we're 1/2 php and 1/2 perl) however, we really
>need to be able to set the vars like this. I did look through the mod_php.c
>and I noticed the php_value, php_flag, php_admin_value, and php_admin_flag,
>but nothing for a variable.

Would it be defined in every PHP script that runs?  Does it really have to 
be a variable, or can it be a constant?

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: PHP 5

[Joe Webster]

I have something that I am currently dealing with:

Using mod_perl with apache, you can put this in a apache directive
(vhost, location, directory):
PerlSetVar somevarname somevarval
and that would pre-define somevarname equal to somevarval. We are trying
to move completely to php (we're 1/2 php and 1/2 perl) however, we really
need to be able to set the vars like this. I did look through the mod_php.c
and I noticed the php_value, php_flag, php_admin_value, and php_admin_flag,
but nothing for a variable.

-Joe

"Andi Gutmans" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Hey,
>
> The Zend Engine 2 has made lots of progress.
> I think we should have a discussion of what other things besides the
> scripting engine we'd like to change for PHP 5.
> I know there was talk on deprecating some stuff such as old-style function
> names, moving extensions to PECL etc.. I think it's a good time to start
> discussing some of these issues (hopefully we can keep things short :)
> Also, let's try and keep the scope to realistic changes which won't turn
> PHP upside down and which are doable within a relatively short period of
> time. I think it'd be really cool if we could get an alpha of PHP 5 out by
> Spring.
>
> Unrelated, I'm still waiting to hear exactly what mechanism the PEAR guys
> implemented for PECL. I know that if it's not a really cool easy to use
> mechanism I would prefer to wait until we write one. One of the main
> strengths of PHP is that everything is bundled together and is easy to
> setup. We shouldn't make it much harder on people. Although we're planning
> on only move the unimportant extensions out of PHP I still think it should
> be extremely easy to get a list of available extensions (maybe even a part
> of the ./configure process) and to easily download/configure/install them.
>
> Andi
>



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Re: PHP 5

[Lukas Smith]

> From: Joao Prado Maia [mailto:[EMAIL PROTECTED]]
> Why not separate everything and then bundle the more popular ones to
the
> normal PHP distribution on the time of a release ? I would love to be
able
> to upgrade just the 'GD' extension if there was a bug on the extension
on
> release PHP4.1.12 and it was fixed on PECL version of the extension
> 2.1.23.

this sounds like the best idea to me
release everything separately and make a current snapshot for a new php
release of the most popular extensions

Best regards,
Lukas Smith
[EMAIL PROTECTED]
___
 DybNet Internet Solutions GbR
 Alt Moabit 89
 10559 Berlin
 Germany
 Tel. : +49 30 83 22 50 00
 Fax : +49 30 83 22 50 07
 www.dybnet.de [EMAIL PROTECTED]
___

> -Original Message-
> Sent: Wednesday, January 02, 2002 5:09 PM
> To: Zeev Suraski
> Cc: Björn Schotte; [EMAIL PROTECTED]; Adam Dickmeiss; Jim Winstead; php-
> [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] Re: PHP 5
> 
> 
> On Wed, 2 Jan 2002, Zeev Suraski wrote:
> 
> > At 16:06 02/01/2002, Björn Schotte wrote:
> > >* Zeev Suraski wrote:
> > > > Well, I think that the main motivation for separating the
modules
> away was
> > > > the release schedule.  I.e., separating the release schedule of
each
> > > > extension from the release schedule of the PHP core itself.
> > >
> > >Jep. Just to note: I'm +1 for it.
> >
> >
> 
> Why not separate everything and then bundle the more popular ones to
the
> normal PHP distribution on the time of a release ? I would love to be
able
> to upgrade just the 'GD' extension if there was a bug on the extension
on
> release PHP4.1.12 and it was fixed on PECL version of the extension
> 2.1.23.
> 
> I would also love to be able to tell the users of my application to
just
> use the PEAR installer to download and install the bugfix release of
the
> GD extension instead of telling them to not use a particular buggy /
not
> compatible version of PHP.
> 
> I can understand that it will mean more work to you guys to handle
> several release independent extensions, but if you can just use the
PEAR
> installer to download the stuff from the repository, you will be able
to
> download the stable releases from PEAR and then build the general PHP
> distribution.
> 
> Joao
> 
> --
> João Prado Maia <[EMAIL PROTECTED]>
> http://phpbrasil.com - php com um jeitinho brasileiro
> --
> Precisando de consultoria em desenvolvimento para a Internet ?
> Impleo.net - http://impleo.net/?lang=br
> 
> 
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail:
[EMAIL PROTECTED]



--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Joao Prado Maia]

On Wed, 2 Jan 2002, Zeev Suraski wrote:

> At 16:06 02/01/2002, Björn Schotte wrote:
> >* Zeev Suraski wrote:
> > > Well, I think that the main motivation for separating the modules away was
> > > the release schedule.  I.e., separating the release schedule of each
> > > extension from the release schedule of the PHP core itself.
> >
> >Jep. Just to note: I'm +1 for it.
>
> I'm +1 for separating the less popular ones, but I'm -1 for separating
> everything (look up the archives as to why...)
>

Why not separate everything and then bundle the more popular ones to the
normal PHP distribution on the time of a release ? I would love to be able
to upgrade just the 'GD' extension if there was a bug on the extension on
release PHP4.1.12 and it was fixed on PECL version of the extension
2.1.23.

I would also love to be able to tell the users of my application to just
use the PEAR installer to download and install the bugfix release of the
GD extension instead of telling them to not use a particular buggy / not
compatible version of PHP.

I can understand that it will mean more work to you guys to handle
several release independent extensions, but if you can just use the PEAR
installer to download the stuff from the repository, you will be able to
download the stable releases from PEAR and then build the general PHP
distribution.

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Zeev Suraski]

At 16:06 02/01/2002, Björn Schotte wrote:
>* Zeev Suraski wrote:
> > Well, I think that the main motivation for separating the modules away was
> > the release schedule.  I.e., separating the release schedule of each
> > extension from the release schedule of the PHP core itself.
>
>Jep. Just to note: I'm +1 for it.

I'm +1 for separating the less popular ones, but I'm -1 for separating 
everything (look up the archives as to why...)

> >  If we still
> > have a full version and a bare-bones version side by side, I'm not sure 
> how
> > much that buys you, in comparison with what we have today...
>
>It buys me nothing because I would prefer the PECL way.

I wasn't talking about you personally, but the PHP project in general 
:)  If we still have to tie up releases to a stable snapshot of all of the 
extensions, then it won't help the release schedule too much.  It may make 
it easier

>I just wanted to say that it could be useful for Sysadmins
>who don't want to download each PECL extension with the
>PEAR/PECL-installer. (like ApacheToolbox)

It'll probably be easier for most people who don't really care too much 
about the version of each individual extension (which, from my experience 
anyway, accounts for most of the users).

Zeev


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Björn Schotte]

* Zeev Suraski wrote:
> Well, I think that the main motivation for separating the modules away was 
> the release schedule.  I.e., separating the release schedule of each 
> extension from the release schedule of the PHP core itself.

Jep. Just to note: I'm +1 for it.

>  If we still 
> have a full version and a bare-bones version side by side, I'm not sure how 
> much that buys you, in comparison with what we have today...

It buys me nothing because I would prefer the PECL way.

I just wanted to say that it could be useful for Sysadmins
who don't want to download each PECL extension with the
PEAR/PECL-installer. (like ApacheToolbox)

-- 
Sichere PHP Applikationen / Notfall-Consulting mit der
PHP Feuerwehr / Code inspection / Code rehearsal / API
Checkup.   mailto:[EMAIL PROTECTED]

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Zeev Suraski]

At 14:01 02/01/2002, Björn Schotte wrote:
>* Zeev Suraski wrote:
> > >Yep. But what about a php_4_3_4_core.tgz (core PHP/ZE/TSRM with
> > >core extensions) and a release of php_4_3_4_complete.tgz packaged
> > >with all extensions together?
> > That can happen, but what does that buy you?
>
>I can err myself, but it's some sort of BC for me in
>the configuration/installation process.

Well, I think that the main motivation for separating the modules away was 
the release schedule.  I.e., separating the release schedule of each 
extension from the release schedule of the PHP core itself.  If we still 
have a full version and a bare-bones version side by side, I'm not sure how 
much that buys you, in comparison with what we have today...

Zeev


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Björn Schotte]

* Zeev Suraski wrote:
> >Yep. But what about a php_4_3_4_core.tgz (core PHP/ZE/TSRM with
> >core extensions) and a release of php_4_3_4_complete.tgz packaged
> >with all extensions together?
> That can happen, but what does that buy you?

I can err myself, but it's some sort of BC for me in
the configuration/installation process.

-- 
Sichere PHP Applikationen / Notfall-Consulting mit der
PHP Feuerwehr / Code inspection / Code rehearsal / API
Checkup.   mailto:[EMAIL PROTECTED]

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Zeev Suraski]

At 13:41 02/01/2002, Björn Schotte wrote:
>* [EMAIL PROTECTED] wrote:
> > and remain that way. It's much easier to distribute (one download), and
> > easier to install. (No more fetching of PECL extensions).
>
>Yep. But what about a php_4_3_4_core.tgz (core PHP/ZE/TSRM with
>core extensions) and a release of php_4_3_4_complete.tgz packaged
>with all extensions together?

That can happen, but what does that buy you?

Zeev


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Björn Schotte]

* [EMAIL PROTECTED] wrote:
> and remain that way. It's much easier to distribute (one download), and
> easier to install. (No more fetching of PECL extensions).

Yep. But what about a php_4_3_4_core.tgz (core PHP/ZE/TSRM with
core extensions) and a release of php_4_3_4_complete.tgz packaged
with all extensions together?

-- 
Sichere PHP Applikationen / Notfall-Consulting mit der
PHP Feuerwehr / Code inspection / Code rehearsal / API
Checkup.   mailto:[EMAIL PROTECTED]

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[derick]

On Wed, 2 Jan 2002, Adam Dickmeiss wrote:

> IMHO, all extensions should be PECL. If it's easier to have some
> extensions part of core PHP 'cause they're important, then it's a
> sign of bad PECL design. PHP should be the glue for SAPI,
> extensions (PECL, I hope) and Zend. No more.

I do not agree with this. Important extensions should be part of the core,
and remain that way. It's much easier to distribute (one download), and
easier to install. (No more fetching of PECL extensions).

Derick


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Adam Dickmeiss]

On Tue, Jan 01, 2002 at 05:56:53PM -, Jim Winstead wrote:
> Andi Gutmans <[EMAIL PROTECTED]> wrote:
> > The Zend Engine 2 has made lots of progress.
> 
> is there an up-to-date summary of the changes beyond the original ze2
> proposal? example scripts that show the new features?
> 
> > Unrelated, I'm still waiting to hear exactly what mechanism the PEAR guys 
> > implemented for PECL. I know that if it's not a really cool easy to use 
> > mechanism I would prefer to wait until we write one. One of the main 
> > strengths of PHP is that everything is bundled together and is easy to 
> > setup. We shouldn't make it much harder on people. Although we're planning 
> > on only move the unimportant extensions out of PHP I still think it should 
> > be extremely easy to get a list of available extensions (maybe even a part 
> > of the ./configure process) and to easily download/configure/install them.
> 
> having everything bundled is a strength for people who install from
> source, but it really doesn't do much to help people who haved installed
> from a distribution or are in a shared-hosting situation. those are the
> places where something like perl's cpan really shines (and where the
> pear/pecl stuff presumably will too).

I think a lot of people are installing from source, so it's very
important that's easy to do so. Distributios are outdated and as
long as you wan't "just" one new feature of the extensions you're
bound to install from source anyway.

> i'd really love to see the existing pear/pecl stuff brought out into the
> open more, even if it is not fully baked. i think the fact that it is
> relatively hidden makes it extremely difficult for people to know where
> things are headed, how close (or far) they are, and how to help.

The main benefit of the PECL is the independent release-cycle. It'll
force less people to install PHP from source when they need stuff from
a newly updated extension.

> (and 'unimportant' is a dangerous word. obviously that depends on the
> situation.)

IMHO, all extensions should be PECL. If it's easier to have some
extensions part of core PHP 'cause they're important, then it's a
sign of bad PECL design. PHP should be the glue for SAPI,
extensions (PECL, I hope) and Zend. No more.

-- Adam

> 
> jim
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]

-- 
Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
Index Data  T: +45 33410100   Mob.: 212 212 66

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Peter Petermann]

Hi,

> having everything bundled is a strength for people who install from
> source, but it really doesn't do much to help people who haved installed
> from a distribution or are in a shared-hosting situation. those are the
well, i dont agree with that.
think about people that are not hosting themself..
its great to have all that stuff included in PHP,
its easiert to tell your provider "hey could you enable this feature"
instead of
"hey.. would you intall..."

just my 2 cents
--
Peter "[DiSAStA]" Petermann



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Andi Gutmans]

At 05:56 PM 1/1/2002 +, Jim Winstead wrote:
>(and 'unimportant' is a dangerous word. obviously that depends on the
>situation.)

I think it's obvious what I meant.

Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: PHP 5

[Sebastian Bergmann]

Jim Winstead wrote:
> is there an up-to-date summary of the changes beyond the original ze2
> proposal? example scripts that show the new features?

  ZendEngine2/ZEND_CHANGES for starters.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: PHP 5

[Jim Winstead]

Andi Gutmans <[EMAIL PROTECTED]> wrote:
> The Zend Engine 2 has made lots of progress.

is there an up-to-date summary of the changes beyond the original ze2
proposal? example scripts that show the new features?

> Unrelated, I'm still waiting to hear exactly what mechanism the PEAR guys 
> implemented for PECL. I know that if it's not a really cool easy to use 
> mechanism I would prefer to wait until we write one. One of the main 
> strengths of PHP is that everything is bundled together and is easy to 
> setup. We shouldn't make it much harder on people. Although we're planning 
> on only move the unimportant extensions out of PHP I still think it should 
> be extremely easy to get a list of available extensions (maybe even a part 
> of the ./configure process) and to easily download/configure/install them.

having everything bundled is a strength for people who install from
source, but it really doesn't do much to help people who haved installed
from a distribution or are in a shared-hosting situation. those are the
places where something like perl's cpan really shines (and where the
pear/pecl stuff presumably will too).

i'd really love to see the existing pear/pecl stuff brought out into the
open more, even if it is not fully baked. i think the fact that it is
relatively hidden makes it extremely difficult for people to know where
things are headed, how close (or far) they are, and how to help.

(and 'unimportant' is a dangerous word. obviously that depends on the
situation.)

jim

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]