Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Rui Hirokawa]

> > iconv P
> 
> The iconv library in itself is useful enough that we should try to
> keep this one within PHP, maybe even integrate it tighter.

I hope so too.
iconv has some important role espetially for handling multibyte 
encoding.
I am also preparing a extension module called jstring for handing 
janapese multibyte string.
This module includes some encoding translation functionality
between Unicode and some other encodings.
It will be also elementary tool for japanese PHP users.
I want to keep tight integration between PHP and encoding
translation functions because of performance and useability.


-- 
--
Rui Hirokawa <[EMAIL PROTECTED]>
maintainer of japanese PHP manual <[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-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Stig Sæther Bakken]

[Andi Gutmans <[EMAIL PROTECTED]>]
> At 08:13 AM 4/19/2001 -0400, Stig Sæther Bakken wrote:
> >
> >To be quite blunt, I don't have the time to implement this in C.
> >
> >I've tried to get people involved in the strategy for PEAR for months
> >and months.  It's typical that nobody reacts until after
> >implementation has started though.  I want to get this system up and
> >running sooner rather than later, so I'm willing to make something
> >that we throw away and reimplement rather than to not have something
> >for one more year.
> 
> I think you are right.
> BTW, how are you planning on making it as transparent as possible for
> a user who downloads PHP and wants to compile it with PEAR
> C-extensions such as XML, MySQL & Oracle (these are just examples, it
> doesn't reflect my opinion if these should stay in or out of the php
> tree itself)?

Well, if all the extensions that are moved out are moved to a similar
structure in the pear CVS module: php4/ext/hyperwave ->
pear/ext/hyperwave, it should only be a matter of copying some files
and running autoconf before configure.  For this we'd need a shell
script, C program or similar though.  I'm in favor of a shell script,
maybe with some C helpers if it turns out to be a problem finding
lynx, wget or something similar on people's systems.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Jason Greene]

> I still think that a large majority of people will want to grab the 
> C-extensions and compile them statically into PHP, i.e. putting them in 
> ext/, ./buildconf, ./configure ...
> 
> Andi

I agree. There is also the possibility that some extensions will have problems as a .so
on some archetectures.

-Jason


-- 
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-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 09:05 AM 4/19/2001 +0300, Alexander Bokovoy wrote:
>On Thu, Apr 19, 2001 at 07:21:32AM +0200, Andi Gutmans wrote:
> > At 09:16 PM 4/18/2001 -0700, Rasmus Lerdorf wrote:
> > > > >When we're past the prototyping phase and stuff stabilizes, a C
> > > > >rewrite may be a good idea, but I don't think it is now.
> > > >
> > > > Well you know the most permanent things are temporary things such as
> > > > prototypes.
> > > > I also thought it would make much more sense to create something 
> very small
> > > > in C (maybe even Perl as it's installed on all systems) and use that.
> > > > I'm not really sure anymore what this installer you are talking 
> about looks
> > > > like. So I think it would be good to get a small update and have a
> > > > discussion of what we need on php-dev@.
> > >
> > >I see no issue with writing a prototype in PHP.  The start of such a
> > >prototype is in cvs (pear/script/pear)
> > >
> > >And yes, using XML is pretty much a no-brainer here.  That will allow a
> > >lot of different nifty tools to access the package information.
> >
> > For a start you don't have PHP installed on most systems. So PHP would 
> need
> > to compile itself and then fetch packages and recompile itself. Seems 
> to me
> > like the no-brainer isn't such a no-brainer.
>Seems that you're forgetting main point of PEAR: you don't need to
>recompile PHP itself when adding some module via PEAR because more
>suitable method exists -- self contained extensions -- which works via
>PEAR right now. Of course, there is small number of extensions from /ext
>which could be compiled in this mode out-of-the-box right now (mostly
>because building environment in PEAR still unreliable), but it exists.

I still think that a large majority of people will want to grab the 
C-extensions and compile them statically into PHP, i.e. putting them in 
ext/, ./buildconf, ./configure ...

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-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 08:13 AM 4/19/2001 -0400, Stig Sæther Bakken wrote:
>[Andi Gutmans <[EMAIL PROTECTED]>]
> >
> > Right but if we chose XML this makes it much harder to have C clients
> > (even Perl because the module might not be installed). I don't think
> 
>
>Over my dead body.  Take a look at all the magazines reviewing which
>web development tools to use.  Most of them end up with PHP because it
>fits their job.  Imagine all the fun authors of such articles can have
>it PHP requires Perl to install the stuff you need.
>
> > it will be such a complicated format for us to need XML here
> > especially as it limits what clients will be created. I think it needs
> > more thought. Having a prototype for the functionality is OK but not
> > if you're talking about a prototype which sets the standard.
>
>XML is a commodity today.  Just take a look at what the industry out
>there is using.
>
> > >If we were to write it in C we would most likely need to provide a
> > >statically linked binary anyway for the different platforms as not
> > >everyone will have access to a fully functioning development environment.
> >
> > If they are compiling PHP and PHP extensions we can expect them to be
> > able to compile an ANSI C program.
> >
> >
> > >Despite the pervasiveness of Perl, chances are high that certain Perl
> > >modules would be missing and then someone has to go looking for Perl
> > >modules to install PHP packages..  Ouch!
> >
> > You can do this kind of stuff with the Vanilla Perl and don't need
> > extensions.
>
>To be quite blunt, I don't have the time to implement this in C.
>
>I've tried to get people involved in the strategy for PEAR for months
>and months.  It's typical that nobody reacts until after
>implementation has started though.  I want to get this system up and
>running sooner rather than later, so I'm willing to make something
>that we throw away and reimplement rather than to not have something
>for one more year.

I think you are right.
BTW, how are you planning on making it as transparent as possible for a 
user who downloads PHP and wants to compile it with PEAR C-extensions such 
as XML, MySQL & Oracle (these are just examples, it doesn't reflect my 
opinion if these should stay in or out of the php tree itself)?

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-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 08:03 AM 4/19/2001 -0400, Stig Sæther Bakken wrote:
>[Andi Gutmans <[EMAIL PROTECTED]>]
> > At 06:53 PM 4/18/2001 -0400, Stig Sæther Bakken wrote:
> >
> > >*BLAM*
> > >
> > >That's the sound of someone shooting himself in the foot.  The PEAR
> > >installer needs the XML extension. :-)
> >
> > What do you mean? Has work started on this already?
> > I'm not quite sure what you mean by the PEAR installer but I think we
> > should discuss the util we would need to list/fetch/build C extensions
> > from the PEAR repository on php-dev@.
> > I think it's a waste of time to decide right now what to remove
> > instead of trying to finalizing this utility. Once we see how well it
> > works it'll be time to start thinking of what extensions to remove. I
> > think it's just putting energy in the wrong place right now :)
>
>You don't read php-cvs anymore do you Andi? :-)

I do but I'm senile :)


>If you configure the CGI and do "make install", you'll have a
>command-line utility written in PHP called "pear" that can do two
>things: make a package tarball, and install a tarball.  It currently
>only support "pure PHP" packages.  How to test it:
>
>$ cvs co pear/HTTP
>$ cd pear/HTTP
>$ pear package package.xml
>(this will give you a file called HTTP-1.0.tgz)
>$ pear install HTTP-1.0.tgz

OK I definitely missed that one.

>There's a lot of stuff missing from the installer still, but that'll
>be added in time.  It is also UNIX-only right now.  Since I'm not a
>Windows user myself, I totally depend on the help of some Windows
>people to make it work in Windows.
>
>The reason I joined the "what extensions to keep" discussion is that I
>think it (the discussion) is going to take some time. :-)

Yeah but I just thought it'd be better to focus people's energy on getting 
it to work :)

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-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Stig Sæther Bakken]

[Andi Gutmans <[EMAIL PROTECTED]>]
> 
> Right but if we chose XML this makes it much harder to have C clients
> (even Perl because the module might not be installed). I don't think


Over my dead body.  Take a look at all the magazines reviewing which
web development tools to use.  Most of them end up with PHP because it
fits their job.  Imagine all the fun authors of such articles can have
it PHP requires Perl to install the stuff you need.

> it will be such a complicated format for us to need XML here
> especially as it limits what clients will be created. I think it needs
> more thought. Having a prototype for the functionality is OK but not
> if you're talking about a prototype which sets the standard.

XML is a commodity today.  Just take a look at what the industry out
there is using.

> >If we were to write it in C we would most likely need to provide a
> >statically linked binary anyway for the different platforms as not
> >everyone will have access to a fully functioning development environment.
> 
> If they are compiling PHP and PHP extensions we can expect them to be
> able to compile an ANSI C program.
> 
> 
> >Despite the pervasiveness of Perl, chances are high that certain Perl
> >modules would be missing and then someone has to go looking for Perl
> >modules to install PHP packages..  Ouch!
> 
> You can do this kind of stuff with the Vanilla Perl and don't need
> extensions.

To be quite blunt, I don't have the time to implement this in C.

I've tried to get people involved in the strategy for PEAR for months
and months.  It's typical that nobody reacts until after
implementation has started though.  I want to get this system up and
running sooner rather than later, so I'm willing to make something
that we throw away and reimplement rather than to not have something
for one more year.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Stig Sæther Bakken]

[Andi Gutmans <[EMAIL PROTECTED]>]
> At 06:53 PM 4/18/2001 -0400, Stig Sæther Bakken wrote:
> 
> >*BLAM*
> >
> >That's the sound of someone shooting himself in the foot.  The PEAR
> >installer needs the XML extension. :-)
> 
> What do you mean? Has work started on this already?
> I'm not quite sure what you mean by the PEAR installer but I think we
> should discuss the util we would need to list/fetch/build C extensions
> from the PEAR repository on php-dev@.
> I think it's a waste of time to decide right now what to remove
> instead of trying to finalizing this utility. Once we see how well it
> works it'll be time to start thinking of what extensions to remove. I
> think it's just putting energy in the wrong place right now :)

You don't read php-cvs anymore do you Andi? :-)

If you configure the CGI and do "make install", you'll have a
command-line utility written in PHP called "pear" that can do two
things: make a package tarball, and install a tarball.  It currently
only support "pure PHP" packages.  How to test it:

$ cvs co pear/HTTP
$ cd pear/HTTP
$ pear package package.xml
(this will give you a file called HTTP-1.0.tgz)
$ pear install HTTP-1.0.tgz

There's a lot of stuff missing from the installer still, but that'll
be added in time.  It is also UNIX-only right now.  Since I'm not a
Windows user myself, I totally depend on the help of some Windows
people to make it work in Windows.

The reason I joined the "what extensions to keep" discussion is that I
think it (the discussion) is going to take some time. :-)

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4/ TODO-4.1.txt

[Derick Rethans]

On Thu, 19 Apr 2001, Andi Gutmans wrote:

> Well you know the most permanent things are temporary things such as
> prototypes.
> I also thought it would make much more sense to create something very small
> in C (maybe even Perl as it's installed on all systems) and use that.

PERL isn't installed in all systems, especialy on Windows systems it
isn't.

> I'm not really sure anymore what this installer you are talking about looks
> like. So I think it would be good to get a small update and have a
> discussion of what we need on php-dev@.

regards,

Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-
JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED]
 Boulevard Heuvelink 102 - 6828 KT Arnhem - The Netherlands
-


-- 
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-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Alexander Bokovoy]

