Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt
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 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] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4/ TODO-4.1.txt
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 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
[Andi Gutmans [EMAIL PROTECTED]] At 06:53 PM 4/18/2001 -0400, Stig Sther 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 Sther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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
At 08:03 AM 4/19/2001 -0400, Stig Sther Bakken wrote: [Andi Gutmans [EMAIL PROTECTED]] At 06:53 PM 4/18/2001 -0400, Stig Sther 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 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] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt
At 08:13 AM 4/19/2001 -0400, Stig Sther 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 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
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 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
"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 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 [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 Sther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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
["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 Sther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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
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 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] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4/ TODO-4.1.txt
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 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] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt
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 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
At 05:33 AM 4/17/01 -0400, Stig Sther 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 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
["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 Sther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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
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 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
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 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
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 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
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 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
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 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
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 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
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 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
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 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
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 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
[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 Sther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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
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 Sther 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 Sther 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 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
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 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
At 01:22 18/4/2001, Stig Sther 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 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
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 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
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 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
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 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
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 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
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 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
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 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
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 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
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 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
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 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
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 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
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 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
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 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] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- 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
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 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
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 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
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 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
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 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]
