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
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
[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
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
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
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
"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
[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
["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
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 -
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
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
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,
["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.
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
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
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
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
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.
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
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
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
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
[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
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
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
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
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
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
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
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
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 -
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
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
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
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
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
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
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,
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
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 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
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
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? :)
--
sebastian bergmann[EMAIL PROTECTED]
44 matches
Mail list logo