On Thu, Apr 19, 2001 at 07:21:32AM +0200, Andi Gutmans wrote:
> At 09:16 PM 4/18/2001 -0700, Rasmus Lerdorf wrote:
> > > >When we're past the prototyping phase and stuff stabilizes, a C
> > > >rewrite may be a good idea, but I don't think it is now.
> > >
> > > Well you know the most permanent things are temporary things such as
> > > prototypes.
> > > I also thought it would make much more sense to create something very small
> > > in C (maybe even Perl as it's installed on all systems) and use that.
> > > I'm not really sure anymore what this installer you are talking about looks
> > > like. So I think it would be good to get a small update and have a
> > > discussion of what we need on php-dev@.
> >
> >I see no issue with writing a prototype in PHP.  The start of such a
> >prototype is in cvs (pear/script/pear)
> >
> >And yes, using XML is pretty much a no-brainer here.  That will allow a
> >lot of different nifty tools to access the package information.
> 
> For a start you don't have PHP installed on most systems. So PHP would need 
> to compile itself and then fetch packages and recompile itself. Seems to me 
> like the no-brainer isn't such a no-brainer.
Seems that you're forgetting main point of PEAR: you don't need to
recompile PHP itself when adding some module via PEAR because more
suitable method exists -- self contained extensions -- which works via
PEAR right now. Of course, there is small number of extensions from /ext
which could be compiled in this mode out-of-the-box right now (mostly
because building environment in PEAR still unreliable), but it exists.
-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project| ALT  Linux  Team | Minsk Linux Users Group
 www.midgard-project.org | www.altlinux.ru  |www.minsk-lug.net 
-- You won't skid if you stay in a rut.
-- Frank Hubbard

-- 
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-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4/ TODO-4.1.txt

[Rasmus Lerdorf]

> >If we were to write it in C we would most likely need to provide a
> >statically linked binary anyway for the different platforms as not
> >everyone will have access to a fully functioning development environment.
>
> If they are compiling PHP and PHP extensions we can expect them to be able
> to compile an ANSI C program.

Which means they can also compile a simple PHP instance since we bundle
xml.

> >Despite the pervasiveness of Perl, chances are high that certain Perl
> >modules would be missing and then someone has to go looking for Perl
> >modules to install PHP packages..  Ouch!
>
> You can do this kind of stuff with the Vanilla Perl and don't need extensions.

Doing this sort of thing non-XML doesn't make much sense to me.  It
severely limits the flexibility.  I suppose we could have a stripped down
simple format and also an XML source to keep it really simple and help
bootstrap people.

To start from absolute scratch I can see grabbing a shell script
initially.  lynx -source http://pear.php.net/go | sh
Or simply download the script and run it if the system doesn't have lynx.

This shell script would then determine which OS it is on and figure out
how to procede.  If it sees a PHP binary with XML support, it can use
that.  If it doesn't, it can grab a simple one for that platform.  Or it
kick into Perl if the Perl setup has XML support.  We could also make the
XML simple enough and bundle a little parser in either Perl or PHP that
was smart enough to parse it.  That way we wouldn't depend on external XML
support.

I just think it is a mistake to come up with some proprietary package
description format here.  The packages themselves can just be compressed
tarballs, but the information about each package should be accessible via
XML somehow.  That virtually guarantees a slew of frontend clients almost
instantly as everyone knows how to handle XML data sources these days.

-Rasmus



-- 
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-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 09:24 PM 4/18/2001 -0700, Rasmus Lerdorf wrote:
> > At 09:16 PM 4/18/2001 -0700, Rasmus Lerdorf wrote:
> > > > >When we're past the prototyping phase and stuff stabilizes, a C
> > > > >rewrite may be a good idea, but I don't think it is now.
> > > >
> > > > Well you know the most permanent things are temporary things such as
> > > > prototypes.
> > > > I also thought it would make much more sense to create something 
> very small
> > > > in C (maybe even Perl as it's installed on all systems) and use that.
> > > > I'm not really sure anymore what this installer you are talking 
> about looks
> > > > like. So I think it would be good to get a small update and have a
> > > > discussion of what we need on php-dev@.
> > >
> > >I see no issue with writing a prototype in PHP.  The start of such a
> > >prototype is in cvs (pear/script/pear)
> > >
> > >And yes, using XML is pretty much a no-brainer here.  That will allow a
> > >lot of different nifty tools to access the package information.
> >
> > For a start you don't have PHP installed on most systems. So PHP would need
> > to compile itself and then fetch packages and recompile itself. Seems to me
> > like the no-brainer isn't such a no-brainer.
>
>We need to somehow work out the functionality.  Once it is well-defined
>other clients will come, I am sure.  We can always provide a small
>statically linked installer program which includes a stripped down PHP
>binary and the appropriate Installer class.

Right but if we chose XML this makes it much harder to have C clients (even 
Perl because the module might not be installed). I don't think it will be 
such a complicated format for us to need XML here especially as it limits 
what clients will be created. I think it needs more thought. Having a 
prototype for the functionality is OK but not if you're talking about a 
prototype which sets the standard.


>If we were to write it in C we would most likely need to provide a
>statically linked binary anyway for the different platforms as not
>everyone will have access to a fully functioning development environment.

If they are compiling PHP and PHP extensions we can expect them to be able 
to compile an ANSI C program.


>Despite the pervasiveness of Perl, chances are high that certain Perl
>modules would be missing and then someone has to go looking for Perl
>modules to install PHP packages..  Ouch!

You can do this kind of stuff with the Vanilla Perl and don't need extensions.

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-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4/ TODO-4.1.txt

[Rasmus Lerdorf]

> At 09:16 PM 4/18/2001 -0700, Rasmus Lerdorf wrote:
> > > >When we're past the prototyping phase and stuff stabilizes, a C
> > > >rewrite may be a good idea, but I don't think it is now.
> > >
> > > Well you know the most permanent things are temporary things such as
> > > prototypes.
> > > I also thought it would make much more sense to create something very small
> > > in C (maybe even Perl as it's installed on all systems) and use that.
> > > I'm not really sure anymore what this installer you are talking about looks
> > > like. So I think it would be good to get a small update and have a
> > > discussion of what we need on php-dev@.
> >
> >I see no issue with writing a prototype in PHP.  The start of such a
> >prototype is in cvs (pear/script/pear)
> >
> >And yes, using XML is pretty much a no-brainer here.  That will allow a
> >lot of different nifty tools to access the package information.
>
> For a start you don't have PHP installed on most systems. So PHP would need
> to compile itself and then fetch packages and recompile itself. Seems to me
> like the no-brainer isn't such a no-brainer.

We need to somehow work out the functionality.  Once it is well-defined
other clients will come, I am sure.  We can always provide a small
statically linked installer program which includes a stripped down PHP
binary and the appropriate Installer class.

If we were to write it in C we would most likely need to provide a
statically linked binary anyway for the different platforms as not
everyone will have access to a fully functioning development environment.

Despite the pervasiveness of Perl, chances are high that certain Perl
modules would be missing and then someone has to go looking for Perl
modules to install PHP packages..  Ouch!

-Rasmus


-- 
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-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 09:16 PM 4/18/2001 -0700, Rasmus Lerdorf wrote:
> > >When we're past the prototyping phase and stuff stabilizes, a C
> > >rewrite may be a good idea, but I don't think it is now.
> >
> > Well you know the most permanent things are temporary things such as
> > prototypes.
> > I also thought it would make much more sense to create something very small
> > in C (maybe even Perl as it's installed on all systems) and use that.
> > I'm not really sure anymore what this installer you are talking about looks
> > like. So I think it would be good to get a small update and have a
> > discussion of what we need on php-dev@.
>
>I see no issue with writing a prototype in PHP.  The start of such a
>prototype is in cvs (pear/script/pear)
>
>And yes, using XML is pretty much a no-brainer here.  That will allow a
>lot of different nifty tools to access the package information.

For a start you don't have PHP installed on most systems. So PHP would need 
to compile itself and then fetch packages and recompile itself. Seems to me 
like the no-brainer isn't such a no-brainer.

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-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4/ TODO-4.1.txt

[Rasmus Lerdorf]

> >When we're past the prototyping phase and stuff stabilizes, a C
> >rewrite may be a good idea, but I don't think it is now.
>
> Well you know the most permanent things are temporary things such as
> prototypes.
> I also thought it would make much more sense to create something very small
> in C (maybe even Perl as it's installed on all systems) and use that.
> I'm not really sure anymore what this installer you are talking about looks
> like. So I think it would be good to get a small update and have a
> discussion of what we need on php-dev@.

I see no issue with writing a prototype in PHP.  The start of such a
prototype is in cvs (pear/script/pear)

And yes, using XML is pretty much a no-brainer here.  That will allow a
lot of different nifty tools to access the package information.

-Rasmus


-- 
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-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 10:03 PM 4/18/2001 -0400, Stig Sæther Bakken wrote:
>["Sean R. Bright" <[EMAIL PROTECTED]>]
> > To continue a tangent... I don't like the idea of having the PEAR
> > fetching/installation mechanism written in PHP (already some base code in
> > PEAR to do this).  It seems to me that it forces the user to download/build
> > PHP and then download and rebuild PHP with any extensions that don't 
> come in
> > the base distribution.  Instead it should be a binary that can be compiled
> > before PHP is built, can download and configure any extensions 
> requested and
> > then build the resulting PHP binary.  We can also build in a dependency
> > mechanism where for example, someone chooses to install a PEAR module 
> (be it
> > PHP or C) and the required extensions would be downloaded as well.
> >
> > Just my $0.02
>
>I see your point, but personally I code 5 times faster in PHP than in
>C, and I want to get this done now, not next year. :-)
>
>When we're past the prototyping phase and stuff stabilizes, a C
>rewrite may be a good idea, but I don't think it is now.

Well you know the most permanent things are temporary things such as 
prototypes.
I also thought it would make much more sense to create something very small 
in C (maybe even Perl as it's installed on all systems) and use that.
I'm not really sure anymore what this installer you are talking about looks 
like. So I think it would be good to get a small update and have a 
discussion of what we need on php-dev@.

Thanks,

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-CVS] cvs: php4 / TODO-4.1.txt

[Rasmus Lerdorf]

It has been in cvs for months.

On Thu, 19 Apr 2001, Andi Gutmans wrote:

> At 06:53 PM 4/18/2001 -0400, Stig Sæther Bakken wrote:
>
> >*BLAM*
> >
> >That's the sound of someone shooting himself in the foot.  The PEAR
> >installer needs the XML extension. :-)
>
> What do you mean? Has work started on this already?
> I'm not quite sure what you mean by the PEAR installer but I think we
> should discuss the util we would need to list/fetch/build C extensions from
> the PEAR repository on php-dev@.
> I think it's a waste of time to decide right now what to remove instead of
> trying to finalizing this utility. Once we see how well it works it'll be
> time to start thinking of what extensions to remove. I think it's just
> putting energy in the wrong place right now :)
>
> 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]
>


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 03:33 AM 4/19/2001 +0300, Zeev Suraski wrote:
>Guys,
>
>Over the years, there's always been a tendency to think about things which 
>are 10 steps ahead.  It never worked, and I don't think it would work here 
>either.  Moreover, I don't see any advantage in discussing this now - on 
>the contrary - we really have no idea what we're talking about.  Whether 
>or not we separate modules *at all* will greatly depend on how good an 
>implementation we end up having.  How many of them we end up separating 
>will also depend on that.  Let's just wait with those discussions until 
>they're somehow connected with reality.
>
>Zeev

Scary... Didn't read this before :)

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-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 06:53 PM 4/18/2001 -0400, Stig Sæther Bakken wrote:

>*BLAM*
>
>That's the sound of someone shooting himself in the foot.  The PEAR
>installer needs the XML extension. :-)

What do you mean? Has work started on this already?
I'm not quite sure what you mean by the PEAR installer but I think we 
should discuss the util we would need to list/fetch/build C extensions from 
the PEAR repository on php-dev@.
I think it's a waste of time to decide right now what to remove instead of 
trying to finalizing this utility. Once we see how well it works it'll be 
time to start thinking of what extensions to remove. I think it's just 
putting energy in the wrong place right now :)

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-CVS] cvs: php4 / TODO-4.1.txt

[Stig Sæther Bakken]

["Sean R. Bright" <[EMAIL PROTECTED]>]
> To continue a tangent... I don't like the idea of having the PEAR
> fetching/installation mechanism written in PHP (already some base code in
> PEAR to do this).  It seems to me that it forces the user to download/build
> PHP and then download and rebuild PHP with any extensions that don't come in
> the base distribution.  Instead it should be a binary that can be compiled
> before PHP is built, can download and configure any extensions requested and
> then build the resulting PHP binary.  We can also build in a dependency
> mechanism where for example, someone chooses to install a PEAR module (be it
> PHP or C) and the required extensions would be downloaded as well.
> 
> Just my $0.02

I see your point, but personally I code 5 times faster in PHP than in
C, and I want to get this done now, not next year. :-)

When we're past the prototyping phase and stuff stabilizes, a C
rewrite may be a good idea, but I don't think it is now.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Sean R. Bright]

To continue a tangent... I don't like the idea of having the PEAR
fetching/installation mechanism written in PHP (already some base code in
PEAR to do this).  It seems to me that it forces the user to download/build
PHP and then download and rebuild PHP with any extensions that don't come in
the base distribution.  Instead it should be a binary that can be compiled
before PHP is built, can download and configure any extensions requested and
then build the resulting PHP binary.  We can also build in a dependency
mechanism where for example, someone chooses to install a PEAR module (be it
PHP or C) and the required extensions would be downloaded as well.

Just my $0.02

> -Original Message-
> From: Ron Chmara [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 18, 2001 8:53 PM
> To: Zeev Suraski
> Cc: Frank M. Kromann; Sterling Hughes; Stig Sather Bakken; php-dev
> mailinglist; Stig Sather Bakken
> Subject: Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt
>
>
> On Wednesday, April 18, 2001, at 05:33  PM, Zeev Suraski wrote:
> > Guys,
> > Over the years, there's always been a tendency to think
> about things
> > which are 10 steps ahead.  It never worked, and I don't
> think it would
> > work here either.
>
> Well, a program spec (or idea) is certainly not the reality
> of the final
> codebase.
>
> But if we don't think a few steps ahead, (or at least know where it's
> going), it's kind of hard to determine the steps to take here
> and now,
> or know where it's really going. I posted a list, and we
> discovered that
> PEAR already has dependancies on some /ext's, and (by
> implication) that
> if this continues in PEAR, eventually many of the minor ext's
> may need
> to be built to run PEAR in which case we may want to
> leave the /ext
> directory out of PEAR entirely.
>
> If something is going to be a possibility, it should probably be
> considered before we build ourselves into a corner, and
> implementing it
> becomes impossible.
>
> >  Whether or not we separate modules *at all* will greatly
> depend on how
> > good an implementation we end up having.
>
> Agreed 100%.
> But that implementation, as it happens requires some feedback and
> discussion, doesn't it?
>
> >  How many of them we end up separating will also depend on
> that.  Let's
> > just wait with those discussions until they're somehow
> connected with
> > reality.
>
> Counterpoint to this, of course, is that if we _would_ be doing this
> with a PEAR scheme, we'd need to design that into PEAR, preferrably
> without having to re-write PEAR from scratch to accomodate
> this idea. :-)
>
>
> -Ronabop
>
> --
> 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-CVS] cvs: php4 / TODO-4.1.txt

