ds,
Glenn.
Lukas Kahwe Smith wrote:
Glenn Richmond wrote:
No, it's never worked as far as I know, but it doesn't mean it's not
a bug. The session functions shouldn't have to be reset every time
session_write_close or session_destroy is called. It's been logged
previously
;s also a
consistent issue in varoius forums of major PHP projects.
Any idea on a solution for this one?
Regards,
Glenn.
Lukas Kahwe Smith wrote:
Glenn Richmond wrote:
i.e. It still knows that it's a custom defined handler, but the
references to the functions are gone. If I make a call to
arge number of
sites.
Glenn.
Antony Dovgal wrote:
> On 10/25/2006 01:04 PM, Glenn Richmond wrote:
>> Hi guys,
>>
>> Just wondering what the status of the user-defined session handlers is?
>
> I don't think it makes any sense to ask such questions on the list,
> for
Hi guys,
Just wondering what the status of the user-defined session handlers is?
I've tested with 5.2rc4 and there is an issue that the references to the
user functions get erased when the user calls session_write_close or
session_destroy. This means that the system reverts to an alternative
hand
gards,
Glenn.
Andreas Korthaus wrote:
> Hi Glenn,
>
> Glenn Richmond wrote:
>> This isn't actually part of the PECL project as I understand it. The
>> PECL memcache project provides a PHP interface to using a memcache
>> server. What I've developed is a memcach
ok, sure - I just made this assumption because there's an sqlite session
handler in there (from what I can see) that I wouldn't have considered
standard. I'll discuss with the PECL developers.
Glenn.
Antony Dovgal wrote:
> On 10/20/2006 12:49 PM, Glenn Richmond wrote:
>&g
such, it's something that could (or perhaps should) be part of the
main source tree. Is there a middle stage here? i.e. Can I provide it as
an optional compile flag in the configure script?
Glenn.
Antony Dovgal wrote:
> On 10/20/2006 08:35 AM, Glenn Richmond wrote:
>> Hi all,
>>
&g
ed by some people.
>
> The argument is that we should not unnecessarily break these people's
> code just because it makes no sense. Personally, I don't buy into this
> argument. Perhaps if their code breaks and there is a good explanation
> in the error message, they might start wr
Hmm, this is interesting - I just joined the mailing list, but I can
relate to this. I've come across a piece of code in that has the
following line in a function within a class:
return $this;
It seems to cause an over-allocation of memory and ultimately a seg
fault in both 5.1.4 and 5.2rc4, but
the
general community and am told that this is the list to discuss this?
So a couple of queries:
* Is this something worth checking back into the main source tree?
* How do I get registered as a developer or can I provide it as a
.diff to an existing developer?
Best Regards,
10 matches
Mail list logo
