At 00:01 02/07/2003, Jason Greene wrote:
If too many files in a dir became a problem, directory hashing could
easily be implemented into the file based handler.
Too late, it's already in there for a few years :)
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: h
i dont know why this is just showing up (i sent it at least a day ago), but
Moriyoshi has already identified the issue and possible solution. See the
thread "Registering constants to internal classes (ZE2)"
l0t3k
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: h
i have a ZE2 OO extension which declares class constants as follows :
void
register_class_long_constant_ex(zend_class_entry * ce, char *key,
uint key_len, long lval)
{
zval *tmp;
MAKE_STD_ZVAL(tmp);
ZVAL_LONG(tmp, lval);
zend_hash_update(&(ce)->constants_table, key, key_len,
Hey,
Bug 24441 (http://bugs.php.net/bug.php?id=24441), displays the following
problem:
array, array($this, 'filter'));
}
function filter ($value) {
return preg_match("/{$this->filter}/i", $value);
}
}
$t = new test;
var_dump($t->filter('hello world'));
?>
Marcus Boerger wrote:
> --SKIPIF--
> needed'); ?>
Do we still need those SKIPIF conditions?
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
--
PHP Internals - PHP Runti
I'll apply this tomorrow if no one beats me to it.
On Tuesday, July 1, 2003, at 11:34 PM, Timm Friebe wrote:
On Wed, 2003-07-02 at 05:32, Timm Friebe wrote:
[...]
This should now be the final patch.
Then again, it would help to attach it:)
- Timm
-- George Schlossnagle
-- Principal Consultant
On Wed, 2003-07-02 at 05:32, Timm Friebe wrote:
[...]
> This should now be the final patch.
Then again, it would help to attach it:)
- Timm
Index: Zend/zend_reflection_api.c
===
RCS file: /repository/ZendEngine2/zend_reflection_api.c
On Wed, 2003-07-02 at 02:17, Timm Friebe wrote:
> On Wed, 2003-07-02 at 00:23, Timm Friebe wrote:
> > On Tue, 2003-07-01 at 23:36, George Schlossnagle wrote:
> > > Csn you make your diff of current cvs? I committed a good bit of your
> > > previous patch.
> > Yup, you'll find it attached.
This s
On Wed, 2003-07-02 at 03:06, George Schlossnagle wrote:
> I don't see how that could work with inherited methods
You mean a constellation like this:
class Base {
public function inbase() {
}
}
class AParent extends Base {
}
class Child extends AParent {
}
$class
I don't see how that could work with inherited methods
On Tuesday, July 1, 2003, at 08:53 PM, Timm Friebe wrote:
On Wed, 2003-07-02 at 02:44, George Schlossnagle wrote:
[...]
It needs the class entry too to really have context. At least thats
how my implementation was working.
Hrm, AFAIK fu
On Wed, 2003-07-02 at 02:44, George Schlossnagle wrote:
[...]
> It needs the class entry too to really have context. At least thats
> how my implementation was working.
Hrm, AFAIK function_ptr->common.scope == .
- Ti "works for me" mm:)
--
PHP Internals - PHP Runtime Development Mailing Lis
On Tuesday, July 1, 2003, at 06:23 PM, Timm Friebe wrote:
On Tue, 2003-07-01 at 23:36, George Schlossnagle wrote:
Csn you make your diff of current cvs? I committed a good bit of your
previous patch.
Yup, you'll find it attached.
cool.
I don't know if i dig the way you implemented reflection_m
I have been staying out of this discussion because everyone has really
been making my points for me. I think SQLite sessions are a good
alternative to what we have now in some situations, and I'd like to see
them in PHP5 for the same reasons as Marcus Wez and Sascha. This isn't
the huge disaster y
It did, but he just wasn't listening ;)
Then I had a meal, watched a film etc.
> > Wez explained to me a real world usage (over IRC).
>
> Could not that have happened a couple of hours earlier? :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.ph
Nay: George
On Tuesday, July 1, 2003, at 08:17 PM, Sascha Schumann wrote:
Tallied votes so far.
Yay: Sterling
Nay: John, Marcus, Wez, Sascha
Abstain: Jani
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-
On Wed, 1 Jul 2003, Sterling Hughes wrote:
> Wez explained to me a real world usage (over IRC).
Could not that have happened a couple of hours earlier? :)
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Wez explained to me a real world usage (over IRC). I still think its a
terrible idea, but I'll drop it .
-Sterling
On Tue, 2003-07-01 at 20:17, Sascha Schumann wrote:
> Tallied votes so far.
>
> Yay: Sterling
> Nay: John, Marcus, Wez, Sascha
> Abstain: Jani
>
> - Sascha
--
On Tue, 2003-07-01 at 20:17, Sascha Schumann wrote:
> Tallied votes so far.
>
> Yay: Sterling
> Nay: John, Marcus, Wez, Sascha
> Abstain: Jani
- John
He hasn't given his opinion in this thread.
-Sterling
>
> - Sascha
--
"Programming today is a race between software enginee
Tallied votes so far.
Yay: Sterling
Nay: John, Marcus, Wez, Sascha
Abstain: Jani
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 2003-07-02 at 00:23, Timm Friebe wrote:
> On Tue, 2003-07-01 at 23:36, George Schlossnagle wrote:
> > Csn you make your diff of current cvs? I committed a good bit of your
> > previous patch.
> Yup, you'll find it attached.
Changelog:
-
Hello Sascha,
Wednesday, July 2, 2003, 1:59:29 AM, you wrote:
SS> Sterling,
SS> you have obviously made up your mind already, so arguing is
SS> moot. Let's have a quick vote and move on.
SS> Pro removing:
SS> Con removing: Sascha
I guess it's 'not the best idea ever'. But
Hello Marcus,
Monday, June 30, 2003, 2:28:35 AM, you wrote:
MB> - Fix static class members. If the are public they need to be accessible from
MB> outside the class. If they have an initial value this value should be used
MB> and the keyword var should be working as well.
MB> php -r 'class t
Btw, the quickest way would be for you to give me a real world usage -
Happen to have any on your mind?
-Sterling
On Tue, 2003-07-01 at 19:59, Sascha Schumann wrote:
> Sterling,
>
> you have obviously made up your mind already, so arguing is
> moot. Let's have a quick vote and move
On Tue, 2003-07-01 at 19:59, Sascha Schumann wrote:
> Sterling,
>
> you have obviously made up your mind already, so arguing is
> moot. Let's have a quick vote and move on.
>
> Pro removing: Sterling
> Con removing: Sascha
>
> - Sascha
--
"Science is like sex: sometime
On Tue, 2003-07-01 at 19:51, Wez Furlong wrote:
> What is the point of publishing a benchmark if you are not comparing an SQL
> data store with an SQL data store?
Speaking of bullshit comparisons :)
One is a client/server architecture, the other is a direct disk access
architecture. Using an RDB
Sterling,
you have obviously made up your mind already, so arguing is
moot. Let's have a quick vote and move on.
Pro removing:
Con removing: Sascha
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
- Original Message -
From: "Sterling Hughes" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, July 01, 2003 9:51 PM
Subject: Re: [PHP-DEV] Removing SQLite sessions from the defaultdistribution
> > 4) Marginally more secure then plain files
>
> Not at all
- Original Message -
From: "Sterling Hughes" <[EMAIL PROTECTED]>
To: "George Schlossnagle" <[EMAIL PROTECTED]>
Cc: "Wez Furlong" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Sascha
Schumann" <[EMAIL PROTECTED]>
Sent: Tuesday, July 01, 2003 9:19 PM
Subject: Re: [PHP-DEV] Removing SQLite sessi
On Tue, 2003-07-01 at 19:45, Sascha Schumann wrote:
> Having a SQL session storage module in the default
> distribution is a good learning example for other storage
> module authors. I don't see any necessity to remove this
> particular piece of code based on the assessment that it
What is the point of publishing a benchmark if you are not comparing an SQL
data store with an SQL data store?
> I will commit my fixes, if the decision is to bundle sqlite. Or someone
> is interested in trying it out in the interim.
Commit it.
> Also note, this would mean that all
> shared hos
Having a SQL session storage module in the default
distribution is a good learning example for other storage
module authors. I don't see any necessity to remove this
particular piece of code based on the assessment that it
does not outperform simple file access on Linux. SQLit
Not to reply to myself, however, one thing I have not heard this time is
a real world usage of this functionality. One case where "you" (ie,
someone on the list) would extract a benefit from using the SQLite
backend. Give me a problem that using SQLite as a *generic* session
backend will solve yo
Hello Marcus,
Wednesday, July 2, 2003, 1:13:11 AM, you wrote:
MB> Hello Marcus,
MB> Wednesday, July 2, 2003, 12:54:12 AM, you wrote:
MB>> Hello Marcus,
MB>> Monday, June 30, 2003, 2:28:35 AM, you wrote:
MB>>> - Fix __clone() visibility. When implementing singletons we must forbid calling
MB>>
Hello Marcus,
Wednesday, July 2, 2003, 12:54:12 AM, you wrote:
MB> Hello Marcus,
MB> Monday, June 30, 2003, 2:28:35 AM, you wrote:
MB>> - Fix __clone() visibility. When implementing singletons we must forbid calling
MB>> __clone() by making it private (private function __clone() is the same t
Hello Marcus,
Monday, June 30, 2003, 2:28:35 AM, you wrote:
MB> - Include SPL (forach/array hooking).
I tested the current patch:
http://marcus-boerger.de/php/ext/ze2/ze2-spl-20030701.diff.tgz
and profiled it again. What i did (in case someone doesn't know yet) was to
read 10 rows
Hello Marcus,
Monday, June 30, 2003, 2:28:35 AM, you wrote:
MB> - Fix __clone() visibility. When implementing singletons we must forbid calling
MB> __clone() by making it private (private function __clone() is the same to
MB> singletons as private function __construct() to factories). Also t
On Tue, 2003-07-01 at 23:36, George Schlossnagle wrote:
> Csn you make your diff of current cvs? I committed a good bit of your
> previous patch.
Yup, you'll find it attached.
> I don't know if i dig the way you implemented reflection_method. I
> have some partially complete work that handles
On July 1, 2003 04:51 pm, Sterling Hughes wrote:
> So of course we should just say 'screw performance' :) Again, if it
> were useful, I would say "yes, totally." 100% and bucket o' bits. But
> it doesn't give you anything, and it can be in PEAR/PECL for those who
> really want it.
No, I certain
Csn you make your diff of current cvs? I committed a good bit of your
previous patch.
I don't know if i dig the way you implemented reflection_method. I
have some partially complete work that handles this in a manner more
consistent with the rest of the code.
George
On Tuesday, July 1, 2003
[EMAIL PROTECTED] (Marcus Börger) wrote:
> Anyway, you need to provide a patch to let us see and test.
Well, I've wanted more feedbacks regarding this issue as it can
well be a drastic change, and a few more engine guys would show interests
than in stuff like i18n... Leave this task to me then.
On Tue, 2003-07-01 at 20:27, Timm Friebe wrote:
> Hello,
> I went ahead and spent some time on the new reflection API. A patch (778
> lines:)) and a demo script are attached.
More to come:
-
- Added some necessary efree()'s before
Hello Moriyoshi,
Tuesday, July 1, 2003, 8:08:04 PM, you wrote:
MK> Hi Marcus,
MK> [EMAIL PROTECTED] (Marcus Börger) wrote:
>> Hello Moriyoshi,
>>
>> to me that sounds good.
MK> Actually I wasn't asking people to say aye or nay.. :) and at this moment
MK> I've got no ZE karma either. BTW I fo
Jason Greene wrote:
Is not a hard cross to bear, and considering that sqlite enabled
sessions should be avoided in the first place, I think its a bad idea to
include them by default.
I still can not see a functionality difference. As to performance, I
think it is obvious that file based sessions ar
On Tue, 2003-07-01 at 16:56, Ilia Alshanetsky wrote:
> >From a performance standpoint you are correct, SQLite looses to files. The
> actually performance seems to be quite drastic (very surprising to me). That
> said, keep in mind that for most applications even 150 requests/second is an
> unatt
On Tue, 2003-07-01 at 15:56, Ilia Alshanetsky wrote:
> From a performance standpoint you are correct, SQLite looses to files. The
> actually performance seems to be quite drastic (very surprising to me). That
> said, keep in mind that for most applications even 150 requests/second is an
> unatta
> Is not a hard cross to bear, and considering that sqlite enabled
> sessions should be avoided in the first place, I think its a bad idea to
> include them by default.
>
> -Sterling
+ 1
One thing I would like to point out here, is that a session backend is
transparent to the user. As long as
>From a performance standpoint you are correct, SQLite looses to files. The
actually performance seems to be quite drastic (very surprising to me). That
said, keep in mind that for most applications even 150 requests/second is an
unattainable limit anyway. For example smarty templating system de
On Tuesday, July 1, 2003, at 04:19 PM, Sterling Hughes wrote:
Sure. But what Wez said was that it only affected you when you got 150
req/s, which is not true. And I am being honest. Over the period of
25000 requests, it is likely that you will have *more* than 300
sessions, not less. This woul
> My point being that 1/3 slowdown seems to be about worst case, given
> the construction of your benchmark. The test was both designed to
> exploit lock contention (which does increase in overhead non-linearly
> under usage due to the queueing issues involved) and to measure only
> the overh
On Tue, 2003-07-01 at 16:33, George Schlossnagle wrote:
> On Tuesday, July 1, 2003, at 04:00 PM, Sterling Hughes wrote:
> > On Tue, 2003-07-01 at 16:15, George Schlossnagle wrote:
> >> On Tuesday, July 1, 2003, at 03:28 PM, Sterling Hughes wrote:
> >>
> >>
> >> This is no different than a typical
On Tuesday, July 1, 2003, at 04:03 PM, Sterling Hughes wrote:
On Tue, 2003-07-01 at 16:20, George Schlossnagle wrote:
Not really. The slowdown in locking is still there. Its not an across
the board slowdown, but with regards to session handling it is a 1/3
slowdown. What percentage of *total*
On Tue, 2003-07-01 at 16:08, Elfyn McBratney wrote:
> On Tue, 1 Jul 2003, Sebastian Bergmann wrote:
>
> > Sterling Hughes wrote:
> > > It offers not one practical advantage.
> >
> > I though the same, the SQLite euphoria should not be taken too far.
> >
> > +1 for removing the SQLite Session S
On Tuesday, July 1, 2003, at 04:00 PM, Sterling Hughes wrote:
On Tue, 2003-07-01 at 16:15, George Schlossnagle wrote:
On Tuesday, July 1, 2003, at 03:28 PM, Sterling Hughes wrote:
This is no different than a typical mysql setup using myisam
datafiles.
Is mysql session handling bundled? Talkin
On Tue, 2003-07-01 at 16:20, George Schlossnagle wrote:
> On Tuesday, July 1, 2003, at 03:49 PM, Sterling Hughes wrote:
> > You can't look at raw performance on a simple script in terms of req/s,
> > but rather percentages. Most scripts are complex, and will have plenty
> > of other logic in them
On Tue, 2003-07-01 at 16:15, George Schlossnagle wrote:
> On Tuesday, July 1, 2003, at 03:28 PM, Sterling Hughes wrote:
>
> > Hi,
> >
> > Recently sqlite sessions have been added by default. I think this is a
> > bad idea to have as a default handler. SQLite is not designed for a
> > write inte
On Tuesday, July 1, 2003, at 03:49 PM, Sterling Hughes wrote:
You can't look at raw performance on a simple script in terms of req/s,
but rather percentages. Most scripts are complex, and will have plenty
of other logic in them. Having a 1/3 performance decrement can add up.
This is a completely
What advantage does it bring?
It is *only* a disadvantage. It can only hurt users, it can't help
them. I would be for it if someone gave me a practical usage, no one
has. Its not the right tool for the job. If you want to shoot yourself
in the foot, PEAR is the place to do that.
-Sterling
On
On Tuesday, July 1, 2003, at 03:28 PM, Sterling Hughes wrote:
Hi,
Recently sqlite sessions have been added by default. I think this is a
bad idea to have as a default handler. SQLite is not designed for a
write intensive environment, and encouraging such usage seems to be
silly.
SQLite is bad
On Tue, 2003-07-01 at 15:57, Wez Furlong wrote:
> Sterling, you still seem to be afraid to benchmark sqlite vs mysql or
> postgresql sessions.
I'm not afraid. Its like compare apples with oranges. MySQL and
PostgreSQL are database servers, they give you wins in terms of
reliability, power and da
On Tue, 1 Jul 2003, Sebastian Bergmann wrote:
> Sterling Hughes wrote:
> > It offers not one practical advantage.
>
> I though the same, the SQLite euphoria should not be taken too far.
>
> +1 for removing the SQLite Session Save Handled from the default
> distribution.
-1
Corporate types
Hello Sterling,
Tuesday, July 1, 2003, 9:28:58 PM, you wrote:
SH> Hi,
SH> Recently sqlite sessions have been added by default. I think this is a
SH> bad idea to have as a default handler. SQLite is not designed for a
SH> write intensive environment, and encouraging such usage seems to be
SH> s
Sterling Hughes wrote:
> It offers not one practical advantage.
I though the same, the SQLite euphoria should not be taken too far.
+1 for removing the SQLite Session Save Handled from the default
distribution.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://p
Sterling, you still seem to be afraid to benchmark sqlite vs mysql or
postgresql sessions.
Also, 150+ req/s is more than most people will ever have hitting their
sites.
Yes, so you fixed some segfaults (are you going to commit that?) but keep in
mind that the code is in the HEAD branch and was on
Looks like it is just a stub with some example PHP code. No C code.
http://cvs.php.net/cvs.php/curl-php
-Rasmus
On Tue, 1 Jul 2003, Derick Rethans wrote:
> On Tue, 1 Jul 2003, Linus Nielsen Feltzing wrote:
>
> > I need commit access to the curl, curl-cpp, curl-java, curl-perl,
> > curl-php and
On Tue, 1 Jul 2003, Linus Nielsen Feltzing wrote:
> I need commit access to the curl, curl-cpp, curl-java, curl-perl,
> curl-php and curl-www repositories.
Just wondering, what is curl-php?
regards,
Derick
--
"Interpreting what the GPL actually means is a job best left to those
Hi,
Recently sqlite sessions have been added by default. I think this is a
bad idea to have as a default handler. SQLite is not designed for a
write intensive environment, and encouraging such usage seems to be
silly.
SQLite is bad because:
1) It uses one file for the entire db. Therefore, ev
I need commit access to the curl, curl-cpp, curl-java, curl-perl, curl-php and
curl-www repositories.
Daniel Stenberg has approved of this:
"The good guys at php.net is now hosting curl and the related repositories, one
of them of course being the perl one and the web one etc.
If you want to ke
On Tuesday, July 1, 2003, at 02:27 PM, Timm Friebe wrote:
- Made use of the ZEND_DO_THROW macro in the constructors (see
previous mail to engine2@ including a patch to zend_API.h)
I privatized this for the moment until your other patch is accepted or
what have you. Otherwise looks great. Com
Hello,
I went ahead and spent some time on the new reflection API. A patch (778
lines:)) and a demo script are attached.
What has changed:
-
- Added documentation for each and every function (using the style
used in ext/*/*.c)
Hi Marcus,
[EMAIL PROTECTED] (Marcus Börger) wrote:
> Hello Moriyoshi,
>
> to me that sounds good.
Actually I wasn't asking people to say aye or nay.. :) and at this moment
I've got no ZE karma either. BTW I forgot to mention that part of my
concern is backwards compatibility for both binarie
On Tuesday, July 1, 2003, at 12:56 PM, Sterling Hughes wrote:
Not to throw a wrench in the wheel, but properties seem to be the more
appropriate pattern. Especially when taking PHP's object overloading
abilities into play. Accessors are a Java paradigm that's as
half-baked
as it is repetitive,
Hello Moriyoshi,
to me that sounds good.
Tuesday, July 1, 2003, 7:33:08 PM, you wrote:
MK> Hi,
MK> Perhaps I'm missing something, but I noticed the current ZE2
MK> implementation doesn't seem to correctly handle constants registered to
MK> internal classes. I tracked down the cause of this pr
Hi,
Perhaps I'm missing something, but I noticed the current ZE2
implementation doesn't seem to correctly handle constants registered to
internal classes. I tracked down the cause of this problem, and finally
figured out that those constants are destroyed by the ordinary
zval_ptr_dtor_wrapper(
Not to throw a wrench in the wheel, but properties seem to be the more
appropriate pattern. Especially when taking PHP's object overloading
abilities into play. Accessors are a Java paradigm that's as half-baked
as it is repetitive, when you have overloading you no longer need
property accessors.
After seeing some heated discussions, I thought I would ask, was the
possibility of just having a separate module for every major rev 3-4-5
similar to the older system discussed?
With this method cvs operations are much quicker because you are not
keeping around thousands of changes in the module
Daniel Khan has asked me to help him with DB_NestedSet by maintaining the MDB driver.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
i included the
test files into the patch.
http://marcus-boerger.de/php/ext/ze2/ze2-spl-20030701.diff.tgz
Best regards,
Marcusmailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Daniel Stenberg referred me as you are now hosting curl/libcurl at php.net. I
presently have cvs commit access to curl at sourceforge (where it's moving from), as I
maintain the curl-perl bindings and perl examples. Can you please arrange access to
the appropriate module or sub-dir to continue t
On Tue, 01 Jul 2003, Alan Knowles wrote:
> It would be alot nicer if you could provide the majority of these as
> object variables (and/or) functions, it would enable
> print_r(new PHP_Function('counter'));
> which would save a lot of messing around, and writing code for general
> queries..
I po
--- Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Hi,
>
> It is still not possible to understand from this .diff what the impact on
> the Engine will be because the code it still saturated with copying of code
> from the Engine. My intentation was to review a patch that is ready to be
> commited.
Hello Andi,
Tuesday, July 1, 2003, 7:33:45 AM, you wrote:
AG> Hi,
AG> It is still not possible to understand from this .diff what the impact on
AG> the Engine will be
No? There a simply 4 additional checks/calls inside zend_execute.c. You can't
see the impact of them? strange! But see down bel
On Tue, 2003-07-01 at 06:29, Wez Furlong wrote:
> Hey John,
>
> Mail me the patch and I'll look at integrating it into the sqlite extension
> itself; as Derick says, it is probably the best place for it.
http://www.coggeshall.org/php/mod_sqlite.tar.gz
I missed rolling the mini-patch I had for s
On Tue, 1 Jul 2003, Derick Rethans wrote:
> On Tue, 1 Jul 2003, Sascha Schumann wrote:
>
> > On Sat, 28 Jun 2003, John Coggeshall wrote:
> >
> > > Since SQLite will be bundled in the future, I sat down and got
> > > acquainted with it by writing a module for the session extension which
> > > allow
Hey John,
Mail me the patch and I'll look at integrating it into the sqlite extension
itself; as Derick says, it is probably the best place for it.
--Wez.
- Original Message -
From: "Derick Rethans" <[EMAIL PROTECTED]>
To: "Sascha Schumann" <[EMAIL PROTECTED]>
Cc: "John Coggeshall" <[EMA
On Tue, 1 Jul 2003, Sascha Schumann wrote:
> On Sat, 28 Jun 2003, John Coggeshall wrote:
>
> > Since SQLite will be bundled in the future, I sat down and got
> > acquainted with it by writing a module for the session extension which
> > allows users to store their session data in a SQLite databas
On Sat, 28 Jun 2003, John Coggeshall wrote:
> Since SQLite will be bundled in the future, I sat down and got
> acquainted with it by writing a module for the session extension which
> allows users to store their session data in a SQLite database*.
>
> To use, just apply the patch to session.c (whi
> We have no intentions to become maintainers of a different codebase,
> integrating libxml into the PHP distribution is a completely separate
> issue. Please read the archives.
This message must have been stuck in my queue, because i sent this
Friday. It's outdated, and as far as I care is a d
At 00:16 28/06/2003, John Coggeshall wrote:
On Fri, 2003-06-27 at 13:08, Sterling Hughes wrote:
> Because, this will encourage people to do :
>
> --without-xml
>
> Instead of upgrading the system libxml2.
If someone actually *needs* XML support for whatever they are doing, and
they have absolutely
On Fri, 2003-06-27 at 13:08, Sterling Hughes wrote:
> Because, this will encourage people to do :
>
> --without-xml
>
> Instead of upgrading the system libxml2.
If someone actually *needs* XML support for whatever they are doing, and
they have absolutely no option but to upgrade libxml2, they'll
Since SQLite will be bundled in the future, I sat down and got
acquainted with it by writing a module for the session extension which
allows users to store their session data in a SQLite database*.
To use, just apply the patch to session.c (which adds the reference to
the new module and adds the
Ignore.
--
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
John Coggeshall
john at coggeshall dot org http://www.coggeshall.org/
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
--
PHP Internals - PHP Runtime Development Mailing List
T
Ignore.
--
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
John Coggeshall
john at coggeshall dot org http://www.coggeshall.org/
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
--
PHP Internals - PHP Runtime Development Mailing List
T
92 matches
Mail list logo