[Ron Chmara]

On Wednesday, April 18, 2001, at 05:33  PM, Zeev Suraski wrote:
> Guys,
> Over the years, there's always been a tendency to think about things 
> which are 10 steps ahead.  It never worked, and I don't think it would 
> work here either.

Well, a program spec (or idea) is certainly not the reality of the final 
codebase.

But if we don't think a few steps ahead, (or at least know where it's 
going), it's kind of hard to determine the steps to take here and now, 
or know where it's really going. I posted a list, and we discovered that 
PEAR already has dependancies on some /ext's, and (by implication) that 
if this continues in PEAR, eventually many of the minor ext's may need 
to be built to run PEAR in which case we may want to leave the /ext 
directory out of PEAR entirely.

If something is going to be a possibility, it should probably be 
considered before we build ourselves into a corner, and implementing it 
becomes impossible.

>  Whether or not we separate modules *at all* will greatly depend on how 
> good an implementation we end up having.

Agreed 100%.
But that implementation, as it happens requires some feedback and 
discussion, doesn't it?

>  How many of them we end up separating will also depend on that.  Let's 
> just wait with those discussions until they're somehow connected with 
> reality.

Counterpoint to this, of course, is that if we _would_ be doing this 
with a PEAR scheme, we'd need to design that into PEAR, preferrably 
without having to re-write PEAR from scratch to accomodate this idea. :-)


-Ronabop

-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Ron Chmara]

On Wednesday, April 18, 2001, at 03:53  PM, Stig Sæther Bakken wrote:
> [Ron Chmara <[EMAIL PROTECTED]>]
>> "Frank M. Kromann" wrote:
>>> Is there a list of modules that stays ?
>> A proposed list where it "cuts close to the bone":
>> (since nobody seems to want to be the 'bad guy', I'll start...)
>> M= Main
>> P= Pear
>> (To show/expose any personal bias, items marked with a "*" are ones 
>> that
>> I use on most servers.)
>>

Major Snip_>

>> pcre P
> PCRE should be in the main distribution, a lot of PEAR code relies on
> it.

Snip Again _>

>> xml P
> *BLAM*
> That's the sound of someone shooting himself in the foot.  The PEAR
> installer needs the XML extension. :-)

LOL!

Well, so we've established that for PEAR-based-extensions to work, we 
_must_
have some of the /ext's included in the main distribution, as well as 
some form
of dependancy checking and resolution.

Looks like we're morping into a PEAR design discussion, in some ways. :-)

>> Which would mean that the main distro would have:
>> apache
>> ftp
> Why ftp, when for example curl is out?

My mental approach was to ask myself what the basic, internet-related,
extensions were, the things likely to be used by a beginner before they
grasped more advanced concepts, so they wouldn't have to learn PEAR
interactions to get started with  the bare basics.. That's why I picked
fairly well-known names, packages, and databases. While cURL can
do a _lot_ of things, a newbie trying to ftp, get ldap entires, etc. 
might
be more likely to look for functions directly associated with their end
goal.

That was my reasoning. Not neccesarrily the best reasoning, tho. :-)
It assumes a learning curve for PEAR, etc.

Of course, if we have sockets, we don't actually "need" ftp, imap,
ldap... well, just about anything that writes or reads :-)  but that 
makes the
learning curve a bit steeper. Clifflike, even.

>> mssql
>> mysql
>> pgsql
> I'm willing to bet my best cap that oci8 is much more used than mssql.

The reason that I wound up with these three is that I was looking for the
"top two". To compensate for our Win32 users, I added mssql, because
IIRC the pg port was pretty much a cygwin-kind-of-kludgy-thing...

(Of course, the WIn32 users do add a whole new dimension to this)

Hmmm it sure would be nice to have some actual metrics on extension 
use,
regardless of what gets put into PEAR.

Do we have any logs on www.php.net/manual page views? Could we use
that in some form  to determine extension use (by how frequently an 
extensions'
pages get looked up)? It's not survey based, and it's passive enough that
timeframes that we were collecting data on could be hidden from 
poll-slamming.

Even if we didn't want to log web hits (in general) for performance 
reasons,
(I have no idea if we do) we could at least get a set of numbers unbiased
by personal use/coding styles/etc. by turning it on for a minute or two,
once an hour, for a few days.

>> pspell
> Why?

I guess I use it often  enough that I associate it with being as 
valuable as any other
form of standard string-validation.

It's the hidden biases (and I guess the above is one of mine) that creep 
into
this

I'd be much happier if we had some metrics on use. Maybe we could also
gather information on number of errata notes for each, opened/closed bugs
for each, and pageviews for each. Those numbers should at least point us
in a few directions, where it gives us an idea of what people are 
actually
working with (as compared to just installing, or a web-poll.) Something 
that
wasn't too geographically based would be nice, as well, because 
application
usage (which interacts with the extensions used) varies from country to
country, timezone to timezone.

-Ronabop

--
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-CVS] cvs: php4 / TODO-4.1.txt

[Zeev Suraski]

Guys,

Over the years, there's always been a tendency to think about things which 
are 10 steps ahead.  It never worked, and I don't think it would work here 
either.  Moreover, I don't see any advantage in discussing this now - on 
the contrary - we really have no idea what we're talking about.  Whether or 
not we separate modules *at all* will greatly depend on how good an 
implementation we end up having.  How many of them we end up separating 
will also depend on that.  Let's just wait with those discussions until 
they're somehow connected with reality.

Zeev

At 00:52 19/4/2001, Ron Chmara wrote:
>"Frank M. Kromann" wrote:
> >
> > Is there a list of modules that stays ?
>
>One of the things I've noticed on this topic is that a few
>folks tend to think that their particular technology should
>be used everywhere, and therefore, it should always be
>installed on machines. Of course, this is how we got into
>this convoluted situation in the first place... sure,
>"XYZ functions" may be touted as a future standard for all
>machines, someday, but quite frankly, many of such "standards"
>aren't even close to widespread use and deployment.
>
>In response to Zeev's point that we don't even know if/how PEAR
>will work, yes, I think this discussion isn't about enforcing the
>future. I'd say it's more about finding some better direction.
>
>A proposed list where it "cuts close to the bone":
>(since nobody seems to want to be the 'bad guy', I'll start...)
>
>M= Main
>P= Pear
>(To show/expose any personal bias, items marked with a "*" are ones that
>I use on most servers.)
>
>apache M *
>aspell P *
>bcmath P *
>bz2 P
>calendar P
>ccvs P
>com P
>cpdf P
>crack P *
>ctype P
>curl P
>cybercash P
>cybermut P
>db P
>dba P
>dbase P
>domxml P
>dotnet P
>exif P
>fdf P
>filepro P
>fribidi P
>ftp M *
>gd P *
>gettext P
>gmp P
>hyperwave P
>icap P
>iconv P
>iisfunc M
>imap M *
>informix P
>ingres_ii P
>interbase P
>ircg P
>java P
>ldap M *
>mcal P
>mcrypt P *
>mhash P *
>midgard P
>ming P
>mnogosearch P
>msql P
>mssql M
>muscat P
>mysql M *
>notes P
>oci8 P *
>odbc P
>openssl P
>oracle P
>ovrimos P
>pcre P
>pdf P
>pfpro P
>pgsql M *
>posix P
>printer P
>pspell M *
>qtdom P
>readline P
>recode P
>sablot P
>satellite P
>session M
>shmop M *
>snmp P *
>sockets M *
>standard M * (duh. :-) )
>swf P
>sybase P
>sybase_ct P
>sysvsem M *
>sysvshm M *
>vpopmail P
>wddx P
>xml P
>yaz P
>yp P
>zlib P
>zziplib P
>
>Which would mean that the main distro would have:
>apache
>ftp
>iisfunc
>imap
>ldap
>mssql
>mysql
>pgsql
>pspell
>session
>shmop
>sockets
>standard
>sysvsem
>sysvshm
>
>This keeps the core system functions, basic database
>services for the most widely used DB's, and the basic
>data exchange services (IMAP, ftp, ldap, etc.)
>
>Another way of looking at it would to leave almost everything
>in some use, and only take out the ones which seem to be for
>special purposes and work environments, such as an XML environment
>pieces, or midgard, or hyperwave
>ccvs P
>com P
>cpdf P
>curl P
>cybercash P
>cybermut P
>domxml P
>dotnet P
>exif P
>fdf P
>fribidi P
>gettext P
>hyperwave P
>icap P
>iconv P
>ircg P
>mcal P
>midgard P
>notes P
>openssl P
>pcre P
>pdf P
>pfpro P
>qtdom P
>readline P
>recode P
>sablot P
>vpopmail P
>wddx P
>xml P
>yaz P
>yp P
>zziplib P
>
>And, adding to the pear discussion, working with blocks of
>these would undoubtedly be easier. So if you wanted to
>get the XML package, it would grab xml, domxml, etc...
>
>-Ronabop
>
>--2D426F70|759328624|00101101011001100111
>Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
>Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
>The opinions expressed in this email are not necessarily those of myself,
>my employers, or any of the other little voices in my head.

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Frank M. Kromann]

> [Ron Chmara <[EMAIL PROTECTED]>]
> > "Frank M. Kromann" wrote:
> > > 
> > > Is there a list of modules that stays ?
> > 
> > One of the things I've noticed on this topic is that a few
> > folks tend to think that their particular technology should
> > be used everywhere, and therefore, it should always be
> > installed on machines. Of course, this is how we got into
> > this convoluted situation in the first place... sure,
> > "XYZ functions" may be touted as a future standard for all
> > machines, someday, but quite frankly, many of such "standards"
> > aren't even close to widespread use and deployment.
> > 
> > In response to Zeev's point that we don't even know if/how PEAR
> > will work, yes, I think this discussion isn't about enforcing the
> > future. I'd say it's more about finding some better direction.
> > 
> > A proposed list where it "cuts close to the bone":
> > (since nobody seems to want to be the 'bad guy', I'll start...)
> > 
> > M= Main
> > P= Pear
> > (To show/expose any personal bias, items marked with a "*" are ones that
> > I use on most servers.)
> > 
> > apache M *
> > aspell P *
> > bcmath P *
> > bz2 P
> > calendar P
> > ccvs P
> > com P
> > cpdf P
> > crack P *
> > ctype P
> > curl P
> > cybercash P
> > cybermut P
> > db P
> > dba P
> 
> I'd like to see dba stay.
> 
> > dbase P
> > domxml P
> > dotnet P
> > exif P
> > fdf P
> > filepro P
> > fribidi P
> > ftp M *
> > gd P *
> > gettext P
> > gmp P
> > hyperwave P
> > icap P
> > iconv P
> 
> The iconv library in itself is useful enough that we should try to
> keep this one within PHP, maybe even integrate it tighter.
> 
> > iisfunc M
> > imap M *
> > informix P
> > ingres_ii P
> > interbase P
> > ircg P
> > java P
> > ldap M *
> > mcal P
> > mcrypt P *
> > mhash P *
> > midgard P
> > ming P
> > mnogosearch P
> > msql P
> > mssql M
> > muscat P
> > mysql M *
> > notes P 
> > oci8 P *
> > odbc P 
> > openssl P
> > oracle P
> > ovrimos P
> > pcre P
> 
> PCRE should be in the main distribution, a lot of PEAR code relies on
> it.
> 
> > pdf P
> > pfpro P
> > pgsql M *
> > posix P
> > printer P
> > pspell M *
> > qtdom P
> > readline P
> > recode P
> > sablot P
> > satellite P
> > session M 
> > shmop M *
> > snmp P *
> > sockets M *
> > standard M * (duh. :-) )
> > swf P
> > sybase P
> > sybase_ct P
> > sysvsem M *
> > sysvshm M *
> > vpopmail P
> > wddx P
> > xml P
> 
> *BLAM*
> 
> That's the sound of someone shooting himself in the foot.  The PEAR
> installer needs the XML extension. :-)
> 
> > yaz P
> > yp P
> > zlib P
> > zziplib P
> > 
> > Which would mean that the main distro would have:
> > apache
> > ftp
> 
> Why ftp, when for example curl is out?
> 
> > iisfunc
> > imap
> > ldap
> > mssql
> > mysql
> > pgsql
> 
> I'm willing to bet my best cap that oci8 is much more used than mssql.

That depends on the platform I think. MSSQL is Win32 only so far though I'm planning 
an integration with FreeTDS to allow support from Linux/Unix.

iisfunc and printer are other Win32 only extension and should be in PEAR, IMHO.

> 
> > pspell
> 
> Why?
> 
> > session
> > shmop
> > sockets
> > standard
> > sysvsem
> > sysvshm
> > 
> > This keeps the core system functions, basic database
> > services for the most widely used DB's, and the basic
> > data exchange services (IMAP, ftp, ldap, etc.)
> > 
> > Another way of looking at it would to leave almost everything
> > in some use, and only take out the ones which seem to be for
> > special purposes and work environments, such as an XML environment
> > pieces, or midgard, or hyperwave
> > ccvs P
> > com P
> > cpdf P
> > curl P
> > cybercash P
> > cybermut P
> > domxml P
> > dotnet P
> > exif P
> > fdf P
> > fribidi P
> > gettext P
> > hyperwave P
> > icap P
> > iconv P
> > ircg P
> > mcal P
> > midgard P
> > notes P 
> > openssl P
> > pcre P
> > pdf P
> > pfpro P
> > qtdom P
> > readline P
> > recode P
> > sablot P
> > vpopmail P
> > wddx P
> > xml P
> > yaz P
> > yp P
> > zziplib P
> > 
> > And, adding to the pear discussion, working with blocks of these
> > would undoubtedly be easier. So if you wanted to get the XML
> > package, it would grab xml, domxml, etc...
> 
> Well, if you use domxml, you probably wouldn't use xml, because they
> offer two different abstractions/approaches to solve more or less the
> same problem.  But such blocks (or bundles, like CPAN calls them) are
> a good idea.
> 
> It'd be interesting to hear what extension maintainers think.
> 
>  - Stig
> 

I think it is important to make sure all extenstions are in sync with the main php 
repository. Especially on Windows where binary distributions are much used. It is not 
possible to use old versions of the dll's with new versions of the php binaries. 
Making php build with CygWin might be a solution for this. Mebye this should be on the 
to-do list ?

I also think it would be a bad idea to remove some database modules an not others. 
That would be the same as saying that php should be used with one of the databases 
su

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Stig Sæther Bakken]

[Ron Chmara <[EMAIL PROTECTED]>]
> "Frank M. Kromann" wrote:
> > 
> > Is there a list of modules that stays ?
> 
> One of the things I've noticed on this topic is that a few
> folks tend to think that their particular technology should
> be used everywhere, and therefore, it should always be
> installed on machines. Of course, this is how we got into
> this convoluted situation in the first place... sure,
> "XYZ functions" may be touted as a future standard for all
> machines, someday, but quite frankly, many of such "standards"
> aren't even close to widespread use and deployment.
> 
> In response to Zeev's point that we don't even know if/how PEAR
> will work, yes, I think this discussion isn't about enforcing the
> future. I'd say it's more about finding some better direction.
> 
> A proposed list where it "cuts close to the bone":
> (since nobody seems to want to be the 'bad guy', I'll start...)
> 
> M= Main
> P= Pear
> (To show/expose any personal bias, items marked with a "*" are ones that
> I use on most servers.)
> 
> apache M *
> aspell P *
> bcmath P *
> bz2 P
> calendar P
> ccvs P
> com P
> cpdf P
> crack P *
> ctype P
> curl P
> cybercash P
> cybermut P
> db P
> dba P

I'd like to see dba stay.

> dbase P
> domxml P
> dotnet P
> exif P
> fdf P
> filepro P
> fribidi P
> ftp M *
> gd P *
> gettext P
> gmp P
> hyperwave P
> icap P
> iconv P

The iconv library in itself is useful enough that we should try to
keep this one within PHP, maybe even integrate it tighter.

> iisfunc M
> imap M *
> informix P
> ingres_ii P
> interbase P
> ircg P
> java P
> ldap M *
> mcal P
> mcrypt P *
> mhash P *
> midgard P
> ming P
> mnogosearch P
> msql P
> mssql M
> muscat P
> mysql M *
> notes P 
> oci8 P *
> odbc P 
> openssl P
> oracle P
> ovrimos P
> pcre P

PCRE should be in the main distribution, a lot of PEAR code relies on
it.

> pdf P
> pfpro P
> pgsql M *
> posix P
> printer P
> pspell M *
> qtdom P
> readline P
> recode P
> sablot P
> satellite P
> session M 
> shmop M *
> snmp P *
> sockets M *
> standard M * (duh. :-) )
> swf P
> sybase P
> sybase_ct P
> sysvsem M *
> sysvshm M *
> vpopmail P
> wddx P
> xml P

*BLAM*

That's the sound of someone shooting himself in the foot.  The PEAR
installer needs the XML extension. :-)

> yaz P
> yp P
> zlib P
> zziplib P
> 
> Which would mean that the main distro would have:
> apache
> ftp

Why ftp, when for example curl is out?

> iisfunc
> imap
> ldap
> mssql
> mysql
> pgsql

I'm willing to bet my best cap that oci8 is much more used than mssql.

> pspell

Why?

> session
> shmop
> sockets
> standard
> sysvsem
> sysvshm
> 
> This keeps the core system functions, basic database
> services for the most widely used DB's, and the basic
> data exchange services (IMAP, ftp, ldap, etc.)
> 
> Another way of looking at it would to leave almost everything
> in some use, and only take out the ones which seem to be for
> special purposes and work environments, such as an XML environment
> pieces, or midgard, or hyperwave
> ccvs P
> com P
> cpdf P
> curl P
> cybercash P
> cybermut P
> domxml P
> dotnet P
> exif P
> fdf P
> fribidi P
> gettext P
> hyperwave P
> icap P
> iconv P
> ircg P
> mcal P
> midgard P
> notes P 
> openssl P
> pcre P
> pdf P
> pfpro P
> qtdom P
> readline P
> recode P
> sablot P
> vpopmail P
> wddx P
> xml P
> yaz P
> yp P
> zziplib P
> 
> And, adding to the pear discussion, working with blocks of these
> would undoubtedly be easier. So if you wanted to get the XML
> package, it would grab xml, domxml, etc...

Well, if you use domxml, you probably wouldn't use xml, because they
offer two different abstractions/approaches to solve more or less the
same problem.  But such blocks (or bundles, like CPAN calls them) are
a good idea.

It'd be interesting to hear what extension maintainers think.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Ron Chmara]

"Frank M. Kromann" wrote:
> 
> Is there a list of modules that stays ?

One of the things I've noticed on this topic is that a few
folks tend to think that their particular technology should
be used everywhere, and therefore, it should always be
installed on machines. Of course, this is how we got into
this convoluted situation in the first place... sure,
"XYZ functions" may be touted as a future standard for all
machines, someday, but quite frankly, many of such "standards"
aren't even close to widespread use and deployment.

In response to Zeev's point that we don't even know if/how PEAR
will work, yes, I think this discussion isn't about enforcing the
future. I'd say it's more about finding some better direction.

A proposed list where it "cuts close to the bone":
(since nobody seems to want to be the 'bad guy', I'll start...)

M= Main
P= Pear
(To show/expose any personal bias, items marked with a "*" are ones that
I use on most servers.)

apache M *
aspell P *
bcmath P *
bz2 P
calendar P
ccvs P
com P
cpdf P
crack P *
ctype P
curl P
cybercash P
cybermut P
db P
dba P
dbase P
domxml P
dotnet P
exif P
fdf P
filepro P
fribidi P
ftp M *
gd P *
gettext P
gmp P
hyperwave P
icap P
iconv P
iisfunc M
imap M *
informix P
ingres_ii P
interbase P
ircg P
java P
ldap M *
mcal P
mcrypt P *
mhash P *
midgard P
ming P
mnogosearch P
msql P
mssql M
muscat P
mysql M *
notes P 
oci8 P *
odbc P 
openssl P
oracle P
ovrimos P
pcre P
pdf P
pfpro P
pgsql M *
posix P
printer P
pspell M *
qtdom P
readline P
recode P
sablot P
satellite P
session M 
shmop M *
snmp P *
sockets M *
standard M * (duh. :-) )
swf P
sybase P
sybase_ct P
sysvsem M *
sysvshm M *
vpopmail P
wddx P
xml P
yaz P
yp P
zlib P
zziplib P

Which would mean that the main distro would have:
apache
ftp
iisfunc
imap
ldap
mssql
mysql
pgsql
pspell
session
shmop
sockets
standard
sysvsem
sysvshm

This keeps the core system functions, basic database
services for the most widely used DB's, and the basic
data exchange services (IMAP, ftp, ldap, etc.)

Another way of looking at it would to leave almost everything
in some use, and only take out the ones which seem to be for
special purposes and work environments, such as an XML environment
pieces, or midgard, or hyperwave
ccvs P
com P
cpdf P
curl P
cybercash P
cybermut P
domxml P
dotnet P
exif P
fdf P
fribidi P
gettext P
hyperwave P
icap P
iconv P
ircg P
mcal P
midgard P
notes P 
openssl P
pcre P
pdf P
pfpro P
qtdom P
readline P
recode P
sablot P
vpopmail P
wddx P
xml P
yaz P
yp P
zziplib P

And, adding to the pear discussion, working with blocks of
these would undoubtedly be easier. So if you wanted to
get the XML package, it would grab xml, domxml, etc...

-Ronabop

--2D426F70|759328624|00101101011001100111
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not necessarily those of myself,
my employers, or any of the other little voices in my head.

-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 11:55 AM 4/18/2001 +0100, Wez Furlong wrote:
>On 2001-04-17 21:08:15, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
> > Any chance you can write a small readme file or add some explanations to
> > the .h file to give people like me a small overview of the abstraction so
> > that it will be easier to start diving into the code?
>
>I've just commited README.STREAMS to the php4 root.

I'm glad I asked you to write this document.
It's extremely helpful for getting a good and quick overview of the streams.
Great job and again, this is something I've wanted to see for a long time!

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-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 11:55 AM 4/18/2001 +0100, Wez Furlong wrote:
>On 2001-04-17 21:08:15, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
> > Any chance you can write a small readme file or add some explanations to
> > the .h file to give people like me a small overview of the abstraction so
> > that it will be easier to start diving into the code?
>
>I've just commited README.STREAMS to the php4 root.

Great! I'll read it soon.
We should probably put it in php4/main or create a php4/doc and move docs 
there. The less we clutter the main directory the better.

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-CVS] cvs: php4 / TODO-4.1.txt

[Wez Furlong]

On 2001-04-17 21:08:15, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
> Any chance you can write a small readme file or add some explanations to 
> the .h file to give people like me a small overview of the abstraction so 
> that it will be easier to start diving into the code?

I've just commited README.STREAMS to the php4 root.

--Wez.


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Wez Furlong]

On 2001-04-17 22:38:00, "Stig Venaas" <[EMAIL PROTECTED]> wrote:
> To do sockets with different families properly I need to store some
> place what family it is when it's created. So I want all sockets in
> PHP to have an associated datastructure with this and perhaps other
> data in it (this is not needed when the socket is created and destroyed
> inside some low level function).

Although I'm currently using stream->abstract to hold the socketd, there is nothing 
stopping us from holding a pointer to a socket info struct to keep that data.

--Wez.


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Wez Furlong]

On 2001-04-17 21:08:15, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
> I haven't had much time to go over it but it looks like it's definitely in 
> the right direction. I've wanted to see something like this in PHP for a while.
> Any chance you can write a small readme file or add some explanations to 
> the .h file to give people like me a small overview of the abstraction so 
> that it will be easier to start diving into the code?

Will do.

--Wez.


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Zeev Suraski]

At 01:22 18/4/2001, Stig Sæther Bakken wrote:
>I'm replying to another message you sent where you say you fail to see
>the advantages.  Well, the advantage is that when you free the PHP
>core from the release cycle of all the extensions, doing PHP releases
>will become less complex, the QA process is broken down into smaller,
>more manageable tasks.

As I said, I don't think this is necessarily a good thing with the popular 
extensions.  It's a great thing with the 'moving targets' or with the 
not-too-popular extensions, but keeping the release cycle of modules like 
MySQL, XML, regex, etc. in sync with the PHP release is a good thing in my 
opinion.  Most people will only be bothered to upgrade their PHP 
installation when there's a whole new release that's out.

>Also, it makes the development cycles of the core and extensions more
>free: if Thies wants to do some heavy surgery on the oci8 extension
>adding support for Oracle 15, he doesn't have to wait until the
>"now-in-RC" PHP is released, he can just go ahead and code knowing
>that the PHP release will ship with the latest version of the OCI
>extension that he labelled as stable.

Well, that's true, but I think that PEAR isn't really the solution to the 
fact that CVS has sucky branches (which would have been the right solution 
for this problem :)

>We won't end up with no extensions but ext/standard in PHP, but I
>think we should be offensive about taking them out unless they are
>very tightly integrated with PHP, and unless the maintainers object.
>The only ones I can think of that are this integrated must be
>"standard", "bcmath" and "session".

At least I get to keep MySQL and PostgreSQL in :)

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-CVS] cvs: php4 / TODO-4.1.txt

[Zeev Suraski]

No there isn't.  As I said, IMHO we should really delay this entire 
discussion until this becomes more relevant.  Right now we don't even know 
how PEAR and the installation tool would look like exactly.

Zeev

At 13:13 18/4/2001, Frank M. Kromann wrote:
>Is there a list of modules that stays ?
>
>I would like to see a way to make sure modules (I maintain) is not falling 
>to far behind main releases.
>
>- Frank
>
> > We need to think about it.  I think that keeping the release cycle of this
> > selected set of modules in sync with the PHP releases is actually a 
> good thing.
> >
> > Zeev
> >
> > At 00:57 18/4/2001, Stig Sæther Bakken wrote:
> > >[Zeev Suraski <[EMAIL PROTECTED]>]
> > > > At 05:03 17/4/2001, Sterling Hughes wrote:
> > > > >Ok, let me just see if I understand...
> > > > >
> > > > >move everything out of the distribution (from mysql popular extensions
> > > > >like mysql to hardly used ones like qtdom), and then, come release 
> time,
> > > > >package a predefined set of PEAR modules and extensions we want to 
> package
> > > > >for PHP4.
> > > >
> > > > Not really - some of the extensions will remain in PHP.  I believe
> > > > that the fact that PHP comes bundled with support for some of the most
> > > > common Web environment applications is still a serious factor in its
> > > > success.  It did get into a situation when there are simply too many
> > > > not-too-mainstream extensions in there, though, which makes it very
> > > > difficult to find a stable point at time to release it.  I wouldn't
> > > > expect MySQL, Oracle or XML support to be removed from PHP, though.
> > >
> > >Why not, as long as we put the latest known-to-be-stable version of
> > >each back in when making a release?
> > >
> > >  - Stig
> > >
> > >--
> > >   Stig Sæther Bakken <[EMAIL PROTECTED]>
> > >   Fast Search & Transfer ASA, Trondheim, Norway
> >
> > --
> > Zeev Suraski <[EMAIL PROTECTED]>
> > CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
> >
> >
> > --
> > 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]
> >
> >
> >

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


--
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-CVS] cvs: php4 / TODO-4.1.txt

[Stig Sæther Bakken]

[[EMAIL PROTECTED] (Stig Sæther Bakken)]
> [Zeev Suraski <[EMAIL PROTECTED]>]
> > At 05:03 17/4/2001, Sterling Hughes wrote:
> > >Ok, let me just see if I understand...
> > >
> > >move everything out of the distribution (from mysql popular extensions
> > >like mysql to hardly used ones like qtdom), and then, come release time,
> > >package a predefined set of PEAR modules and extensions we want to package
> > >for PHP4.
> > 
> > Not really - some of the extensions will remain in PHP.  I believe
> > that the fact that PHP comes bundled with support for some of the most
> > common Web environment applications is still a serious factor in its
> > success.  It did get into a situation when there are simply too many
> > not-too-mainstream extensions in there, though, which makes it very
> > difficult to find a stable point at time to release it.  I wouldn't
> > expect MySQL, Oracle or XML support to be removed from PHP, though.
> 
> Why not, as long as we put the latest known-to-be-stable version of
> each back in when making a release?

I'm replying to another message you sent where you say you fail to see
the advantages.  Well, the advantage is that when you free the PHP
core from the release cycle of all the extensions, doing PHP releases
will become less complex, the QA process is broken down into smaller,
more manageable tasks.

Also, it makes the development cycles of the core and extensions more
free: if Thies wants to do some heavy surgery on the oci8 extension
adding support for Oracle 15, he doesn't have to wait until the
"now-in-RC" PHP is released, he can just go ahead and code knowing
that the PHP release will ship with the latest version of the OCI
extension that he labelled as stable.

We won't end up with no extensions but ext/standard in PHP, but I
think we should be offensive about taking them out unless they are
very tightly integrated with PHP, and unless the maintainers object.
The only ones I can think of that are this integrated must be
"standard", "bcmath" and "session".

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Frank M. Kromann]

Is there a list of modules that stays ?

I would like to see a way to make sure modules (I maintain) is not falling to far 
behind main releases.

- Frank

> We need to think about it.  I think that keeping the release cycle of this 
> selected set of modules in sync with the PHP releases is actually a good thing.
> 
> Zeev
> 
> At 00:57 18/4/2001, Stig Sæther Bakken wrote:
> >[Zeev Suraski <[EMAIL PROTECTED]>]
> > > At 05:03 17/4/2001, Sterling Hughes wrote:
> > > >Ok, let me just see if I understand...
> > > >
> > > >move everything out of the distribution (from mysql popular extensions
> > > >like mysql to hardly used ones like qtdom), and then, come release time,
> > > >package a predefined set of PEAR modules and extensions we want to package
> > > >for PHP4.
> > >
> > > Not really - some of the extensions will remain in PHP.  I believe
> > > that the fact that PHP comes bundled with support for some of the most
> > > common Web environment applications is still a serious factor in its
> > > success.  It did get into a situation when there are simply too many
> > > not-too-mainstream extensions in there, though, which makes it very
> > > difficult to find a stable point at time to release it.  I wouldn't
> > > expect MySQL, Oracle or XML support to be removed from PHP, though.
> >
> >Why not, as long as we put the latest known-to-be-stable version of
> >each back in when making a release?
> >
> >  - Stig
> >
> >--
> >   Stig Sæther Bakken <[EMAIL PROTECTED]>
> >   Fast Search & Transfer ASA, Trondheim, Norway
> 
> --
> Zeev Suraski <[EMAIL PROTECTED]>
> CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
> 
> 
> --
> 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-CVS] cvs: php4 / TODO-4.1.txt

[Stig Venaas]

On Tue, Apr 17, 2001 at 09:43:06PM +0100, Wez Furlong wrote:
> Hi Stig (the other one), 
> 
> I would like to end up with a "definitive" hostconnect call - something like a blend 
>between the fsockopen code in fsock.c and php_hostconnect in network.c
> 
> If you could make me aware of any gotchas I should look out for while coming up with 
>the code, I would appreciate it!

The main idea anyway is to pass a hostname to connect to, and have the
function sort out what addresses are available and try them in turn with
IPv6-addresses first. As you can see in hostconnect I have a high level
routine php_network_getaddresses() abstracting the lookup so that it's
the same whether getaddrinfo() is available or not. I think the current
hostconnect can be re-used in fsockopen when the timeout has been
implemented, I've been planning to do that for a while, but wanted to get
thorough testing of the current hostconnect() before I made it more complex.
As you see hostconnect() already takes a time-out argument, but it's
ignored at the moment. BTW if you look in fsock.c there is some socket
structure there and functions with php_sockcreate(), php_sockdestroy()
etc. It might be that can add room for address family in there. We need
something that can also be used in socket.c.

> 
> > with some input regarding how important you think IPv6 support is, and how
> > much breakage we can allow and ideas for how to cope with it.
> 
> Since I don't know of or have access to a network running IPv6 (or I'm too isolated 
>from the real world to have realized how to do it ;-), I'm not sure just how 
>important it is.

If you want to, I could tell you how, and you could be up and running
pretty quickly. You don't really need it to do any work though.

> 
> The perfectionist in me would like to see it in PHP; I have no problems running PHP 
>without having IPv6 configured, and if the people that ARE having problems are using 
>bad implementations/configurations, it should really be down to them to fix them.

Yes, and it is I think. The problem though is that some people may be put
off and don't use PHP because of our change.

> What kind of problems are showing up in the bug DB?

Some of the problems with fopen() are because of this, it's often hard to
know if this is the problem or other things. But there are a couple of
cases where it's been tracked down to getaddrinfo() bugs or broken
installations.

> Any idea how many people are using IPv6?

Not really, it's going to increase quicker and quicker though. Actually
RedHat 7.1, Solaris 8, recent BSD's etc. got IPv6 out of the box.

> Are the problems apparent on systems with IPv6 support (in the libs and headers), 
>but not yet configured?

The problem is that we use getaddrinfo() if it exists, but on some systems
the getaddrinfo() implementation is broken. getaddrinfo() is a bit complex
and changed a bit before it stabilized.

> We might be able to get away with a note in the installation instructions about 
>using IPv6 and how to resolve simple issues, or advise to upgrade, as appropriate?

Actually that's a good and simple idea. I'll add a note there.

BTW, for some reason I've used the same IPv6 code other places without
that many bug reports, but PHP has got quite a lot of users...

Your OpenSSL extension work looks good,

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]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Wez Furlong]

On 2001-04-17 22:22:47, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> At 20:24 17/4/2001, Wez Furlong wrote:
> >It's in CVS now - take a look at main/php_streams.h.
> 
> Cool - it looks very good!  That's exactly what I meant in the 'something 
> similar to C++'s virtual classes' :)

Thanks for your approval; it's good to know that I'm on the right track.

--Wez.



-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Zeev Suraski]

We need to think about it.  I think that keeping the release cycle of this 
selected set of modules in sync with the PHP releases is actually a good thing.

Zeev

At 00:57 18/4/2001, Stig Sæther Bakken wrote:
>[Zeev Suraski <[EMAIL PROTECTED]>]
> > At 05:03 17/4/2001, Sterling Hughes wrote:
> > >Ok, let me just see if I understand...
> > >
> > >move everything out of the distribution (from mysql popular extensions
> > >like mysql to hardly used ones like qtdom), and then, come release time,
> > >package a predefined set of PEAR modules and extensions we want to package
> > >for PHP4.
> >
> > Not really - some of the extensions will remain in PHP.  I believe
> > that the fact that PHP comes bundled with support for some of the most
> > common Web environment applications is still a serious factor in its
> > success.  It did get into a situation when there are simply too many
> > not-too-mainstream extensions in there, though, which makes it very
> > difficult to find a stable point at time to release it.  I wouldn't
> > expect MySQL, Oracle or XML support to be removed from PHP, though.
>
>Why not, as long as we put the latest known-to-be-stable version of
>each back in when making a release?
>
>  - Stig
>
>--
>   Stig Sæther Bakken <[EMAIL PROTECTED]>
>   Fast Search & Transfer ASA, Trondheim, Norway

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


--
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-CVS] cvs: php4 / TODO-4.1.txt

[Stig Sæther Bakken]

[Zeev Suraski <[EMAIL PROTECTED]>]
> At 05:03 17/4/2001, Sterling Hughes wrote:
> >Ok, let me just see if I understand...
> >
> >move everything out of the distribution (from mysql popular extensions
> >like mysql to hardly used ones like qtdom), and then, come release time,
> >package a predefined set of PEAR modules and extensions we want to package
> >for PHP4.
> 
> Not really - some of the extensions will remain in PHP.  I believe
> that the fact that PHP comes bundled with support for some of the most
> common Web environment applications is still a serious factor in its
> success.  It did get into a situation when there are simply too many
> not-too-mainstream extensions in there, though, which makes it very
> difficult to find a stable point at time to release it.  I wouldn't
> expect MySQL, Oracle or XML support to be removed from PHP, though.

Why not, as long as we put the latest known-to-be-stable version of
each back in when making a release?

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Wez Furlong]

Hi Stig (the other one), 

I would like to end up with a "definitive" hostconnect call - something like a blend 
between the fsockopen code in fsock.c and php_hostconnect in network.c

If you could make me aware of any gotchas I should look out for while coming up with 
the code, I would appreciate it!

> with some input regarding how important you think IPv6 support is, and how
> much breakage we can allow and ideas for how to cope with it.

Since I don't know of or have access to a network running IPv6 (or I'm too isolated 
from the real world to have realized how to do it ;-), I'm not sure just how important 
it is.

The perfectionist in me would like to see it in PHP; I have no problems running PHP 
without having IPv6 configured, and if the people that ARE having problems are using 
bad implementations/configurations, it should really be down to them to fix them.

What kind of problems are showing up in the bug DB?
Any idea how many people are using IPv6?
Are the problems apparent on systems with IPv6 support (in the libs and headers), but 
not yet configured?

We might be able to get away with a note in the installation instructions about using 
IPv6 and how to resolve simple issues, or advise to upgrade, as appropriate?

--Wez.


--
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-CVS] cvs: php4 / TODO-4.1.txt

[Stig Venaas]

On Wed, Apr 18, 2001 at 12:22:47AM +0300, Zeev Suraski wrote:
> Cool - it looks very good!  That's exactly what I meant in the 'something 
> similar to C++'s virtual classes' :)

It looks good, but it also looks like it doesn't solve my problem. Well
I guess that's my problem not yours (:

To do sockets with different families properly I need to store some
place what family it is when it's created. So I want all sockets in
PHP to have an associated datastructure with this and perhaps other
data in it (this is not needed when the socket is created and destroyed
inside some low level function). Well, I'll look into that at some point.
Well, it's going to be at least some months before I'll look into that I
guess, it's probably something I'll do for 4.1. There are also other IPv6
things I could do before, as I wrote earlier today though, I'm a bit
discouraged by some of the problems people are having with getaddrinfo().

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]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Zeev Suraski]

At 20:24 17/4/2001, Wez Furlong wrote:
>On 2001-04-17 17:20:34, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> > How did you implement it?  The main problem with doing this until now was
> > that under Windows, it's pretty much impossible to get a FILE* from a
> > socket.  The right way to implement it would most probably be implementing
> > something similar to C++'s virtual classes, so I'm wondering whether you
> > did it that way...
>
>It's in CVS now - take a look at main/php_streams.h.

Cool - it looks very good!  That's exactly what I meant in the 'something 
similar to C++'s virtual classes' :)

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-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

Wez,

I haven't had much time to go over it but it looks like it's definitely in 
the right direction. I've wanted to see something like this in PHP for a while.
Any chance you can write a small readme file or add some explanations to 
the .h file to give people like me a small overview of the abstraction so 
that it will be easier to start diving into the code?

Thanks,

Andi

At 06:24 PM 4/17/2001 +0100, Wez Furlong wrote:
>On 2001-04-17 17:20:34, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> > How did you implement it?  The main problem with doing this until now was
> > that under Windows, it's pretty much impossible to get a FILE* from a
> > socket.  The right way to implement it would most probably be implementing
> > something similar to C++'s virtual classes, so I'm wondering whether you
> > did it that way...
>
>It's in CVS now - take a look at main/php_streams.h.
>
>It's a bit like implementing our own set of stdio functions and using 
>those rather than the ANSI ones; these call down into the ANSI stdio or 
>fds/sockets (or SSL sockets eventually) as appropriate.
>
>Casting into a FILE* just makes use of fdopen for sockets, or returns the 
>underlying FILE* if there is one.
>
>We can only pass back a FILE* for something really alien if we have 
>fopencookie.
>
>There's no real magic in it :-)
>
>If you can spot problems with this let me know!
>
>--Wez.
>
>
>--
>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-CVS] cvs: php4 / TODO-4.1.txt

[Stig Venaas]

On Tue, Apr 17, 2001 at 05:22:55PM +0100, Wez Furlong wrote:
> I'm on the verge of checking-in my work-so-far (it can be enabled by 
>--enable-php-streams) so that others can try it and comment.  In particular, I would 
>like someone who knows buffers to review the buffering - I've borrowed code from 
>fsock.c but it looks like a memory hog to me, and doesn't allow buffered writes.

And I need this for IPv6 work. I've also been waiting with further IPv6
work since there seems some people have problems with getaddrinfo() which
is used for fopen(). I'm not quite sure how much attention the bug reports
deserves. It's hard to know if it's caused by broken installations bad
implementations on some systems or whatever. Anyway I'm tempted to go on
with the IPv6 implementation anyway, perhaps it's best to do that in 4.1
and leave 4.0 like it is now. Other applications are also starting to use
getaddrinfo() so I expect people will have to fix their setups anyway soon,
or that bad implementations will be fixed and people upgrade. We could of
course have a configure option for turning it on. Switching to getaddrinfo()
is good in other ways too though, the main point perhaps is that it's thread
safe. Hope this made some sense, just some quick thoughts. Would be nice
with some input regarding how important you think IPv6 support is, and how
much breakage we can allow and ideas for how to cope with it.

One thing I'm planning to do RSN, hopefully in 4.0, is persistent LDAP
connections.

Stig
(the other one)

-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Edin Kadribasic]

> At 05:03 17/4/2001, Sterling Hughes wrote:
> >Ok, let me just see if I understand...
> >
> >move everything out of the distribution (from mysql popular extensions
> >like mysql to hardly used ones like qtdom), and then, come release time,
> >package a predefined set of PEAR modules and extensions we want to
package
> >for PHP4.
>
> Not really - some of the extensions will remain in PHP.  I believe that
the
> fact that PHP comes bundled with support for some of the most common Web
> environment applications is still a serious factor in its success.  It did
> get into a situation when there are simply too many not-too-mainstream
> extensions in there, though, which makes it very difficult to find a
stable
> point at time to release it.  I wouldn't expect MySQL, Oracle or XML
> support to be removed from PHP, though.
>
> Zeev

I'm maintaining PHP installation (as well as everything else ) on 10 servers
that run our e-business software. Personally I don't think that perl's cpan
model is the best I've seen so far. Sure, the idea is great but often I end
up spending ours trying to install relatively simple applications,
ReportMagic for example. All those module interdependencies easily turn into
installation nightmare.

I have to agree with Zeev here, that having all the necessary modules in one
distribution is great contributor to PHP's success. How long would it take
and how much hassle would it be to download and install all the modules that
our application needs (sockets, dba, gdbm, ftp, gd, gettext, oci8, readline,
recode, sysvshm, sysvsem, xml, imap, curl & zlib) if all of them needed to
be download separately? Perl's build system promises to automate this, but
in my experience it rarely works as advertised.

So how do you solve the problem when we look at the prospect of having 100+
extensions? I do not have a ready answer for that question. Maybe something
along the lines of Linux kernel distribution, with make menuconfig or
something similar. Or maybe a combined approach where there would be an
option of downloading the whole of PHP including the extensions (like the
Linux kernel) and another where you would have to download only PHP core and
some auto magical script that will let you pick the optional components.

Edin


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Wez Furlong]

On 2001-04-17 17:20:34, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> How did you implement it?  The main problem with doing this until now was 
> that under Windows, it's pretty much impossible to get a FILE* from a 
> socket.  The right way to implement it would most probably be implementing 
> something similar to C++'s virtual classes, so I'm wondering whether you 
> did it that way...

It's in CVS now - take a look at main/php_streams.h.

It's a bit like implementing our own set of stdio functions and using those rather 
than the ANSI ones; these call down into the ANSI stdio or fds/sockets (or SSL sockets 
eventually) as appropriate.

Casting into a FILE* just makes use of fdopen for sockets, or returns the underlying 
FILE* if there is one.

We can only pass back a FILE* for something really alien if we have fopencookie.

There's no real magic in it :-)

If you can spot problems with this let me know!

--Wez.


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Zeev Suraski]

How did you implement it?  The main problem with doing this until now was 
that under Windows, it's pretty much impossible to get a FILE* from a 
socket.  The right way to implement it would most probably be implementing 
something similar to C++'s virtual classes, so I'm wondering whether you 
did it that way...

Zeev

At 19:22 17/4/2001, Wez Furlong wrote:
>On 2001-04-17 16:26:19, "Hartmut Holzgraefe" <[EMAIL PROTECTED]> wrote:
>
> > Wez Furlong wrote:
>
> > > I'm working on a file abstraction for fopen and friends,
>
> > > with the aim of nuking all those issock parameters
>
> > > and paving the way so that I can finally integrate
>
> > > SSL support for those functions.
>
> >
>
> > Would that be something as general as the GLIBC fopen cookies?
>
>
>
>It borrows from that idea, but has to work without them.  It takes 
>advantage of fopen cookies is available by allowing you to "cast" the 
>stream into a FILE* regardless of whether it's an fd, socketd, FILE*, SSL 
>socket, memory based stream or whatever.
>
>
>
>I'm on the verge of checking-in my work-so-far (it can be enabled by 
>--enable-php-streams) so that others can try it and comment.  In 
>particular, I would like someone who knows buffers to review the buffering 
>- I've borrowed code from fsock.c but it looks like a memory hog to me, 
>and doesn't allow buffered writes.
>
>
>
>--Wez

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Wez Furlong]

On 2001-04-17 16:26:19, "Hartmut Holzgraefe" <[EMAIL PROTECTED]> wrote:
> Wez Furlong wrote:
> > I'm working on a file abstraction for fopen and friends, 
> > with the aim of nuking all those issock parameters 
> > and paving the way so that I can finally integrate 
> > SSL support for those functions.
> 
> Would that be something as general as the GLIBC fopen cookies?

It borrows from that idea, but has to work without them.  It takes advantage of fopen 
cookies is available by allowing you to "cast" the stream into a FILE* regardless of 
whether it's an fd, socketd, FILE*, SSL socket, memory based stream or whatever.

I'm on the verge of checking-in my work-so-far (it can be enabled by 
--enable-php-streams) so that others can try it and comment.  In particular, I would 
like someone who knows buffers to review the buffering - I've borrowed code from 
fsock.c but it looks like a memory hog to me, and doesn't allow buffered writes.

--Wez


--
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-CVS] cvs: php4 / TODO-4.1.txt

[Christoph Kassen]

>  Stig Bakken wrote:
> One of the most important changes I suggested for 4.1 was to move
> stuff like the XSLT extension, cURL etc. out of the php4 CVS module
> and into PEAR.  There they can live their own lives, producing stable

In my opinion XML and XSTL modules should be installed by default with every
PHP installation.
XML and XSL/XSTL will become very important in future web-applications and
therefore PHP should not ship without the modules to work efficently with
XML and XSLT.

- cmk





-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Zeev Suraski]

At 06:48 17/4/2001, Sterling Hughes wrote:
>On Tue, 17 Apr 2001, Zeev Suraski wrote:
>
> > At 05:03 17/4/2001, Sterling Hughes wrote:
> > >Ok, let me just see if I understand...
> > >
> > >move everything out of the distribution (from mysql popular extensions
> > >like mysql to hardly used ones like qtdom), and then, come release time,
> > >package a predefined set of PEAR modules and extensions we want to package
> > >for PHP4.
> >
> > Not really - some of the extensions will remain in PHP.  I believe that the
> > fact that PHP comes bundled with support for some of the most common Web
> > environment applications is still a serious factor in its success.  It did
> > get into a situation when there are simply too many not-too-mainstream
> > extensions in there, though, which makes it very difficult to find a stable
> > point at time to release it.  I wouldn't expect MySQL, Oracle or XML
> > support to be removed from PHP, though.
> >
>
>Right, that's not what I'm saying...
>
>I would even suggest that extensions such as the XSLT extension or the
>PostgreSQL extension should be bundled as well (more, just those two as an
>example).
>
>What I meant was that they were taken out of the PHP distribution until a
>release cycle when they are again re-bundled for users to have, so:
>
>4.1.1-dev == No extensions are bundled
>4.1.1 == Take "stable" versions of predefined extensions out of pear and
>bundle with the php distro.

Well, I'm not sure there's any advantage in doing that, and I can see some 
disadvantages...
At any rate, I'd suggest delaying these discussions until the PEAR 
mechanism shows up and matures.  We can make more informed decisions then.

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-CVS] cvs: php4 / TODO-4.1.txt

[Sterling Hughes]

On Tue, 17 Apr 2001, Zeev Suraski wrote:

> At 05:03 17/4/2001, Sterling Hughes wrote:
> >Ok, let me just see if I understand...
> >
> >move everything out of the distribution (from mysql popular extensions
> >like mysql to hardly used ones like qtdom), and then, come release time,
> >package a predefined set of PEAR modules and extensions we want to package
> >for PHP4.
>
> Not really - some of the extensions will remain in PHP.  I believe that the
> fact that PHP comes bundled with support for some of the most common Web
> environment applications is still a serious factor in its success.  It did
> get into a situation when there are simply too many not-too-mainstream
> extensions in there, though, which makes it very difficult to find a stable
> point at time to release it.  I wouldn't expect MySQL, Oracle or XML
> support to be removed from PHP, though.
>

Right, that's not what I'm saying...

I would even suggest that extensions such as the XSLT extension or the
PostgreSQL extension should be bundled as well (more, just those two as an
example).

What I meant was that they were taken out of the PHP distribution until a
release cycle when they are again re-bundled for users to have, so:

4.1.1-dev == No extensions are bundled
4.1.1 == Take "stable" versions of predefined extensions out of pear and
bundle with the php distro.

-Sterling


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Zeev Suraski]

At 05:03 17/4/2001, Sterling Hughes wrote:
>Ok, let me just see if I understand...
>
>move everything out of the distribution (from mysql popular extensions
>like mysql to hardly used ones like qtdom), and then, come release time,
>package a predefined set of PEAR modules and extensions we want to package
>for PHP4.

Not really - some of the extensions will remain in PHP.  I believe that the 
fact that PHP comes bundled with support for some of the most common Web 
environment applications is still a serious factor in its success.  It did 
get into a situation when there are simply too many not-too-mainstream 
extensions in there, though, which makes it very difficult to find a stable 
point at time to release it.  I wouldn't expect MySQL, Oracle or XML 
support to be removed from PHP, though.

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-CVS] cvs: php4 / TODO-4.1.txt

[Hartmut Holzgraefe]

Wez Furlong wrote:
> I'm working on a file abstraction for fopen and friends, 
> with the aim of nuking all those issock parameters 
> and paving the way so that I can finally integrate 
> SSL support for those functions.

Would that be something as general as the GLIBC fopen cookies?

-- 
Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77

-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Stig Sæther Bakken]

["Colin Viebrock" <[EMAIL PROTECTED]>]
> 
> Either the extention you want comes with PHP, or you get it from PEAR.  I
> don't think that's too non-inuitive. :)
> 
> Of course, no matter what we decide, there is nothing to stop people from
> *not* contributing their code into the main PEAR repository.  Not all Perl
> modules are in CPAN.
> 
> Or for starting their own PEAR-ish repository ... PHP Library of Unlisted
> Modules = PLUM ;)

Colin, you're incredible.  Remind me to whack you the next time we
meet :)

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Sterling Hughes]

On 17 Apr 2001, Stig Sæther Bakken wrote:

> [Sterling Hughes <[EMAIL PROTECTED]>]
> > On Sat, 14 Apr 2001, Sebastian Bergmann wrote:
> >
> > > Stig Bakken wrote:
> > > >   Log:
> > > >   here's a preliminary list of stuff for 4.1
> > >
> > >   Is there any timeframe for when PHP 4.1.0 will be released?
> > >
> >
> >I don't know, but I'd like to start a branch for the 4.1.0 code in a
> >week or so (or sooner, that's just when I'll have a use for it).  I've
> >got a bunch of stuff to put in, a new XSLT extension (syntax *will*
> >change, but speed, stability and memory usage are greatly improved, as
> >well as allowing multiple XSLT backends, initial support for
> >Sablotron and libxslt).  I'd also like to put the ADT stuff in 4.1
> >(nearing completion, still have to work up a good proposal).  There are
> >also some changes in cURL which don't really change the API but would
> >be good to announce along with 4.1 (persistent connections)...  That's
> >just my stuff (I think I have a bit more for 4.1 too :)...
> >
> >I have a feeling from the todo that other people have a bunch of
> >patches or things "todo" for 4.1 as well.  Therefore I think setting up
> >a branch at this time or pretty soon would be a good idea.  That way we
> >can start preparing for and stabilizing 4.1.
>
> One of the most important changes I suggested for 4.1 was to move
> stuff like the XSLT extension, cURL etc. out of the php4 CVS module
> and into PEAR.  There they can live their own lives, producing stable
> output now and again.  The PHP distribution bundles the latest stable
> release from each extension/package we want to bundle, but until then
> they are completely separate from PHP itself.
>

Ok, let me just see if I understand...

move everything out of the distribution (from mysql popular extensions
like mysql to hardly used ones like qtdom), and then, come release time,
package a predefined set of PEAR modules and extensions we want to package
for PHP4.

1
;)

> I don't see 4.1 happening if we have to keep coordinating the TODO
> lists of 80 extensions.
>

I'd agree with that.

-Sterling


--
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-CVS] cvs: php4 / TODO-4.1.txt

[Andrei Zmievski]

At 05:33 AM 4/17/01 -0400, Stig Sæther Bakken wrote:
>I don't see 4.1 happening if we have to keep coordinating the TODO
>lists of 80 extensions.

Yep, the main reason I didn't want to add php-gtk to the default PHP dist.

-Andrei


--
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-CVS] cvs: php4 / TODO-4.1.txt

[Stig Sæther Bakken]

["Wez Furlong" <[EMAIL PROTECTED]>]
> On 2001-04-16 00:09:05, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> > here.  Generally, the main differences we came up with so far are (as per 
> > Stig):
> > - Move most of the non-popular extensions out of the release and into PEAR 
> > (requires lots of PEAR work to be made)
> > - Always build the CGI
> > - No language-level (i.e. Zend Engine) changes scheduled for this release 
> > at this time
> 
> I'm working on a file abstraction for fopen and friends, with the
> aim of nuking all those issock parameters and paving the way so that
> I can finally integrate SSL support for those functions.
> 
> It would make sense for it to appear in PHP 4.1.

+++1

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Stig Sæther Bakken]

[Sebastian Bergmann <[EMAIL PROTECTED]>]
> Sterling Hughes wrote:
> > got a bunch of stuff to put in, a new XSLT extension (syntax *will*
> > change, but speed, stability and memory usage are greatly improved, 
> > as well as allowing multiple XSLT backends, initial support for 
> > Sablotron and libxslt).
> 
>   Sounds good.
> 
> > I'd also like to put the ADT stuff in 4.1 (nearing completion, still 
> > have to work up a good proposal).
> 
>   This is good news! I can't wait to get my hands on your ADT stuff,
> Sterling.
> 
> > a branch at this time or pretty soon would be a good idea. That way 
> > we can start preparing for and stabilizing 4.1.
> 
>   +1
> 
>   PS: What changes to the ZendEngine could be done for a 4.1 release?
> No, I'm not starting another ApplicationServer debate, but during the
> last one there were a couple of good ideas that should be considerd,
> IMHO.

IMHO, we should not go out looking for things to change in Zend (that
would more or less be Zeev and Andi's decision anyway).  Please let's
try to keep the TODO-4.1 list short. :-)

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Stig Sæther Bakken]

[Sterling Hughes <[EMAIL PROTECTED]>]
> On Sat, 14 Apr 2001, Sebastian Bergmann wrote:
> 
> > Stig Bakken wrote:
> > >   Log:
> > >   here's a preliminary list of stuff for 4.1
> >
> >   Is there any timeframe for when PHP 4.1.0 will be released?
> >
> 
>I don't know, but I'd like to start a branch for the 4.1.0 code in a
>week or so (or sooner, that's just when I'll have a use for it).  I've
>got a bunch of stuff to put in, a new XSLT extension (syntax *will*
>change, but speed, stability and memory usage are greatly improved, as
>well as allowing multiple XSLT backends, initial support for
>Sablotron and libxslt).  I'd also like to put the ADT stuff in 4.1
>(nearing completion, still have to work up a good proposal).  There are
>also some changes in cURL which don't really change the API but would
>be good to announce along with 4.1 (persistent connections)...  That's
>just my stuff (I think I have a bit more for 4.1 too :)...
> 
>I have a feeling from the todo that other people have a bunch of
>patches or things "todo" for 4.1 as well.  Therefore I think setting up
>a branch at this time or pretty soon would be a good idea.  That way we
>can start preparing for and stabilizing 4.1.

One of the most important changes I suggested for 4.1 was to move
stuff like the XSLT extension, cURL etc. out of the php4 CVS module
and into PEAR.  There they can live their own lives, producing stable
output now and again.  The PHP distribution bundles the latest stable
release from each extension/package we want to bundle, but until then
they are completely separate from PHP itself.

I don't see 4.1 happening if we have to keep coordinating the TODO
lists of 80 extensions.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Stig Sæther Bakken]

[Sebastian Bergmann <[EMAIL PROTECTED]>]
> Stig Bakken wrote:
> >   Log:
> >   here's a preliminary list of stuff for 4.1
> 
>   Is there any timeframe for when PHP 4.1.0 will be released?

First we figure out what 4.1 should be, the we can start thinking
about timeframes.  PHP has an excellent track record of never sticking
to such timeframes though.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Colin Viebrock]

> I think my main point is valid though. Placing popular extensions in one
> place and unpopular ones in another draws an arbitrary line in the sand
> which makes it impossible to intuitively guess where things should be. The
> only way for this to be handled elegantly is for all extensions to live in
> the same place.

Either the extention you want comes with PHP, or you get it from PEAR.  I
don't think that's too non-inuitive. :)

Of course, no matter what we decide, there is nothing to stop people from
*not* contributing their code into the main PEAR repository.  Not all Perl
modules are in CPAN.

Or for starting their own PEAR-ish repository ... PHP Library of Unlisted
Modules = PLUM ;)

So no matter what some non-intuitiveness will eventually creep in.  I just
think that'll be a by-product of PHP becoming so popular.

- Colin


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Phil Driscoll]

Sterling wrote:

>Well, I don't know how valid that argument (dialup) really is.  I
>currently use a dial up connection (56k) and I'm fine with php (it takes
>at most 20 minutes to download and I can do other things while php is
>downloading).

For sure it's an argument that gets weaker as time goes on and bandwidths
increase :)

I think my main point is valid though. Placing popular extensions in one
place and unpopular ones in another draws an arbitrary line in the sand
which makes it impossible to intuitively guess where things should be. The
only way for this to be handled elegantly is for all extensions to live in
the same place.

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Sterling Hughes]

On Mon, 16 Apr 2001, Anil Madhavapeddy wrote:

> > ALL extensions are in PEAR, and a download tool allows easy
> > selection of extensions, perhaps with a 'most common options'
> > button to include the favourite extensions.
>
> Also, if you put most of the extensions into PEAR initially, it would be
> easy to monitor the download statistics to find the most popular ones,
> and integrate them into core PHP from that point.
>

I wouldn't do that with *all* the extensions, some we already no are
popular just by the amount of people asking questions and having problems
with them (ie, MySQL, XML, OCI to name a few).

-Sterling


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Sterling Hughes]

On Mon, 16 Apr 2001, Phil Driscoll wrote:

> The business of moving extensions to PEAR appeals to me as I think that PHP
> currently feels too big - especially from the point of view of the potential
> new user with a dial up connection, who may well look elsewhere for
> something smaller. However, I think the idea of moving some extensions to
> PEAR and leaving others alone will produce a situation where 'knowing' where
> to find an extension is not intuitive.
>

Well, I don't know how valid that argument (dialup) really is.  I
currently use a dial up connection (56k) and I'm fine with php (it takes
at most 20 minutes to download and I can do other things while php is
downloading).

> The two solutions to this which spring to mind are:
>
> ALL extensions are in PEAR, and a download tool allows easy selection of
> extensions, perhaps with a 'most common options' button to include the
> favourite extensions.
>

I think this would be a unfavorable solution, since one of PHP's main
advantages to new users is they don't have to go looking somewhere else
for all of their extensions.  Offering a full download and a selector tool
might be a nice option though.


> As above except that the most common extensions are somehow promoted fom
> being extensions into the core of PHP.
>

I don't see the point of this.  That's simply a move from

ext/extname
to
ext/standard/extname

...

-Sterling



-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Sterling Hughes]

On Mon, 16 Apr 2001, Alexander Bokovoy wrote:

> On Sun, Apr 15, 2001 at 08:00:42AM -0400, Sterling Hughes wrote:
> > On Mon, 16 Apr 2001, Zeev Suraski wrote:
> >
> > > We need to do some thinking about this 4.1 business, before we actually do
> > > anything.  Please don't branch anything at this point - we've had a fairly
> > > bad experience with premature branching with PHP 3.1.
> > >
> > don't worry, I wasn't planning on creating the branch :)
> >
> > > We need to get a clear understanding of what's going to be the main changes
> > > in PHP 4.1, and then shift 99% of the development to it.  We've been
> > > discussing this in the group@ forum, and should now move the discussion
> > > here.  Generally, the main differences we came up with so far are (as per
> > > Stig):
> > > - Move most of the non-popular extensions out of the release and into PEAR
> > > (requires lots of PEAR work to be made)
> >
> > definetly :)
> >
> > deciding which extensions are non-popular should be, uh, fun. :)))
> One possible way to determine it is to run poll on php.net sites (as well
> as zend.com ones) where people could select extensions
> 1) they are working with;
> 2) they are planning to use when they'll be more stable;
> 3) they are considering important supporting for PHP itself as well;
>
> These three positions will provide enough info to select important
> extensions, to see 'most wanted' from new stuff. #3 is a check point poll
> which will allow to make possible errors and personal preferences lower.

I was also thinking of this, but as Zeev mentioned these are easily
spoofed and really don't carry more than interest value (we only reach a
certain portion of our audience, people who answer may represent 1% of our
market, etc.)

-Sterling


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Anil Madhavapeddy]

> ALL extensions are in PEAR, and a download tool allows easy
> selection of extensions, perhaps with a 'most common options'
> button to include the favourite extensions.

Also, if you put most of the extensions into PEAR initially, it would be
easy to monitor the download statistics to find the most popular ones,
and integrate them into core PHP from that point.

Anil


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Wez Furlong]

On 2001-04-16 00:09:05, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> here.  Generally, the main differences we came up with so far are (as per 
> Stig):
> - Move most of the non-popular extensions out of the release and into PEAR 
> (requires lots of PEAR work to be made)
> - Always build the CGI
> - No language-level (i.e. Zend Engine) changes scheduled for this release 
> at this time

I'm working on a file abstraction for fopen and friends, with the aim of nuking all 
those issock parameters and paving the way so that I can finally integrate SSL support 
for those functions.

It would make sense for it to appear in PHP 4.1.

--Wez.


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Phil Driscoll]

The business of moving extensions to PEAR appeals to me as I think that PHP
currently feels too big - especially from the point of view of the potential
new user with a dial up connection, who may well look elsewhere for
something smaller. However, I think the idea of moving some extensions to
PEAR and leaving others alone will produce a situation where 'knowing' where
to find an extension is not intuitive.

The two solutions to this which spring to mind are:

ALL extensions are in PEAR, and a download tool allows easy selection of
extensions, perhaps with a 'most common options' button to include the
favourite extensions.

As above except that the most common extensions are somehow promoted fom
being extensions into the core of PHP.

Maybe neither of these are ideal, but I just think we need to make sure that
whatever happens in logical and intuitive.

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Zeev Suraski]

At 10:10 16/4/2001, Alexander Bokovoy wrote:
>One possible way to determine it is to run poll on php.net sites (as well
>as zend.com ones) where people could select extensions

The main problem with this approach is that such polls can very easily and 
usually are manipulated...

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-CVS] cvs: php4 / TODO-4.1.txt

[Alexander Bokovoy]

On Sun, Apr 15, 2001 at 08:00:42AM -0400, Sterling Hughes wrote:
> On Mon, 16 Apr 2001, Zeev Suraski wrote:
> 
> > We need to do some thinking about this 4.1 business, before we actually do
> > anything.  Please don't branch anything at this point - we've had a fairly
> > bad experience with premature branching with PHP 3.1.
> >
> don't worry, I wasn't planning on creating the branch :)
> 
> > We need to get a clear understanding of what's going to be the main changes
> > in PHP 4.1, and then shift 99% of the development to it.  We've been
> > discussing this in the group@ forum, and should now move the discussion
> > here.  Generally, the main differences we came up with so far are (as per
> > Stig):
> > - Move most of the non-popular extensions out of the release and into PEAR
> > (requires lots of PEAR work to be made)
> 
> definetly :)
> 
> deciding which extensions are non-popular should be, uh, fun. :)))
One possible way to determine it is to run poll on php.net sites (as well
as zend.com ones) where people could select extensions 
1) they are working with;
2) they are planning to use when they'll be more stable;
3) they are considering important supporting for PHP itself as well;

These three positions will provide enough info to select important
extensions, to see 'most wanted' from new stuff. #3 is a check point poll
which will allow to make possible errors and personal preferences lower.


-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project| ALT  Linux  Team | Minsk Linux Users Group
 www.midgard-project.org | www.altlinux.ru  |www.minsk-lug.net 
-- You won't skid if you stay in a rut.
-- Frank Hubbard

-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Sterling Hughes]

On Mon, 16 Apr 2001, Zeev Suraski wrote:

> We need to do some thinking about this 4.1 business, before we actually do
> anything.  Please don't branch anything at this point - we've had a fairly
> bad experience with premature branching with PHP 3.1.
>
don't worry, I wasn't planning on creating the branch :)

> We need to get a clear understanding of what's going to be the main changes
> in PHP 4.1, and then shift 99% of the development to it.  We've been
> discussing this in the group@ forum, and should now move the discussion
> here.  Generally, the main differences we came up with so far are (as per
> Stig):
> - Move most of the non-popular extensions out of the release and into PEAR
> (requires lots of PEAR work to be made)

definetly :)

deciding which extensions are non-popular should be, uh, fun. :)))

> - Always build the CGI
> - No language-level (i.e. Zend Engine) changes scheduled for this release
> at this time
>
> In my opinion, we shouldn't do anything on the repository level until the
> new PEAR services are in place.  If we do, we're going to shoot ourselves
> in the foot - we won't be able to release 4.1, and we won't really have an
> updated CVS to release 4.0.x from.  It's probably premature to branch at
> this time.
>

I'd agree with that.

I think 4.1 is also when we were planning on implementing the naming
conventions for the functions (breaking compat).

> In my opinion #2, the changes you mentioned aren't necessarily something
> that belongs in 4.1 - they can easily find themselves in 4.0 (you can add
> the new XSLT stuff under a different extension, for instance).  That's just
> my opinion though - you can wait :)
>

definetly.  just saying when the 4.1 branch would be usable for me. ;)

-Sterling


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Zeev Suraski]

We need to do some thinking about this 4.1 business, before we actually do 
anything.  Please don't branch anything at this point - we've had a fairly 
bad experience with premature branching with PHP 3.1.

We need to get a clear understanding of what's going to be the main changes 
in PHP 4.1, and then shift 99% of the development to it.  We've been 
discussing this in the group@ forum, and should now move the discussion 
here.  Generally, the main differences we came up with so far are (as per 
Stig):
- Move most of the non-popular extensions out of the release and into PEAR 
(requires lots of PEAR work to be made)
- Always build the CGI
- No language-level (i.e. Zend Engine) changes scheduled for this release 
at this time

In my opinion, we shouldn't do anything on the repository level until the 
new PEAR services are in place.  If we do, we're going to shoot ourselves 
in the foot - we won't be able to release 4.1, and we won't really have an 
updated CVS to release 4.0.x from.  It's probably premature to branch at 
this time.

In my opinion #2, the changes you mentioned aren't necessarily something 
that belongs in 4.1 - they can easily find themselves in 4.0 (you can add 
the new XSLT stuff under a different extension, for instance).  That's just 
my opinion though - you can wait :)

Zeev

At 05:10 14/4/2001, Sterling Hughes wrote:
>On Sat, 14 Apr 2001, Sebastian Bergmann wrote:
>
> > Stig Bakken wrote:
> > >   Log:
> > >   here's a preliminary list of stuff for 4.1
> >
> >   Is there any timeframe for when PHP 4.1.0 will be released?
> >
>
>I don't know, but I'd like to start a branch for the 4.1.0 code in a
>week or so (or sooner, that's just when I'll have a use for it).  I've
>got a bunch of stuff to put in, a new XSLT extension (syntax *will*
>change, but speed, stability and memory usage are greatly improved, as
>well as allowing multiple XSLT backends, initial support for
>Sablotron and libxslt).  I'd also like to put the ADT stuff in 4.1
>(nearing completion, still have to work up a good proposal).  There are
>also some changes in cURL which don't really change the API but would
>be good to announce along with 4.1 (persistent connections)...  That's
>just my stuff (I think I have a bit more for 4.1 too :)...
>
>I have a feeling from the todo that other people have a bunch of
>patches or things "todo" for 4.1 as well.  Therefore I think setting up
>a branch at this time or pretty soon would be a good idea.  That way we
>can start preparing for and stabilizing 4.1.
>
>-Sterling
>
>
>--
>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]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Sterling Hughes]

On Sun, 15 Apr 2001, Jon Parise wrote:

> On Sat, Apr 14, 2001 at 03:04:19PM -0400, Sterling Hughes wrote:
>
> > > In our model, we start branches for releases and keep working on the main
> > > trunk.
> >
> >   I think that's in general a good plan.  But I'm loath to commit stuff
> >   that will break a minor release (and I think there should be a few more
> >   minor releases before 4.1, even if its just bug fixes).  That's why I
> >   would suggest for this case a branch might be appropriate, that way work
> >   and testing, etc. can go on for 4.1 even while minor releases are being
> >   worked on.
>
> That's pretty much what he was saying.  Instead of creating a 4.1
> branch for new development, we create a new 4.0 branch off of the
> current trunk for minor releases.  Additional RC branches can be made
> off of that 4.0 branch for QA testing.  The main trunk ('HEAD') will
> be for the latest development.
>
> Diagrammatically:
>
>
> (now)- 4.1.0-cvs
> \
>  ` 4.0.8-cvs
> \ \
>  ` 4.0.6   ` 4.0.7
>
>

Ahh, ok, thanks, that makes sense.

-Sterling


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Jon Parise]

On Sat, Apr 14, 2001 at 03:04:19PM -0400, Sterling Hughes wrote:

> > In our model, we start branches for releases and keep working on the main
> > trunk.
> 
>   I think that's in general a good plan.  But I'm loath to commit stuff
>   that will break a minor release (and I think there should be a few more
>   minor releases before 4.1, even if its just bug fixes).  That's why I
>   would suggest for this case a branch might be appropriate, that way work
>   and testing, etc. can go on for 4.1 even while minor releases are being
>   worked on.
 
That's pretty much what he was saying.  Instead of creating a 4.1
branch for new development, we create a new 4.0 branch off of the
current trunk for minor releases.  Additional RC branches can be made
off of that 4.0 branch for QA testing.  The main trunk ('HEAD') will
be for the latest development.

Diagrammatically:


(now)- 4.1.0-cvs
\
 ` 4.0.8-cvs
\ \
 ` 4.0.6   ` 4.0.7

-- 
Jon Parise ([EMAIL PROTECTED])  .  Rochester Inst. of Technology
http://www.csh.rit.edu/~jon/  :  Computer Science House Member

-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Sterling Hughes]

On Sat, 14 Apr 2001, Andrei Zmievski wrote:

> At 10:10 PM 4/13/01 -0400, you wrote:
> >I don't know, but I'd like to start a branch for the 4.1.0 code in a
> >week or so (or sooner, that's just when I'll have a use for it).  I've
>
> In our model, we start branches for releases and keep working on the main
> trunk.
>

  I think that's in general a good plan.  But I'm loath to commit stuff
  that will break a minor release (and I think there should be a few more
  minor releases before 4.1, even if its just bug fixes).  That's why I
  would suggest for this case a branch might be appropriate, that way work
  and testing, etc. can go on for 4.1 even while minor releases are being
  worked on.

  -Sterling


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Anil Madhavapeddy]

> Right, so the 4.0.* code would branch off and the HEAD
> revision would become the 4.1.0 (development) tree.

Exactly - you can branch down from a branch as well, so there's no
problem creating further RC branches from the 4.0.* branches.  If you
re-read that sentence, it'll make sense :-)

Anil


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Jon Parise]

On Sat, Apr 14, 2001 at 12:00:20PM -0500, Andrei Zmievski wrote:

> >I don't know, but I'd like to start a branch for the 4.1.0 code in a
> >week or so (or sooner, that's just when I'll have a use for it).  I've
> 
> In our model, we start branches for releases and keep working on the main 
> trunk.
 
Right, so the 4.0.* code would branch off and the HEAD revision would
become the 4.1.0 (development) tree.

-- 
Jon Parise ([EMAIL PROTECTED])  .  Rochester Inst. of Technology
http://www.csh.rit.edu/~jon/  :  Computer Science House Member

-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Andrei Zmievski]

At 10:10 PM 4/13/01 -0400, you wrote:
>I don't know, but I'd like to start a branch for the 4.1.0 code in a
>week or so (or sooner, that's just when I'll have a use for it).  I've

In our model, we start branches for releases and keep working on the main 
trunk.

-Andrei


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Sebastian Bergmann]

Sterling Hughes wrote:
> got a bunch of stuff to put in, a new XSLT extension (syntax *will*
> change, but speed, stability and memory usage are greatly improved, 
> as well as allowing multiple XSLT backends, initial support for 
> Sablotron and libxslt).

  Sounds good.

> I'd also like to put the ADT stuff in 4.1 (nearing completion, still 
> have to work up a good proposal).

  This is good news! I can't wait to get my hands on your ADT stuff,
Sterling.

> a branch at this time or pretty soon would be a good idea. That way 
> we can start preparing for and stabilizing 4.1.

  +1

  PS: What changes to the ZendEngine could be done for a 4.1 release?
No, I'm not starting another ApplicationServer debate, but during the
last one there were a couple of good ideas that should be considerd,
IMHO.

  Happy Easter,
Sebastian

-- 
 sebastian bergmann[EMAIL PROTECTED]
   http://www.sebastian-bergmann.de

 bonn.phpug.de | www.php.net | www.phpOpenTracker.de | www.titanchat.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]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Sterling Hughes]

On Sat, 14 Apr 2001, Sebastian Bergmann wrote:

> Stig Bakken wrote:
> >   Log:
> >   here's a preliminary list of stuff for 4.1
>
>   Is there any timeframe for when PHP 4.1.0 will be released?
>

   I don't know, but I'd like to start a branch for the 4.1.0 code in a
   week or so (or sooner, that's just when I'll have a use for it).  I've
   got a bunch of stuff to put in, a new XSLT extension (syntax *will*
   change, but speed, stability and memory usage are greatly improved, as
   well as allowing multiple XSLT backends, initial support for
   Sablotron and libxslt).  I'd also like to put the ADT stuff in 4.1
   (nearing completion, still have to work up a good proposal).  There are
   also some changes in cURL which don't really change the API but would
   be good to announce along with 4.1 (persistent connections)...  That's
   just my stuff (I think I have a bit more for 4.1 too :)...

   I have a feeling from the todo that other people have a bunch of
   patches or things "todo" for 4.1 as well.  Therefore I think setting up
   a branch at this time or pretty soon would be a good idea.  That way we
   can start preparing for and stabilizing 4.1.

   -Sterling


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[James Moore]

> Stig Bakken wrote:
> >   Log:
> >   here's a preliminary list of stuff for 4.1
>
>   Is there any timeframe for when PHP 4.1.0 will be released?
>
>   PS: When will PHP 4.0.5 be released? :)

Well im not happy with the current state of some bugs in HTTP_AUTH section
and waiting for a reply from Rasmus on this issue then we can have yet
another final RC and release it hopefully.

- James


-- 
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]